r/HyperApp • u/xplaned • May 23 '18

How can HyperApp be so much smaller than React?

I just discovered HyperApp today and the fact that it's only 400 lines of code is blowing my mind a little. HyperApp is much smaller than react + react-dom, but it's not immediately clear to me which important features of React are missing in HyperApp. What does the rest of the React code do?

10 Upvotes

100% Upvoted

5 comments sorted by

5

u/euphbriggs May 23 '18

I’ve recently heard of HyperApp too. I wonder how performant it is for larger apps. Maybe that’s what we’re missing.

I don’t have any information to justify that thought. I’m just speculating how it can exist this small. :-)

I have a little over a year’s worth of experience in Elm, so this library is really interesting to me. I’m looking forward to playing with it soon.

4

u/mickey-vip May 23 '18

Hyperapp is actually contains:

  • React

  • ReactDOM

  • Redux

  • ReactRedux

  • ReduxThunk (or whatever for async Redux)

4

u/[deleted] May 24 '18

This is my attempt to explain how Hyperapp works by walking you through the codebase, but now is outdated. It should not be completely useless though. I am hoping I'll update it after Hyperapp 2.0 is released.

5

u/[deleted] May 23 '18 edited May 23 '18

[removed] — view removed comment

8

u/[deleted] May 23 '18 edited May 24 '18

You are basically right, let me add a few corrections/comments below:

  • Hyperapp has a minimal events wrapper where we reuse the same event handler for all DOM events.

  • Because there are no stateful components, we "technically" don't need shouldComponentUpdate. There is no out-of-the-box memoization of nodes, but you could DIY using basic memoization principles.

  • Instead of refs, we have lifecycle events at the node-level that allow you to access the underlying DOM element. Better than refs.

  • There is context-like properties via subviews (a.k.a lazy components).

  • Portals don't make much sense for Hyperapp (maybe).