Is this concerning?
https://www.google.com/trends/explore?q=ember.js,react.js
In any case congrats on the new gig Tom.
In any case congrats on the new gig Tom.
Ember.js had many strong parts, but also had many issues that pulled it down. Documentation overfocused on explaining concepts but not providing examples of how to solve real issues. New release every six weeks bringing painful deprecations and changes. Lack of realworld apps to look up to for examples. Ember-Data that worked out the box... unless you weren't using Rails for your backend, in which case you've needed bridges and drivers for it to work. Rich of resources assuming that your backend is Rails or that you have enough of understaing about it to translate examples for your tech. All of this eventually pushed me away to React.js that seemed less opiniated about your backend and richer in examples and manuals, as well as unopiniated enough to forgive my mistakes and let me lear from them. Since moving I've made a lot of mistakes with my own solution build using React.js and libs from its ecosystem, which eventually made me understand design choices behind Ember.js, but I still preffer to improve on what I have now instead of considering returning to Ember.js.
I've only worked on a few SPA's in the past years and every single one of them had some unique fundamental demands that led to some equally unique and fundamental differences in how the app was built.
Maybe I'm just not creative enough, but I find it difficult to come up with one Rails-size solution that would've been useful for all of these apps.
On the other hand, I remember when Rails took off, it seemed like an obvious batteries-included solution to a whole set of rather typical CRUD websites.
Few random thoughts of things that make SPA's less 'standardized' and perhaps, at this time, less likely to benefit from Rails-size frameworks:
- with SPA's you often have to work with the back-end that is provided to you. That's usually not an issue with Rails. - since the significant logic is now client-side (routing, etc), you have a large number of possible ways to synchronize server-side routing with client-side routing. - code size is an issue, so in some cases choosing a simpler solution for one part of the stack is necessary, plus for anything big you need to deal with code splitting and all that this entails. - performance is an issue so we can't just re-render the entire page. React and similar solutions have been one of the best improvements in this regard and take out a bunch of complexity (but add some of their own). With a non-SPA solution this is just not an issue. - browser compatibility is still an issue. With an SPA solution you need to consider all the same stuff as with a non-SPA framework, but now you also have to deal with things like javascript version support, event handling inconsistencies, local storage, animations, multiple forms of interaction (slide, drag&drop, etc.), loading indicators and potentially a whole bunch of async stuff.
But perhaps most fundamentally: in a 'typical' Rails setup, the basic form of interaction is basically url -> page. It's turning one string into a bigger string. But in a typical SPA, there are tons of different types of interactions that lead to tons of different results. Any interaction with the page can mean: change state, send or retrieve something to or from server, save something in a cookie, go to a different page, load a different piece of content without changing the route, load content and animate to it (so simply navigating to a different route is not enough), and that's just off the top of my head.
And you generally still need some kind of back-end on top of that with its own complexities and odd ways of interacting with your client-side code.
For example, ember-redux exists to take the functional centralized state-management of redux that makes react great and ports it to ember. Similarly, react-scripts takes the developer-ease of ember-cli and gives it to react. Everybody uses the DDAU for handling DOM interaction, shadow-dom-tree-diffing (or whatever it's called) for rendering, some sort of declarative remote data-layer in both ember-data and redux-orm (and there's even ember-redux-orm), and junk like animation-handling and whatnot all expose the same change-attribute-yield-block API to the programmer.
If you look beyond the stylistic difference of things like writing jsx v. hbs, there's actually very little philosophical difference between modern 2.x ember and modern react
That said, it's a great abstraction for handling relational data, and I'm a huge fan of it.
It quietly sits in the back, takes what it can get from other frameworks and attempts to innovate on them (see FastBoot vs. the mess that is server-rendered React) while enjoying a smaller but lively community.
For example, the Ember NYC meetup is a lot better than any React NYC one I've been to in terms of community and quality.
Regardless, I've bet on Ember both at my company and personally because I think they've done a lot of things right and their community process sets them up to continue on that track. As long as the community and innovation continues, I don't think it matters if React keyword searches are 20x Ember's.
It definitely matters, it's a huge deal: popularity > usage > superior ecosystem > jobs > repeat