10 ms·

Throne of JS: Eight JavaScript MV* Libraries Compared

167 points by jashkenas 14y ago

jblz 14y ago
"It's not just you! http://blog.stevensanderson.com http://blog.stevensanderson.com looks down from here." http://www.downforeveryoneorjustme.com/http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012 http://www.downforeveryoneorjustme.com/http://blog.stevensan...
- steve-sanderson 14y ago
  Sorry, looks like I need to rebuild my Linode instance. It's back now.
  - ryanhuff 14y ago
    It looks to be down again.
    - daemon13 14y ago
      Now up - all works.
      - davydka 14y ago
        Down again.
    - cancelbubble 14y ago
      11:28am PST, site has been down about an hour for me.
  - speg 14y ago
    Still down.
- peter_l_downs 14y ago
  Just worked fine for me here.
jarito 14y ago
I wish he'd touched on testability. I chose Angular for my project because it is dependency injected by default and includes mocks for common tasks. This makes is possible to do the majority of my UI testing in unit testing which is much faster and easier than using something like Selenium.
- ch0wn 14y ago
  I really can't emphasize that enough. Angular's test support is by far the best any MV* framework I've seen has, at the moment. With dependency injection being the foundation of the framework, AngularJS has a major benefit over most competing products in this area.
- steve-sanderson 14y ago
  Unit testing your viewmodels/scopes is great, but it's a totally different kind of activity to end-to-end testing via browser automation, isn't it? Unit testing will help with design, but end-to-end tests will catch an entirely different (and bigger) set of bugs. So don't you need both?
  - vtry 14y ago
    Most frameworks it is not possible to do proper unit test. With Angular, you can actually do it. As the controller is totally separate from the view (html/dom).
    - steve-sanderson 14y ago
      OK. I was just taking it for granted that it was easy, because the same is true in Knockout (viewmodels are entirely independent of views, and so are trivial to unit test with QUnit or whatever else).
      - vtry 14y ago
        Pretty much only Angular and KnockOut and maybe 1 other js framework can do real unit test
fuzzythinker 14y ago
If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.
- steve-sanderson 14y ago
  Is Enyo really a comparable kind of technology? I'm not familiar with it, and its website seems to imply it's for building mobile apps more than web apps.
  - fuzzythinker 14y ago
    I'm not using enyo, so I don't know from a dev's perspective, but according to http://enyojs.com/about/ http://enyojs.com/about/ , it is targeted to be cross platform, including all major browsers on the web.
- quarterto 14y ago
  Enyo is nothing like Meteor or Derby.
- MindTwister 14y ago
  They weren't there: The premise was to take the seven top JavaScript frameworks/libraries for single-page and rich JavaScript applications — Angular, Backbone, Batman, CanJS, Ember, Meteor, Knockout, Spine — get the creators of all of them in one location, and compare the technologies head to head.
  - unwiredben 14y ago
    We had two Enyo engineers up there to talk to attendees, but we weren't able to get a speaking slot due to being a bit late to the event.
scotty79 14y ago
Knockout is awsome. Check it out. You can grasp it over the afternoon and examples of advanced ui-s are interesting and concise.
- rimantas 14y ago
  And then you try to use it for more complicated cases, run into limitations and switch to backbone.
  - scotty79 14y ago
    I've done Backbone course in codechool.com It's very basic and targeted at beginners but in last lessons already I've seen how it becomes tangled and begins to fall apart. I feel that Knockout provides you with much more structure that prevents you from making too much of a mess. Custom bindings provide easy way to insane flexibility http://learn.knockoutjs.com/#/?tutorial=custombindings http://learn.knockoutjs.com/#/?tutorial=custombindings and the models don't look like hundredth attempt at just implementing CRUD. Also no re-rendering of html and no need for rebinding DOM events (vide http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt-always-simple/ http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt... ). Thus my noob preference.
  - krosaen 14y ago
    knockout and backbone serve different goals: http://stackoverflow.com/a/6340870/231589 http://stackoverflow.com/a/6340870/231589 For me, the dependency tracking and automatic ui refresh provided by knockout hits the sweet spot, functionality that isn't in the scope of what backbone provides.
  - WickyNilliams 14y ago
    I take issue with this kind of generalisation. I don't think these problems are inherent to knockout, but I do think there is a lack of architectural guidance on building large apps with it. That said, building a maintainable, extensible knockout app is the same as building any other object-oriented system. First, decompose your app into multiple view models (a single view model doesn't have to be bound to the entire page) with clearly defined responsibilities. Combine that with a good Pub/Sub system [1] and you're most of the way there. That said, it would be nice to see some examples of large-scale knockout apps, as there doesn't seem to be much discussion out in the open in this area. A perfect candidate (in my mind) would be for Steve to release the source code for the knockout tutorial site since that is fairly complex. [1] https://github.com/rniemeyer/knockout-postbox https://github.com/rniemeyer/knockout-postbox
