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)

3.
Derby/Meteor – Common Concepts

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)

10.
Derby

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”

17.
Derby Demo

18.
Meteor

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

23.
Meteor Demo

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