7 ms·

It is bad design, but more importantly, server push is a (subpar) solution to a problem we shouldn't have in the first place. How exactly modern web ended up i

It is bad design, but more importantly, server push is a (subpar) solution to a problem we shouldn't have in the first place. How exactly modern web ended up in a situation where, first time browser is displaying a single page (with maybe 3 pictures and 2 paragraphs of text), it has to download 300 resources from 12 different servers, including 2 megabytes of minified javascript?

vbezhenar 4y ago
How many files touches some typical desktop program to display 3 pictures and 2 paragraphs of text? How many megabytes its installation occupies? My bet is that numbers will be comparable. That's the way people write software. Standards and tools should adapt. It makes no sense to complain about it as nothing changes. Every popular JS build tool helps with good practices by building a single minified bundle. Popular JS frameworks are tiny portion of those 2 megabytes. Developers just don't care and you can't do anything about it. You can build better protocols and better tools to make those applications work faster. And developers will leverage those to make their apps even slower. Who cares about 2 MB with 5G?
- okasaki 4y ago
  Even if so, the javascript doesn't replace the OS "bloat", it adds to it.
  - mrjin 4y ago
    JS is the most abused stuff I guess. Current web apps is a "can we" rather than "should we" approach.
    - allendoerfer 4y ago
      Humanity is a "can we" approach.
- nousermane 4y ago
  > How many files touches some typical desktop program to display 3 pictures Not sure about typical, but here is rough estimate for the rock bottom of it: "feh" image viewer on Ubuntu/X11: $ strace -e openat -o >(wc -l) feh -F \ one.jpg two.jpg three.jpg 105
  - jchw 4y ago
    That's not the whole story of course: there's an X server that feh is communicating with over a domain socket and usually shared memory, and X implements significant functionality on its end. Then there's drivers, and the stuff between these things.
    - nousermane 4y ago
      Sure. And bloated websites aren't dropping from the race here, either. They are communicating, over HTTP (and maybe WS/SSE), with fair number of servers, that also implement significant functionality. Then, there are microservices, databases, network between those...
      - jchw 4y ago
        Ultimately, though, even the script-free HTML pages that purists generally like and do not see as a problem do all of these things just as much. The point is that people have a lot of feelings about how simple, small and self-contained different software is, but realistically if you're not on a Commodore 64 they're all nightmarishly complicated. It only feels otherwise because encapsulation can be effective.
    - LtWorf 4y ago
      an X server is not implementing as much functionality as a browser, but it's anyway needed to display our initial HTML
      - jchw 4y ago
        It's a bit nitpicky to go this direction, but in general having the display server implement all of the things X does is not necessary at all, especially because most apps, certainly browsers, essentially ignore those features of the display server, because they need more functionality and better performance. That said, I would not be surprised if XFree86 was, at some point, significantly larger than contemporary web browsers, given the enormous amount of functionality that was loaded into it. Of course, modern web browsers definitely trump any old X server, so is this really relevant? I guess it depends. I get a huge sense that what people are longing for is a return to the "good ol days" when software was simple and fast, and X is a damning counter example, though it certainly doesn't mean that there's no point to be made at all, just that it is perhaps less black and white than people suggest. I am not trying to say that feh is as complex or as slow as a web browser, only that in general, people treat the division of "native code" and "browser code" such that code running in a browser is always more bloated and slow. Somehow though, this is demonstrably not true. Looking at only very simple software with intentionally very limited scope is not going to give the whole picture. When you look at fairly complex software, the additional burden of having a browser underneath can fade away compared to algorithmic complexity issues and poorly optimized code. Your text layout and font shaping routines are probably going to struggle to compete with a browser if you have a very heavy layout to handle, and if you're doing accidentally quadratic things it's going to matter more than JIT or GC overhead.
