4 ms·

I have been building web apps for 19+ years. I like many of the frameworks out there but for some reason I HATE React. I think JSX is a huge turnoff for me.

I have been building web apps for 19+ years. I like many of the frameworks out there but for some reason I HATE React. I think JSX is a huge turnoff for me. I just can't get past html in javascript. It feels wrong. With that said, there are so many VERY smart people embracing React, so I am always questioning my "hate". Maybe one day I will change my mind. I haven't use Vue but watched/read about it and seems very cool and simple to use. For now, my favorite framework by far is Ember JS and it really blows my mind why it is not the most popular framework out there. The amount of stuff you get out of the box and the incredible productivity and happiness it brings to the developer experience is IMPRESSIVE. It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app* * I could be wrong.

Bahamut 9y ago
Interestingly, I had recently joined a team that was using Ember, and we found that Ember hampered our productivity. We switched to React and was able to rebuild 4 months of Ember work in about 3 weeks of work in React (not sure how many developers were working on the Ember app originally, but it was mainly 2 of us who built the React app), including requisite tests. I’m of the opinion that Angular is much better than Ember (note: I have 4.5 years of experience in the Angular ecosystem, including in open source), and I think I am overall perhaps more productive with React than Angular, although I feel like there are less issues with state management in Angular, which has been a pita in React. All the libraries/frameworks have various tradeoffs ultimately, so I don’t believe there is a cure all for everyone’s preferences. A note about JSX - I am not a big fan of it, but I see it more as having tradeoffs like more traditional templating languages, but different ones. I have been a bit resigned that this is the direction the ecosystem has turned towards, so I have personally decided to hold that dislike more loosely and focus on more important architecture issues. It does little good to let dislike over style paper over higher level issues if you can help it IMO. I don’t think we’ll ever see a perfect template language.
- tommyd 9y ago
  Regarding state management, have you tried MobX? It makes state management almost ridiculously simple. I've noticed a slight performance hit using it for deriving values for 60fps animations on React Natuve but in normal usage you'd never notice.
- thecrazyone 9y ago
  Very well put. This has helped me crystallize my own opinions about react. There's something very unlikeable (to me) about basic things like a router not being in the library (or should I say framework) I'm choosing. I like the way how you articulate your thoughts about keeping dislikes aside and focusing on architectural issues more.
- felideon 9y ago
  A rewrite is always going to take less time to build than the original poorly-specified version when people were trying to figure out what to do. And the original team could have been more junior, or if similarly-experienced than your 2-person team, adding more people to the team without good leadership can also affect productivity---or as they say in Scrum, "velocity".
pitaj 9y ago
For a long time, people have been saying "separation of concerns" to support the idea of keeping HTML, JavaScript, and CSS in separate files. The problem with that is that the document, application state, and styling is all highly coupled when dealing with web apps. Web pages which are content based are fine with these being separate, changes to one don't necessarily affect another. For web pages, the separation of languages is a separation of concerns. However, for web apps, the separation of languages becomes a barrier, since everything about a certain behavior in your program could be in three different languages or more. React changes this notion with the idea of a component. A component is ideally pure, meaning that it affects itself and it's children, and nothing else in the application. Components are composable, so you can combine multiple components, allowing for very DRY view code. Idiomatically, React components have elements, styles, and the relevant code in a single file. This keeps things encapsulated and easily maintainable.
- mnutt 9y ago
  While it didn't start out this way, these days Ember apps lean heavily on components and all of the apps I work on use a pod structure that groups each component into a directory containing a component.js, a template.hbs, and a style.scss file. This maintains the spirit of "components should be self-contained" while not having to define html and css within javascript. Ember has React to thank for the idea, but I prefer Ember's implementation.
- jamie_ca 9y ago
  Separation of concerns means put your styles in a <style> tag rather than the style attribute of a tag, and behaviour in a <script> tag rather than in an onclick/onhover/whatever on the tag. Grouping logically related components together makes perfect sense (and this is coming from a backend Rails dev who thinks the rails directory structure is totally wrong as well).
