Hacker News Reader

Comment by laszlokorte | Hacker News Reader

What I did for a mobile web app I built last year after the react prototype was to slow on old devices:

- Render all pages/routes/states into a single html file (size ~2mb) but each page/component/state hidden via style=display:none;.

- then write some hand crafted js (few hundred lines) to add event listeners to forms and show/hide the components depending on url change

- cache everything via appcache/serviceworker

- result: not so fast initial load (1-2 seconds) but really fast interaction afterwards even on old lowend devices, almost no time spent running js/react/vdom. even some scrolbugs I had to work round before when using react (eg replacing dom nodes but keeping scroll position of a parent container) resolved on their own.

View on HN

2mb html file, + whatever else for initial load?

That's only 1-2 seconds on a fast connection.

If you have zero of that content cached locally and are on a mobile or just not-fast connection it'll be way more than 1-2 seconds.

Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.

> 2mb html file, + whatever else for initial load?

nothing else because all images are already inlined as svg as well as all styles and the mentioned js code

> Your "solution" is one of the ones responsible for locking up mobile browsers all over the place, because the browser still has to deal with the entire DOM, and it's often done way inefficiently.

I only came up with doing it this way after previously having build the same app using react and old devices (eg android pre chrome) could not handle all the vdom diffing and add/removeNode.

Our users preferred a slightly longer initial load (even 10 seconds) and lightning fast interactions afterwards over fast initial load and sluggish UI for all the time using the app.

When doing client sit rendering you would still have to transfer and parse little chunks of json all the time.

As it turns out browsers are really good at handling even huges DOMs as long as you do not manipulate it to much.

Granted this way only works if you have a limited set of states/pages (eg a few thousand).

> built last year after the react prototype was to slow on old devices:

Do you have a public implementation available for review? I'm having trouble understanding why this would be the case (I am pretty familiar with React's implementation).

>Render all pages/routes/states into a single html file (size ~2mb)

That's not good at all for mobile web pages.

This is one page/app I built that way [0]. In this particular case it's not even fully optimized (eg js and css not minified, loads some external images...)

[0] https://app.ishl.eu/

Took 4 seconds to load on mobile. But after that, the navigation was lightning-fast. Not bad.

Nice site. I don't think the entire card should be clickable to collapse, though, in case you just want to select some text.

Thank you, that's a good suggestion. I have changed that.

This is the worst approach I've ever read about.

why? It solved all the probles the previous implementations had and was even easier to implement.

Reply on news.ycombinator.com