- aaaaaaaaaaab 4y ago
  Yawn… Strawman argument. I just want to read a damn article. Why does it need to download hundreds of resources from dozens of origins? Reading a PDF article on my desktop touches exactly one file, the PDF. Ok, maybe some dylibs from the OS related to PDF rendering. But surprise! Browsers already have everything built-in for HTML rendering! No need to download an HTML rendering engine, because it’s already there: it’s the browser!
  - vbezhenar 4y ago
    Basically because site owner wants to monetise your visit. Those who don't want to monetise you, usually don't put loads of trackers, ads and other stuff which is main reason of those hundreds of requests.
  - staticassertion 4y ago
    Why is multiple files worse than one? PDF is an insanely complex format, I don't think the argument of "I can just read a PDF file" is strong.
    - LtWorf 4y ago
      Because multiple files require multiple roundtrip times, more connections, and the total amount of data is higher because of all the waste that happens with headers.
      - bruce511 4y ago
        The headers are not the wasteful part. Headers are typically in the low-hundreds of bytes. This extra data is insignificant as "waste" compared to the request/response content. The real waste is in the time it takes to create and destroy the connection. (hence why http/3 switched to UDP, and also why multiplexing is a thing.) Thing is, combining js and css on the server side into 1 file pretty much negates this speed benefit. I've been building sites this way forever, and performance is great. First page takes longer, but then those files are in the cache anyway. The actual problem is Ads. They require tracking, and of course displaying. If you're looking for waste, or indeed why a server would bother with http/3 then look no further. No ads, no problem. Unfortunately for those sites that rely on advertising for revenue, I don't have an alternative suggestion. I get it, ads pay for lots of the Internet I "browse". I'm not a fan of pay walls and subscriptions. So http/3 is a solution to an economic reality - and really only benefits the ad-supported Web - but for them it is important.
- mtoohig 4y ago
  As much as I agree in general, the last part affects me and many others. I only get 2.5Mb/s and I work for the WISP. The wife's family living away from the main city have intermittent connection and slower speeds. We have only one submarine cable and poor infrastructure further out. So heavy, bloated sites eat up people's pre-paid internet packages quickly or have trouble loading altogether. Prepaid is around $1.25 for 500MB or $10 for 5.5GB. I think lower bundle sizes should be a goal. Or lower bandwidth websites should be available such as a 'm.' Domain. IMO
  - shadowgovt 4y ago
    This was one of the goals of AMP cache: require sites to use a subset of HTML and vend the data from a server local to the request.
- doliveira 4y ago
  > Who cares about 2 MB with 5G Statements like this reminds me we live in different planets. I'd argue we should still care, just like we care about accessibility in general, but obviously it's indeed a lost cause. Anyone not on 1Gbps and 32 GB of RAM is to be relegated
- alerighi 4y ago
  There is a difference: a webpage is not a program, the program is the browser. The browser is a program to display documents, just like a text editor can display text, a PDF viewer can display a PDF or a video player can play a video. The problem is that who make websites, instead of making documents, maybe built dynamically by the server and with some interactive elements in it, doesn't sent you a document but instead sends you an application that builds the document into the browser, basically turning an application that simply displays you document into a virtual machine that runs an entire graphical environment. The fact is that most of the websites to function doesn't need a line of JavaScript, and still are downloading Mb of libraries to do what?
  - slaymaker1907 4y ago
    I think the web is a great application framework, but I agree some sites really don't need as much JS as they use. For example, my note taking setup is a self modifying HTML file that relies heavily on JS for obvious reasons. Your typical blog or news site really doesn't need it in the same way.
    - alerighi 4y ago
      I think that one of the problem of the modern web is that it's seen as an application framework, and we forgot the origin that is the browser as a document viewer, basically. Most of the problems wouldn't be even present if we reason in terms of documents, and in terms of operations that you can do on these documents (GET, PUT, DELETE, POST). You find out that for most website you don't need JS! One could argue that JS is an optimization because you don't load up again the whole page each time you navigate to a different URL. That is false: if you cache the assets that doesn't change between pages such as stylesheets and images correctly, downloading just the HTML of the page is something trivial. Look at the number of requests that a webpage that uses JS does: is that more efficient?
    - deleted 4y ago
      [deleted]
  - shadowgovt 4y ago
- mrjin 4y ago
  Do you reinstall your OS/apps daily or even hourly? ^Who cares about 2 MB with 5G? That's exactly how we get into current shitty situation. Network is fast, memory is cheap so let's do whatever we want. In 2004, I only had 512MB memory on my computer, it run pretty smoothly. But now I got 64GB of memory and I run of memory now and then. I'm wondering how soon I'm going to put 1TB of RAM into my computer, not going to be too far away I reckon.