Maciek416 14y ago
I attended the conference, and the topic (framework vs. framework vs. library) was definitely timely. There are strong points of contention between the major competing frameworks/libraries right now, and this was reflected in the panel discussions. What struck me about the talks I saw was the degree to which each project strongly reflects the personalities of its authors; Jeremy Ashkenas was indeed (as the article says) the calm zen master of the panels, taking a minimally-prescriptive stance on how his code should shape your code. Tom Dale and Yehuda Katz, on the other hand, came in with passionate arguments for the idea that JS frameworks should have strong opinions and exert a great deal of influence on your code and the outcome of your solutions. Katz's central thesis seemed to be that for highly common problems for which Ember would be used, extremely similar (if not identical) solutions should emerge. All in all a good conference, and very differently-flavoured from JSConf.
ilaksh 14y ago
http://tjholowaychuk.com/post/27984551477/components http://tjholowaychuk.com/post/27984551477/components Those frameworks are great, but they all fail to take advantage of a key advance in software development: the widget. Reusable, composable GUI components that package front end and back end files together and can be distributed easily as plugins are the next step up in abstraction and superior from a software engineering perspective. The reason many web developers aren't able to either grasp or accept that is because A) understanding and building those types of components that are truly generic enough to be applicable to a wide variety of applications as well as reusable, has a significant learning curve and is time consuming and B) the better you are at it, the less likely you are to get credit for your programming skills, because unfortunately if you can build an application without typing colorful ASCII text, then you didn't do any programming and aren't a programmer. To get past B) we just need to redefine what programming is, and also grow up a little. Also realize that even if you are programming with GUI components, you still have to create new components sometimes, so you are still programming and still a programmer. I have a very early rough draft system that I am throwing together on my own, mostly because very few people seem to be able to appreciate these concepts. Or the ones that do are happy to use existing systems like ASP.NET or WordPress. https://github.com/ithkuil/cureblog https://github.com/ithkuil/cureblog https://vimeo.com/43784316 https://vimeo.com/43784316 Note that I have modernized the interface somewhat since I made that video.
- jmesserly 14y ago
  Agree on widgets. Have you seen the Web Components effort? http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i... It's an attempt to standardize widgets at the browser level. Really cool stuff. It's based on ShadowDOM, which is an encapsulation notion: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado... There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org/ http://x-tags.org/ and http://html5engineers.com/projects/playing-with-web-components http://html5engineers.com/projects/playing-with-web-componen... Also some of the frameworks do have a "widget" or "component" notion. For example, see "Create Components" at http://angularjs.org http://angularjs.org.
dj_axl 14y ago
"The only stalwarts here appear to be Backbone (other than its default routing feature, it works on IE6) and Knockout (which for now at least insists on total IE6 support)." IE6 support is a must-have for me (corporate clients).
- geon 14y ago
  Is the ie6 support accidental or do the devs sacrifice maintainability, readability or performance to specifically support it? It seems to me that since it is so small, and doesn't really do much, they'd have to go out of their way not to support ie6.
  - steve-sanderson 14y ago
    > they'd have to go out of their way not to support ie6 Oh, how I wish! Try searching the Knockout source code for "IE" and see how many special-case rendering and event bugs it has to work around. For sure, getting 90% IE6/7 support might be quite easy, but that last 10% is a real pain and that's the value of using a mature framework where someone else has already debugged the heck out of it.
