9 ms·

We design for slow internet, react is one of the better options for it with ssr, code splitting and http2 push, mixed in with more off-line friendly clients lik

by devjab 2y ago

We design for slow internet, react is one of the better options for it with ssr, code splitting and http2 push, mixed in with more off-line friendly clients like Tauri. You can also deploy very near people if you work “on the edge”. I’m not necessarily disagreeing with your overall point, but modern JS is actually rather good at dealing with slow internet for server-client “applications”. It’s not necessarily easy to do, and there is almost no online resources that you can base your projects on if you’re a Google/GPT programmer. Part of this is because of the ocean of terrible JS resources online, but a big part of it is also that the organisations which work like this aren’t sharing. We have 0 public resources for the way we work as an example, because why would we hand that info to our competition?

jiggawatts 2y ago
By far the lightest weight JS framework isn't React, it's no javascript at all. I regularly talk to developers who aren't even aware that this is an option.
- arp242 2y ago
  When used well, JS will improve the experience especially for high-latency low bandwidth users. Not doing full page refreshes for example, or not loading all data at once. So no, "no JS at all" is not "by far the lightest weight" in many cases. This is just uncritically repeating dogma. Even 5K to 20K of JS can significantly increase performance.
  - malinens 2y ago
    I always ask people to give example of real world SPAs where JS is "used well" and nobody could give me an example
    - arp242 2y ago
      FastMail is pretty good; that's my go-to example. However, you don't need to go full SPA. "No JS at all" and "SPA" are not the only options that exist. See my other comment: https://news.ycombinator.com/item?id=40541555 https://news.ycombinator.com/item?id=40541555 Sites like Hacker News, Stack Overflow, old.reddit.com, and many more greatly benefit from JS. I made GoatCounter tons faster with JS as well: rendering 8 charts on the server can be slow. It uses a "hybrid approach" where it renders only the first one on the server, sends the HTML, and then sends the rest later over a websocket. That gives the best of both: fast initial load without too much waiting, and most of the time you don't even notice the rest loads later.
- j45 2y ago
  Very true, Javascript was never meant to be mandatory for web pages. Two of the lighter options right now though seem to be things like alpinejs, htmx, etc. Basic building blocks where / if needed.
- mike_hearn 2y ago
  If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.
  - rightbyte 2y ago
    Loading an entire page with cached pictures is more or less instant, connection wise, though.
  - bayindirh 2y ago
    However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.
    - mwcampbell 2y ago
      False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.
      - SpaceNugget 2y ago
        Well, in TFA, if you re-read the section labeled "Detailed, Real-world Example" yes, that is exactly what the person was encountering. So no hyperbole at all actually.
      - bayindirh 2y ago
        I just tried some websites: - https://web.whatsapp.com 11.12MB compressed / 26.17MB real. - https://www.arstechnica.com 8.82MB compressed / 16.92MB real. - httsp://www.reddit.com 2.33MB compressed / 5.22 MB real. - https://www.trello.com (logged in) 2.50MB compressed / 10.40MB real. - https://www.notion.so (logged out) 5.20MB compressed / 11.65MB real. - https://www.notion.so (logged in) 19.21MB compressed / 34.97MB real.
- nicoburns 2y ago
  In my experience page weight isn't usually the biggest issue. On unreliable connections you'll often get decent bandwidth when you can get through. It's applications that expect to be able to multiple HTTP requests sequentially and don't deal well with some succeeding and failing (or just network failures in general) that are the most problematic. If I can retry a failed a network request that's fine. If I have to restart the entire flow when I get a failure that's unusable.
- miki123211 2y ago
  No JS can actually increase roundtrips in some cases, and that's a problem if you're latency-bound and not necessarily speed-bound. Imagine a Reddit or HN style UI with upvote and downvote buttons on each comment. If you have no JS, you have to reload the page every time one of the buttons is clicked. This takes a lot of time and a lot of packets. If you have an offline-first SPA, you can queue the upvotes up and send them to the server when possible, with no impact on the UI. If you do this well, you can even make them survive prolonged internet dropouts (think being on a subway). Just save all incomplete voting actions to local storage, and then try re-submmitting them when you get internet access.
