4 ms·

I recently gave Ember (Octane) a try on a project and couldn’t have been happier with the simplicity and productivity in comparison to React. The React communi

by jtdev 6y ago

I recently gave Ember (Octane) a try on a project and couldn’t have been happier with the simplicity and productivity in comparison to React. The React community seems to want to over complicate everything lately and spend more time arguing about philosophy than getting shit done.

Mc_Big_G 6y ago
I find it very, very sad that Ember lost the marketing war. It was painful to work with for the first 5 years or so but then became a real pleasure. I'll never understand why anyone would prefer JSX over templates. I like opinionated frameworks like Rails and Ember because, even if it's not initially designed that way, a "right way" to do things becomes apparent over time and it's built-in, documented and blogged about. You could switch companies every month and be productive in days because you know where everything should be and how it should be done (mostly). Yes, you can do everything wrong and it will still "work" but it's difficult to get anything done the wrong way in an opinionated framework. When you find yourself struggling hard to do something that should be relatively simple, it means you're doing it wrong. In contrast, React gives devs more freedom to reinvent the wheel and so when you dig in to a new-to-you React code base, you're completely lost and must learn how the previous dev decided to architect things, which can be a total nightmare. Redux feels like a valiant effort to make React more opinionated and remove the opportunity for devs to repeatedly make bad bad decisions or write similar code in multiple different ways, but it doesn't fully solve the problem. I'd choose Ember over React in a second if they were equals in terms of mindshare but trying to hire someone who wants to work in Ember is nearly impossible.
- acemarke 6y ago
  FWIW, Redux has never been pitched as "an effort to make React more opinionated". It's always been about trying to make state management more predictable. See my post "The Tao of Redux, Part 1: Implementation and Intent" for details on the original design goals of Redux: https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
  - Mc_Big_G 6y ago
    That's why I said "feels". Redux is quite obviously about making state management better but just try to build a reasonably sized app using the Context api instead of Redux and you'll quickly realize that the structured, opinionated, "right way" of doing things in Redux makes for a much happier experience.
    - acemarke 6y ago
      Heh. As a Redux maintainer, I do appreciate seeing comments like this :) Btw, if you haven't yet seen our official Redux Toolkit package, you should check it out. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-toolkit.js.org https://redux-toolkit.js.org Also, I just published a brand-new "Redux Essentials" core docs tutorial, which teaches "how to use Redux, the right way", using our latest recommended tools and practices like Redux Toolkit and the React-Redux hooks API. I'd encourage you to check it out even if you're already familiar with Redux: https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co...
      - Mc_Big_G 6y ago
        I'm actually on "Performance and Normalizing Data" right now. :) The documentation and tutorial is really well done, so thanks for that! I'm glad I attempted to build something without Redux first because at every step of the documentation/tutorial my brain just keeps exploding with "wow, this is going to make my life so much better" and helps me understand why it's built the way it is. Also, the toolkit is great and feels very Rails-y by providing default, built-in (and I'd argue opinionated) ways of doing things that simplifies development and reduces design decisions. Much appreciated.
        acemarke 6y ago
        Thank you, it's really great to hear that feedback! Totally agree that RTK works best if you already know how to write Redux code "by hand", so that you're familiar with the concepts and can see what the abstractions are doing for you. That said, my goal for that "Essentials" tutorial is that folks who have never used Redux before (like, say, someone in the middle of a typical bootcamp) would hopefully be able to start writing real Redux code using RTK and be productive with it, even if they don't understand everything that's going on under the hood. The feedback we've gotten on this new tutorial, as well as on RTK in general, tell me we've mostly managed to hit that goal. FWIW, my next task is to rewrite the existing "Basics/Advanced" tutorial sequence. It will still be a "bottom-up" explanation that teaches the underlying mechanics and shows how to do things "by hand", but I want to clean it up considerably to remove outdated references and show simpler patterns. If you're interested, my notes on how I want to redo it are here: https://github.com/reduxjs/redux/issues/3855 https://github.com/reduxjs/redux/issues/3855 If you've got any feedback on the contents of the existing tutorial and what you'd like to see improved, please feel free to leave a comment there.
- sergiotapia 6y ago
  They didn't lose the marketing war. Ember back in the day was ember-data way or the highway. If your API wasn't truly RESTful you were fucked. This is what killed it. Same reason why MeteorJS died, it was mongodb or the highway.
  - Mc_Big_G 6y ago
    Ember-data was definitely a contributing factor, although one could argue that you could build your own system, just like a lot of people do with React.