easternmonk 14y ago
Incomplete without including YUI3 App framework.
- drgath 14y ago
  Yup. Oddly enough, YUI had a core team member (Eric Ferraiuolo) at Throne of JS to talk about Y.App, but apparently didn't get a mention in the linked blog post. shrugs
  - steve-sanderson 14y ago
    Eric's talk was more about general web development principles than about any YUI technologies specifically.
ianstormtaylor 14y ago
"In my view, the strongest argument here came from the Angular guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. " Would love to know where this was discussed in more detail.
- vtry 14y ago
  Angular meetup.
netghost 14y ago
For what it's worth, I've been playing around with making a really tiny MV* library called Ivy (http://adamsanderson.github.com/ivy/ http://adamsanderson.github.com/ivy/). It's similar to Knockout with data binding, dom templating, and some nice debugging tricks. The entire thing clocks in around 900 lines with comments, and has no dependencies so if you're curious, have a look.
- steve-sanderson 14y ago
  Nice one! It's cool to see these ideas expressed in such minimal code.
ebiester 14y ago
"Agreement: Progressive enhancement isn’t for building real apps. All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code. Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s not even a novelty any more)." I really don't understand this. While I get WAI-ARIA for accessability, Google still depends on static content for indexing, last I checked. Are we just stuck doing two separate page flows? If that's the case, why bother with the framework at all if it's just doubling the workload? (Note: I'm looking at a way to allow the initial rendering of the page statically, then using backbone to attach to events after the fact and use as a single page application after the fact. Handlebars and Hogan handle the templating on client and server side, and both client and server models are extending a common model shared with both. It will be great if it all works. ;)
- ilaksh 14y ago
  See my comment in this thread, I have a link to my github repo (and a video describing the project) where I have a solution to the static content on dynamic websites problem. My solution is to use PhantomJS to render static pages using the same code that the dynamic pages are rendered with.
- asolove 14y ago
  There are two answers here. If your page is a content page, you should follow the pattern that YUI's MVC uses, which is to hydrate your model objects by scraping the html on the page. So you need templates shared (or similar) on back-end and front-end, you render them on the back-end with initial content, when dom ready happens you create models instances with the data that you grep out of that markup, and then as soon as the user does something you re-render that data with the client-side templates. Needless to say, this is less than fun. (Especially if you do i18n and need templates that can do so on both front- and back-end.) The second answer is: web apps usually aren't for searchable content. Let's say you're a startup with information about local restaurants, and you add a Backbone app for finding things nearby and filtering by type. Google should crawl your external site (home page, marketing pages, etc.) as well as your data pages (one page per restaurant, one per type per city, etc.). And all those pages link to or include your shiny new restaurant-finder Backbone app/widget. But Google doesn't need to crawl that app. For most users of Backbone, where their app sits behind a login wall anyway, worrying about search engines is irrelevant.
