4 ms·

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 m

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.
  - tecleandor 2y ago
    Well, I'm working right now so let me check our daily "productivity" sites (with an adblocker installed): - Google Mail: Inbox is ~18MB (~6MB Compressed). Of that, 2.5MB is CSS (!) and the rest is mostly JS - Google Calendar: 30% lower, but more or less the same proportions - Confluence: Home is ~32MB (~5MB Comp.). There's easily 20MB of Javascript and at least 5MB of JSON. - Jira: Home is ~35MB (~7MB compressed). I see more than 25MB of Javascript - Google Cloud Console: 30MB (~7MB Comp.). I see at least 16MB of JS - AWS Console: 18MB (~4MB Comp.). I think it's at least 12MB of JS - New Relic: 14MB (~3MB Comp.). 11MB of JS. This is funny because even being way more data heavy than the rest, its weight is way lower. - Wiz: 23MB (~6MB Comp.) 10MB of JS and 10MB of CSS - Slack: 60MB (~13MB Compressed). Of that, 48MB of JS. No joke.
    - tonyhart7 2y ago
      too much crap holy and this is worse case scenario with adblock
    - jerf 2y ago
      I sometimes wish I could spare the time just to tear into something like that Slack number and figure out what it is all doing in there. Javascript should even generally be fairly efficient in terms of bytes/capability. Run a basic minimizer on it and compress it and you should be looking at something approaching optimal for what is being done. For instance, a variable reference can amortize down to less than one byte, unlike compiled code where it ends up 8 bytes (64 bits) at the drop of a hat. Imagine how much assembler "a.b=c.d(e)" can compile into to, in what is likely represented in less compressed space than a single 64-bit integer in a compiled language. Yet it still seems like we need 3 megabytes of minified, compressed Javascript on the modern web just to clear our throats. It's kind of bizarre, really.
      - LtWorf 2y ago
        js developers had this idea of "1 function = 1 library" for a really long time, and "NEVER REIMPLEMENT ANYTHING". So they will go and import a library instead of writing a 5 line function, because that's somehow more maintainable in their mind. Then of course every library is allowed to pin its own dependencies. So you can have 15 different versions of the same thing, so they can change API at will. I poked around some electron applications. I've found .h files from openssl, executables for other operating systems, megabytes of large image files that were for some example webpage, in the documentation of one project. They literally have no idea what's in there at all.
  - b3orn 2y ago
    I'm getting almost 2MB (5MB uncompressed) just for a google search.
  - ezequiel-garzon 2y ago
    I agree with adding very little JavaScript, say 1kB https://instant.page/ https://instant.page/ to make it snappier.
- andrepd 2y ago
  Yes. It's inexcusable that text and images and video pulls in megabytes of dependencies from dozens of domains. It's wasteful on every front: network, battery, and it's also SLOW.
  - LtWorf 2y ago
    The crap is that even themes for static site generators like mkdocs link resources from cloudflare rather than including them in the theme. For typedload I've had to use wget+sed to get rid of that crap after recompiling the website. https://codeberg.org/ltworf/typedload/src/branch/master/Makefile#L132-L139 https://codeberg.org/ltworf/typedload/src/branch/master/Make...
- RGamma 2y ago
  Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...
  - pgraf 2y ago
    Shouldn’t HTTP compression reap most of the benefits of this approach for bigger pages?
  - chris_pie 2y ago
    Check this proposal out: https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
  - jiggawatts 2y ago
    The generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image is only 23.7 megabytes. At some point you might be better off doing "server side rendering" with a GPU instead of sending more JavaScript!
    - RGamma 2y ago
      Soo.. there should be a standardized web API for page content. And suddenly... gopher (with embedded media/widgets).
    - Lex-2008 2y ago
      > "server side rendering" with a GPU instead of sending more JavaScript Some 7~10 years ago I remember I saw somewhere (maybe here on HN) a website which did exactly this: you gave it an URL - it downloaded a webpage with all its resources, rendered and screenshot'ed it (probably in headless Chrome or something), and compared size of png screenshot versus size of webpage with all its resources. For many popular websites, png screenshot of a page indeed was several times less than webpage itself!
