Successfully reported this slideshow.

Overview of Derby.js and Meteor.js (for 7/10 NoVa Node.js Meetup)

15

Share

Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 25
1 of 25

Overview of Derby.js and Meteor.js (for 7/10 NoVa Node.js Meetup)

15

Share

Download to read offline

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

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Overview of Derby.js and Meteor.js (for 7/10 NoVa Node.js Meetup)

  1. 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. 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. 3. Derby/Meteor – Common Concepts
  4. 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. 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. 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. 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. 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. 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. 10. Derby
  11. 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. 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. 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. 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. 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. 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. 17. Derby Demo
  18. 18. Meteor
  19. 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. 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. 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. 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. 23. Meteor Demo
  24. 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. 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
  • ×