overview of derby.js and meteor.js (for 7/10 nova node.js meetup)

Derby.js & Meteor.js

The “next generation” of web development frameworks?

(thanks to Node.js)

David Rees@studgeekabout.me/studgeek

7/10/12Nova Node Meetup

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)

Derby/Meteor – Common Concepts

Common Language• Same language and thinking on server and client• Same code and model structures• Same libraries • Same tools (IDE, debug, logging)• Same developers

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

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>

</template>

<div>Hello there, Alyssa Hacker!</div>

{first: "Alyssa", last: "Hacker"}

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

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

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)

Derby

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)

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>

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

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 serverget('/', 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

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 pathmodel.subscribe(’users', callback);

• Model access/mutation is very data/path-centricvar 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 codestore.query.expose(’olderUsers', 'olderThan', function (age) { return this.where('age').gt(age);});

// App codevar eligibleVotersQuery = model.query(‘olderUsers').olderThan(20);model.subscribe(eligibleVotersQuery, callback);

Derby: Misc• Installed and used as normal NPM package(s)• Core developers are using it for other project• “focused on building our app”

Derby Demo

Meteor

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

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

Meteor: Build/Deployment• You (must) use meteor to create

meteor create myapp

• You use meteor (not node) to runmeteor

• For play you can use their serversmeteor deploy <anything you want>

• Or you can bundle a normal node app for deployment meteor bundle

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

Meteor Derby

GitHub Watchers 4060 924

GutHub Forks 324 54

StackOverflow Qs 312 12

Meteor Demo

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

Q & A & B

David Rees@studgeekabout.me/studgeek

7/10/12Nova Node Meetup

Will tweet slides…