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.<p>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.<p>Also...<p><i>The first thing that is a clear difference with the Ember Octane version is that it's split across multiple files.</i><p>The React example is one file <i>because it's an example.</i> 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.
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.
From a perspective of someone who codes react, what i dont like in ember:<p>- this this this, so many this keywords<p>- not a fan of decorators<p>- constructor and super<p>- mutability (unless it hides an immutable nature)<p>- hbs feels weirder to me than jsx<p>- 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)
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 <i></i>*, ASI in Bootstrap), hackers have stopped the "biggest dick contest" posts. Guess it's on twitter now...
I find all this code so hard to read, because there are very few elements being <i>composed</i> together. It reads like one monolithic chunk of code (and with a global state!).<p>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.<p>I wrote an example in [Concur](<a href="https://github.com/ajnsit/concur" rel="nofollow">https://github.com/ajnsit/concur</a>) to demonstrate what I mean - <a href="https://gist.github.com/ajnsit/f0fee9a83480289a5a052273ce21cc1b" rel="nofollow">https://gist.github.com/ajnsit/f0fee9a83480289a5a052273ce21c...</a>. 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.
I wrote the Elm counterpart of the same example...<p><a href="https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and-react-1in2" rel="nofollow">https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and...</a>