4 ms·

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 fil

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.

arcticwombat 8y ago
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.
- laszlokorte 8y ago
  > 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).
kadendogthing 8y ago
> 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.
- laszlokorte 8y ago
  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/ https://app.ishl.eu/
  - hu3 8y ago
    Took 4 seconds to load on mobile. But after that, the navigation was lightning-fast. Not bad.
  - Raphael 8y ago
    Nice site. I don't think the entire card should be clickable to collapse, though, in case you just want to select some text.
    - laszlokorte 8y ago
      Thank you, that's a good suggestion. I have changed that.
k__ 8y ago
This is the worst approach I've ever read about.
- laszlokorte 8y ago
  why? It solved all the probles the previous implementations had and was even easier to implement.

arcticwombat 8y ago

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.

laszlokorte 8y ago
> 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).

kadendogthing 8y ago

> 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.

laszlokorte 8y ago
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/ https://app.ishl.eu/
- hu3 8y ago
  Took 4 seconds to load on mobile. But after that, the navigation was lightning-fast. Not bad.
- Raphael 8y ago
  Nice site. I don't think the entire card should be clickable to collapse, though, in case you just want to select some text.
  - laszlokorte 8y ago
    Thank you, that's a good suggestion. I have changed that.

k__ 8y ago

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

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