This article does a pretty good job of comparing three of the most popular: http://smashingboxes.com/ideas/choosing-a-front-end-framework-angular-ember-react
Aw man! Trying to do a good turn. Now I feel bad : )
Thanks for the article. Now I'm doubting again though. It seems React only takes care of the UI? So for the rest (communication with the server) I should use something else? It would be a pity if I had to use jQuery just for the Ajax part?
Maybe I might as well look into Ember? Or would that be overkill?
I built something for work using Ember, which I then had talking to a Rails back end. That was a while back, but I remember being quite pleased at how familiar it seemed (coming from a Rails background).
We also had this on the JS channel recently: http://www.sitepoint.com/whats-new-in-ember-2/
Personally, I've been wanting to check out Angular 2, so I would be tempted to look at that.
But reading the article I had the impression angular 2 is not stable yet?
Their documentation still says to not use it in production.
Ah, come on. That's the excitement of using bleeding edge.
The Sword of Damocles that any to all of your work could be scrap at any time
Spend some time reading the docs and use case for all that is available in the various frameworks and then make an informed choice. People some times get religious about questions like there. You therefore have to dive in and make your own choice.
All the best in the world of endless frameworks
Easier said than done.
New frameworks appear so quickly I dare say by the time one is evaluated there will be two more.
Seems there must be some way to narrow things down a bit.
- Open Source?
- Community Support?
Correct, React only handles the ui but I'd still suggest that's the best framework to adopt today. In React you'll find yourself using other smaller dedicated libaries(react-router, lodash, moment etc..) rather than a behemoth that includes all of those. This is the way most js dev's prefer to build their apps but an all encompassing framework may be better for large distributed teams where having conventions for everyone to follow are important.
The first big hurdle you'll have to jump in React is learning how to manage data changes and state, after completing the tutorial you'll have a basic idea of how to pass data into your components. When you're dealing with an application made up of lots of components that have shared state you'll need something more sophisticated, there's a bunch of Flux implementations for handling state, the ones that seem popular at the moment are Alt and Redux.
For your first few components just use plain React, handle the data in variables, when you need to share more state you'll find the need for a flux library.
For me, Ember and Angular both fall into that trap of having a far too large API which means getting up to speed is difficult and the number of things you have to keep in your mind reaches breaking point. React is different, and it's simplicity is a clear winner for me.
If it's just the ajax functions you need from jQuery grab the fetch polyfill
I'm ready to make the bold claim that React has already won the client-side framework war.
Of course there will be more but they'll all be heavily influenced by the ideas of one way data flow, component hierarchies and do virtual dom diffing.
Pretty bold statement when I can say with the up most certainty that "next year" everyone will be moving onto the next flavor of the "month". That is technology so I much prefer choosing the most reliable and well documented over the most "new". Much of the newer stuff doesn't have anywhere near the amount of resources as the slightly older stuff.
I haven't used react but from what I see it all falls under the same category as stuff like Angular just with different marketing surrounding it. Everyone thinks their stuff is the latest and greatest. Only a fool buys into that without actually experimenting and forming their own opinion.
For existing HTML websites I prefer jQuery – pure and simple. The amount of information out there FAR surpasses any other utility based library. Which results in a smaller learning curve and more production throughout.
Now for single page sites I could really go with anything. I've used Angular it was ok. Though I wouldn't say it is better or worse than anything else out there that fulfills similar problems.
Again though I always prefer the more proven solution as more resources typically exist.
I accept your challenge there will be new libraries but people won't be abandoning React or it's patterns any time soon.
I'm a late adopter of technology as well.
jQuery was great but people are moving away from it for the right reasons.
2. Manual DOM manipulation leads to bugs and is messier to deal with - You only realise how true this is when you compare with the declarative renders in React, they are simpler to understand and you never need to search the DOM for the truth e.g.
The amount of information/resources available shouldn't be the benchmark to choose tech, my favourite tools are those with tiny API's and fewer resources - Backbone, CoffeeScript, Underscore, React. They seem simple because they are simple. Angular, Ember, even jQuery have huge api's compared with these.
I do agree that js frameworks have been abandoned in the past, that's why my prediction is so bold - React is here to stay.. at least for a little while longer
You could use fetch.
It's not supported in any version of IE or Edge though: http://caniuse.com/#feat=fetch
IE Polyfill: https://github.com/github/fetch
Pretty good SP article on it: http://www.sitepoint.com/introduction-to-the-fetch-api/
But, I'm not going to lie. I've only played with it and I'm not sure about all the pitfalls of using it.
Bower is a frontend dependency management tool. You don't need Bower for Babel, you do need NodeJS for Babel though. NPM is the Node Package Manager. If you're using NodeJS at all, you need NPM. Almost all your interaction with NodeJS will be through NPM.
Don't worry, if you wait a week it'll all change.
If it makes you feel any better:
(Laurie Voss is the Co-Founder/CTO of NPM)
Hey guys, Mark has taken his thoughts from post#28 (above) and written them up in a post on our main site.
Go check it out : )
That's cool. It's nice that a question of mine actually led to an article
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.