- mike_hearn 2y ago
  Yeah, but your blog is not a full featured chat system with integrated audio and video calling, strapped on top of a document format. There are a few architectural/policy problems in web browsers that cause this kind of expansion: 1. Browsers can update large binaries asynchronously (=instant from the user's perspective) but this feature is only very recently available to web apps via obscure caching headers and most people don't know it exists yet/frameworks don't use it. 2. Large download sizes tend to come from frameworks that are featureful and thus widely used. Browsers could allow them to be cached but don't because they're over-aggressive at shutting down theoretical privacy problems, i.e. the browser is afraid that if one site learns you used another site that uses React, that's a privacy leak. A reasonable solution would be to let HTTP responses opt in to being put in the global cache rather than a partitioned cache, that way sites could share frameworks and they'd stay hot in the cache and not have to be downloaded. But browsers compete to satisfy a very noisy minority of people obsessed with "privacy" in the abstract, and don't want to do anything that could kick up a fuss. So every site gets a partitioned cache and things are slow. 3. Browsers often ignore trends in web development. React style vdom diffing could be offered by browsers themselves, where it'd be faster and shipped with browser updates, but it isn't so lots of websites ship it themselves over and over. I think the SCIter embedded browser actually does do this. CSS is a very inefficient way to represent styling logic which is why web devs write dialects like sass that are more compact, but browsers don't adopt it. I think at some pretty foundational level the way this stuff works architecturally is wrong. The web needs a much more modular approach and most JS libraries should be handled more like libraries are in desktop apps. The browser is basically an OS already anyway.
  - semi 2y ago
    The privacy issues aren't just hypothetical, but that aside, that caching model unfortunately doesn't mesh well with modern webdev. It requires all dependencies to be shipped in full, no tree shaking to only include the needed functions. And separately as individual files.. and for people to actually stick to the same versions of dependencies
    - mike_hearn 2y ago
nrabulinski 2y ago
Yeah, right. GitHub migrated from serving static sites to displaying everything dynamically and it’s basically unusable nowadays. Unbelievably long load times, frustratingly unresponsive, and that’s on my top spec m1 MacBook Pro connected to a router with fiber connection. Let’s not kid ourselves, no matter how many fancy features, splitting, optimizing, whatever you do, JS webapps may be an upgrade for developers, they’re a huge downgrade for users in all aspects
- inferiorhuman 2y ago
  Between massacring the UX and copilot I've more or less stopped engaging with github. I got tempted the other day to comment on an issue and it turns out the brain trust over at Microsoft broke threaded comment replies. They still haven't fixed keyboard navigation in their bullshit text widget. I could put up with the glacial performance if it actually worked in the first place, but apparently adding whiz bang "AI" features is the only thing that matters these days. The whole thing smacks of a rewrite so someone could get a bonus and/or promotion.
  - kellpossible2 2y ago
    Surprisingly my experience of GitLab is even worse! How's yours? BitBucket wasn't much better from memory either. Seems like most commercial offerings in this spaces suck.
    - inferiorhuman 2y ago
      I've been using Sourcehut. I respect Drew's commitment to open source, but I think that a lot of the UX misses the mark. For most things I really don't want an email based work flow and some pieces feel a bit disjointed. Overall though it has most of the features I want, and dramatically less bullshit than Github.
- FridgeSeal 2y ago
  Every time I click a link in GitHub, and watch their _stupid_ SPA “my internal loading bar is better than yours” I despair. It’s never faster than simply reloading the page. I don’t know what they were thinking, but they shouldn’t have.
rcxdude 2y ago
This makes perfect sense in theory and yet it's the opposite of my experience in practice. I don't know how, but SPA websites are pretty much always much more laggy than just plain HTML, even if there are a lot of page loads.
- arp242 2y ago
  There's quite some space between "100% no JS" and "full SPA"; many applications are mostly backend template-driven, but use JS async loads for some things where it makes sense. The vote buttons on Hacker News is a good example. I agree a lot of full SPAs are poorly done, but some are do work well. FastMail is an example of a SPA done well. The reason many SPAs are slower is just latency; traditional template-driven is: - You send request - Backend takes time to process that - Sends all the data in one go. - Browser renders it. But full SPA is: - You send request - You get a stub template which loads JS. - You load the JS. - You parse the JS. - You send some number of requests to get some JSON data, this can be anything from 1 to 10 depending on how it was written. Sometimes it's even serial (e.g. request 1 needs to complete, then uses some part of that to send request 2, and then that needs to finish). - Your JS parses that and converts it to HTML. - It injects that in your DOM. - Browser renders it. There are ways to make that faster, but many don't.
- NohatCoder 2y ago
  Having written a fair amount of SPA and similar I can confirm that it is actually possible to just write some JavaScript that does fairly complicated jobs without the whole thing ballooning into the MB space. I should say that I could write a fairly feature-rich chat-app in say 500 kB of JS, then minified and compressed it would be more like 50 kB on the wire. How my "colleagues" manage to get to 20 MB is a bit of mystery.
  - RunSet 2y ago
    > How my "colleagues" manage to get to 20 MB is a bit of mystery. More often than not (and wittingly or not) it is effectively by using javascript to build a browser-inside-the-browser, Russian doll style, for the purposes of tracking users' behavior and undermining privacy. Modern "javascript frameworks" do this all by default with just a few clicks.
FridgeSeal 2y ago
Getting at least “n”kb of html with content in it that you can look at in the interim is better than getting the same amount of framework code. SPA’s also have a terrible habit of not behaving well after being left alone for a while. Nothing like coming back to a blank page and having it try to redownload the world to show you 3kb of text, because we stopped running the VM a week ago.
withinboredom 2y ago
Here’s something that’s not true: in js, the first link you click navigates you. In the browser, clicking a second link cancels the first one and navigates to the second one. GitHub annoys the fuck out of me with this.

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.
- tecleandor 2y ago
  Well, I'm working right now so let me check our daily "productivity" sites (with an adblocker installed): - Google Mail: Inbox is ~18MB (~6MB Compressed). Of that, 2.5MB is CSS (!) and the rest is mostly JS - Google Calendar: 30% lower, but more or less the same proportions - Confluence: Home is ~32MB (~5MB Comp.). There's easily 20MB of Javascript and at least 5MB of JSON. - Jira: Home is ~35MB (~7MB compressed). I see more than 25MB of Javascript - Google Cloud Console: 30MB (~7MB Comp.). I see at least 16MB of JS - AWS Console: 18MB (~4MB Comp.). I think it's at least 12MB of JS - New Relic: 14MB (~3MB Comp.). 11MB of JS. This is funny because even being way more data heavy than the rest, its weight is way lower. - Wiz: 23MB (~6MB Comp.) 10MB of JS and 10MB of CSS - Slack: 60MB (~13MB Compressed). Of that, 48MB of JS. No joke.
  - tonyhart7 2y ago
    too much crap holy and this is worse case scenario with adblock
  - jerf 2y ago
    I sometimes wish I could spare the time just to tear into something like that Slack number and figure out what it is all doing in there. Javascript should even generally be fairly efficient in terms of bytes/capability. Run a basic minimizer on it and compress it and you should be looking at something approaching optimal for what is being done. For instance, a variable reference can amortize down to less than one byte, unlike compiled code where it ends up 8 bytes (64 bits) at the drop of a hat. Imagine how much assembler "a.b=c.d(e)" can compile into to, in what is likely represented in less compressed space than a single 64-bit integer in a compiled language. Yet it still seems like we need 3 megabytes of minified, compressed Javascript on the modern web just to clear our throats. It's kind of bizarre, really.
    - LtWorf 2y ago
      js developers had this idea of "1 function = 1 library" for a really long time, and "NEVER REIMPLEMENT ANYTHING". So they will go and import a library instead of writing a 5 line function, because that's somehow more maintainable in their mind. Then of course every library is allowed to pin its own dependencies. So you can have 15 different versions of the same thing, so they can change API at will. I poked around some electron applications. I've found .h files from openssl, executables for other operating systems, megabytes of large image files that were for some example webpage, in the documentation of one project. They literally have no idea what's in there at all.
- b3orn 2y ago
  I'm getting almost 2MB (5MB uncompressed) just for a google search.
- ezequiel-garzon 2y ago
  I agree with adding very little JavaScript, say 1kB https://instant.page/ https://instant.page/ to make it snappier.
andrepd 2y ago
Yes. It's inexcusable that text and images and video pulls in megabytes of dependencies from dozens of domains. It's wasteful on every front: network, battery, and it's also SLOW.
- LtWorf 2y ago
  The crap is that even themes for static site generators like mkdocs link resources from cloudflare rather than including them in the theme. For typedload I've had to use wget+sed to get rid of that crap after recompiling the website. https://codeberg.org/ltworf/typedload/src/branch/master/Makefile#L132-L139 https://codeberg.org/ltworf/typedload/src/branch/master/Make...
RGamma 2y ago
Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...
- pgraf 2y ago
  Shouldn’t HTTP compression reap most of the benefits of this approach for bigger pages?
- chris_pie 2y ago
  Check this proposal out: https://github.com/tc39/proposal-binary-ast https://github.com/tc39/proposal-binary-ast
- jiggawatts 2y ago
  The generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image is only 23.7 megabytes. At some point you might be better off doing "server side rendering" with a GPU instead of sending more JavaScript!
  - RGamma 2y ago
    Soo.. there should be a standardized web API for page content. And suddenly... gopher (with embedded media/widgets).
  - Lex-2008 2y ago
    > "server side rendering" with a GPU instead of sending more JavaScript Some 7~10 years ago I remember I saw somewhere (maybe here on HN) a website which did exactly this: you gave it an URL - it downloaded a webpage with all its resources, rendered and screenshot'ed it (probably in headless Chrome or something), and compared size of png screenshot versus size of webpage with all its resources. For many popular websites, png screenshot of a page indeed was several times less than webpage itself!
mike_hearn 2y ago
Yeah, but your blog is not a full featured chat system with integrated audio and video calling, strapped on top of a document format. There are a few architectural/policy problems in web browsers that cause this kind of expansion: 1. Browsers can update large binaries asynchronously (=instant from the user's perspective) but this feature is only very recently available to web apps via obscure caching headers and most people don't know it exists yet/frameworks don't use it. 2. Large download sizes tend to come from frameworks that are featureful and thus widely used. Browsers could allow them to be cached but don't because they're over-aggressive at shutting down theoretical privacy problems, i.e. the browser is afraid that if one site learns you used another site that uses React, that's a privacy leak. A reasonable solution would be to let HTTP responses opt in to being put in the global cache rather than a partitioned cache, that way sites could share frameworks and they'd stay hot in the cache and not have to be downloaded. But browsers compete to satisfy a very noisy minority of people obsessed with "privacy" in the abstract, and don't want to do anything that could kick up a fuss. So every site gets a partitioned cache and things are slow. 3. Browsers often ignore trends in web development. React style vdom diffing could be offered by browsers themselves, where it'd be faster and shipped with browser updates, but it isn't so lots of websites ship it themselves over and over. I think the SCIter embedded browser actually does do this. CSS is a very inefficient way to represent styling logic which is why web devs write dialects like sass that are more compact, but browsers don't adopt it. I think at some pretty foundational level the way this stuff works architecturally is wrong. The web needs a much more modular approach and most JS libraries should be handled more like libraries are in desktop apps. The browser is basically an OS already anyway.
- semi 2y ago
  The privacy issues aren't just hypothetical, but that aside, that caching model unfortunately doesn't mesh well with modern webdev. It requires all dependencies to be shipped in full, no tree shaking to only include the needed functions. And separately as individual files.. and for people to actually stick to the same versions of dependencies
  - mike_hearn 2y ago

nrabulinski 2y ago

Yeah, right. GitHub migrated from serving static sites to displaying everything dynamically and it’s basically unusable nowadays. Unbelievably long load times, frustratingly unresponsive, and that’s on my top spec m1 MacBook Pro connected to a router with fiber connection. Let’s not kid ourselves, no matter how many fancy features, splitting, optimizing, whatever you do, JS webapps may be an upgrade for developers, they’re a huge downgrade for users in all aspects

inferiorhuman 2y ago
Between massacring the UX and copilot I've more or less stopped engaging with github. I got tempted the other day to comment on an issue and it turns out the brain trust over at Microsoft broke threaded comment replies. They still haven't fixed keyboard navigation in their bullshit text widget. I could put up with the glacial performance if it actually worked in the first place, but apparently adding whiz bang "AI" features is the only thing that matters these days. The whole thing smacks of a rewrite so someone could get a bonus and/or promotion.
- kellpossible2 2y ago
  Surprisingly my experience of GitLab is even worse! How's yours? BitBucket wasn't much better from memory either. Seems like most commercial offerings in this spaces suck.
  - inferiorhuman 2y ago
    I've been using Sourcehut. I respect Drew's commitment to open source, but I think that a lot of the UX misses the mark. For most things I really don't want an email based work flow and some pieces feel a bit disjointed. Overall though it has most of the features I want, and dramatically less bullshit than Github.
FridgeSeal 2y ago
Every time I click a link in GitHub, and watch their _stupid_ SPA “my internal loading bar is better than yours” I despair. It’s never faster than simply reloading the page. I don’t know what they were thinking, but they shouldn’t have.

rcxdude 2y ago

This makes perfect sense in theory and yet it's the opposite of my experience in practice. I don't know how, but SPA websites are pretty much always much more laggy than just plain HTML, even if there are a lot of page loads.

arp242 2y ago
There's quite some space between "100% no JS" and "full SPA"; many applications are mostly backend template-driven, but use JS async loads for some things where it makes sense. The vote buttons on Hacker News is a good example. I agree a lot of full SPAs are poorly done, but some are do work well. FastMail is an example of a SPA done well. The reason many SPAs are slower is just latency; traditional template-driven is: - You send request - Backend takes time to process that - Sends all the data in one go. - Browser renders it. But full SPA is: - You send request - You get a stub template which loads JS. - You load the JS. - You parse the JS. - You send some number of requests to get some JSON data, this can be anything from 1 to 10 depending on how it was written. Sometimes it's even serial (e.g. request 1 needs to complete, then uses some part of that to send request 2, and then that needs to finish). - Your JS parses that and converts it to HTML. - It injects that in your DOM. - Browser renders it. There are ways to make that faster, but many don't.
NohatCoder 2y ago
Having written a fair amount of SPA and similar I can confirm that it is actually possible to just write some JavaScript that does fairly complicated jobs without the whole thing ballooning into the MB space. I should say that I could write a fairly feature-rich chat-app in say 500 kB of JS, then minified and compressed it would be more like 50 kB on the wire. How my "colleagues" manage to get to 20 MB is a bit of mystery.
- RunSet 2y ago
  > How my "colleagues" manage to get to 20 MB is a bit of mystery. More often than not (and wittingly or not) it is effectively by using javascript to build a browser-inside-the-browser, Russian doll style, for the purposes of tracking users' behavior and undermining privacy. Modern "javascript frameworks" do this all by default with just a few clicks.

FridgeSeal 2y ago

Getting at least “n”kb of html with content in it that you can look at in the interim is better than getting the same amount of framework code. SPA’s also have a terrible habit of not behaving well after being left alone for a while. Nothing like coming back to a blank page and having it try to redownload the world to show you 3kb of text, because we stopped running the VM a week ago.

withinboredom 2y ago

Here’s something that’s not true: in js, the first link you click navigates you. In the browser, clicking a second link cancels the first one and navigates to the second one. GitHub annoys the fuck out of me with this.