4 ms·

Is this concerning? https://www.google.com/trends/explore?q=ember.js,react.js https://www.google.com/trends/explore?q=ember.js,react.js In any case congrats o

Is this concerning? https://www.google.com/trends/explore?q=ember.js,react.js https://www.google.com/trends/explore?q=ember.js,react.js In any case congrats on the new gig Tom.

jonnii 10y ago
Probably not for the same reason this isn't concerning: https://www.google.com/trends/explore?q=vue.js,react.js https://www.google.com/trends/explore?q=vue.js,react.js
- ChemicalScum 10y ago
  Ooooh I like this game! How about now? https://www.google.com/trends/explore?q=ember%20js,react%20js,vue%20js,angular%20js https://www.google.com/trends/explore?q=ember%20js,react%20j...
Ralfp 10y ago
I've moved from Ember to React year back. Then over year I've (crappily) recreated Ember.js using React.js and libraries. 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.
- orf 10y ago
  I agree with your points about documentation and release cadence (they do have a LTS release now though), but we've used ember-data with a Django backend since day one and it's been flawless in every respect. Once you configure it there are no issues
- mercer 10y ago
  Maybe the front-end (SPA) ecosystem, both in terms of technology and use-cases, just isn't stable enough for a Rails-type framework? 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.
ffn 10y ago
Honestly, though, Tomster v. electrons-circling-nucleus branding aside, both ember and react are currently experiencing a lot of community-driven convergence in core philosophy. 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
- acemarke 10y ago
  Nitpick: Redux-ORM is _only_ about managing relational data in normalized form locally. (Technically, it's not even Redux-specific - you can hand it any plain JS object to work with.) It doesn't do any remote requests or syncing. That said, it's a great abstraction for handling relational data, and I'm a huge fan of it.
mnutt 10y ago
I think a more accurate comparison is this: https://www.google.com/trends/explore?q=ember%20javascript,react%20javascript https://www.google.com/trends/explore?q=ember%20javascript,r... 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.
- WhitneyLand 10y ago
  >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
sotojuan 10y ago
Ember has never been the trendiest and hottest framework. 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.
romanovcode 10y ago
No. https://www.google.com/trends/explore?q=ember.js,react.js,angular2,vue.js https://www.google.com/trends/explore?q=ember.js,react.js,an...

Is this concerning? https://www.google.com/trends/explore?q=ember.js,react.js https://www.google.com/trends/explore?q=ember.js,react.js In any case congrats on the new gig Tom.

jonnii 10y ago

Probably not for the same reason this isn't concerning: https://www.google.com/trends/explore?q=vue.js,react.js https://www.google.com/trends/explore?q=vue.js,react.js

ChemicalScum 10y ago
Ooooh I like this game! How about now? https://www.google.com/trends/explore?q=ember%20js,react%20js,vue%20js,angular%20js https://www.google.com/trends/explore?q=ember%20js,react%20j...

Ralfp 10y ago

I've moved from Ember to React year back. Then over year I've (crappily) recreated Ember.js using React.js and libraries. 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.

orf 10y ago
I agree with your points about documentation and release cadence (they do have a LTS release now though), but we've used ember-data with a Django backend since day one and it's been flawless in every respect. Once you configure it there are no issues
mercer 10y ago
Maybe the front-end (SPA) ecosystem, both in terms of technology and use-cases, just isn't stable enough for a Rails-type framework? 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.

ffn 10y ago

Honestly, though, Tomster v. electrons-circling-nucleus branding aside, both ember and react are currently experiencing a lot of community-driven convergence in core philosophy. 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

acemarke 10y ago
Nitpick: Redux-ORM is _only_ about managing relational data in normalized form locally. (Technically, it's not even Redux-specific - you can hand it any plain JS object to work with.) It doesn't do any remote requests or syncing. That said, it's a great abstraction for handling relational data, and I'm a huge fan of it.

mnutt 10y ago

I think a more accurate comparison is this: https://www.google.com/trends/explore?q=ember%20javascript,react%20javascript https://www.google.com/trends/explore?q=ember%20javascript,r... 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.

WhitneyLand 10y ago
>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

sotojuan 10y ago

Ember has never been the trendiest and hottest framework. 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.

romanovcode 10y ago

No. https://www.google.com/trends/explore?q=ember.js,react.js,angular2,vue.js https://www.google.com/trends/explore?q=ember.js,react.js,an...