Live data from Hacker News

Choosing the Right JavaScript Framework

airpair.com

41–50 of 91 posts

Re: Choosing the Right JavaScript Framework

#41

Earlier quoted context omitted.

While Backbone's strength is its lack of assumptions and 'freeness', angular forces developers to strictly follow their constructs. Marionette [0] is an extension of backbone that also forces developers to follow constructs that lead to scalable, modular web apps. Marionette makes backbone feel like a tool to make prototypes. 0: http://marionettejs.com/

But how big is its community?

Sizable enough. I never struggle to find answers to Marionette questions, and the documentation is GREAT. Plus the code is well commented at all the extensibility points.

There are also three excellent books[0] about Marionette, and about 3x more Marionette questions on Stack Overflow than React questions (for what that's worth).

We introduced it into our Backbone app and haven't looked back. It's great.

[0]https://leanpub.com/building-backbone-plugins https://leanpub.com/marionette-gentle-introduction https://leanpub.com/marionette-serious-progression

Re: Choosing the Right JavaScript Framework

#42

JS frameworks are absolute cancer. They do nothing but kill page load times and degrade user experience: since when is it a good idea to recompile the whole entire standard library each time a program is run? They're also completely redundant in the modern browser, since standard compliance has gotten much better and more features have been added to HTML/JS/CSS. It's just yet another api that developers have to learn…

You can't get around needing to do some DOM manipulation via javascript, and Angular completely reduces the amount of code necessary to perform common user interactions. I've coded the jQuery way forever, and as a developer I quickly fell in love with Angular. That being said, it really depends on your needs for you application whether or not to implement a framework.

Re: Choosing the Right JavaScript Framework

#43

JS frameworks are absolute cancer. They do nothing but kill page load times and degrade user experience: since when is it a good idea to recompile the whole entire standard library each time a program is run? They're also completely redundant in the modern browser, since standard compliance has gotten much better and more features have been added to HTML/JS/CSS. It's just yet another api that developers have to learn…

I consider developer productivity and code maintainability to be features. Sure, there are performance tradeoffs, but there are some obvious benefits.

> I consider developer productivity and code maintainability to be features. Sure, there are performance tradeoffs, but there are some obvious benefits.

In a client side application,if the app is slow,the users wont be happy about it.

If it takes for ever to load,the users wont be happy about it.

On the server there is always caching so that requests never hit the app itself.

On the client,if the js code is slow ,for whatever reason,you cant hide it to the user.

What you say might be true on the server,these "features" definetly have to be balanced with performances on the client.That's why sometimes it make sense to use React over AngularJS,for instance,because Angular is known to be slow.

Re: Choosing the Right JavaScript Framework

#44
> Backbone lacks support for two-way data binding

Actually Backbone is painful because of the two way data binding. You do have to write way more boiler plate, but forms and actions in views will update your models and so will content coming in from the server and your event listeners have to be able to ensure that your events don't runaway from you causing all kinds of problems. Like view action -> updates model -> listener sends something to websocket -> websocket sends a response event -> updates model -> listener sends something to websocket -> an error or infinite recursion.

Re: Choosing the Right JavaScript Framework

#45
post #35

Earlier quoted context omitted.

> If you're just getting started with frameworks, I'd recommend Backbone. Backbone only is not enough to do any serious kind of work today.One always end up with tons of plugins making it as complicated as EmberJS or AngularJS. There is no serious view layer,so one has to use React,Vue,or Ractive. The router sucks,frankly,so one has to replace it. The model layer doesnt handle relationships between model,so one ends…

> There is nothing good in Backbone today frankly.It was one of the first successfull "clientside" framework AngularJS was released in 2009 [1], whereas Backbone was released a year later in 2010 [2]. [1] http://en.wikipedia.org/wiki/AngularJS [2] http://en.wikipedia.org/wiki/Backbone.js

> AngularJS was released in 2009 [1], whereas Backbone was released a year later in 2010 [2].

Sure,that's why i said

> It was one of the first successfull "clientside" framework

Did you miss the word successfull or what?

furthermore old angularjs looked more like Adobe Spry than current AngularJS,while Backbone hardly evolved(which is not good of course).

Re: Choosing the Right JavaScript Framework

#46
post #37

Earlier quoted context omitted.

Which is exactly why you should choose it.

How could I do something like http://ichord.github.com/At.js in React?

React would handle the DOM; you would have to have some data model that handles the autocomplete list/cursor position and then feeds the results back into the react component.

Re: Choosing the Right JavaScript Framework

#47

If you're just getting started with frameworks, I'd recommend Backbone. You can learn it in half the time it takes to understand Angular and it'll be a good introduction to MV*. This is probably why its more popular than Angular - its easier and its good enough. Angular has a lot of "magic" which can be intimidating and frustrating. Also writing JS logic in html just feels icky when separation was the manifesto for s…

> If you're just getting started with frameworks, I'd recommend Backbone. You can learn it in half the time it takes to understand Angular and it'll be a good introduction to MV*.

Backbone is easier to learn, agreed. I would recommend checking out a list of sites built with Angular & Backbone too.

Sites built with Angular: https://builtwith.angularjs.org/

Sites built with Backbone: http://backbonejs.org/#examples-documentcloud

Re: Choosing the Right JavaScript Framework

#48

No Meteor?

I think the author is only talking about what he knows... I hope that is the case at least.

As for Meteor, I think this was a comparison of frontend-only js frameworks. I would love to see a Meteor vs. Rails vs Djano comparison however :).

Re: Choosing the Right JavaScript Framework

#49
post #6

What, no React/Flux? How can this be a serious comparison without React?

React + what? Is there a standard router/controller and model that get's used with React?

I think they just could have added the line "As an alternative to using underscore templates in Backbone, you can use React instead."

Re: Choosing the Right JavaScript Framework

#50
post #19

Enough with the "No X? http://www.X.ly" comments. Assuming you're not spamming, submit an article yourself or talk about your framework's tradeoffs engaging points from the article above.

That's the messy thing about the JS framework ecosystem. To the outsider, it looks like there's roughly a kazillion frameworks, and it's difficult to tell what they all do, what the differences are, and how to make a reasonable decision on which one to use for a project. Post a decent comparison article like this, and you get buried in comments about how you skipped these frameworks or those plugins.
Post reply on HN