1.
Derby & Meteor .js .js The “next generation” of web development frameworks? (thanks to Node.js)David Rees@studgeek 7/10/12about.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 TemplateRendering• 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/PackageEnvironment• 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/12about.me/studgeek Nova Node Meetup