encoderer 14y ago
I recently had to choose between client-side frameworks for a fairly complicated browser-based application. I had no real requirements, except that I really preferred easily using CoffeeScript. Obviously all of them can be used with CoffeeScript, but some easier than others. I embraced and evaluated Batman. This was before they updated their documentation a couple months ago. Their docs were so brief that I had to consult the (partially annotated) source for basic things like bindings, routings, etc. I built a little example in about 5 days and called it quits. When it gets to 1.0 I'll take another look. Their new documentation looks promising. I then went pursuing frameworks with automatic 2-way binding like Knockout (and batman). I really didn't want to go w/ Backbone because it doesn't provide that feature. But what I ended up finding is that implicit 2-way bindings like that are more of a performance blackbox. Not altogether bad, but that they have enough downside that they're not an absolute must-have. I ended up choosing Backbone flavor Chaplin. Chaplin is an opinionated implementation of Backbone written in CoffeeScript. It implements a Pub/Sub message bus using Backbone Events. It gives you defined structure that makes it easier to get started. And it provides garbage collection which can be super helpful. When a controller (and its models) is swapped out there are a lot of circular references that have to be manually broken for it to be garbage collected. Chaplin takes care of that for us. And Brunch.io includes Chaplin now in its default recipe, which is also super helpful.
ww520 14y ago
Knockout is pretty good. Simple to use and get the job done.
trung_pham 14y ago
Why are people so quick to dismiss Yahoo Mojito? All these frameworks only run inside the browser. A little ehh to me, nothing revolutionizing. Yahoo's Mojito is a game changer. It can run in the browser and on the server. And it's SEO friendly! Really wish Yahoo does a better job at marketing their own framework.
SchizoDuckie 14y ago
The one thing i'm missing most in all these frameworks is proper data access, offline I agree that it's an awesome time we live in with an mv* framework coming out every day, but where's the love for offline apps? None of the frameworks seem to support grabbing data from SQLite in a proper way without including hundreds of extra kb's of js. How about a real world scenario where you store products, and categories and prices in an sqlite database, and want to access and filter those, especially offline? There's no use in using a REST service, and you'd have to implement Sqlite Support yourself in all of them. (and no, compiling from coffeescript or depending on Nodejs doesnt count) Building a (properly performing!) CRUD system for a tablet that works offline is still a hassle. That's why i'm currently working on CreateReadUpdateDelete.js, a project that aims to solve this by bringing my tiny ORM to JS. Check it out if you're interested in a WIP, there will be a post here soon. http://goo.gl/avnzk http://goo.gl/avnzk
- SchizoDuckie 14y ago
  [edit]whoops, wrong link: http://goo.gl/gz7zo http://goo.gl/gz7zo [/edit]
malandrew 14y ago
For those that are using AngularJS, the frontend guys over at Duolingo gave a great talk about using browserify to perform dependency injection into angular so it feels like you are using angular as a library instead of a framework. It was some really cool stuff.

167 points by jashkenas 14y ago

jblz 14y ago

"It's not just you! http://blog.stevensanderson.com http://blog.stevensanderson.com looks down from here." http://www.downforeveryoneorjustme.com/http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012 http://www.downforeveryoneorjustme.com/http://blog.stevensan...

steve-sanderson 14y ago
Sorry, looks like I need to rebuild my Linode instance. It's back now.
- ryanhuff 14y ago
  It looks to be down again.
  - daemon13 14y ago
    Now up - all works.
    - davydka 14y ago
      Down again.
  - cancelbubble 14y ago
    11:28am PST, site has been down about an hour for me.
- speg 14y ago
  Still down.
peter_l_downs 14y ago
Just worked fine for me here.

jarito 14y ago

I wish he'd touched on testability. I chose Angular for my project because it is dependency injected by default and includes mocks for common tasks. This makes is possible to do the majority of my UI testing in unit testing which is much faster and easier than using something like Selenium.

ch0wn 14y ago
I really can't emphasize that enough. Angular's test support is by far the best any MV* framework I've seen has, at the moment. With dependency injection being the foundation of the framework, AngularJS has a major benefit over most competing products in this area.
steve-sanderson 14y ago
Unit testing your viewmodels/scopes is great, but it's a totally different kind of activity to end-to-end testing via browser automation, isn't it? Unit testing will help with design, but end-to-end tests will catch an entirely different (and bigger) set of bugs. So don't you need both?
- vtry 14y ago
  Most frameworks it is not possible to do proper unit test. With Angular, you can actually do it. As the controller is totally separate from the view (html/dom).
  - steve-sanderson 14y ago
    OK. I was just taking it for granted that it was easy, because the same is true in Knockout (viewmodels are entirely independent of views, and so are trivial to unit test with QUnit or whatever else).
    - vtry 14y ago
      Pretty much only Angular and KnockOut and maybe 1 other js framework can do real unit test

