I’ve been a software engineer / technical leader for about 15 years now, and I have no interest in the pedantic “tabs vs. spaces” type of holy wars that I see rage all the time.
I’ve recently been entertaining the notion of taking a job building and being a technical mentor on a team building a non-trivial web app with ember that seems well-suited to Ember’s use case.
I wanted to quickly drop in to ask for some input. I just watched the Fireside Chat from Ember Conf (a few days back) with @wycats and @ef4 and I felt that the conversation missed some important nuance in the lessons that I’ve learned from building substantial UIs in React over the past 7 years.
Garbage collection / cleanup were a plague to me and my team I was leading in 2013~ish while we were building a large Backbone / Marionette web app. The “hard MVC” patterns that were established there create these silos that things have to fit into categorically. “Service” “Factory” “Model” “View” “Controller” are a few. I saw unreasonable amounts of time wasted arguing about which silo a given “thing” should be put into when it straddled the line between a “service” vs. “factory” and similar debates. React doesn’t care about your file structure or silos. Obviously you need organization / structure in order to have a successful project, but when things don’t need to extend some JS base class, they can just do exactly what they are supposed to, and if you don’t know what “shelf” they belong on, you can just put them in the mis “utils” directory. Native ES5 modules / import statements allow things to depend on each other without undue formality in their contract and no need to compare their relative match to the base class they extend from. Something useful in the React ecosystem has been functional programming, when you add the needed evolution of React hooks / context so that you’re not constantly having to blindly spread props down or bloat your intermediary components with irrelevant passthrough props, things get much better. Along similar lines (and I realize this is an implementation choice that is not applicable to every project) Apollo and GraphQL are powerful in that ecosystem for getting only the data you need. Apollo acts as middleware and de-dupes requests so that each component can call
useQuery for itself and not have to worry about a second component in a highly dynamic screen potentially duplicating the data request (a common anti-pattern in REST sans framework, which I think Ember solves via the Factory / Service pattern).
On the subject of state mutation, @wycats mentioned that Starbeam lets you look at the output but React doesn’t. This feels like a misunderstanding, and is the reason Redux is commonly paired with React. It gives you time-traveling state mutation history and the ability to very concisely bisect a problem in a step-by-step debug step through mode (e.g. Chrome Debugger js breakpoints).
All that to say, some lessons I feel could be useful for Ember to learn from the principles of React (and don’t get me wrong, the ecosystem has no shortage of frivolity, and best practices, standards, and incremental change are appealing philosophically after betting on a project and then watching it die!)
Functional programming + Redux is powerful, why couldn’t Redux be added under the hood to as a source for ember-data via built-in mechanism to then give time-traveling debugging (immense time savings and developer productivity boosts in my experience with large applications) and avoid re-inventing the wheel?
Garbage collection is almost never a problem in React because of functional paradigms and the built-in garbage collection in the framework. Are the Ember lifecycle hooks like
willDestroyreally beneficial? @wycats mentioned the need to unsubscribe from websockets. In React I’ve not needed to unsubscribe, I can just kill the DOM node and the unsubscription is implicit. Can someone explain this use case to me?
There are more things I could ask, but I’ll start with these questions, mainly because further conclusions I draw might be based on a flawed assumption before I fully understand the reasons for some of these decisions I find confusing. I’m just worried that there’s a lack of real collaboration with those familiar with React and it’s real-world use cases / benefits.