Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Client-side JS MV* Framework Roundup

blog.susestudio.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Client-side JS MV* Framework Roundup

#11

Post by bear454 »

hmottestad wrote: post #7
bear454 wrote: post #5

Earlier quoted context omitted.

> 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.

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 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.

Re: Client-side JS MV* Framework Roundup

#13

Post by wambotron »

bear454 wrote: post #5
ganarajpr wrote: post #3

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…

> 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 don't think you should take these comments personally. The world of frameworks is loaded with fanboys of one or the other. :/

Re: Client-side JS MV* Framework Roundup

#14

Post by Smudge »

xal wrote: post #6

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."

Re: Client-side JS MV* Framework Roundup

#15

Post by vlad »

kevinastone wrote: post #10

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 familiari…

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.

Re: Client-side JS MV* Framework Roundup

#17

Post by taproot »

vlad wrote: post #15
kevinastone wrote: post #10

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 familiari…

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.

Re: Client-side JS MV* Framework Roundup

#18

Post by taproot »

bear454 wrote: post #5
ganarajpr wrote: post #3

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…

> 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 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.)

Re: Client-side JS MV* Framework Roundup

#19

Post by 33degrees »

bear454 wrote: post #4
adamnemecek wrote: post #2

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 chu…

>> 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.

No need to roll your own, there are solutions out there already: https://github.com/railsware/smt_rails, and surely others by this point

Re: Client-side JS MV* Framework Roundup

#20

Post by james2vegas »

Smudge wrote: post #14
xal wrote: post #6

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 definitely seems to be the way people are defining it these days, sadly.
Post reply on HN