chiefalchemist 2y ago
It's not always the application itself per se. It's the various / numerour marketing, analytics or (sometimes) ad-serving scripts. These third party vendors aren't often performance minded. They could be. They should be.
- FridgeSeal 2y ago
  And the insistence on pushing everything into JS instead of just serving the content. So you’ve got to wait for the skeleton to dl, then the JS, which’ll take its sweet time, just to then(usually blindly) make half a dozen _more_requests back out, to grab JSON, which it’ll then convert into html and eventually show you. Eventually.
  - chiefalchemist 2y ago
    Yup. There's definitely too much unnecessary complexity in tech and too much over-design in presentation. Applications, I understand. Interactions and experience can get complicated and nuanced. But serving plain ol' content? To a small screen? Why has that been made into rocket science?
  - LtWorf 2y ago
    Well grabbing json isn't that bad. I made a CLI for ultimateguitar (https://packages.debian.org/sid/ultimateultimateguitar https://packages.debian.org/sid/ultimateultimateguitar) that works by grabbing the json :D
    - chiefalchemist 2y ago
      I've not so much good vs not so bad vs bad. It's more necessary vs unnecessary. There's also "just because you can, doesn't mean you should."
matthews2 2y ago
HTTP/2 push is super dead: https://evertpot.com/http-2-push-is-dead/ https://evertpot.com/http-2-push-is-dead/
- collinmanderson 2y ago
  Very sad. I use http/2 push on my website to push the CSS if there’s no same-origin referrer. It saves a full roundtrip which can be pretty significant on high latency connections. The html+css is less than 14kb so it can all be sent on the first roundtrip as it’s generally within TCP’s initial congestion window of about 10*1400. The only other alternative is to send the CSS inline, but that doesn’t work as well for caching for future page loads. 103 Early Hints is not nearly as useful as it doesn’t actually save a round trip. It only works around long request processing time on the server. Also, most web frameworks will have a very hard time supporting early hints, because it doesn’t fit in the normal request->response cycle, so I doubt it’s going get much adoption. Also it would be nice to be able to somehow push 30x redirects to avoid more round trips.

by devjab 2y ago

jiggawatts 2y ago

By far the lightest weight JS framework isn't React, it's no javascript at all. I regularly talk to developers who aren't even aware that this is an option.

arp242 2y ago
When used well, JS will improve the experience especially for high-latency low bandwidth users. Not doing full page refreshes for example, or not loading all data at once. So no, "no JS at all" is not "by far the lightest weight" in many cases. This is just uncritically repeating dogma. Even 5K to 20K of JS can significantly increase performance.
- malinens 2y ago
  I always ask people to give example of real world SPAs where JS is "used well" and nobody could give me an example
  - arp242 2y ago
    FastMail is pretty good; that's my go-to example. However, you don't need to go full SPA. "No JS at all" and "SPA" are not the only options that exist. See my other comment: https://news.ycombinator.com/item?id=40541555 https://news.ycombinator.com/item?id=40541555 Sites like Hacker News, Stack Overflow, old.reddit.com, and many more greatly benefit from JS. I made GoatCounter tons faster with JS as well: rendering 8 charts on the server can be slow. It uses a "hybrid approach" where it renders only the first one on the server, sends the HTML, and then sends the rest later over a websocket. That gives the best of both: fast initial load without too much waiting, and most of the time you don't even notice the rest loads later.
j45 2y ago
Very true, Javascript was never meant to be mandatory for web pages. Two of the lighter options right now though seem to be things like alpinejs, htmx, etc. Basic building blocks where / if needed.
mike_hearn 2y ago
If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.
- rightbyte 2y ago
  Loading an entire page with cached pictures is more or less instant, connection wise, though.
