Client-side JS MV* Framework Roundup
blog.susestudio.com
blog.susestudio.com
If you just vetoed AngularJS based on an incorrect assumption, why would it be your summary headline? How even did those attributes impact your system and force you to explore alternatives?
I'd suggest a less sensationalist headline: "SUSE Studio uses Batman.js because due to familiarity and ease of rails integration".
I should probably note that in general I dislike the ideas put forward by angular, knockout, and similar. Binding logic to your view or in other words tight model/view coupling is just a stupid idea in the first place, it is quite plainly analogous to inline scripting like binding click events with onclick albeit in a slightly tidier way.
These frameworks basically undo the last decade or so of separating logic from presentation.
Feel free to discount / argue my point, I'm interested in a response as it is an opinion more than anything else. I have seen these frameworks work well, I just don't really agree with the ideas.
I, in fact, think quite the opposite and appreciate(d) both Knockout and AngularJS's data binding models to make it much easier to create more interactive web apps without the usual boilerplate of DOM manipulation (or other scaffolding) required in other frameworks.
It appears that they did not actually try any other framework to be frank. Just noted their cons mostly.
Wrote code in every one of the 13 frameworks I mentioned. Thanks, though, for assuming I'm a complete jackass.
I'm currently using Angular for a personal project, and I really really like it. Pity you didn't.
I have to say, it looks really cool. But, its just not something we'd use in SUSE Studio.
I'm sure a thousand other people will have a thousand other ways of describing how I've slighted or misrepresented their project... and I totally expected that. It's a blog post, not a term paper - there's just no way to comprehensively describe everything about everthing.
That being said, the effort I put into making a responsible decision for my project wasn't one I took lightly. I'm sorry folks seem to think so, just because I tried (and slightly failed) to write a 3K word summary of 80 hours of JS framework madness.
Also, "Wrote code" is pretty relative, did you ship something significant in each, preferably the same thing? Maybe even do your own todo but something relevant to your shop. Or even just a basic twitter / simple blog in each. Until you really use something for something meaningful writing a couple of little gists won't tell you what you really need to know.
If you just want to use the shiny new cool kid on the block that is batman, just say so, lots of us do this, not enough of us simply own it (and its consequences.)
>> Views are handled via 2-way binding against rendered Mustache templates;
Ember uses Handlebars.
>> we would need to roll our own Mustache template compiler
I'm not sure if I understand this point but why not just use Sprockets to compile templates? Or what do they mean by 'own [...] template compiler'?
>> the typical SPI issue of a blank page, followed by the browser chugging on JSON and templates before finally rendering the page
In practice, both JSON and templates is usually inlined, so no additional requests are necessary on the initial page load.
> I'm not sure if I understand this point but why not just use Sprockets to compile templates? Or what do they mean by 'own [...] template compiler'?
We'll be using the same partials for both server-side and client-side rendering. Its enough we have to have two sets of controllers, and two sets of models; I'm not about to maintain two sets of views as well.
That is, if you define "production ready" as "already being used in production."