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

Choosing the Right JavaScript Framework

airpair.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Choosing the Right JavaScript Framework

#71

Post by lsdafjklsd »

fennecfoxen wrote: post #59
acconrad wrote: post #54

The comments are already pretty deep, but I still want to mention that the right framework is all dependent on what your needs are and what your company is willing to support. Which is why I get tired of article comparisons like this, and trust me, I wrote an article on choosing AngularJS[1] but I still wouldn't push it on anyone. Each framework has it's advantages, and it really depends on where you and your company…

> But in 2012 Backbone seemed like an outdated solution to an outdated app landscape Eh. Backbone is good for enabling small elements of interactivity on mostly-static web pages (a design which isn't dead yet and useful if you have a lot of people landing on a lot of individual pages from third-party sources search engines or the like, and you want to keep down page load times). Angular and Ember are much more target…

I would absolutely not use Backbone for anything view related anymore. React.js is a much better choice, even for just enabling small islands of richness.

Re: Choosing the Right JavaScript Framework

#73

Post by basch »

bsimpson wrote: post #53

I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Granted, they aren't restricted to MVC either.) Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together…

What are your thoughts on polymer vs famo.us.

Are there any real world combinations of real time frameworks like Derby, Meteor, SocketStream, Mojito, or even Firebase+MVC with a pre-rendering engine like Polymer or Famo.us?

>This means you can render your initial request on the server, and pass markup down to the client

That's how derby works too.

Re: Choosing the Right JavaScript Framework

#74

Post by aikah »

oceanstone wrote: post #51
aikah wrote: post #45

Earlier quoted context omitted.

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

> while Backbone hardly evolved(which is not good of course) Backbone is a much simpler library than Angular. There's less of a need for it to evolve, since it's meant to be extended on a per project basis.

I disagree totally.

Re: Choosing the Right JavaScript Framework

#75

Post by prodigal_erik »

bsimpson wrote: post #53

I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Granted, they aren't restricted to MVC either.) Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together…

>There are no assumptions that your client speaks JavaScript, so it's more friendly to non-browser clients like searchbots

Thanks for pointing this out, I'm always glad to see people taking responsibility for the quality of their contributions to the web and finding tools that enable good work.

Re: Choosing the Right JavaScript Framework

#77

Post by findjashua »

bsimpson wrote: post #53

I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Granted, they aren't restricted to MVC either.) Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together…

The thing that I don't like about web components is that it's a browser specific technology. With React, I can render the first page on the server, so the user doesn't have to wait 3 seconds for the initial page load. So I'm not a huge fan of anything that's browser specific and can't be rendered on the server. I see why Google is pushing for it - web components would mean crawlers not having to execute Javascript, which translates to significant savings on crawling infrastructure. But it'd make for a shitty user experience.

Re: Choosing the Right JavaScript Framework

#78

Post by phpnode »

basch wrote: post #73
bsimpson wrote: post #53

I just did a bunch of research on state-of-the-art JS architectures for a new project I'm working on, and neither of my first two choices are on this list. (Granted, they aren't restricted to MVC either.) Polymer is interesting because it's the first one that's geared around the idea that the browser is an app rendering engine, not a document reader. Being able to declare your own HTML elements and bind them together…

What are your thoughts on polymer vs famo.us. Are there any real world combinations of real time frameworks like Derby, Meteor, SocketStream, Mojito, or even Firebase+MVC with a pre-rendering engine like Polymer or Famo.us? >This means you can render your initial request on the server, and pass markup down to the client That's how derby works too.

famo.us is shockingly bad IMHO. It breaks many common user interactions and goes through a load of hoops to enable "native performance" and then doesn't even get that right, I really don't understand the hype.

Re: Choosing the Right JavaScript Framework

#79

Post by robot »

The article is very much inclined towards angular. I find Ember much easier to develop with due to the neat separation of application logic and HTML. In Ember, most of the logic is in the javascript, templates merely serving the final result in a presentable way. In Angular I dislike to see the angular specific programming logic molded into HTML. In my opinion HTML is just a presentation layer. An example from angular:

for me this is too much programming logic in html. Same goes for React.js too. Too much html + logic mixup, that requires two parsers to work in your head in parallel (html + javascript, and maybe even some css?). I find it messy.

None of it in ember. Logic is neatly separated. In ember I also really enjoy how you separate functionality on a single page into neatly defined controllers/routes/ and components.

Also the article says you add lots of tags to your code. Not true. Using ember-cli you don't see any tags.

Re: Choosing the Right JavaScript Framework

#80

Post by angersock »

Terr_ wrote: post #67

After searching the comments here too... is Dojo just too old/unsexy, or is there some sort of filtering criteria for "Javascript framework" that I'm missing?

Dojo is huge and old and bloated, and has a lot of great features.

Personally, I'm a bit suspicious of any JS framework more than a few years old, barring a few notable exceptions (jQuery, bootstrap, etc.).

Dojo is just too large for me to feel comfortable using it in an app--with Angular or Backbone, I know there's only so much crazy in the tin; Dojo has mudballed a lot.

Post reply on HN