SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
Overview of Derby.js and Meteor.js (for 7/10 NoVa Node.js Meetup)
With a focus on their philosophy (vs practical usage tips)...
Agenda
- Derby.js/Meteor.js - Common Concepts
- A little more about Derby.js
- A short Derby.js demo (Oooooo)
- A little more about Meteor.js
- A short Meteor.js demo (Ahhhhh)
- Discussion & Beers (Yummm)
Blog post - http://studgeek.com/2012/07/11/nodejs-meteorjs-derbyjs-overview-nodedc
With a focus on their philosophy (vs practical usage tips)...
Agenda
- Derby.js/Meteor.js - Common Concepts
- A little more about Derby.js
- A short Derby.js demo (Oooooo)
- A little more about Meteor.js
- A short Meteor.js demo (Ahhhhh)
- Discussion & Beers (Yummm)
Blog post - http://studgeek.com/2012/07/11/nodejs-meteorjs-derbyjs-overview-nodedc
Overview of Derby.js and Meteor.js (for 7/10 NoVa Node.js Meetup)
1.
Derby & Meteor .js .js
The “next generation” of web development frameworks?
(thanks to Node.js)
David Rees
@studgeek 7/10/12
about.me/studgeek Nova Node Meetup
2.
Intro
• Just an overview, with focus on what they “are”
• Agenda
• Derby/Meteor - Common Concepts
• A little more about Derby
• A short Derby demo (Oooooo)
• A little more about Meteor
• A short Meteor demo (Ahhhhh)
• Discussion & Beers (Yummm)
4.
Common Language
• Same language and thinking on server and client
• Same code and model structures
• Same libraries
• Same tools (IDE, debug, logging)
• Same developers
5.
Base Development Framework
• All the core packages need to build a web application are
included and integrated
• Node.js, Express, Socket.IO, MongoDB, Handlebars, Stylus,
CoffeeScript
• Derby – Redis, Browserify, UglifyJS
• Meteor – Fibers
6.
Model-Bound Templates
• HTML is generated from HTML template
• Variables are bound to model data
• GUI updates automatically as the model properties change
<template name="hello”>
<div>Hello there, {{first}} {{last}}!</div> {first: "Alyssa", last: "Hacker"}
</template>
<div>Hello there, Alyssa Hacker!</div>
7.
Synchronized Model State
• Clients, Servers, and database all share a common state
• Changes anywhere are synchronized everywhere (Socket.IO)
• Models are created, searched, and updated the same way
everywhere
• “Subscriptions” manage what data is propagated where
8.
Live Rendering
• Synchronized Model State publishes changes to
clients/servers/browsers
• Model-Bound Templates recognize changes in their Models
• So… HTML is “magically” updated everywhere
• Subscriptions filter what is pushed where
• Templates control what is updated
• Local data can be used with model events to manage when
HTML updates
9.
Misc
• Changes in code are automatically pushed to all clients (as
view updates)
• Open Source (MIT)
• Neither is production ready yet
• Security is biggest “to do” (unless you really trust your users)
11.
Derby: Templates
• Derby-specific template approach based on Handlebars
• Uses knockout/angular-style model property bindings
• Only changed parts are updated as the model properties
change (like Knockout)
12.
Derby: Templates Cont.
• Reuse (“components”)
<Body:>
<app:nav>
<nav:>
<ul>{{each navItems}}<app:navItem>{{/}}</ul>
<navItem:>
<li><a href="{{link}}">{{title}}</a></li>
• Recently added “widgets” which extend the tag library
<boot:tabs current={test.currentTab}>
<boot:tab title="One">
Stuff
</boot:tab>
<boot:tab title="Two">
More stuff
</boot:tab>
</boot:tabs>
13.
Derby: Server-Side Template
Rendering
• Pages are initially rendered on server as HTML and then
pushed to client
• Results in real HTML being pushed to client (rather than
generated on client)
• Additional changes are then handled on client
• More SEO friendly
• Probably more mobile friendly also
• Meteor plans to implement
14.
Derby: Routes
• Routes are defined Express/Sinatra style
• Initially generated on server and pushed to client
• Subsequent route accesses reuse client HTML
// Routes render on client as well as server
get('/', function (page, model) {
// Subscribe specifies the data to sync to client
// Can also use fetch for static data
model.subscribe('users', function () {
// Render the page (server), reuse the template (client)
page.render('home');
});
});
• Includes history support
• “Transitional” routes support local updates (DOM/CSS changes)
• Form submits can be captured and used on client
15.
Derby: Models (Racer)
• “Models” are synchronized stores using Redis
• Optionally backed by MongoDB
• Supports conflict resolution (very basic so far)
• Data is made available on client by subscribing to a path
model.subscribe(’users', callback);
• Model access/mutation is very data/path-centric
var model = store.createModel();
model.set('users.Dave.favoriteBeer', 'Racer 5');
var dave = model.at('users.Dave');
dave.set('favoriteBeer', 'Racer 5');
• Queries support more fine-grained subscriptions
// Server code
store.query.expose(’olderUsers', 'olderThan', function (age) {
return this.where('age').gt(age);
});
// App code
var eligibleVotersQuery = model.query(‘olderUsers').olderThan(20);
model.subscribe(eligibleVotersQuery, callback);
16.
Derby: Misc
• Installed and used as normal NPM package(s)
• Core developers are using it for other project
• “focused on building our app”
19.
Meteor: Templates
• Use any template engine you want
• Entire template section is regenerated when underlying model
properties change
• Pushes view generation JavaScript to client (no HTML)
• This is a serious SEO issue – try googling for meteor.com
20.
Meteor: Full Build/Package
Environment
• Goal is to be a complete development environment
• Improves on rails/express with simpler file structure
• Much less boilerplate than Derby
• “Improves” on npm with “dynamic packages”
• npm-like, not documented yet
• Uses node and node packages internally
21.
Meteor: Build/Deployment
• You (must) use meteor to create
meteor create myapp
• You use meteor (not node) to run
meteor
• For play you can use their servers
meteor deploy <anything you want>
• Or you can bundle a normal node app for deployment
meteor bundle
22.
Meteor: Misc
• Installed as a .sh
curl install.meteor.com | /bin/sh
• Getting a lot more community love so far
• Meteor folks seems to be better (and more focused) on SMO
Meteo Derby
r
GitHub Watchers 4060 924
GutHub Forks 324 54
StackOverflow Qs 312 12
24.
Last Thoughts (IMHO)
• Both have great potential
• Demonstrate what is possible with common language
• Show Node can be more than Ruby in JavaScript
• Security/scaling issues need to be (and will be) solved
• Personally digging Derby a bit more right now
• Normal packages and building
• Property-level bindings
• HTML in browser
• But worried about core developer’s support
• I do prefer some aspects of Meteor though
• Super simple for simple stuff
• Less generated boilerplate
• More community love
25.
Q&A&B
Will tweet slides…
David Rees
@studgeek 7/10/12
about.me/studgeek Nova Node Meetup
Editor's Notes
Notes:Derby and Meteor have a pretty different model for how how subscriptions/channels are handled