4 ms·

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 a

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

by Ralfp 10y ago

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.