"Choosing the Right JavaScript Framework" - by someone wearing an Angular t-shirt and an Angular sticker on his laptop
I'm sure it's not going to be biased at all.
Choosing the Right JavaScript Framework
81–90 of 91 posts
Re: Choosing the Right JavaScript Framework
#82Earlier quoted context omitted.
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."
There's no standards, but at this point I'd say Flux + React-router are quickly becoming it. react-router is made in the spirit of Ember's which is pretty well liked. - Flux Architecture Pattern [0] - React Router [1] Note that there isn't really a prescribed model in Angular aside from $scope either. [0] - http://facebook.github.io/flux/ [1] - https://github.com/rackt/react-router
I like react-router that looks quite nice. Flux looks like a description of an idea rather a JavaScript library. Is there a flux store that persists to a REST backend?
A model really isn't part of Angular core since it was split out but something like angular-resource is what I am talking about.
Re: Choosing the Right JavaScript Framework
#83Every few months I review the top js frameworks and always come to the same conclusion: for existing projects you're probably better off sticking with what you're already using.
Each framework follows such a different paradigm that it's hard to transition incrementally, especially if you're app has a rich data layer rooted in an existing framework's mentality (in our case the backbone model/collection/sync mentality).
I'd love a better view framework, but not if it requires a full rewrite of the model layer and all the related libraries.
Until there's a ruby on rails quality model/collection/associations library that can be paired with a performant view framework with two-way data binding, I'll just stick with backbone where things are simple. Even if it costs me a few extra keystrokes.
> A good rule of thumb is not to have more than 2,000 active bindings on the same page.
Anyone personally run into this? What are you supposed to do in angular if you need to listen to change events for thousands of models?
Re: Choosing the Right JavaScript Framework
#84Earlier quoted context omitted.
There's no standards, but at this point I'd say Flux + React-router are quickly becoming it. react-router is made in the spirit of Ember's which is pretty well liked. - Flux Architecture Pattern [0] - React Router [1] Note that there isn't really a prescribed model in Angular aside from $scope either. [0] - http://facebook.github.io/flux/ [1] - https://github.com/rackt/react-router
I like react-router that looks quite nice. Flux looks like a description of an idea rather a JavaScript library. Is there a flux store that persists to a REST backend? A model really isn't part of Angular core since it was split out but something like angular-resource is what I am talking about.
I'd recommend looking at the docs on Flux, it explains it all better than I could.
Re: Choosing the Right JavaScript Framework
#85If you like React for its virtual dom, but are looking for something more MVC-ish, there's also Mithril ( http://lhorie.github.io/mithril ).
Some of the pros are that it's easy to learn (e.g. if you know js, you already know the templating language syntax), and it's one of the fastest frameworks in the market right now.
There's also a more detailed comparison w/ other frameworks here: http://lhorie.github.io/mithril/comparison.html
Re: Choosing the Right JavaScript Framework
#86But, but, but... what about the Un-JS Un-Framework, intercooler: http://intercoolerjs.org/
Thanks for posting this. I have yet to get into front-end work, but this looks like the least painful way to dive in I've seen.
Re: Choosing the Right JavaScript Framework
#87I 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…
Been meaning to look into React, so thanks for the review. Polymer is really not an option until Web Components are more broadly accepted by the browsers and better specified. One of the things I like about Angular JS is that it represents, IMO, a "baby-step" towards Web Components (which Polymer is built atop) through Directives.
React is also elemental, but in a different sort of way. Your elements effectively become substitutions:
// When I say
// give me
Re: Choosing the Right JavaScript Framework
#88I 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…
If you don't mind sharing, have you done any research on data layers for React? From what I can see, there seems to be three major schools of thought: the Flux architecture, using Backbone's models, or just writing something custom.
Still working on the data layer, but I think I'm going to use Reflux. One of the things I was initially skeptical of React about is its lack of support for custom event bubbling (which is the technique I like to use to keep my components decoupled).
Flux lets you cheat around that: Since you're using require statements, you can make an action and `require()` it in both the component it's dispatched from and the one that's listening to it.
// Traditional event bubbling
child.dispatchEvent(...) ----> parent.addEventListener(...)
// Reflux
child:action() ----> store.listenTo(action) ----> store.trigger(data) ----> parent.listenTo(store)
Honestly, I'm murky on the utility of the Store and even less confident in the utility of the Dispatcher. That's why I'm using Reflux instead of FBFlux, and I'm still tempted to skip the store and just listen to my actions from the parent component.
Re: Choosing the Right JavaScript Framework
#89The 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 angula…
I've always found it weird that many people put the HTML, JS, and CSS for one component in three different files, but never thought enough about it to put it into words. Pete Hunt (one of React's maintainers) does that here:
https://www.youtube.com/watch?v=DgVS-zXgMTk
React is about separating concerns, not technologies. Everything you need to know to draw an App Bar is in AppBar.jsx. You can dynamically generate the markup with JavaScript, but that doesn't change your separation of concerns, because everything concerning that component lives in that file.