Everybody knows React. But what is Hyperdom?
Hyperdom is a virtual dom based framework. It's been first released around 5 years ago and back then was known as Plastiq.
Hyperdom was set out to fix some of the react shortcomings (more on that later) and it has succeeded to do so. The ultimate goal however was to make a tool that we could use to build websites for our clients faster and easier. As a consequence Hyperdom remained in the dark as no attempts to market it were made.
Back then the SPA framework scene was fluctuating without a clear leader. And so we were able to get away with using Hyperdom. That seems to have changed in recent years with React emerging a defacto standard. At least according to what our clients demand (fun fact: 5 years ago they were insisting on Angular 1).
Over the years a strong community built up around React. There is plethora of solid complimentary projects that solve all sorts of problems. To be fair, that alone is a good reason to stick to React. But here is a crazy thing: at its core, React hasn't changed a great deal. The reasons that prompted Hyperdom into existence are still there.
What reasons though? Seriously, why not React? That's probably the most popular Hyperdom related question ever asked. And so I've got it all laid out for you exclusively by Hyperdom creator - Tim Macfarlane.
Below is an excerpt from a chat that took place around 2 years ago where Tim gives his answer to a another developer (all names are changed, company is called The Company, project is called The Project, etc.). If that's bit of a long read, you can skip down to tldr
_Ok, I bet this comes up pretty often, and I’m sort of surprised this is the first time somebody has genuinely asked this question, out loud and directly to The Team.
Probably two different answers to that question. First answer is pretty straightforward: it’s just faster than React. There are other libraries that are again faster than Hyperdom, but they didn’t exist at the time we chose Hyperdom - and it’s not clear that moving to those faster frameworks would be ideal in terms of dev productivity.
The second, more significant, and more complicated answer lies in the way React does application state management, or doesn’t as it turns out, and why React+Redux was born which is in many ways a different beast. Here we need to understand and compare how Hyperdom, React and React+Redux do application state management - because that’s basically what you’ll be spending most of your time on when building UIs. With a front-end application the size of The Project, I’m pretty confident in saying that we’ve saved a significant amount of dev time in not using React, or React+Redux - and I’m happy to explain this in more detail.
Other than that there are some other things to point out, firstly, React wasn’t nearly as big a thing 2 years back than it is today. I say this because back then people were asking us why it wasn’t in Angular! But suffice to say that the context of the decision has changed pretty significantly in the last two years, I think we’d still make the same decision, but it’s also true that there’s a lot more out there to research than there was 2 years ago so I don’t know for sure. It’s hard to be certain of any framework decision these days, especially in Javascript world - things just move extremely fast, and you need to stay flexible, which brings me to my final point:
We actually started Booking Engine in Angular 1. The strongest thing we took from that first version were the automated UI tests, which were extremely fast (they still are) and framework agnostic. They allowed us to port the UX over to another UI framework relatively easily (i say relatively..!) while being confident we hadn’t changed or broken any UX. My point here being, that we’re well placed to port BE to another framework if there were any compelling reasons to do that. We’re not locked into using Hyperdom!
Right now however, of all the things that are keeping us awake at night, Hyperdom (or the UX in general) is not one of them. People just get on, they’re able to make UX changes reasonably easily without much disruption (or many WTFs), so it hasn’t ever become a major source of headaches on the team. It may be a bone of contention in terms of hiring new staff, as we’re not easily able to say that they’ll be working on an awesome React app, but frankly, if React is all people want to work with, they’ll quickly realise that it’s only a very small part of what we’re trying to do here. _
_Tim Macfarlane [12 h 26]
Coming back to performance just for a second - it’s not necessarily performance for users we’re concerned with (although we like to think we take that seriously too), it’s really the automated test performance that matters for us as it has a direct correlation with dev productivity. _
_Dave [12 h 57]
@tim thanks for the quite a detailed explanation. Just a few things as a followup:
\1) When you say Hyperdom is faster than React, was any performance bench marking done to prove this? And do you still have the numbers?
2) What do you think are the drawbacks of having chosen Hyperdom over React?
3) One problem which is common in home-grown frameworks/libraries etc (at least what I have seen) and you kind of mentioned it as well in your explanation is how a framework/library with much bigger user base naturally matures/improves over time. As you mentioned above React now is much bigger and probably much better than what it was 2 years back. In the same two years what has changed in Hyperdom? What I have seen is home-grown frameworks start on a very strong note filling in lot of gaps which available open source frameworks don't provide. But over time open source frameworks catch up and probably become even better but the in house one kind of stays where it was originally. And this is because the developer(s) who created them get busy with other stuff and probably have different priorities than improving the thing they created, the feedback on what can be improved only comes from a smaller user base etc.
Probably one of the question here is that in future if we face a similar situation what should be direction we should choose _
Tim Macfarlane [13 h]
performance: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html. You need to look at plastiq performance, as this was taken before hyperdom rename.
_in terms of drawbacks: perhaps that we could have used more off-the-shelf components for things from the React world, date pickers for e.g., but frankly are a very small part of the whole UX, that we'd have a slightly faster warm up period with new devs familiar with React.
3rd point is interesting in two years most of the development towards hyperdom has been in fixing minor bugs and performance improvements, nothing significant. that being said however, the client-side routing has seen some significant changes. _
_React has of course changed externally, quite significantly, in terms of community and sister projects, etc. Internally I'd counter that it's evolution has been quite conservative, it's essentially the same beast as it was 2 years ago - and crucially from our perspective - it has the same application state issues. Architecturally speaking, React hasn't changed a great deal. _
in two years most of the development towards hyperdom has been in fixing minor bugs and performance improvements, nothing significant. that being said however, the client-side routing has seen some significant changes.
_Actually I tell a lie, there were some changes we made to make general application architecture a lot easier. which was a bit of a departure from the original plastiq in 2015.
I'm sort of much more interested in what's happening in the world of Vue.js and perhaps even Angular 4 (!) _
_Tim Macfarlane [13 h 24]
but, yes @piyush i do agree, there's a tendency for these lesser known projects to stall as they solve their immediate problems, and meanwhile for other projects to grow and mature. I think to this i'd want to go back to my point above, which is, if hyperdom is indeed behind in any way, and there are obvious advantages to replacing it then we'd be all for it - our project would be fairly unique in TTC in making that a relatively painless experience. _
_Tim Macfarlane [13 h 28]
probably also worth pointing out that frameworks like these are in constant flux, being replaced, superceded, rewritten, rebranded. It's certainly not exclusive to Hyperdom vs React that we find ourselves faced with this problem of which framework we should use, should we rewrite, etc... _
_i.e. we use express on the backend, but could we have used Hapi, or Koa? yeah, definitely. Is express causing us all kinds of problems? not really. _
_Dave [13 h 30]
@tim I will put the explanations provided by you here, into a wiki page. So that next time when someone has this question, he/she can start from somewhere and you don't have to write it all over again :) _
_Tim Macfarlane [13 h 30]
lol, thanks @dave! _
_Dave [13 h 32]
Just lastly, may be for people who have worked with React or who are starting with React and see Hyperdom, since they are somewhat similar i.e. both use components as an example, this question arises that why Hyperdom and why not React. _
Tim Macfarlane [13 h 41]
right, so might be worth adding a tiny explainer here: React components have a lifetime that corresponds to their visibility on screen - from when they're first visible to when they're removed from screen. In Hyperdom, components have a lifetime that is managed entirely by the app, visible or not. Might not be obvious when you first look at them, but it's significant to the way you reason and develop your app.
this is the application state issue mentioned above, and is why flux/redux exists to solve it - albeit with a lot of additional architectural overhead and complexity
Compared to React, Hyperdom:
- does not require any state management beyond regular javascript
- is fast
- has a built-in router
- has input bindings
- has a small, concise API
- is 9k gzipped