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.

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.

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.

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.

Sure, but there's a lot more to the example that a single component. There's the app component, 3 other components, a reducer, and a custom hook. Putting all that in a single file is fine for an extended example explaining how things work together with a further chapter explaining how to break it down in to separate files, but it's not how you'd write a real app. The article author clearly doesn't know that if his criticism is that Ember does it better by using more files, so it not unreasonable to question if his knowledge of React is up to comparing it to Ember. It's quite a fundamental mistake he's making.

As someone who worked with Ember in the past (our company inherited a new product with an acquisition so we were forced to change tech stacks), this comment really comes from the fact that Ember has a very comprehensive file layout system. And one of the major criticisms about Ember classic was how different core pieces for the same component, were located in so many distant folders (hence the comment about colocation of component code, which seems trivial, but is a huge usability gain IMO).

I think that sentence should be read more as a reflection on Ember, than suggesting the author does not think React components can be broken into multiple files, and hence an indication of their knowledge of react.

When I first started working with ember many years ago, I felt the same way. But now after working on many ember apps, I feel the opposite. The "convention over configuration" really only applies to basic application structure e.g. routing/templates/controllers etc. All it's really doing is creating a standard place to put files, which itself is flexible and more recently allows e.g. colocated components like you'd see in react/vue/etc.

I think the core point from the article is just how much ember.js has changed and matured. If you read to the bottom it looks like single-file components with glimmer are in the pipeline as well.

But it’s definitely not the worst idea. People who like that approach seem to be extremely productive with it.

It’s definitely not my cup of tea though.

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.

I'm confused, ember uses standard js imports as well so what's the difference?

- 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)

You end up with few ugly situations. First, I hate that I have to wrap my components (what if you want different fallback for different components? You end up with many wraps), how my UI will render is not isolated anymore. I often end up returning loading view from the components as we as well using it as a fallback for suspense. It just feels wrong. I lack control.

Example you can create some "task" (promise-like), then in a template you have automatic access to it's state so e.g.

``` {{#if this.fetchStoriesTask.isRunning}} loading... {{else}} <span>Loaded 10 Stories</span> {{/if}} ``` https://github.com/machty/ember-concurrency

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}}

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.

[1] https://en.wikipedia.org/wiki/Scope_(computer_science)#Lexic...

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) to demonstrate what I mean - 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.

https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and...