DALLE generated chalkedgoose programming logo

My Experience with React and Ember

Edit: It should be noted that I wrote this priorto joining LinkedIn and working with it day to day.

These are just my personal opinions and you should take or leave whatever you’d like.

React is a prevalent library that some argue is not just a JavaScript library for Developing apps but a high level approach to building interfaces across any platform. We have evidence of this from its usage in Desktop, Mobile, Virtual Reality, and Web Apps, not all of which are written in JavaScript; Some are even completely independent of it except for bindings for JSX, the templating language most often used with React.

On the other hand, Ember is a framework composed of several reliable libraries to build full and complex Web Applications. It has built-in client side routing, global state management, and rich extensions to Handlebars, the third-party templating engine for Ember. Ember is very oriented around Components and Services and allows for a much richer routing experience than is often seen with React applications, allowing for powerful lifecycle hooks, paths, dynamic route generation, and easy use of path and query parameters.

React is very component centric leaving the choice of routing, global state management, and even project configurations up to you. Unfortunately, most major configuration choices unless you are forced to use CRA (often the case) are incredibly frustrating and often unreliable.

React abstracts almost all behaviors related to the DOM and State to a level where it almost feels diluted and hard to understand. This complexity can be advantageous to those who are not interested in the underlying workings of the application state but can be frustrating when trying to dissect and debug applications.

Often it feels as if we aren’t working with JavaScript or the DOM, which of course, is false. Working with React, it is easy to forget that the document and application will eventually live in someone’s browser.

Ember Octane has a massive reliance on ES6 classes and experimental decorators for its applications, but when I am working with Ember, I feel I am still writing JavaScript and have a richer understanding of the costs and reliability of my application.

I don’t need to be a core member of the Ember Team or even heavily study Ember to get a rough idea of what my application is doing. It also makes it frictionless to set a breakpoint and debug my application’s logic and state in the Chrome Dev Tools.

Overall I still like React for writing quick single-page apps or adding features to existing React codebases, but whenever I start a new application except for Next.js projects, I find myself quickly feeling overwhelmed and frustrated with all the nuances and failures while trying to configure or eject a React application.

React allows for compelling applications across most platforms but often lacks the centralization and toolings needed to make scaling web applications easier. I like Embers approach, and although I don’t believe it to be the best or even the easiest to use framework, it’s opinionated architecture, baked in features, stability, and easy to debug code make it a very appealing tool for building Web Applications.

Made in 🇪🇸 without the S.