- bayindirh 2y ago
  However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.
  - mwcampbell 2y ago
    False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.
    - SpaceNugget 2y ago
      Well, in TFA, if you re-read the section labeled "Detailed, Real-world Example" yes, that is exactly what the person was encountering. So no hyperbole at all actually.
    - bayindirh 2y ago
      I just tried some websites: - https://web.whatsapp.com 11.12MB compressed / 26.17MB real. - https://www.arstechnica.com 8.82MB compressed / 16.92MB real. - httsp://www.reddit.com 2.33MB compressed / 5.22 MB real. - https://www.trello.com (logged in) 2.50MB compressed / 10.40MB real. - https://www.notion.so (logged out) 5.20MB compressed / 11.65MB real. - https://www.notion.so (logged in) 19.21MB compressed / 34.97MB real.
nicoburns 2y ago
In my experience page weight isn't usually the biggest issue. On unreliable connections you'll often get decent bandwidth when you can get through. It's applications that expect to be able to multiple HTTP requests sequentially and don't deal well with some succeeding and failing (or just network failures in general) that are the most problematic. If I can retry a failed a network request that's fine. If I have to restart the entire flow when I get a failure that's unusable.
miki123211 2y ago
No JS can actually increase roundtrips in some cases, and that's a problem if you're latency-bound and not necessarily speed-bound. Imagine a Reddit or HN style UI with upvote and downvote buttons on each comment. If you have no JS, you have to reload the page every time one of the buttons is clicked. This takes a lot of time and a lot of packets. If you have an offline-first SPA, you can queue the upvotes up and send them to the server when possible, with no impact on the UI. If you do this well, you can even make them survive prolonged internet dropouts (think being on a subway). Just save all incomplete voting actions to local storage, and then try re-submmitting them when you get internet access.

chiefalchemist 2y ago

It's not always the application itself per se. It's the various / numerour marketing, analytics or (sometimes) ad-serving scripts. These third party vendors aren't often performance minded. They could be. They should be.

FridgeSeal 2y ago
And the insistence on pushing everything into JS instead of just serving the content. So you’ve got to wait for the skeleton to dl, then the JS, which’ll take its sweet time, just to then(usually blindly) make half a dozen _more_requests back out, to grab JSON, which it’ll then convert into html and eventually show you. Eventually.
- chiefalchemist 2y ago
  Yup. There's definitely too much unnecessary complexity in tech and too much over-design in presentation. Applications, I understand. Interactions and experience can get complicated and nuanced. But serving plain ol' content? To a small screen? Why has that been made into rocket science?
- LtWorf 2y ago
  Well grabbing json isn't that bad. I made a CLI for ultimateguitar (https://packages.debian.org/sid/ultimateultimateguitar https://packages.debian.org/sid/ultimateultimateguitar) that works by grabbing the json :D
  - chiefalchemist 2y ago
    I've not so much good vs not so bad vs bad. It's more necessary vs unnecessary. There's also "just because you can, doesn't mean you should."

matthews2 2y ago

HTTP/2 push is super dead: https://evertpot.com/http-2-push-is-dead/ https://evertpot.com/http-2-push-is-dead/

collinmanderson 2y ago
Very sad. I use http/2 push on my website to push the CSS if there’s no same-origin referrer. It saves a full roundtrip which can be pretty significant on high latency connections. The html+css is less than 14kb so it can all be sent on the first roundtrip as it’s generally within TCP’s initial congestion window of about 10*1400. The only other alternative is to send the CSS inline, but that doesn’t work as well for caching for future page loads. 103 Early Hints is not nearly as useful as it doesn’t actually save a round trip. It only works around long request processing time on the server. Also, most web frameworks will have a very hard time supporting early hints, because it doesn’t fit in the normal request->response cycle, so I doubt it’s going get much adoption. Also it would be nice to be able to somehow push 30x redirects to avoid more round trips.