Client-side JS MV* Framework Roundup(blog.susestudio.com)
blog.susestudio.com
Client-side JS MV* Framework Roundup
http://blog.susestudio.com/2013/03/client-side-js-mv-framework-roundup.html
6 comments
Even though the author updated the article to point out that Angular definitely works with strict HTML, he or she left the conclusion that AngularJS requires "invalid" HTML to use it to full capacity. That's incorrect.
Aside from the poor title choice, I find it hard to discount that angular encourages invalid html. Work arounds aside, it says a lot about the framework mentality.
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 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.
Thanks, I wanted that little expansion about the concerns about Angular's markup.
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.
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.
Its already clear from the article that they did not actually do an objective study of the different frameworks. They were already heavily biased towards rails and given that batmanjs is something that is very close ( convention over configuration, coffeescript, works quite well with rails ) it was an obvious choice for them.
It appears that they did not actually try any other framework to be frank. Just noted their cons mostly.
It appears that they did not actually try any other framework to be frank. Just noted their cons mostly.
> 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.
Wrote code in every one of the 13 frameworks I mentioned. Thanks, though, for assuming I'm a complete jackass.
I don't like the way the AP made his feelings known but I felt a similar way, I felt the scoring of each point was rather subjective and more or less fixed in order to give the desired outcome. (eg: YUI 4 for community / consistency, and a laughable 3 for publicity, reading your definitions for those and your evaluation of yui, I'm amazed you didn't give 5's across the board)
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.)
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.)
Batman.js does look quite good.
I'm currently using Angular for a personal project, and I really really like it. Pity you didn't.
I'm currently using Angular for a personal project, and I really really like it. Pity you didn't.
I'm tickled pink Angular is working for you.
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.
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.
Thx
I don't think you should take these comments personally. The world of frameworks is loaded with fanboys of one or the other. :/
[deleted]
To comment on what they say about ember.js.
>> 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.
>> 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.
>> 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'?
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.
> 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.
No need to roll your own, there are solutions out there already: https://github.com/railsware/smt_rails, and surely others by this point
One thing that batman.js has that none of the other systems have is that it's origin is an extraction from a huge production system. Batman was extracted from Shopify's admin interface that is one of the largest single page JS apps. It's production ready by definition.
> It's production ready by definition.
That is, if you define "production ready" as "already being used in production."
That is, if you define "production ready" as "already being used in production."
That definitely seems to be the way people are defining it these days, sadly.
These things always miss jsrender and jsviews by boris moore, which imo is the most promising of the bunch.
[deleted]
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".