skyde 4y ago
When working on the Bing web crawler, we tried to take screenshot of webpage to use as thumbnail. What you describe was a huge pain, most page forced us to download 15MB of data and load it in memory just to display 2 small images and some text. A format like PDF would have been much better because we could have read enough byte until we are able to render the visible part of the document. But instead we had to download and execute 30 javascript files.
jupp0r 4y ago
> How exactly modern web ended up in a situation where [...] > it has to download 300 resources from 12 different servers, > including 2 megabytes of minified javascript? This is "best practice" that is used widely to work around HTTP 1.1 Head of Line Blocking [1]. HTTP/2 and to a greater degree HTTP/3 (as it also alleviates TCP head of line blocking) are fixing the underlying problem making the former best practice an anti pattern (but only for those users able to use modern HTTP implementations). [1] https://en.wikipedia.org/wiki/Head-of-line_blocking#In_HTTP https://en.wikipedia.org/wiki/Head-of-line_blocking#In_HTTP
- divbzero 4y ago
  “12 different servers” and “minified JavaScript” were indeed workarounds for head-of-line blocking, but I think the GP’s main point is that “300 resources” and “2 megabytes” should not be required for displaying a web page.
  - nine_k 4y ago
    They are not required to display a web page. They are mostly required to make money off that web page, and, to a smaller degree, to observe how users interact with it and thus improve it (also aligns with making more money). Fortunately, Reader Mode is available in a few user-friendly browsers.
    - deleted 4y ago
      [deleted]
  - jupp0r 4y ago
    Adobe Photoshop and Quake 3 are JS apps nowadays so depending on your use case it's completely legitimate to download hundreds of megabytes of code and data in modern browsers. I once worked on an app that was a heavily optimized tree shaken 40MB bundle of JS because it was a telephony system, video conferencing and document sharing and collaboration app. Completely ok size for that use case. If it's just a normal non-interactive website then it shouldn't have any javascript in the first place.
- 4y ago
dwheeler 4y ago
> How exactly [has the] modern web ended up in a situation where, first time browser is displaying a single page (with maybe 3 pictures and 2 paragraphs of text), it has to download 300 resources from 12 different servers, including 2 megabytes of minified javascript? Ads.
- edude03 4y ago
  Also bundlers without treeshaking - I personally once delivered 70MB of compressed JS to clients in production
  - the-anarchist 4y ago
    Your honesty is being appreciated.
    - w-ll 4y ago
      we've all used moment.js at some point
      - thejosh 4y ago
        I remember looking at a graph showing our frontend usage of various libraries. Moment was huge, because it depended on so much. At the time there's wasn't really a good alternative though.
  - zxcvbn4038 4y ago
    You used jquery? :)
mrjin 4y ago
LOL, only 2MB of minified javascript? How about those over 20MB ones?

vbezhenar 4y ago

How many files touches some typical desktop program to display 3 pictures and 2 paragraphs of text? How many megabytes its installation occupies? My bet is that numbers will be comparable. That's the way people write software. Standards and tools should adapt. It makes no sense to complain about it as nothing changes. Every popular JS build tool helps with good practices by building a single minified bundle. Popular JS frameworks are tiny portion of those 2 megabytes. Developers just don't care and you can't do anything about it. You can build better protocols and better tools to make those applications work faster. And developers will leverage those to make their apps even slower. Who cares about 2 MB with 5G?

okasaki 4y ago
Even if so, the javascript doesn't replace the OS "bloat", it adds to it.
- mrjin 4y ago
  JS is the most abused stuff I guess. Current web apps is a "can we" rather than "should we" approach.
  - allendoerfer 4y ago
    Humanity is a "can we" approach.
