Party of Five : The Wrapup

What I’ve learned from this experiment, and some of my general experiences.

Originally I called this section the conclusion, but that was poorly named. I’m not going to crown a winner here. This isn’t a zero-sum game where only one can be the chosen. I did want to sum up a few general findings, though.

People Talk A Lot Of Shit

In writing this I spent a reasonable amount of time looking into various aspects of these frameworks, trying one approach and another, etc. In doing that research I regularly ran into arguments for the frameworks.

A huge number of these rely on a woeful lack of knowledge of other frameworks. Other frameworks tout “Standard ES6 classes” as a feature — but almost all of them have components as ES6 classes and the ones that don’t support ES6 in other ways. Frameworks routinely call themselves “modern”, often as some sort of comparison to (presumably) AngularJS. But all of these frameworks use modern tools and techniques, again it’s not a point of difference. Or they claim that they’re “component based” for reusability of code. But they all implement components.

I’ve repeatedly seen different frameworks brag that there’s a browser extension that “makes debugging a breeze” unlike other frameworks. They all have one of those.

If you’re going to proclaim benefits of one framework, make sure the benefit is neither a standard feature of every modern framework, nor highly subjective like “easy to learn” or “makes coding fun”.

Every framework needs to be more clear in its comparisons. “Benefits of x” is meaningless without knowing what x is instead of. Many of these frameworks end up stating “features” that are present in all framework, or at the very least not unique. If you can’t come up with legitimate benefits… maybe you should be doing some thinking?

I have seen each of the following touted as a killer feature of one framework or many.

• Components for reusable markup and behaviour
• A Chrome plug-in for debugging
• Virtual DOM
• A CLI tool
• One Way binding
• Two Way binding
• Three Way binding

One of those I just made up but the rest are things people think make a framework stand out in the market place. React is the by far the most notable for this. It’s like React’s peeps think other developers are scratching jQuery on a piece of bark.

I should also point out that purely subjective benefits aren’t any more meaningful. Easy to learn! Great community! Excellent documentation! Every framework (or advocates thereof) claim these things. Backing them up in any meaningful way is harder.

Here’s a fine example: https://www.altexsoft.com/blog/engineering/the-good-and-the-bad-of-reactjs-and-react-native/

Not atypically React based. Literally every benefit listed here is common to every other framework with the exception that AFAIK Aurelia does’t use V-DOM. If these are reasons to use React, does that mean there’s no longer a reason to use React? Ironically, every con is unique to React.

They All Have Merit

Every framework I investigated had features or syntax I found particularly elegant or effective.

Angular’s architecture and developer experience was a genuine joy. Its use of Observables is also a great pattern when you scratch the surface, and it integrates nicely with TypeScript.

Aurelia has the nicest templating system of any of the Angular-style templates, and its router is rich in features and has excellent documentation. It also uses pure ES6 classes as its components — nothing extended.

Ember’s workflow is incredibly powerful, its out-of-the-box experience is full of batteries, and its templating engine is my personal favourite. It has excellent solutions to difficult problems.

Composing up components and markup in React is nice and elegant, and having native JS control structures and iteration is powerful. Redux takes practise but provides excellent organisation and there’s a wealth of mature, disciplined software solutions.

I… this is hard to say but there was literally nothing that impressed me about Vue. I was going to edit this section out entirely just because I couldn’t think of one. But I think that’s an interesting point on its own.

They Also All Have Flaws

Open minded investigation of any framework reveals areas in which it’s weak, or not well optimised.

Angular’s actual templating language is godawful and the resulting DOM summons the Dark God Kardarak if you read it out loud.

Aurelia’s tooling is terribad, and fundamental elements of the framework just didn’t work. Aurelia was the framework I enjoyed working with the least.

Ember struggles to make clear the distinction between routes and controllers as an abstraction. This becomes particularly difficult with best-practice use of components. It’s miles behind the tech curve with native APIs – promises, class components, etc. It’s also still an enormous payload, which has real world implications for mobile, especially.