fuzzythinker 14y ago

If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.

steve-sanderson 14y ago
Is Enyo really a comparable kind of technology? I'm not familiar with it, and its website seems to imply it's for building mobile apps more than web apps.
- fuzzythinker 14y ago
  I'm not using enyo, so I don't know from a dev's perspective, but according to http://enyojs.com/about/ http://enyojs.com/about/ , it is targeted to be cross platform, including all major browsers on the web.
quarterto 14y ago
Enyo is nothing like Meteor or Derby.
MindTwister 14y ago
They weren't there: The premise was to take the seven top JavaScript frameworks/libraries for single-page and rich JavaScript applications — Angular, Backbone, Batman, CanJS, Ember, Meteor, Knockout, Spine — get the creators of all of them in one location, and compare the technologies head to head.
- unwiredben 14y ago
  We had two Enyo engineers up there to talk to attendees, but we weren't able to get a speaking slot due to being a bit late to the event.

scotty79 14y ago

Knockout is awsome. Check it out. You can grasp it over the afternoon and examples of advanced ui-s are interesting and concise.

rimantas 14y ago
And then you try to use it for more complicated cases, run into limitations and switch to backbone.
- scotty79 14y ago
  I've done Backbone course in codechool.com It's very basic and targeted at beginners but in last lessons already I've seen how it becomes tangled and begins to fall apart. I feel that Knockout provides you with much more structure that prevents you from making too much of a mess. Custom bindings provide easy way to insane flexibility http://learn.knockoutjs.com/#/?tutorial=custombindings http://learn.knockoutjs.com/#/?tutorial=custombindings and the models don't look like hundredth attempt at just implementing CRUD. Also no re-rendering of html and no need for rebinding DOM events (vide http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt-always-simple/ http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt... ). Thus my noob preference.
- krosaen 14y ago
  knockout and backbone serve different goals: http://stackoverflow.com/a/6340870/231589 http://stackoverflow.com/a/6340870/231589 For me, the dependency tracking and automatic ui refresh provided by knockout hits the sweet spot, functionality that isn't in the scope of what backbone provides.
- WickyNilliams 14y ago
  I take issue with this kind of generalisation. I don't think these problems are inherent to knockout, but I do think there is a lack of architectural guidance on building large apps with it. That said, building a maintainable, extensible knockout app is the same as building any other object-oriented system. First, decompose your app into multiple view models (a single view model doesn't have to be bound to the entire page) with clearly defined responsibilities. Combine that with a good Pub/Sub system [1] and you're most of the way there. That said, it would be nice to see some examples of large-scale knockout apps, as there doesn't seem to be much discussion out in the open in this area. A perfect candidate (in my mind) would be for Steve to release the source code for the knockout tutorial site since that is fairly complex. [1] https://github.com/rniemeyer/knockout-postbox https://github.com/rniemeyer/knockout-postbox

Maciek416 14y ago

I attended the conference, and the topic (framework vs. framework vs. library) was definitely timely. There are strong points of contention between the major competing frameworks/libraries right now, and this was reflected in the panel discussions. What struck me about the talks I saw was the degree to which each project strongly reflects the personalities of its authors; Jeremy Ashkenas was indeed (as the article says) the calm zen master of the panels, taking a minimally-prescriptive stance on how his code should shape your code. Tom Dale and Yehuda Katz, on the other hand, came in with passionate arguments for the idea that JS frameworks should have strong opinions and exert a great deal of influence on your code and the outcome of your solutions. Katz's central thesis seemed to be that for highly common problems for which Ember would be used, extremely similar (if not identical) solutions should emerge. All in all a good conference, and very differently-flavoured from JSConf.

ilaksh 14y ago