nousermane 4y ago
> How many files touches some typical desktop program to display 3 pictures Not sure about typical, but here is rough estimate for the rock bottom of it: "feh" image viewer on Ubuntu/X11: $ strace -e openat -o >(wc -l) feh -F \ one.jpg two.jpg three.jpg 105
- jchw 4y ago
  That's not the whole story of course: there's an X server that feh is communicating with over a domain socket and usually shared memory, and X implements significant functionality on its end. Then there's drivers, and the stuff between these things.
  - nousermane 4y ago
    Sure. And bloated websites aren't dropping from the race here, either. They are communicating, over HTTP (and maybe WS/SSE), with fair number of servers, that also implement significant functionality. Then, there are microservices, databases, network between those...
    - jchw 4y ago
      Ultimately, though, even the script-free HTML pages that purists generally like and do not see as a problem do all of these things just as much. The point is that people have a lot of feelings about how simple, small and self-contained different software is, but realistically if you're not on a Commodore 64 they're all nightmarishly complicated. It only feels otherwise because encapsulation can be effective.
  - LtWorf 4y ago
    an X server is not implementing as much functionality as a browser, but it's anyway needed to display our initial HTML
    - jchw 4y ago
      It's a bit nitpicky to go this direction, but in general having the display server implement all of the things X does is not necessary at all, especially because most apps, certainly browsers, essentially ignore those features of the display server, because they need more functionality and better performance. That said, I would not be surprised if XFree86 was, at some point, significantly larger than contemporary web browsers, given the enormous amount of functionality that was loaded into it. Of course, modern web browsers definitely trump any old X server, so is this really relevant? I guess it depends. I get a huge sense that what people are longing for is a return to the "good ol days" when software was simple and fast, and X is a damning counter example, though it certainly doesn't mean that there's no point to be made at all, just that it is perhaps less black and white than people suggest. I am not trying to say that feh is as complex or as slow as a web browser, only that in general, people treat the division of "native code" and "browser code" such that code running in a browser is always more bloated and slow. Somehow though, this is demonstrably not true. Looking at only very simple software with intentionally very limited scope is not going to give the whole picture. When you look at fairly complex software, the additional burden of having a browser underneath can fade away compared to algorithmic complexity issues and poorly optimized code. Your text layout and font shaping routines are probably going to struggle to compete with a browser if you have a very heavy layout to handle, and if you're doing accidentally quadratic things it's going to matter more than JIT or GC overhead.
aaaaaaaaaaab 4y ago
Yawn… Strawman argument. I just want to read a damn article. Why does it need to download hundreds of resources from dozens of origins? Reading a PDF article on my desktop touches exactly one file, the PDF. Ok, maybe some dylibs from the OS related to PDF rendering. But surprise! Browsers already have everything built-in for HTML rendering! No need to download an HTML rendering engine, because it’s already there: it’s the browser!
- vbezhenar 4y ago
  Basically because site owner wants to monetise your visit. Those who don't want to monetise you, usually don't put loads of trackers, ads and other stuff which is main reason of those hundreds of requests.
- staticassertion 4y ago
  Why is multiple files worse than one? PDF is an insanely complex format, I don't think the argument of "I can just read a PDF file" is strong.
  - LtWorf 4y ago
    Because multiple files require multiple roundtrip times, more connections, and the total amount of data is higher because of all the waste that happens with headers.
    - bruce511 4y ago
      The headers are not the wasteful part. Headers are typically in the low-hundreds of bytes. This extra data is insignificant as "waste" compared to the request/response content. The real waste is in the time it takes to create and destroy the connection. (hence why http/3 switched to UDP, and also why multiplexing is a thing.) Thing is, combining js and css on the server side into 1 file pretty much negates this speed benefit. I've been building sites this way forever, and performance is great. First page takes longer, but then those files are in the cache anyway. The actual problem is Ads. They require tracking, and of course displaying. If you're looking for waste, or indeed why a server would bother with http/3 then look no further. No ads, no problem. Unfortunately for those sites that rely on advertising for revenue, I don't have an alternative suggestion. I get it, ads pay for lots of the Internet I "browse". I'm not a fan of pay walls and subscriptions. So http/3 is a solution to an economic reality - and really only benefits the ad-supported Web - but for them it is important.
mtoohig 4y ago
As much as I agree in general, the last part affects me and many others. I only get 2.5Mb/s and I work for the WISP. The wife's family living away from the main city have intermittent connection and slower speeds. We have only one submarine cable and poor infrastructure further out. So heavy, bloated sites eat up people's pre-paid internet packages quickly or have trouble loading altogether. Prepaid is around $1.25 for 500MB or $10 for 5.5GB. I think lower bundle sizes should be a goal. Or lower bandwidth websites should be available such as a 'm.' Domain. IMO
- shadowgovt 4y ago
  This was one of the goals of AMP cache: require sites to use a subset of HTML and vend the data from a server local to the request.
