8 ms·

Comparing Ember Octane and React

63 points by mokkol 6y ago

holler 6y ago
This is an excellent writeup. Something that sticks out to me is that the Ember code feels much more readable than React with hooks. The "future" component at the bottom using inline glimmer templates with @use is especially exciting! To be honest I think that could be a game changer and get more developers excited about Ember.js.
- arodyginc 6y ago
  I'd agree that React Hooks is a big shift towards unhealthy coding practices. But used wisely it can simplify the trivial scenarios. Only problem is to find wise javascript devs...
onion2k 6y ago
The author has taken an Ember app they wrote themselves, and compared it to a React example that includes code from the 19th chapter of a guide to learning React, "React Custom Hooks (Advanced)", without working through the first 18 chapters. It's no wonder they found it complicated. Comparing things is good and useful, but if you're not qualified to understand both sides of the argument well it's really hard to do a good job. This article fails hard on that count. Also... The first thing that is a clear difference with the Ember Octane version is that it's split across multiple files. The React example is one file because it's an example. The idea is to demonstrate all the moving parts in one place. It's not presented as a representation of what you would build as a production app. If you look at Road To React there's a chapter called "Folder/File Organization" in the appendices that explains how you might progress after working through the tutorial app.
- thawaway1837 6y ago
  Having interacted with Core Ember devs I would be very surprised if the author didn’t know anything about React. I’d wager that he indeed knows a lot about React. At least the ones I interacted with did not only know React, they knew it well enough to identify its pitfalls, and be able to translate what they believed to be its best parts to EmberJs. Also, the comment about different files is a thing even outside this example (and is one reason I prefer react over Ember personally). React has no defined file system, and strongly encourages components are written in a single file. Ember, OTOH, does a lot of file separation, and a lot of convention over configuration.
  - cageface 6y ago
    Convention over configuration is one of the worst ideas ever in software in my opinion. All it means is that you have to memorize all the implicit assumptions about how an app is put together before you can work productively. It makes for great convention talk demos but in production what you really want is very explicit and obvious relationships between pieces. For example, this is the reason I find a React/Typescript codebase vastly easier to understand than Rails. If your language is so verbose that making things explicit is too painful then maybe it's time to reach for a more expressive language instead of hiding everything behind a set of implicit rules.
    - 101404 6y ago
      No, it means that there's a way things are usually done, but if, in you situation, a different way works better, you are free to use it without having to fight the framework.
      - cageface 6y ago
        In a React codebase, for example, I can look at the imports and see immediately where everything in play in that file came from. In real production codebases this is invaluable.
        pzuraq 6y ago
        I definitely agree with this! In large codebases especially. This is ultimately why Ember has decided to move toward using JS imports to stitch components together as well, we recently merged an RFC to do just that.
        thawaway1837 6y ago
        This was my favorite part about Ember, and what I miss the most. The Ember team is one of the least dogmatic teams that I have come across, and has been willing to change their entire strategy when presented with a better idea (while providing a well defined and fairly convenient upgrade path). I still remember when React first came out, and showed how one way binding was so much better than 2 way bindings, and the Ember team was able to quickly switch to this new philosophy via DDAU, while still providing an easy upgrade path for our code. And all this was before 1.0 if I remember correctly.
- mnutt 6y ago
  I didn’t get the sense that the author was passing a value judgment against react for being in a single file. Later on he mentions that he likes the ability to colocate component and template, as it is more flexible.