http://tjholowaychuk.com/post/27984551477/components http://tjholowaychuk.com/post/27984551477/components Those frameworks are great, but they all fail to take advantage of a key advance in software development: the widget. Reusable, composable GUI components that package front end and back end files together and can be distributed easily as plugins are the next step up in abstraction and superior from a software engineering perspective. The reason many web developers aren't able to either grasp or accept that is because A) understanding and building those types of components that are truly generic enough to be applicable to a wide variety of applications as well as reusable, has a significant learning curve and is time consuming and B) the better you are at it, the less likely you are to get credit for your programming skills, because unfortunately if you can build an application without typing colorful ASCII text, then you didn't do any programming and aren't a programmer. To get past B) we just need to redefine what programming is, and also grow up a little. Also realize that even if you are programming with GUI components, you still have to create new components sometimes, so you are still programming and still a programmer. I have a very early rough draft system that I am throwing together on my own, mostly because very few people seem to be able to appreciate these concepts. Or the ones that do are happy to use existing systems like ASP.NET or WordPress. https://github.com/ithkuil/cureblog https://github.com/ithkuil/cureblog https://vimeo.com/43784316 https://vimeo.com/43784316 Note that I have modernized the interface somewhat since I made that video.

jmesserly 14y ago
Agree on widgets. Have you seen the Web Components effort? http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i... It's an attempt to standardize widgets at the browser level. Really cool stuff. It's based on ShadowDOM, which is an encapsulation notion: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado... There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org/ http://x-tags.org/ and http://html5engineers.com/projects/playing-with-web-components http://html5engineers.com/projects/playing-with-web-componen... Also some of the frameworks do have a "widget" or "component" notion. For example, see "Create Components" at http://angularjs.org http://angularjs.org.

dj_axl 14y ago

"The only stalwarts here appear to be Backbone (other than its default routing feature, it works on IE6) and Knockout (which for now at least insists on total IE6 support)." IE6 support is a must-have for me (corporate clients).

geon 14y ago
Is the ie6 support accidental or do the devs sacrifice maintainability, readability or performance to specifically support it? It seems to me that since it is so small, and doesn't really do much, they'd have to go out of their way not to support ie6.
- steve-sanderson 14y ago
  > they'd have to go out of their way not to support ie6 Oh, how I wish! Try searching the Knockout source code for "IE" and see how many special-case rendering and event bugs it has to work around. For sure, getting 90% IE6/7 support might be quite easy, but that last 10% is a real pain and that's the value of using a mature framework where someone else has already debugged the heck out of it.

easternmonk 14y ago

Incomplete without including YUI3 App framework.

drgath 14y ago
Yup. Oddly enough, YUI had a core team member (Eric Ferraiuolo) at Throne of JS to talk about Y.App, but apparently didn't get a mention in the linked blog post. shrugs
- steve-sanderson 14y ago
  Eric's talk was more about general web development principles than about any YUI technologies specifically.

ianstormtaylor 14y ago

"In my view, the strongest argument here came from the Angular guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. " Would love to know where this was discussed in more detail.

vtry 14y ago
Angular meetup.

netghost 14y ago

For what it's worth, I've been playing around with making a really tiny MV* library called Ivy (http://adamsanderson.github.com/ivy/ http://adamsanderson.github.com/ivy/). It's similar to Knockout with data binding, dom templating, and some nice debugging tricks. The entire thing clocks in around 900 lines with comments, and has no dependencies so if you're curious, have a look.

steve-sanderson 14y ago
Nice one! It's cool to see these ideas expressed in such minimal code.

ebiester 14y ago

"Agreement: Progressive enhancement isn’t for building real apps. All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code. Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s not even a novelty any more)." I really don't understand this. While I get WAI-ARIA for accessability, Google still depends on static content for indexing, last I checked. Are we just stuck doing two separate page flows? If that's the case, why bother with the framework at all if it's just doubling the workload? (Note: I'm looking at a way to allow the initial rendering of the page statically, then using backbone to attach to events after the fact and use as a single page application after the fact. Handlebars and Hogan handle the templating on client and server side, and both client and server models are extending a common model shared with both. It will be great if it all works. ;)

