How we react - Hooks

Hello everyone,

yesterday i was reading about react-hooks. To be honest, i don´t grok the concept (yet), but since they seem to cause a bit of hype, i would like to know, if that´s a concept one could pick up for developing with aurelia / if we do already have s.t. like hooks with aurelia?

I find myself doing stuff in the attached-lifecycle-hook, that could be seperated and possibly re-used in other components (e.g. binding drag- & drop-handlers). How would you do that, via mixins maybe?

Hoping that i could spark the interest of someone smarter than me. :wink:



I’ll take the bait :rofl:

I’ve looked extensively at hooks, including trying them out in real applications that I’ve worked on and I have to let you know that I think they are going to cause so many problems for React apps (and Vue, who pretty much copies whatever React is doing).

Yes, there is a ton of hype. There’s more hype in the JavaScript community than I’ve ever seen in any community or around any technology in my entire career. It’s outrageous and unhealthy. My best advice would be to focus instead on demonstrated designs, practices, etc. that are published in books and journals, which have stood the test of time for multiple decades. Pay more attention to people who have some real experience behind them, and not so much to some of the framework authors who have less than 10yrs under their belt (and some of whom don’t appear to have shipped a real app ever). It’s the blind leading the blind out there.

With Aurelia, we don’t need hooks because we have three very powerful things:

  • Observability
  • Dependency Injection
  • Metaprogramming

There are more, but these are things we have, which have been around for decades, and which neither React nor Vue has in full.

React can’t actually observe arbitrary objects. So, as a result, it needs to be told when to update through calling explicit APIs (e.g. setState). In the real world, this turns out to be completely untenable. So, the React community came up with Flux and various libraries like Redux. Of course, Redux forces you to centralize all your state and magnifies the amount of work you have to do to accomplish the most basic of scenarios. This causes issues of complexity, lack of modularization in the code, debugging challenges, and so much more. So, then the React community moved on to Hooks as its 3rd attempt. Hooks are difficult to understand and they force you to pull all normal logic out of encapsulated object boundaries, as all state must be modeled with hooks, or it doesn’t really work. So, complexity, intrusiveness, etc. There’s also some questionable performance characteristics (actually, all of these techniques have perf issues) and other items of debate even within their community.

With Aurelia, we can observe normal objects/class properties. So, you can leverage the last 40ish years of OOP techniques and battle-tested approaches to building software. Also, the general observer pattern has been around for a very long time and has scaled to some of the most complex apps today.

Vue has observability too, but can’t observe as many edge cases as Aurelia (for example, it can’t observe Set and Map). However, taking those shortcomings aside, Vue doesn’t have dependency injection and it utilizes a custom non-standard way to create objects. As a result, as a Vue app tends to grow larger, it gets more and more spaghetti-like. It’s hard to properly modularize and compose the objects. One has to result to globals and other strange hacks to simulate a DI-like functionality. They are looking to hooks to solve this issue for them, but it’s not going to end well.

On the other hand, Aurelia has a very powerful DI framework. This lets you decompose any problem into small pieces that work together to tackle something complex. Need to make something reusblabe? Just factor it out into a new class and inject it wherever you need. That’s a basic form of composition that works very well, with decades of history behind it.

None of the frameworks have metaprogramming capabilities like Aurelia. In Aurelia’s case, you can apply a decorator to a class, and the framework will use your declaration to “write” code for you, so you don’t have to. We take this further with conventions. So, you can write vanilla js, following a simple pattern, and Aurelia will write code for you to make things into custom elements, etc. Again, this sort of technique goes way, way back. When you combine it with observability and DI, some magical things happen. You get plain objects and classes that you can model in whatever way makes sense for your app, based on 40ish years of solid practices, and the framework can just make those into components (metaprogramming) that interoperate with one another (DI), and can reflect their state to the view automatically (observability).

