Because it is 2018 and people have forgotten how to static HTML. All that lovely rendering code in your browser goes unused as people rewrite it in Javascript, badly; or even in C++ and then compile to web assembly, that’s all the rage now, because why stick with one layer of abstraction when you can involve three? Oh, and of course everyone rolls their own, so that website with the dancing pigs not only has its own…
Expectations for the web are different. Also, there are more applications running in a web browser than there were in the past.
Because it is 2018 and people have forgotten how to static HTML. All that lovely rendering code in your browser goes unused as people rewrite it in Javascript, badly; or even in C++ and then compile to web assembly, that’s all the rage now, because why stick with one layer of abstraction when you can involve three? Oh, and of course everyone rolls their own, so that website with the dancing pigs not only has its own…
Writing small footprint website helps, but the major culprit here is Google Chrome. It consumes way too much memory per tab (compared to Firefox on Linux), I've heard it's because it has a strict «one process per tab» policy, whereas Firefox has several processes but not one per tab.
Chrome doesn't have a strict one process per tab, but doesn't cap it anywhere near such a low number as Firefox (currently) does.
In large part, I suspect, chromes resource use stems from google wanting to scour everything you do. I wouldn’t be surprised to find out it logs how many seconds your cursor is over ads and all other user input.
Because it is 2018 and people have forgotten how to static HTML. All that lovely rendering code in your browser goes unused as people rewrite it in Javascript, badly; or even in C++ and then compile to web assembly, that’s all the rage now, because why stick with one layer of abstraction when you can involve three? Oh, and of course everyone rolls their own, so that website with the dancing pigs not only has its own…
I don't know, WebAssembly compiles to very small blobs (if done right), you can get a lot of functionality out of a few KBytes. Imagine if we could throw out all the high-level crap from the browser core (WebAudio's node graph, all the video and audio codecs, HTML/CSS/JS engines with all legacy features they need to support, etc etc... and replace that with wasm modules which are only loaded on demand. Then browsers…
And a lot more websites would be inaccessible to blind people, and people with other disabilities, because those lean, mean WebAssembly blobs wouldn't include the accessibility support that's built into the current bloated browsers. No, web accessibility isn't perfect, but I think throwing out what we already have could only be a step backwards.
Obviously, it depends on the site. However, when you're on YouTube you don't want the site to suggest videos you're not interested in (or Amazon, products). When you're on a blog, you don't want "related articles" to list articles you've already read. Etc. Etc. I don't know if people want this--in part because they don't even realize these features exist--but I'm sure the opposite can be annoying. It also depends how…
As a user of both YouTube and Amazon.com I really don't want either recommendations you mentioned. I go to YouTube to watch specific videos and I go to Amazon to buy specific things. Those organizations want to give me recommendations but if I could turn them off and gain performance I would do that in a heartbeat.
Ah, I see. I discover awesome things on both platforms this way.
On the performance side, Hacker News still takes 100MB of memory in Chrome, so...
I’ve not seen much WebAssembly “done right” to date; IME it is most often employed to spew gargantuan legacy C++ applications verbatim into the browser to avoid having to understand which parts are actually desired, whether and how they can be unpicked from the rest, and whether they are trivial enough to actually just reimplement in Javascript or otherwise as standalone modules. This does not bode well for the utopi…
Don't worry. If we've managed to blow our binaries up to 100s of MB, we can do it with our websites, too! (Seriously. Chromium is 124MB. How does anyone think web dev will go differently?)
We will never go back ; there is only a tiny niche group (embedded, retro and demoscene) that cares about tiny and efficient. The rest simply wants to deliver features fast. On their (I include myself in that often) island, most reason that computers are fast enough and have enough memory. But that arguments really does not take into account things like: multitasking (if all devs think like that, what happens when you run 20 apps at the same time?) and, in many cases, battery life (that does not have to be the case; bloat does not have to hog cpu but often does).
I fundamentally disagree. I don’t think ‘people’ really do want that. That reminds me of the thinking during the 90’s and early 00’s that everyone somehow must want 10 browser toolbars that spam them with ads all the time.
Obviously, it depends on the site. However, when you're on YouTube you don't want the site to suggest videos you're not interested in (or Amazon, products). When you're on a blog, you don't want "related articles" to list articles you've already read. Etc. Etc. I don't know if people want this--in part because they don't even realize these features exist--but I'm sure the opposite can be annoying. It also depends how…
You cannot create an efficient static page with recommends below a video?
(clientside that is; serverside it would be dynamic but Chrome should not be bothered, it is, but that is another story)
Obviously, it depends on the site. However, when you're on YouTube you don't want the site to suggest videos you're not interested in (or Amazon, products). When you're on a blog, you don't want "related articles" to list articles you've already read. Etc. Etc. I don't know if people want this--in part because they don't even realize these features exist--but I'm sure the opposite can be annoying. It also depends how…
You cannot create an efficient static page with recommends below a video? (clientside that is; serverside it would be dynamic but Chrome should not be bothered, it is, but that is another story)
Don't worry. If we've managed to blow our binaries up to 100s of MB, we can do it with our websites, too! (Seriously. Chromium is 124MB. How does anyone think web dev will go differently?)
We will never go back ; there is only a tiny niche group (embedded, retro and demoscene) that cares about tiny and efficient. The rest simply wants to deliver features fast. On their (I include myself in that often) island, most reason that computers are fast enough and have enough memory. But that arguments really does not take into account things like: multitasking (if all devs think like that, what happens when yo…
It's better yet if we can deliver features fast with internationalization, accessibility, security, maintainability, and so on. Whenever I dabble in retro computing, usually via emulation, I appreciate how much progress we've really made. And if a phone needs 2 GB of RAM, and a laptop needs 8, well, the world has much bigger problems.
(I have worked as an engineer on both Ubuntu and Chrome) > One tab on chrome takes about 100MB memory, why? It probably doesn't. Much of that apparent memory usage is shared between all tabs, and the browser renderer process, etc. in the form of shared memory. Quite a bit of it will be the executable code itself, which is "mapped" into memory, given an address, and allocated the full size but doesn't actually consume…
Okay, may be OP's estimation of that being a per tab usage was not quite right, but why does ~30 tabs result in 3GB+ of usage?
May be happening for other people, but I've never had this happen. 60+ tabs and it never breaks 2GB.