
Comparing Ember Octane and React - mokkol
https://www.pzuraq.com/comparing-ember-octane-and-react/
======
onion2k
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
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
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
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
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
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
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.

------
holler
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
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...

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

~~~
airstrike
Honest question, what's so bad about `this`?

~~~
lhorie
Dynamic scope[1] is generally considered to be harder to reason about since
their values are not determined by where they appear in a file (but rather by
how the code executes at runtime)

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

------
tangue
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
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/f0fee9a83480289a5a052273ce21c...](https://gist.github.com/ajnsit/f0fee9a83480289a5a052273ce21cc1b).
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
I wrote the Elm counterpart of the same example...

[https://dev.to/eberfreitas/comparing-elm-to-ember-octane-
and...](https://dev.to/eberfreitas/comparing-elm-to-ember-octane-and-
react-1in2)

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

~~~
flowerlad
I don't get why so many JavaScript developers thing functional is cool.
Functional has been around for 30+ years. OOP won against functional because
OOP is easier to understand and leads to more maintainable code. These days
people are taking a second look at functional because functional avoids state,
which makes it easier to write concurrent code with no locks. (This has
suddenly become important because Moore's law is coming to an end, and CPUs
are adding more cores instead of making cores faster and faster.) But this
advantage of functional is not applicable to JavaScript because there are no
locks in JavaScript in any case!

~~~
nonsense1234
JavaScript is also an extremely bad functional language unless you don't mind
ridiculous memory bloat and inefficiency. To be even reasonably efficient
you're basically forced to use classes because the primary ergonomic
alternative is objects that contain functions that close over lexical scope.
This is ridiculously inefficient because functions that would normally have a
single instance on the prototype chain are now duplicated for every single
object. Modern JavaScript engines can't optimize this without breaking the
spec which they obviously won't do. You can resort to just using plain
functions and objects that contain nothing but data but this quickly becomes
quite ugly without a pipeline operator.

The standard library is also filled with mutating methods and doesn't include
proper functional data structures and pure JavaScript implementations of
functional data structures, such as immutable.js, are so slow that you might
as well just use arrays and objects and repeatedly do shallow copies.

Programs that stress functional purity in JavaScript are becoming hard to
meaningfully benchmark because instead of having a few hotspots absolutely
everything is incredibly inefficient and slow. Death by a thousand cuts.

~~~
thawaway1837
To be fair, JavaScript is also an extremely bad OOP language.

And I’m not complaining about its prototypical inheritance either (I actually
like it), but the fact that it tries to hide its prototypical nature under a
Java like veneer.