To sum up, don’t let hype get the better of you. It’s good to keep tabs on what’s going on, but root yourself in practices that have stood the test of time and have been proven over multiple decades to work for small, medium, large, and gigantic-scale apps and teams. Aurelia chooses a specific set of approaches based on my 15+ years of UI engineering focus, working on apps of every size and in almost every industry. I have yet to come across a scenario where these few basic concepts didn’t get the job done, and with great extensibility, testability, etc.

Always keep learning new things, but don’t forget what you’ve already learned and what you know works. A lot of time in our industry has been spent fixing things that aren’t broken, in search of some hyped tech revolution. I prefer a more iterative approach of slowly evolving and refining things over time that I’ve seen work. Hopefully, you can experience some of that through Aurelia.


Donnerwetter, I didn’t expect my bait to attract the big fish. :grinning:

Thank you very much for the personal and thorough answer and elaborating on the differences between Aurelia and other frameworks! I’ve read it quite a few times and pondered on what you said.

Absolutely, I :heart: working with Aurelia everyday.


I couldn’t agree more. But I also feel that the hype makes this really difficult. I feel like if I don’t jump into the hype, I’ll become outdated. I try to fight (at least only for my own sanity).

And it’s one of the reason I feel to at ease with Aurelia. Most of the time I don’t feel like I’m writing code for a framework but just writing JS code following good OOP practices. And that feels good and empowering!


There’s nothing preventing you from jumping on the hype and see what it’s all about. You don’t have to stay there :slight_smile:


I feel like if I don’t jump into the hype, I’ll become outdated.

That’s why we seek for self-believe. If you are confident with your technical taste, then there is no fun to be a follower. Everything out there was designed by someone no smarter than you.


The difficulty is: when the hype is huge, I find it hard to doubt :wink:

1 Like

The problem with HDD (hype driven development) is not unique to Frontend but it has manifested quite differently. If it where all about hype on the backend side of things nobody would use Java anymore. Nobody would do low-level in C/C++ and everybody would leave Postgres/MySQL on the DB side of things. Except, this simply didnt happen. By all means those mentioned samples arent really what youd call a sexy technology. But they get their job done reportedly for decades. The issue with Frontend though is that there are rarely tools out l there mature enough. So what we learn is that mature is not sexy but does the job well. So that might explain why there is a lot noise about some and less about other solutions :wink:


I get your point, but speaking of Java…I really think it’s about time for Java to retire and let Kotlin take over. :slight_smile:

1 Like

Couldnt agree more :wink: but most likely I’d go straight away to Node or C# .net core

1 Like

I had the same feelings six years ago, when I just started learning web development; but I realized and still think that all of these libraries and frameworks are sharing fundamental concepts, patterns, and architectures so switching between them should not be of any problem; that’s why I always stick to the one I think will ease the path to a better software, and I will reason about my choice. I’d rather to invest on learning fundamentals of software development rather than moving around with the hype.


It’s generally the best attitude yes and I’m trying to do that too :wink:


I’ve found that there is typically a reason for all the hype. Buried deep down somewhere in all the hubbub there is a reason why something caught on. This reason is usually a pretty good one. If these fads weren’t good at something, they wouldn’t appeal to the masses. Occasionally it boils down to pure coincidence: the right person gets the right message from the wrong thing at the right time and somehow manages to influence a wave of unquestioning zealots; but this is a rare occurrence.

These things have a place, but “place” is very specific. In the case of front-end frameworks, each of them have strengths and weaknesses of course that could lend themselves better to solving a particular problem in an application but there is more.

Place includes the team (or person) using it: culture, experience, talent availability, and that certain patterns seem to “click” better for some than others. Other factors like community and the availability of libraries or samples that fit your needs play big roles. In the past I’ve chosen a framework for a specific application just to use a library I found that solves the core problem of the application particularly well.

tl;dr - There are a lot of potential reasons to use any technology. It is up to you to sift through the noise to find the best tool for the job and the team. Before you know it you get to a point where learning new things is trivial and the “best tool” might change for every other project or team.