React’s enthusiastic rejection of the very idea of abstraction and its 12,000 different types of component and ecosystem of gibberish libraries make getting started a nightmare. The Redux pattern creates unacceptable amounts of boilerplate, and Jesus H Fuck, that router.

Vue’s unwillingness to make an informed default has left it with an ecosystem of widely differing interpretations and implementations. The requirement to name your props deliberately wrong is the single dumbest design decision I saw in any framework covered.

I have to say again that I’m looking at different requirements than many people would be. I don’t care what’s the easiest to learn, the most popular, the most hyped, or even the best job prospects. I’m a veteran developer with 20 years experience, my job prospects are fine.

State Matters

One thing I’ve learned in this process is that the real innovations in these frameworks actually lie in their state management patterns and technologies. Reactive bindings and routers are all more or less syntax variations. But things like Ember Data, Redux, and Observables are genuinely innovative and interesting.

Personal Conclusions

Each of these examinations I’ve eliminated options. Previously I was considering Meteor a valid option, but began to see that more as a backend NodeJS framework with a React frontend. Talking about AngularJS also has become irrelevant.

This time there are three “losers”. The least controversial would be Aurelia. Honestly there is little or nothing to recommend it to a modern web developer. I routinely found myself wondering why you’d use this over Angular and even though it had some nice features they didn’t make up for the shit that straight up didn’t work.

The next was Angular. I liked Angular. I genuinely enjoyed working with it and if I was employed at a place that used it I’d jump into it happily. But I fucking hate its template syntax. More to the point, though, I feel like it does much the same as Ember. Or rather, Ember does all the same things only better. There are tons of tools and add ons for Ember that Angular either lacks outright or has only poor implementations of. Backend mocking, for example is natively supported by Angular’s http class but it’s woefully limited compared to Mirage. Angular has a sub domain of instructions for setting up Server Side Rendering, but Ember has a simple command line install. Angular has a very productive command line tool, but it’s literally taken from Ember, which offers even more functionality.

This won’t be a universal view. I don’t begrudge anyone who considers Angular a more useful generally valued solution. Given a different position to myself, especially without a deep knowledge of Ember, I can certainly understand why Angular would have appeal.

Finally, Vue. Vue doesn’t seem to solve any problem that React doesn’t solve better. The React ecosystem is more mature, and its solutions and patterns seem to lead to better emergent architecture. There was honestly nothing significant that impressed me. It more or less works, I guess. IMO both React and Vue have similar issues. While they’re focused around smaller, discrete libraries that necessarily compromises their capability on larger, more comprehensive applications. At least by comparison to tools dedicated to exactly (and only) that.

React and Ember are the two that really stood out for me. And I can’t help thinking of Netflix. I’m literally watching Netflix as I write this, and it’s interesting that the two techs that really work for me are also the choice of Netflix. This provides a great example of the sorts of use cases that work so well for each option. The actual players and client interface is built with React. But for administration, Netflix actually uses Ember extensively.

Both of these frameworks excel in their roles. Ember is exceptional where the API is under your control, and where there is extensive CRUD requirements. It’s particularly well suited to administration interfaces, etc. React is well suited to more esoteric interfaces, especially ones where a lot of requirements are met by a backend framework such as Node, or where there are specific requirements for a mobile native app — an area in which React excels.

A Final Word

This has been an interesting project and I’ve learned loads doing it. I wouldn’t necessarily recommend people do the same - it’s really time-consuming. But I definitely would recommend trying to step out of your comfort zone and learning at least one other framework, just for a small test project.

Try something else. Something new. In particular, if you’re a React developer, try Angular or Ember. Try it with an open mind and find a developer experience and rapid scaffolding that might actually appeal. Correspondingly, if you’re primarily an Ember or Angular developer, try some React. See what it’s like to get closer to the bare metal and kick off the training wheels a little bit.

Something like Mirage is entirely possible in any framework — it mostly just stitches together Pretender and Faker. Angular’s opinionated choice of TypeScript is something other frameworks can benefit from, and Ember seems to be heading that way.

Because the simple fact is it doesn’t have to be all or nothing. React can or could have the developer experience and rapid workflow of Ember. Ember can or could have the flexibility and performance of React. But it has to be something we value first.