Throne of JS: Eight JavaScript MV* Libraries Compared(blog.stevensanderson.com)
blog.stevensanderson.com
Throne of JS: Eight JavaScript MV* Libraries Compared
http://blog.stevensanderson.com/2012/08/01/rich-javascript-applications-the-seven-frameworks-throne-of-js-2012
16 comments
[edit]whoops, wrong link: http://goo.gl/gz7zo [/edit]
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.
Really wish Yahoo does a better job at marketing their own framework.
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.
Knockout is pretty good. Simple to use and get the job done.
"It's not just you! http://blog.stevensanderson.com looks down from here."
http://www.downforeveryoneorjustme.com/http://blog.stevensan...
http://www.downforeveryoneorjustme.com/http://blog.stevensan...
Sorry, looks like I need to rebuild my Linode instance. It's back now.
Still down.
Just worked fine for me here.
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.
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.
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?
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).
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).
Pretty much only Angular and KnockOut and maybe 1 other js framework can do real unit test
If meteor is included, I would say enyojs and derby (linked in his meteor's overview) should be too.
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.
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.
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.
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.
I'm not using enyo, so I don't know from a dev's perspective, but according to http://enyojs.com/about/ , it is targeted to be cross platform, including all major browsers on the web.
Enyo is nothing like Meteor or Derby.
Incomplete without including YUI3 App framework.
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
Eric's talk was more about general web development principles than about any YUI technologies specifically.
Knockout is awsome. Check it out. You can grasp it over the afternoon and examples of advanced ui-s are interesting and concise.
And then you try to use it for more complicated cases, run into limitations and switch to backbone.
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
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
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 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... ).
Thus my noob preference.
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 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... ).
Thus my noob preference.
knockout and backbone serve different goals:
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.
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.
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.
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.
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://vimeo.com/43784316 Note that I have modernized the interface somewhat since I made that video.
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://vimeo.com/43784316 Note that I have modernized the interface somewhat since I made that video.
Agree on widgets. Have you seen the Web Components effort?
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/shado...
There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org/ and 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.
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/shado...
There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org/ and 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.
Right, web components and angular js components are an improvement, but they still emphasize manual ASCII coding, which defeats one of the main advantages of GUI components.
Also the strong separation and lack of cohesion between the front and back end systems is a severe limitation.
Also the strong separation and lack of cohesion between the front and back end systems is a severe limitation.
Is it? One could argue that divorcing widgets from backend infrastructure so thoroughly is an asset.
Almost everyone does argue that.. sort of.. only there usually is no argument. Its taken as a given in most cases.
That belief is more a result of where we have been than on a logical assessment of where we are now.
If your back end team is separate from your front end team, programming in a different language, building a codebase to support multiple departments or multiple third-party integrators with a single web API for a one-of-a-kind world changing application running primarily in HTML browsers, then it may not make a lot of sense to try to package together the back end and front end code the way I am suggesting.
However, if your goal is to create an easy to use desktop-like website/web application building/editing experience that maximizes code reuse across applications (built on the same framework) on a Node.js/WebSocket/MongoDB/HTML5 stack, however, then my approach with packaging the back end code along with the front end code makes more sense. Yes, you may need to add a REST API on top of the back end if you need that.
That belief is more a result of where we have been than on a logical assessment of where we are now.
If your back end team is separate from your front end team, programming in a different language, building a codebase to support multiple departments or multiple third-party integrators with a single web API for a one-of-a-kind world changing application running primarily in HTML browsers, then it may not make a lot of sense to try to package together the back end and front end code the way I am suggesting.
However, if your goal is to create an easy to use desktop-like website/web application building/editing experience that maximizes code reuse across applications (built on the same framework) on a Node.js/WebSocket/MongoDB/HTML5 stack, however, then my approach with packaging the back end code along with the front end code makes more sense. Yes, you may need to add a REST API on top of the back end if you need that.
Angular directive is pure genius. Much more reusable than traditional "widgets"
Widgets are expensive to build into a framework and very limited in their application. They only fit the use-case of something that widgets are a core part of (iGoogle/widget pages) or something that is marketed at parttime programmers (Wordpress/blogging platforms).
If you can create a website from scratch. Using widgets in place of custom code is a waste of everyone's time, including the person who is going to extending and maintaining that application.
If you can create a website from scratch. Using widgets in place of custom code is a waste of everyone's time, including the person who is going to extending and maintaining that application.
The thing is, the sites that benefit most from these client-side-centric approaches are single page applications [1]. I'd imagine the benefits of having prewritten reusable widgets are the same for SPAs as they are for desktop software. They provide computer illiterate end users with an interface consistent with other similar applications, and like any form of abstraction, they make development faster and maintenance easier.
[1] I know some JavaScript lovers are convinced that client-side rendering is better than server-side even for non-SPAs, but I'm of the rather strong opinion that they're wrong. For non-SPAs that are sufficiently complex, the sexp model of server-side rendering in Clojure, Common Lisp, and Racket produces applications that are so much more concise than their client-side DOM-manipulating equivalents. For the few sites small enough that the overhead of macro writing/bottom-up development outweighs productivity gain, rendering HTML in Rails or Django is probably better than an all-JS approach.
[1] I know some JavaScript lovers are convinced that client-side rendering is better than server-side even for non-SPAs, but I'm of the rather strong opinion that they're wrong. For non-SPAs that are sufficiently complex, the sexp model of server-side rendering in Clojure, Common Lisp, and Racket produces applications that are so much more concise than their client-side DOM-manipulating equivalents. For the few sites small enough that the overhead of macro writing/bottom-up development outweighs productivity gain, rendering HTML in Rails or Django is probably better than an all-JS approach.
Widgets have the same strengths and weakness when choosing software products to buy. If the product meets your needs exactly, it makes sense to buy. If you are going to have to customize the product to actually meet your needs, build the whole thing instead.
In my experience, widgets generally end up in the second category. This is also shared by people generally looking down on things like drag and drop development. Obviously nothing is going to be faster than dragging the complex control someone wants to use into an HTML page and clicking deploy. The problem is that it is almost never the case that the user or your needs are met by the default setup. Then you start configuring and customizing the control. Developers often spend more time configuring and hacking these widgets than it would take to write something that exactly met their needs.
In my experience, widgets generally end up in the second category. This is also shared by people generally looking down on things like drag and drop development. Obviously nothing is going to be faster than dragging the complex control someone wants to use into an HTML page and clicking deploy. The problem is that it is almost never the case that the user or your needs are met by the default setup. Then you start configuring and customizing the control. Developers often spend more time configuring and hacking these widgets than it would take to write something that exactly met their needs.
Widgets are very limited in their application?
I think that there may be a few full-time professional Swing, WPF, ActiveX, Wicket, Flex, ASP.NET, Sencha, WordPress, etc. developers who would disagree with you.
I think that there may be a few full-time professional Swing, WPF, ActiveX, Wicket, Flex, ASP.NET, Sencha, WordPress, etc. developers who would disagree with you.
ASP.NET is a nightmare. An absolute nightmare to work with. Sencha (assuming ExtJS) is one of the worst JS libraries you could pick. Not a great deal of experience with the others, so I cannot comment.
That said, there are no doubt good examples using those technologies to do useful things. I am not arguing that widgets make it impossible to create useful things. I am arguing that widgets by their very nature limit what the developer can do. At best you get indirect access to things you need (Application state, Database, etc...) and often times you have no access.
They are the worst form of abstraction. Extremely easy to do one thing. Hard to customize and nearly impossible to do something unintended.
That said, there are no doubt good examples using those technologies to do useful things. I am not arguing that widgets make it impossible to create useful things. I am arguing that widgets by their very nature limit what the developer can do. At best you get indirect access to things you need (Application state, Database, etc...) and often times you have no access.
They are the worst form of abstraction. Extremely easy to do one thing. Hard to customize and nearly impossible to do something unintended.
To say that ASP.NET is a nightmare.. I just don't think that's accurate. None of the ASP.NET models are my ideal, and there are plenty of things that can become problematic with the different types of ASP.NET development, but that doesn't have to be the case.
I think that it isn't that hard to have a difficult experience with widgets, but that doesn't invalidate the model, and not all component frameworks are alike in regards to things like ease of extension/modification etc.
I think that it isn't that hard to have a difficult experience with widgets, but that doesn't invalidate the model, and not all component frameworks are alike in regards to things like ease of extension/modification etc.
Actually in my experience ExtJs is one of the best libraries/frameworks* [1]. It has a steep learning curve* [2] but after that you can build awesome applications quite fast.
* [1] : library based on the author's definition and framework based on sencha's documentation.
* [2] : the learning curve is steep even for experienced javascript developers.
edit: I just had to fight the * * *
* [1] : library based on the author's definition and framework based on sencha's documentation.
* [2] : the learning curve is steep even for experienced javascript developers.
edit: I just had to fight the * * *
I am not a JS guy, but many in my org swear by ExtJS, especially because of widgets. Would be helpful to know whats bad about ExtJS.
If something is working for you, don't change it. ExtJS is a fairly large framework and replacing it with something 'better' would have a large cost for your organization.
That said, my experience is primarily with coolite and versions 2 and 3 of the framework. I was working closely with another team using 4, which sounded better.
ExtJS' main problem is that it does too much. It tries to replace jQuery, CSS, JavaScript OO frameworks and then adds it's widget/control and code structure on top of all that.
If it just did the last one (maybe two), it would be a decent framework. I still would not choose it because I don't like how it gets in the way of API calls nor the control of event handling in versions 2 and 3. This last point has probably been improved in 4 with the introduction of an actual MVC structure, but I don't know for certain.
In any case, using enormous object literals to configure and control everything from styles, events and actions made it both difficult to work with and test. Often times these blocks of code would exceed hundreds of lines. In short, ExtJS sets up developers to fail. Most of what it does can be written in jQuery using CSS classes far more concisely. It's strongest points were it's UI controls, especially the grids. I think these are the things where the framework adds value, the rest would be better served using more commonly adapted practices.
That said, my experience is primarily with coolite and versions 2 and 3 of the framework. I was working closely with another team using 4, which sounded better.
ExtJS' main problem is that it does too much. It tries to replace jQuery, CSS, JavaScript OO frameworks and then adds it's widget/control and code structure on top of all that.
If it just did the last one (maybe two), it would be a decent framework. I still would not choose it because I don't like how it gets in the way of API calls nor the control of event handling in versions 2 and 3. This last point has probably been improved in 4 with the introduction of an actual MVC structure, but I don't know for certain.
In any case, using enormous object literals to configure and control everything from styles, events and actions made it both difficult to work with and test. Often times these blocks of code would exceed hundreds of lines. In short, ExtJS sets up developers to fail. Most of what it does can be written in jQuery using CSS classes far more concisely. It's strongest points were it's UI controls, especially the grids. I think these are the things where the framework adds value, the rest would be better served using more commonly adapted practices.
[deleted]
Reusable widgets are the core of the Enyo JS framework (www.enyojs.com) that I work on under sponsorship of HP.
We had a few of the Enyo engineers up at Throne of JS, but we didn't get a speaking slot. Maybe next time.
We had a few of the Enyo engineers up at Throne of JS, but we didn't get a speaking slot. Maybe next time.
Coming from Wicket, the thing I'm really looking for to make reusable components more possible is a very weak templating system. I want inert, textual templates where literally the only thing they can do is define an anchor point at which the code inserts text, or another component. Maybe I have to write it myself.
> The reason many web developers aren't able to either
> grasp or accept <…>
The reason is simple: they have already been burnt and know better.
The reason is simple: they have already been burnt and know better.
In knockoutjs, bindings (and the ability to create custom bindings) are akin to widgets in they define exactly how view model state maps to and from the dom. I've created a number of custom bindings to bind things like a number range to a jQueryUI slider widget.
Angular.JS has widgets, eg: http://blog.angularjs.org/2012/05/custom-components-part-1.h...
How about the dojo widgets, do those qualify?
I was about to ask the same thing. How good is Dojo? This seems to be a complete framework with widgets support. How does this differ from the frameworks discussed above? When should I choose one over the other group?
Honestly, and this may sound like I am contradicting myself a bit, but I guess what I am talking about is not quite the same thing as Dojo Widgets etc. Its along the same lines, but if you are trying to choose between for example building on top of Dojo Wigets or Sencha and using something like Meteor, I would lean towards Meteor unless the UI you are building looks like a traditional desktop application and has a lot of classic desktopy widgets in it that you can map to the existing Dojo (or whatever) widgets.
If the choice is between Meteor and my system, I would choose my system, of course (although I may be biased and honestly my system has a month or two of work left before its really ready for release). Whereas Dojo Widgets (for example) are only for the front end and designed to look like a desktop application, my components include both front end and back end code, with automatic database wiring, and the widgets are set up so that it is easy to customize their appearance.
If the choice is between Meteor and my system, I would choose my system, of course (although I may be biased and honestly my system has a month or two of work left before its really ready for release). Whereas Dojo Widgets (for example) are only for the front end and designed to look like a desktop application, my components include both front end and back end code, with automatic database wiring, and the widgets are set up so that it is easy to customize their appearance.
I like it and prefer the coding style to jquery. Unfortunately dojo (and everything else) has been overshadowed by it.
"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).
IE6 support is a must-have for me (corporate clients).
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.
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.
> 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.
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.
"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.
Would love to know where this was discussed in more detail.
Angular meetup.
For what it's worth, I've been playing around with making a really tiny MV* library called 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.
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.
Nice one! It's cool to see these ideas expressed in such minimal code.
"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. ;)
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. ;)
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.
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.
Throwing away Progressive Enhancement makes sense for things way at the 'App' end of the spectrum but it's going to spread like a cancer right up to the 'Content' end of things and if we're not careful one day we're going to look back and realise we've broken the web.
Google still depends on static content for indexing
Actually, no. Google now will run JS in some cases[1]. I don't believe they have made public statements about when they do this, but I would suspect it may to to verify that the ajax-crawlerable version of the site[2] matches the real one.
[1] http://swapped.tumblr.com/post/23133779276/google-bot-now-cr...
[2] https://developers.google.com/webmasters/ajax-crawling/
Actually, no. Google now will run JS in some cases[1]. I don't believe they have made public statements about when they do this, but I would suspect it may to to verify that the ajax-crawlerable version of the site[2] matches the real one.
[1] http://swapped.tumblr.com/post/23133779276/google-bot-now-cr...
[2] https://developers.google.com/webmasters/ajax-crawling/
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.
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.
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.
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