Hyperapp: V2 Router support

[johnhorsema]

After googling for the past 3 hours, I do not see a plug-and-play solution to implement routing in Hyperapp with history.

I tried to use Universal Router but no example exist for Universal Router + Hyperapp...

[loteoo]

If you have very loose requirements you could have a look at hyperstatic, but keep in mind it's still pretty early in it's development.

[johnhorsema]

If you have very loose requirements you could have a look at hyperstatic, but keep in mind it's still pretty early in it's development.

Thanks @loteoo! hyperstatic seem like a very cool project! How much faster is it compared to React or Vue?

[loteoo]

Hyperstatic is just tools around hyperapp, so it's like hyperapp in terms of performance.

[jorgebucaran]

@johnhorsema Hyperapp is faster than Vue and React.

[jaeh]

hyperstatic looks interesting, will look at the code splitting especially ;)

i have spent quite some time thinking about this stuff and done some testing whilst building the babel tasks to bundle a generated hyperapp app.

@magic is the result and a quite comprehensive (~40 npm packages now, each with docs generated by @magic.) ecosystem for smallish pages (less than ~50 pages total).

what i learned:
hyperapp is tiny.
the code @magic generates is tiny (could be smaller though, it's ~15kb html+css+js boilerplate).

the user will not notice the load of some (smallish) javascript if the html is static.
but the user will notice the loadtime of the split bundles, every time a link gets clicked.

even if the user notices the load of initial js,
then the effect of loading a split off bundle will be even worse,
because once a connection is established, downloads are always quicker than connection establishment (esp. on phone networks).

if the user clicks a link before javascript routing can take over,
the link will load the html file without client side routing,
but as soon as the html file is loaded, the javascript will be cached from the first page load.

one phone http request for a js file can take 300ms just negotiating, before download even starts.

as an example, the @magic core docs:
@magic core docs
load 50kb of javascript. after decompression.
this includes all the page contents for client side routing.
even phones decompress and jit 50kb relatively quickly.
oh, and the page actually loads 18kb because gzip.

btw, this inspired: https://github.com/magic/core/issues/95, which will solve big library imports in @magic sometime in the near future.