5 ms·

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.

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.