ilaksh 14y ago
See my comment in this thread, I have a link to my github repo (and a video describing the project) where I have a solution to the static content on dynamic websites problem. My solution is to use PhantomJS to render static pages using the same code that the dynamic pages are rendered with.
asolove 14y ago
There are two answers here. If your page is a content page, you should follow the pattern that YUI's MVC uses, which is to hydrate your model objects by scraping the html on the page. So you need templates shared (or similar) on back-end and front-end, you render them on the back-end with initial content, when dom ready happens you create models instances with the data that you grep out of that markup, and then as soon as the user does something you re-render that data with the client-side templates. Needless to say, this is less than fun. (Especially if you do i18n and need templates that can do so on both front- and back-end.) The second answer is: web apps usually aren't for searchable content. Let's say you're a startup with information about local restaurants, and you add a Backbone app for finding things nearby and filtering by type. Google should crawl your external site (home page, marketing pages, etc.) as well as your data pages (one page per restaurant, one per type per city, etc.). And all those pages link to or include your shiny new restaurant-finder Backbone app/widget. But Google doesn't need to crawl that app. For most users of Backbone, where their app sits behind a login wall anyway, worrying about search engines is irrelevant.

encoderer 14y ago

I recently had to choose between client-side frameworks for a fairly complicated browser-based application. I had no real requirements, except that I really preferred easily using CoffeeScript. Obviously all of them can be used with CoffeeScript, but some easier than others. I embraced and evaluated Batman. This was before they updated their documentation a couple months ago. Their docs were so brief that I had to consult the (partially annotated) source for basic things like bindings, routings, etc. I built a little example in about 5 days and called it quits. When it gets to 1.0 I'll take another look. Their new documentation looks promising. I then went pursuing frameworks with automatic 2-way binding like Knockout (and batman). I really didn't want to go w/ Backbone because it doesn't provide that feature. But what I ended up finding is that implicit 2-way bindings like that are more of a performance blackbox. Not altogether bad, but that they have enough downside that they're not an absolute must-have. I ended up choosing Backbone flavor Chaplin. Chaplin is an opinionated implementation of Backbone written in CoffeeScript. It implements a Pub/Sub message bus using Backbone Events. It gives you defined structure that makes it easier to get started. And it provides garbage collection which can be super helpful. When a controller (and its models) is swapped out there are a lot of circular references that have to be manually broken for it to be garbage collected. Chaplin takes care of that for us. And Brunch.io includes Chaplin now in its default recipe, which is also super helpful.

ww520 14y ago

Knockout is pretty good. Simple to use and get the job done.

trung_pham 14y ago

Why are people so quick to dismiss Yahoo Mojito? All these frameworks only run inside the browser. A little ehh to me, nothing revolutionizing. Yahoo's Mojito is a game changer. It can run in the browser and on the server. And it's SEO friendly! Really wish Yahoo does a better job at marketing their own framework.

SchizoDuckie 14y ago

The one thing i'm missing most in all these frameworks is proper data access, offline I agree that it's an awesome time we live in with an mv* framework coming out every day, but where's the love for offline apps? None of the frameworks seem to support grabbing data from SQLite in a proper way without including hundreds of extra kb's of js. How about a real world scenario where you store products, and categories and prices in an sqlite database, and want to access and filter those, especially offline? There's no use in using a REST service, and you'd have to implement Sqlite Support yourself in all of them. (and no, compiling from coffeescript or depending on Nodejs doesnt count) Building a (properly performing!) CRUD system for a tablet that works offline is still a hassle. That's why i'm currently working on CreateReadUpdateDelete.js, a project that aims to solve this by bringing my tiny ORM to JS. Check it out if you're interested in a WIP, there will be a post here soon. http://goo.gl/avnzk http://goo.gl/avnzk

SchizoDuckie 14y ago
[edit]whoops, wrong link: http://goo.gl/gz7zo http://goo.gl/gz7zo [/edit]

malandrew 14y ago

For those that are using AngularJS, the frontend guys over at Duolingo gave a great talk about using browserify to perform dependency injection into angular so it feels like you are using angular as a library instead of a framework. It was some really cool stuff.