doliveira 4y ago
> Who cares about 2 MB with 5G Statements like this reminds me we live in different planets. I'd argue we should still care, just like we care about accessibility in general, but obviously it's indeed a lost cause. Anyone not on 1Gbps and 32 GB of RAM is to be relegated
alerighi 4y ago
There is a difference: a webpage is not a program, the program is the browser. The browser is a program to display documents, just like a text editor can display text, a PDF viewer can display a PDF or a video player can play a video. The problem is that who make websites, instead of making documents, maybe built dynamically by the server and with some interactive elements in it, doesn't sent you a document but instead sends you an application that builds the document into the browser, basically turning an application that simply displays you document into a virtual machine that runs an entire graphical environment. The fact is that most of the websites to function doesn't need a line of JavaScript, and still are downloading Mb of libraries to do what?
- slaymaker1907 4y ago
  I think the web is a great application framework, but I agree some sites really don't need as much JS as they use. For example, my note taking setup is a self modifying HTML file that relies heavily on JS for obvious reasons. Your typical blog or news site really doesn't need it in the same way.
  - alerighi 4y ago
    I think that one of the problem of the modern web is that it's seen as an application framework, and we forgot the origin that is the browser as a document viewer, basically. Most of the problems wouldn't be even present if we reason in terms of documents, and in terms of operations that you can do on these documents (GET, PUT, DELETE, POST). You find out that for most website you don't need JS! One could argue that JS is an optimization because you don't load up again the whole page each time you navigate to a different URL. That is false: if you cache the assets that doesn't change between pages such as stylesheets and images correctly, downloading just the HTML of the page is something trivial. Look at the number of requests that a webpage that uses JS does: is that more efficient?
  - deleted 4y ago
    [deleted]
- shadowgovt 4y ago
mrjin 4y ago
Do you reinstall your OS/apps daily or even hourly? ^Who cares about 2 MB with 5G? That's exactly how we get into current shitty situation. Network is fast, memory is cheap so let's do whatever we want. In 2004, I only had 512MB memory on my computer, it run pretty smoothly. But now I got 64GB of memory and I run of memory now and then. I'm wondering how soon I'm going to put 1TB of RAM into my computer, not going to be too far away I reckon.

skyde 4y ago

When working on the Bing web crawler, we tried to take screenshot of webpage to use as thumbnail. What you describe was a huge pain, most page forced us to download 15MB of data and load it in memory just to display 2 small images and some text. A format like PDF would have been much better because we could have read enough byte until we are able to render the visible part of the document. But instead we had to download and execute 30 javascript files.

jupp0r 4y ago

> How exactly modern web ended up in a situation where [...] > it has to download 300 resources from 12 different servers, > including 2 megabytes of minified javascript? This is "best practice" that is used widely to work around HTTP 1.1 Head of Line Blocking [1]. HTTP/2 and to a greater degree HTTP/3 (as it also alleviates TCP head of line blocking) are fixing the underlying problem making the former best practice an anti pattern (but only for those users able to use modern HTTP implementations). [1] https://en.wikipedia.org/wiki/Head-of-line_blocking#In_HTTP https://en.wikipedia.org/wiki/Head-of-line_blocking#In_HTTP

divbzero 4y ago
“12 different servers” and “minified JavaScript” were indeed workarounds for head-of-line blocking, but I think the GP’s main point is that “300 resources” and “2 megabytes” should not be required for displaying a web page.
- nine_k 4y ago
  They are not required to display a web page. They are mostly required to make money off that web page, and, to a smaller degree, to observe how users interact with it and thus improve it (also aligns with making more money). Fortunately, Reader Mode is available in a few user-friendly browsers.
  - deleted 4y ago
    [deleted]
- jupp0r 4y ago
  Adobe Photoshop and Quake 3 are JS apps nowadays so depending on your use case it's completely legitimate to download hundreds of megabytes of code and data in modern browsers. I once worked on an app that was a heavily optimized tree shaken 40MB bundle of JS because it was a telephony system, video conferencing and document sharing and collaboration app. Completely ok size for that use case. If it's just a normal non-interactive website then it shouldn't have any javascript in the first place.
4y ago

dwheeler 4y ago

> How exactly [has the] modern web ended up in a situation where, first time browser is displaying a single page (with maybe 3 pictures and 2 paragraphs of text), it has to download 300 resources from 12 different servers, including 2 megabytes of minified javascript? Ads.

edude03 4y ago
Also bundlers without treeshaking - I personally once delivered 70MB of compressed JS to clients in production
- the-anarchist 4y ago
  Your honesty is being appreciated.
  - w-ll 4y ago
    we've all used moment.js at some point
    - thejosh 4y ago
      I remember looking at a graph showing our frontend usage of various libraries. Moment was huge, because it depended on so much. At the time there's wasn't really a good alternative though.
- zxcvbn4038 4y ago
  You used jquery? :)

mrjin 4y ago

LOL, only 2MB of minified javascript? How about those over 20MB ones?