>> 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.
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.
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 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.)
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.
So, the answer to your headline of why batman.js over AngularJS is because of "invalid html" attributes despite that being incorrect?
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".
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.
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.
20 comments
[ 4.2 ms ] story [ 77.5 ms ] thread>> 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.
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.)
That is, if you define "production ready" as "already being used in production."
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.