alpinecode 9y ago
I worked with Ember for a few months and I like it a lot - it definitely deserves more recognition. One thing that frustrated me a lot in Ember was the run loop. The docs suggest that you don't have to worry about the run loop at all and its merely an implementation detail, yet we had to constantly us Ember.run, Ember.run.schedule, etc. all over the app. But of course in order to know which Ember.run methods to use, you end up diving deeply into the implementation details of the framework itself.
guscost 9y ago
> It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app You're probably right about this. But it's not always the whole story - maintain and grow your app for a year, and you may find your experience shifts dramatically. Disclaimer: I haven't used Ember for anything but the tutorial, and I hear it's pretty good these days.

Bahamut 9y ago

Interestingly, I had recently joined a team that was using Ember, and we found that Ember hampered our productivity. We switched to React and was able to rebuild 4 months of Ember work in about 3 weeks of work in React (not sure how many developers were working on the Ember app originally, but it was mainly 2 of us who built the React app), including requisite tests. I’m of the opinion that Angular is much better than Ember (note: I have 4.5 years of experience in the Angular ecosystem, including in open source), and I think I am overall perhaps more productive with React than Angular, although I feel like there are less issues with state management in Angular, which has been a pita in React. All the libraries/frameworks have various tradeoffs ultimately, so I don’t believe there is a cure all for everyone’s preferences. A note about JSX - I am not a big fan of it, but I see it more as having tradeoffs like more traditional templating languages, but different ones. I have been a bit resigned that this is the direction the ecosystem has turned towards, so I have personally decided to hold that dislike more loosely and focus on more important architecture issues. It does little good to let dislike over style paper over higher level issues if you can help it IMO. I don’t think we’ll ever see a perfect template language.

tommyd 9y ago
Regarding state management, have you tried MobX? It makes state management almost ridiculously simple. I've noticed a slight performance hit using it for deriving values for 60fps animations on React Natuve but in normal usage you'd never notice.
thecrazyone 9y ago
Very well put. This has helped me crystallize my own opinions about react. There's something very unlikeable (to me) about basic things like a router not being in the library (or should I say framework) I'm choosing. I like the way how you articulate your thoughts about keeping dislikes aside and focusing on architectural issues more.
felideon 9y ago
A rewrite is always going to take less time to build than the original poorly-specified version when people were trying to figure out what to do. And the original team could have been more junior, or if similarly-experienced than your 2-person team, adding more people to the team without good leadership can also affect productivity---or as they say in Scrum, "velocity".

pitaj 9y ago

For a long time, people have been saying "separation of concerns" to support the idea of keeping HTML, JavaScript, and CSS in separate files. The problem with that is that the document, application state, and styling is all highly coupled when dealing with web apps. Web pages which are content based are fine with these being separate, changes to one don't necessarily affect another. For web pages, the separation of languages is a separation of concerns. However, for web apps, the separation of languages becomes a barrier, since everything about a certain behavior in your program could be in three different languages or more. React changes this notion with the idea of a component. A component is ideally pure, meaning that it affects itself and it's children, and nothing else in the application. Components are composable, so you can combine multiple components, allowing for very DRY view code. Idiomatically, React components have elements, styles, and the relevant code in a single file. This keeps things encapsulated and easily maintainable.

mnutt 9y ago
While it didn't start out this way, these days Ember apps lean heavily on components and all of the apps I work on use a pod structure that groups each component into a directory containing a component.js, a template.hbs, and a style.scss file. This maintains the spirit of "components should be self-contained" while not having to define html and css within javascript. Ember has React to thank for the idea, but I prefer Ember's implementation.
jamie_ca 9y ago
Separation of concerns means put your styles in a <style> tag rather than the style attribute of a tag, and behaviour in a <script> tag rather than in an onclick/onhover/whatever on the tag. Grouping logically related components together makes perfect sense (and this is coming from a backend Rails dev who thinks the rails directory structure is totally wrong as well).

alpinecode 9y ago

I worked with Ember for a few months and I like it a lot - it definitely deserves more recognition. One thing that frustrated me a lot in Ember was the run loop. The docs suggest that you don't have to worry about the run loop at all and its merely an implementation detail, yet we had to constantly us Ember.run, Ember.run.schedule, etc. all over the app. But of course in order to know which Ember.run methods to use, you end up diving deeply into the implementation details of the framework itself.

guscost 9y ago

> It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app You're probably right about this. But it's not always the whole story - maintain and grow your app for a year, and you may find your experience shifts dramatically. Disclaimer: I haven't used Ember for anything but the tutorial, and I hear it's pretty good these days.