EmberJS vs. React

Question

Good day! I have a question. It is planned to develop a large web project, which will be scaled in the future. I would like to know what is better to choose EmberJS or React? There is experience with EmberJs, but I would like to hear the opinion of experts who have experience with both frameworks. I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js. Tell me, please. It would be great to see some benchmarks in various conditions. Thanks guys!

Answer 1

I started with React and later moved to Ember. The truth of the matter is that the core problems teams face when developing frontend / single-page-apps are about the same regardless of what tool you're using. Those problems are going to include learning the business, learning the history, struggling with how to not over-use the framework, and instead using "the platform" (using MDN more than framework docs, etc). Generally, it takes way more time to learn a business / existing product than it does to learn a framework.

For some benefits of ember's whole ecosystem, which React does not have:

• Ember has a more cohesive ecosystem which makes upgrades much more straight forward.
• Ember's goal in frontend is to reduce the meanial differences between apps so that you can focus on features. This includes stuff like state management, routing, etc. For comparison, there are features in Next.JS that landed in the last month or so that Ember has had since the beginning.
• Ember's discord is an invaluable tool of helpful people. A bit US-work-week centric at times, but it is the go-to place to get more synchronous help outside of your own team. Link here: https://discord.gg/emberjs (which is found on the community page: https://emberjs.com/community/ ) -- React also has a discord, but I found it way less welcoming due to the sheer volume of people moving through there.
• Conventions is key to any framework in the single-page-app approaching SDK space. Conventions are optional guidance that are happy-path defaults that, once memorized, bring productivity ahead of where it would be without the conventions
• Ember is mostly "Just JS". React has this same claim, and maybe that was true back when they were using classes for things, but with everything needing hooks now, and the over-use of useEffect, Folks end up writing more React than they write JS. With Ember, you still write more JS than the framework. Ember has tried very hard to allow you to stick to MDN for for anything but reactivity and routing. State management is even allow "normal JS" (with some conventions due to limitations of JS, itself)

I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js.

This is true, however, It stops mattering very quickly. Ember is only 100KB (min+gzip) -- React (at a minimum, I think is ~40kb (min+gzip), with no libraries (react + react-dom)), and the size of your underlying framework begins to not matter in comparison to the rest of your app's code very quickly. Unless you're targeting low-connectivity areas and trying to also get your site to load in < 0.1s, the framework choice w/r/t size also doesn't matter. (I'd say this of Angular, too!).

Fwiw, and maybe this is a bit of a disclaimer, I feel like React is a modern day jQuery (usage in the vernacular is nearly the same as jQuery). Nearly everyone is using it because nearly everyone knows it. It doesn't matter if the tool is good or not, it's everywhere, yet holds no opinions about anything and relies on the broader community tot learn how to use it. You can't build products out of just React.

And kind of more cynical, React is an avenue to very cheap labor for employers to hire straight out of bootcamps.

As an aside, one thing I've noticed about frameworks, is that most of the "cool stuff" (that you'd want to use day to day) isn't documented in the framework docs. It's knowledge derived from knowledge of both the framework, and what the web can do on its own.

For example:

• handling form submissions without a ton of wireup: https://twitter.com/nullvoxpopuli/status/1502682732178124805
• dynamic imports / await import ing a component: https://twitter.com/nullvoxpopuli/status/1507715367581462531
• testing with MSW:
  • https://twitter.com/nullvoxpopuli/status/1525509103317041152
  • https://twitter.com/nullvoxpopuli/status/1525508184353406978
• Filtering local data: https://twitter.com/nullvoxpopuli/status/1496512125237440515
• Integrating Tailwind: https://twitter.com/nullvoxpopuli/status/1481993894430658568 (the lazy way)
• Thinking about template syntax: https://twitter.com/nullvoxpopuli/status/1474037335583080449