- pzuraq 6y ago
  Hey there! Author here. I actually did work through all of the examples and am very familiar with all of the hooks, I have done a lot of in-depth research while designing and working on Ember in order to understand the pros and cons of hooks. Typically, when another framework makes a new API that is popular, my first reaction is to do research and try to understand how the API works, what its pros and cons are, and to see what I would like to pull back into our own work. As I noted near then end, there is actually a lot I like about hooks! While it does feel a bit overly granular and tricky to me, especially at the lowest level, it adds a composition primitive that didn't really exist before, and doesn't exist currently in Ember (though we're working on it, like I mention near the end). I think we may just have a different sense of what drives complexity, and what can cause antipatterns at a high level. I would prefer something just a little bit less expressive, but with many of the same composability benefits. > The React example is one file because it's an example. The idea is to demonstrate all the moving parts in one place. It's not presented as a representation of what you would build as a production app. I'm very aware of that! I was actually just pointing out a difference there, and that difference is actually something that is _enforced_ in Ember (and actually something we're looking to change, as I discuss in the last section of the post), so I was mainly pointing it out in case people were wondering why I didn't have a more equivalent example. I didn't use the later examples because they added too much more functionality for me to address in a single blog post, and I didn't want to split the files out in the example because I didn't want to change anything in general, in case people thought I was making bad-faith changes just to make React look bad.
- lhorie 6y ago
  > The React example is one file because it's an example The argument here is that Ember - true to its frameworkiness - enforces a certain file organization pattern. In React, you _can_ split things into different files, but how _you_ do it might not be the same as how _I_ do it (and one may not even do it depending on the situation, e.g. a one-off Error component in a bundle-split API.) On a similar account, because Ember is frameworky and convention-over-configuration, then a happy path in it _should_ be less "complicated" than wiring everything up manually in a less opinionated system. That's sorta the whole point. There are certainly arguments to be made about magical-ness and not-so-happy-paths, but I don't think it's fair to characterize the differences in framework philosophies as an author failing.
isakkeyten 6y ago
From a perspective of someone who codes react, what i dont like in ember: - this this this, so many this keywords - not a fan of decorators - constructor and super - mutability (unless it hides an immutable nature) - hbs feels weirder to me than jsx - the fact that you have yet another filetype in your code means even the tiniest components MUST be in more than 1 file, react lets you choose (edit: i rushed, seems there are template literals one can use)
- jmisavage 6y ago
  A lot of these apply to other frameworks too especially Angular, which has a very unhealthy love affair with decorators.
  - searchableguy 6y ago
    I am curious where decorators make sense. I find them unreadable with little to gain back so I avoid writing them myself. Class extensions works for most of the use cases of decorators. I guess they are helpful when you need to modify class methods and properties.
- erikrothoff 6y ago
  I like and use Ember a lot, but the one gripe I have is that Handlebars uses s-expressions instead of just inline JS. The constant context switch is massive and it’s not possible to hook into Typescript types, and I doubt it ever will. Would love the possibility to enable a flag to just enable JS-in HBS like {{#if this.model.isEnabled(this.byOtherVariable}} {{aHelperCall(this.args.thing)}} {{/if}} Kinda like a hybrid of JSX and HBS, but combining the best of both worlds.
  - chriskrycho 6y ago
    > it’s not possible to hook into Typescript types, and I doubt it ever will While it's not possible today, it's definitely possible in principle. (Vue is a great example of this!) The folks working on TS integration in Ember (of whom I am one) are very well aware both of the problem, what it will take to solve it, and what the state of the art is elsewhere. No timelines, but we're working on it and when we're done the experience should be comparable to TSX. All of us working on it think TSX is a killer bit of DX and it absolutely is a thing we're aiming to match.
jtdev 6y ago
The functional zealotry stink permeates every corner of React. The Ember approach seems much more aligned with my preferences.
- yowlingcat 6y ago
  +1. I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity.
  - aphextron 6y ago
    >I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity. Did you actually build anything with Hooks? I was pretty turned off by it at first sight as well. It doesn't jive with the sensibilities of a class based OOP developer's natural instincts. But once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about. No more component lifecycles and massive class files.
    - jtdev 6y ago
      > "once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about" This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I guess I'm among the ranks that can't see the clothes.
      - aphextron 6y ago
        > This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I wouldn't call myself a zealot. We chose functional components for a new project on my team as a direct response to problems we were having with maintainability of larger React applications. Specifically that class components tend to get massively bloated over time with business logic, lifecycle based rendering logic, and local state. I was skeptical at first as well. But it turns out that once you start fully separating things out into reducers and actions, the class becomes little more than boilerplate. When you enforce that there are no class members or local state allowed in UI components, it pushes people into proper separation of concerns. The project becomes much more maintainable as you don't have to dig around through components to find out what's going on.
tangue 6y ago
I expected a flamewar trigger but it was a nice writeup. It's nice to see that compared to a few years ago (remembers rails dramas, Node.js is *, ASI in Bootstrap), hackers have stopped the "biggest dick contest" posts. Guess it's on twitter now...
haskman 6y ago
I find all this code so hard to read, because there are very few elements being composed together. It reads like one monolithic chunk of code (and with a global state!). I find code enjoyable to read and write when it's like Lego. You build small little self contained pieces and join them together. It makes a big difference when building large applications. I wrote an example in [Concur](https://github.com/ajnsit/concur https://github.com/ajnsit/concur) to demonstrate what I mean - https://gist.github.com/ajnsit/f0fee9a83480289a5a052273ce21cc1b https://gist.github.com/ajnsit/f0fee9a83480289a5a052273ce21c.... The "app" is composed of self-contained widgets, each of which are short and easy to read, and have a defined purpose (show the searchbox, render a story etc.) In a larger app, they can be mixed and matched together in logical ways.
eberfreitas 6y ago
I wrote the Elm counterpart of the same example... https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and-react-1in2 https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and...

63 points by mokkol 6y ago

This is an excellent writeup. Something that sticks out to me is that the Ember code feels much more readable than React with hooks. The "future" component at the bottom using inline glimmer templates with @use is especially exciting! To be honest I think that could be a game changer and get more developers excited about Ember.js.

arodyginc 6y ago
I'd agree that React Hooks is a big shift towards unhealthy coding practices. But used wisely it can simplify the trivial scenarios. Only problem is to find wise javascript devs...

onion2k 6y ago

The author has taken an Ember app they wrote themselves, and compared it to a React example that includes code from the 19th chapter of a guide to learning React, "React Custom Hooks (Advanced)", without working through the first 18 chapters. It's no wonder they found it complicated. Comparing things is good and useful, but if you're not qualified to understand both sides of the argument well it's really hard to do a good job. This article fails hard on that count. Also... The first thing that is a clear difference with the Ember Octane version is that it's split across multiple files. The React example is one file because it's an example. The idea is to demonstrate all the moving parts in one place. It's not presented as a representation of what you would build as a production app. If you look at Road To React there's a chapter called "Folder/File Organization" in the appendices that explains how you might progress after working through the tutorial app.

thawaway1837 6y ago
Having interacted with Core Ember devs I would be very surprised if the author didn’t know anything about React. I’d wager that he indeed knows a lot about React. At least the ones I interacted with did not only know React, they knew it well enough to identify its pitfalls, and be able to translate what they believed to be its best parts to EmberJs. Also, the comment about different files is a thing even outside this example (and is one reason I prefer react over Ember personally). React has no defined file system, and strongly encourages components are written in a single file. Ember, OTOH, does a lot of file separation, and a lot of convention over configuration.
- cageface 6y ago
  Convention over configuration is one of the worst ideas ever in software in my opinion. All it means is that you have to memorize all the implicit assumptions about how an app is put together before you can work productively. It makes for great convention talk demos but in production what you really want is very explicit and obvious relationships between pieces. For example, this is the reason I find a React/Typescript codebase vastly easier to understand than Rails. If your language is so verbose that making things explicit is too painful then maybe it's time to reach for a more expressive language instead of hiding everything behind a set of implicit rules.
  - 101404 6y ago
    No, it means that there's a way things are usually done, but if, in you situation, a different way works better, you are free to use it without having to fight the framework.
    - cageface 6y ago
      In a React codebase, for example, I can look at the imports and see immediately where everything in play in that file came from. In real production codebases this is invaluable.
      - pzuraq 6y ago
        I definitely agree with this! In large codebases especially. This is ultimately why Ember has decided to move toward using JS imports to stitch components together as well, we recently merged an RFC to do just that.
        thawaway1837 6y ago
        This was my favorite part about Ember, and what I miss the most. The Ember team is one of the least dogmatic teams that I have come across, and has been willing to change their entire strategy when presented with a better idea (while providing a well defined and fairly convenient upgrade path). I still remember when React first came out, and showed how one way binding was so much better than 2 way bindings, and the Ember team was able to quickly switch to this new philosophy via DDAU, while still providing an easy upgrade path for our code. And all this was before 1.0 if I remember correctly.
mnutt 6y ago
I didn’t get the sense that the author was passing a value judgment against react for being in a single file. Later on he mentions that he likes the ability to colocate component and template, as it is more flexible.
pzuraq 6y ago
Hey there! Author here. I actually did work through all of the examples and am very familiar with all of the hooks, I have done a lot of in-depth research while designing and working on Ember in order to understand the pros and cons of hooks. Typically, when another framework makes a new API that is popular, my first reaction is to do research and try to understand how the API works, what its pros and cons are, and to see what I would like to pull back into our own work. As I noted near then end, there is actually a lot I like about hooks! While it does feel a bit overly granular and tricky to me, especially at the lowest level, it adds a composition primitive that didn't really exist before, and doesn't exist currently in Ember (though we're working on it, like I mention near the end). I think we may just have a different sense of what drives complexity, and what can cause antipatterns at a high level. I would prefer something just a little bit less expressive, but with many of the same composability benefits. > The React example is one file because it's an example. The idea is to demonstrate all the moving parts in one place. It's not presented as a representation of what you would build as a production app. I'm very aware of that! I was actually just pointing out a difference there, and that difference is actually something that is _enforced_ in Ember (and actually something we're looking to change, as I discuss in the last section of the post), so I was mainly pointing it out in case people were wondering why I didn't have a more equivalent example. I didn't use the later examples because they added too much more functionality for me to address in a single blog post, and I didn't want to split the files out in the example because I didn't want to change anything in general, in case people thought I was making bad-faith changes just to make React look bad.
lhorie 6y ago
> The React example is one file because it's an example The argument here is that Ember - true to its frameworkiness - enforces a certain file organization pattern. In React, you _can_ split things into different files, but how _you_ do it might not be the same as how _I_ do it (and one may not even do it depending on the situation, e.g. a one-off Error component in a bundle-split API.) On a similar account, because Ember is frameworky and convention-over-configuration, then a happy path in it _should_ be less "complicated" than wiring everything up manually in a less opinionated system. That's sorta the whole point. There are certainly arguments to be made about magical-ness and not-so-happy-paths, but I don't think it's fair to characterize the differences in framework philosophies as an author failing.

isakkeyten 6y ago

From a perspective of someone who codes react, what i dont like in ember: - this this this, so many this keywords - not a fan of decorators - constructor and super - mutability (unless it hides an immutable nature) - hbs feels weirder to me than jsx - the fact that you have yet another filetype in your code means even the tiniest components MUST be in more than 1 file, react lets you choose (edit: i rushed, seems there are template literals one can use)

jmisavage 6y ago
A lot of these apply to other frameworks too especially Angular, which has a very unhealthy love affair with decorators.
- searchableguy 6y ago
  I am curious where decorators make sense. I find them unreadable with little to gain back so I avoid writing them myself. Class extensions works for most of the use cases of decorators. I guess they are helpful when you need to modify class methods and properties.
erikrothoff 6y ago
I like and use Ember a lot, but the one gripe I have is that Handlebars uses s-expressions instead of just inline JS. The constant context switch is massive and it’s not possible to hook into Typescript types, and I doubt it ever will. Would love the possibility to enable a flag to just enable JS-in HBS like {{#if this.model.isEnabled(this.byOtherVariable}} {{aHelperCall(this.args.thing)}} {{/if}} Kinda like a hybrid of JSX and HBS, but combining the best of both worlds.
- chriskrycho 6y ago
  > it’s not possible to hook into Typescript types, and I doubt it ever will While it's not possible today, it's definitely possible in principle. (Vue is a great example of this!) The folks working on TS integration in Ember (of whom I am one) are very well aware both of the problem, what it will take to solve it, and what the state of the art is elsewhere. No timelines, but we're working on it and when we're done the experience should be comparable to TSX. All of us working on it think TSX is a killer bit of DX and it absolutely is a thing we're aiming to match.

jtdev 6y ago

The functional zealotry stink permeates every corner of React. The Ember approach seems much more aligned with my preferences.

yowlingcat 6y ago
+1. I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity.
- aphextron 6y ago
  >I think hooks is what finally pushed me over the edge towards saying to myself, enough with this insanity. Did you actually build anything with Hooks? I was pretty turned off by it at first sight as well. It doesn't jive with the sensibilities of a class based OOP developer's natural instincts. But once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about. No more component lifecycles and massive class files.
  - jtdev 6y ago
    > "once you start using pure functional components it all makes sense and your code becomes so much cleaner and easier to reason about" This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I guess I'm among the ranks that can't see the clothes.
    - aphextron 6y ago
      > This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I wouldn't call myself a zealot. We chose functional components for a new project on my team as a direct response to problems we were having with maintainability of larger React applications. Specifically that class components tend to get massively bloated over time with business logic, lifecycle based rendering logic, and local state. I was skeptical at first as well. But it turns out that once you start fully separating things out into reducers and actions, the class becomes little more than boilerplate. When you enforce that there are no class members or local state allowed in UI components, it pushes people into proper separation of concerns. The project becomes much more maintainable as you don't have to dig around through components to find out what's going on.

tangue 6y ago

I expected a flamewar trigger but it was a nice writeup. It's nice to see that compared to a few years ago (remembers rails dramas, Node.js is *, ASI in Bootstrap), hackers have stopped the "biggest dick contest" posts. Guess it's on twitter now...

haskman 6y ago

I find all this code so hard to read, because there are very few elements being composed together. It reads like one monolithic chunk of code (and with a global state!). I find code enjoyable to read and write when it's like Lego. You build small little self contained pieces and join them together. It makes a big difference when building large applications. I wrote an example in [Concur](https://github.com/ajnsit/concur https://github.com/ajnsit/concur) to demonstrate what I mean - https://gist.github.com/ajnsit/f0fee9a83480289a5a052273ce21cc1b https://gist.github.com/ajnsit/f0fee9a83480289a5a052273ce21c.... The "app" is composed of self-contained widgets, each of which are short and easy to read, and have a defined purpose (show the searchbox, render a story etc.) In a larger app, they can be mixed and matched together in logical ways.

eberfreitas 6y ago

I wrote the Elm counterpart of the same example... https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and-react-1in2 https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and...