by jtdev 6y ago

Mc_Big_G 6y ago

I find it very, very sad that Ember lost the marketing war. It was painful to work with for the first 5 years or so but then became a real pleasure. I'll never understand why anyone would prefer JSX over templates. I like opinionated frameworks like Rails and Ember because, even if it's not initially designed that way, a "right way" to do things becomes apparent over time and it's built-in, documented and blogged about. You could switch companies every month and be productive in days because you know where everything should be and how it should be done (mostly). Yes, you can do everything wrong and it will still "work" but it's difficult to get anything done the wrong way in an opinionated framework. When you find yourself struggling hard to do something that should be relatively simple, it means you're doing it wrong. In contrast, React gives devs more freedom to reinvent the wheel and so when you dig in to a new-to-you React code base, you're completely lost and must learn how the previous dev decided to architect things, which can be a total nightmare. Redux feels like a valiant effort to make React more opinionated and remove the opportunity for devs to repeatedly make bad bad decisions or write similar code in multiple different ways, but it doesn't fully solve the problem. I'd choose Ember over React in a second if they were equals in terms of mindshare but trying to hire someone who wants to work in Ember is nearly impossible.

acemarke 6y ago
FWIW, Redux has never been pitched as "an effort to make React more opinionated". It's always been about trying to make state management more predictable. See my post "The Tao of Redux, Part 1: Implementation and Intent" for details on the original design goals of Redux: https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
- Mc_Big_G 6y ago
  That's why I said "feels". Redux is quite obviously about making state management better but just try to build a reasonably sized app using the Context api instead of Redux and you'll quickly realize that the structured, opinionated, "right way" of doing things in Redux makes for a much happier experience.
  - acemarke 6y ago
    Heh. As a Redux maintainer, I do appreciate seeing comments like this :) Btw, if you haven't yet seen our official Redux Toolkit package, you should check it out. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-toolkit.js.org https://redux-toolkit.js.org Also, I just published a brand-new "Redux Essentials" core docs tutorial, which teaches "how to use Redux, the right way", using our latest recommended tools and practices like Redux Toolkit and the React-Redux hooks API. I'd encourage you to check it out even if you're already familiar with Redux: https://redux.js.org/tutorials/essentials/part-1-overview-concepts https://redux.js.org/tutorials/essentials/part-1-overview-co...
    - Mc_Big_G 6y ago
      I'm actually on "Performance and Normalizing Data" right now. :) The documentation and tutorial is really well done, so thanks for that! I'm glad I attempted to build something without Redux first because at every step of the documentation/tutorial my brain just keeps exploding with "wow, this is going to make my life so much better" and helps me understand why it's built the way it is. Also, the toolkit is great and feels very Rails-y by providing default, built-in (and I'd argue opinionated) ways of doing things that simplifies development and reduces design decisions. Much appreciated.
      - acemarke 6y ago
        Thank you, it's really great to hear that feedback! Totally agree that RTK works best if you already know how to write Redux code "by hand", so that you're familiar with the concepts and can see what the abstractions are doing for you. That said, my goal for that "Essentials" tutorial is that folks who have never used Redux before (like, say, someone in the middle of a typical bootcamp) would hopefully be able to start writing real Redux code using RTK and be productive with it, even if they don't understand everything that's going on under the hood. The feedback we've gotten on this new tutorial, as well as on RTK in general, tell me we've mostly managed to hit that goal. FWIW, my next task is to rewrite the existing "Basics/Advanced" tutorial sequence. It will still be a "bottom-up" explanation that teaches the underlying mechanics and shows how to do things "by hand", but I want to clean it up considerably to remove outdated references and show simpler patterns. If you're interested, my notes on how I want to redo it are here: https://github.com/reduxjs/redux/issues/3855 https://github.com/reduxjs/redux/issues/3855 If you've got any feedback on the contents of the existing tutorial and what you'd like to see improved, please feel free to leave a comment there.
sergiotapia 6y ago
They didn't lose the marketing war. Ember back in the day was ember-data way or the highway. If your API wasn't truly RESTful you were fucked. This is what killed it. Same reason why MeteorJS died, it was mongodb or the highway.
- Mc_Big_G 6y ago
  Ember-data was definitely a contributing factor, although one could argue that you could build your own system, just like a lot of people do with React.