Hacker News Reader

Comment by t8sr | Hacker News Reader

Alternatively, web developers could calm down and just write mostly HTML with some plain javascript where warranted.

I've recently done some web development for the first time in 12 years, and I was horrified at all these pointless frameworks that break every usability win web browsers have made in the past 20 years, cost extra bandwidth and have atrocious performance. Like, why? Can web devs really not learn the 4 functions that make up the websockets API? Do they really need a special framework named after a coffee bean?

This kinda crap is why the gmail tab uses a GB of memory.

View on HN

Tools like htmx aren't the reason the gmail tab uses a GB of memory. You'll find the majority of cases where pages are using way more resources than it should, are due to reasons forced on web developers, like a billion different trackers and several different ad networks, and workarounds to ad blocking to sell more subscriptions, etc.

This is what is so shocking to me when HN spends such an absurd amount of time rallying around this idea that frameworks are the reason sites are bad. Mind you, I do think a lot of them are misused, but 99.9999999% of poor websites aren't because of the framework chosen.

According to my browser, the default view in gmail needs 8.32 MiB of javascript spread over 90 files to render.

While IDLE, the gmail tab uses 10-30% of an M1 CPU core.

That stuff is not down to tracking - it's because the damn thing keeps messing with the DOM, because it has some insane structure where javascript controllers are attached as strings to DOM elements, because it uses about 100 divs to render every row in the list of messages, and because every message is nested literally 15-30 layers deep in a pointless tree of divs.

I am sorry, but web frontend is an insane dumpster fire.

What browser are you using? Having Gmail open doesn't even use half of a percent of a single core on my machine (Linux, x86, Chromium).

Same for macOS, Chrome. CPU sometimes jumps to 3%, but that's about it (and I guess that's because it uses slow core).

I have very clean mailbox, though.

Chrome on an M1 Pro Mac. This is the number that Chrome’s task manager shows me.

I do have a lot of emails, but I think it should only have to worry about 100 of them at a time, so I don’t know why it’s different for me and you. It is possible that my account still receives beta features, because I used to work there, but I remember it being like this for multiple years, since the new gmail came out.

Are you using Chrome through Rosetta? I'm still unable to replicate this on either my desktop or laptop, both of them just idle when I open Gmail and neither will push past 5% usage while I'm opening emails. Your metrics seem a bit odd here.

I haven’t tested the following claim and not at the computer atm (^U, see below), but divs must be cheap. They’re just structures which a rendering engine walks through and computes hierarchical offsets of via stylesheets.

I’m not arguing for using hundreds of divs, because that’s a sign of engineering insanity imo, but it’s not a performance issue. You can create a static page with thousands of them and (likely) see that it still doesn’t use 250Mb+ neither idles at 30% cpu core.

Added:

damn thing keeps messing with the DOM … web frontend is an insane dumpster fire.

Totally agree with these parts.

—————

… I just tested 50 div-rows with 200 spans containing numbers from 1 to 199. Total 10k elements, text doesn’t fit on the screen. Bootstrap css+js is imported via CDN.

Mithril.js implementation uses 50Mb of RAM consistently.

A static page with the exact same content uses 71-96Mb depending on the run.

Both use 5-14% cpu when I shake my mouse and 0% when I don’t.

Refresh is significantly faster with Mithril, idk why, probably because static html parser is slow. (Opera, Windows 10, no extensions).

With a single span per row instead of 200 both take 23Mb.

Removing bootstrap from the head inconsistently frees 0-2Mb for both.

maybe they are cheap, maybe not. but lighthouse prints a warning for "excessive number of dom elements" already at 1500...

Well google use all of their own internal 'frameworks', so you can't really use their web applications to judge the rest of the web.

This used to be true but isn’t anymore. For a while they pushed Angular, nowadays I think a lot of teams are using react. GWT is long deprecated and gone.

To be fair, gmail was quite great at the time of GWT. Not sure how much use their Clojure “platform” still get, but I think it was very ahead in terms of maintainability of large js code bases (or even ahead as we have it now)

I think citation needed on that one.

From what I understand (no special insider information) React is essentially non-existent inside of Google, and NPM is not even available to engineers (be default)

I am not sure how much I can say, because I used to work there. But I think it's OK to say many Google engineers don't particularly like Angular.

It depends what org you're in. Cloud seems to use a lot of Angular, but the rest of the company is coalescing around an in-house framework called Wiz (you can poke around the open sourced jsaction library to get an idea of the design philosophy).

I keep saying the same thing at work on the NextJS / MaterialUI project I’m working on and I largely get blank stares in response.

If you can limit yourself to exactly one, maybe two external deps, which are really just to make your dev life eaiser, you may have something of a point.

You have to remember that a large chunk of "web apps" means "electron apps" which are absolute bloated pieces of junk next to their desktop cousins.

You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.

We all agree tracking junk makes it even worse, but the whole thing is already overcomplicated before you get to that point.

> You also have to remember a 'framework' typically doesn't stand in isolation - tens, hundreds, thousands of dependencies typically lurk.

While this is true, at least by having a large number of people commit to the same set of dependencies, you stand a higher chance of complications between those dependencies being ironed out, either directly by the framework maintainers or by the user base of the framework.

> This kinda crap is why the gmail tab uses a GB of memory.

Actually no, and the real reason is organisational.

It has been a pattern for years now for front-end projects to consist of multiple, independent modules developed by separate teams - banking apps are a prime example of this.

Gmail appears to have went the same route, because it now sends over 200 requests when loading - a hallmark of a highly modularized front-end.

The organisational benefit is less knowledge required per developer, which in turn brings other advantages like resistance to turnover.

You can say that about any engineering problem and be right 99% of the time. Because it’s always true, it’s not a super useful analysis.

Somehow, software on embedded, the kernel, graphics, flight control, etc. is all developed by equally large organizations and while they’re far from perfect, they produce far better software than the vast majority of web UX organizations.

Something about web dev is uniquely terrible, in addition to the common factors you mentioned.

There's a lot of great software that's not written by people who work with web development. There's also plenty of utter garbage software that's not written by people who work with web development. I don't think web development sticks out enough to make it unique

I think you judge it like that because errors in UI are usually the most visible.

Meanwhile I can't get my laptop into sleep mode at times because such a seemingly simple feature can't be reliably implemented for some reason and it's been like that for years - that's just one out of many instances of non-web software being terrible.

Gmail is just poorly written. The old version of Gmail was still an SPA, and it was perfectly quick.

As a side note; iirc the old version of Gmail was the first big scale example of SPAs.

Yeah, I agree - the old version of gmail was perfectly reasonable. But the current version is IMO representative of trends in web dev. Google is both influential and tends to follow the recent trends. Gmail is by no means unique - every web app created in the past few years is the same insane jumble of frameworky js code and a DOM 100 layers deep, just because someone can't be bothered to learn CSS and plain JS.

Google's frontend engineering tends to be pretty poor and out of step with wider industry practice in my experience. They have created not one, but 3 of their own frameworks (Angular, Angular 2 and Polymer), two of which (Angular and Polymer) were rather poorly performing, and the third of which is kinda ok but doesn't seem to be that widely used internally. They tried to create their own frontend language (Dart), which nobody uses.

Meanwhile most of the industry is using React, which is actually pretty well engineered and perfectly fast (you may well find yourself using a slow React app, but that's not React's fault).

P.S. Talking layer of DOM nodes, I actually did a few samples of this the other day. Gmail has 34, which was by far the deepest of any website I checked and probably isn't helping it's performance.

You didn't even mention GWT. I don't know what is causing it, but yeah, Google has dropped some turds over the years.

The original version of GWT was mainly about solving compatibility issues between browsers (of which there were many). Modern GWT/J2CL is all about leveraging the mature Java development tools, especially code completion. GWT can be used with just the standard DOM APIs very effectively these days via the elemental2 library.

Apologies on the slow response.

That makes sense, but I also recall it was about trying to use the same language on the server as the client. And it worked as well as the efforts to use JavaScript is the server. Which is not to say it can't work. There are a lot of traps there, though.

Material Design is also Google’s fault. Regrettably a pretty sizable chunk of the industry either uses it directly or—worse—incorporates elements of it in their design.

I also have a pet peeve with the Roboto font family developed by Google and used everywhere on the web. But I’ll admit that it is a fine font face for its purpose, just very boring and used way too much.

> Talking layer of DOM nodes, I actually did a few samples of this the other day.

Is there a tool for this? I’m kind of wanting to check my site now…

You can run the following snippet in the console:

    function getMaxNestLevel() {
        var i = 1, sel = '* > *'; /* html > body is always present */
        while(document.querySelector(sel)) {
            sel += ' > *';
            i++;
        }
        return i;
    }
    
    console.log('total nodes', document.getElementsByTagName('*').length);
    console.log('max nest level', getMaxNestLevel());

Well, get ready for it. GitHub is moving towards React, Next, etc. I bet it will be another disaster like Reddit.

I’m actually happy about how garbage reddit is. I considered installing a redirect plugin to send me to the old.reddit subdomain[1], but ultimately decided I shouldn’t encourage myself to use Reddit, having it load into that dumpster fire of a front end has really helped discourage me from using or interacting with it. I can happily report my reddit usage is at an all time low!

[1] fun fact, you can shorten this to “ol.reddit.com” which is nice because it only requires one hand to touch type “ol.” and get an autocompletion. I always thought reddit was a great name because for right handed users, “redd” could be typed with the hand that would typically stay on the keyboard and would 100% get an autocompletion. Alas, most users are now on mobile.

> I considered installing a redirect plugin to send me to the old.reddit subdomain

I use RES[1] to force the old layout (along with many other things).

1: https://redditenhancementsuite.com/

Where is that setting in res? I was looking but could not find it.

So you haven't done web development in 12 years, but you're qualified enough to call these frameworks pointless?

I haven't written Java in years so I can tell you with authority that Java 17 is terrible and we should just go back to the good old days of J2EE.

I feel qualified, because I’ve been a SWE for 20 years, have worked in lots of domains (including web, sometime ago) and so I feel I am able to draw comparisons.

Not for nothing, but when I wrote a couple of web apps recently (most recently a market monitoring tool and a physics simulation in wasm and webgl for rendering), I tried different frameworks, but always ended up dropping them. The end result is snappy and fits in kilobytes, and the freaking back button works.

I did of course use some libraries for rendering things like graphviz. I am not a crazy person. But I fail to see what value e.g. react.js* adds, or why there are libraries to wrap websockets.

* For react specifically, I can actually imagine scenarios where it’s useful, but in practice, 95% of places where it’s used should have probably just been HTML with some minor JavaScript for bits of interactivity.

I've also worked as a SWE for many years, and I can tell you hands down that self-rolled frontend codebases are _always_ harder to maintain and add features to, than ones that lean into frameworks and libraries. They are shared understandings that are easily transferrable between contexts.

You don't mention maintainability in your examples, purely things like back button support and disk footprint. They're just pieces in the puzzle.

React and Angular are both blazing fast, and are definitely not pointless. Open create react app, spin up a page with 50000 buttons, compare that to a plain js version, then come back and tell us about the atrocious performance.

Apparently you've never heard of event delegation, which has been around for at least twenty years? (I could swear I was using it on IE6, but I might be misremembering.) At any rate, the plain JS way of handling 50,000+ HTML buttons efficiently is a long-solved problem.

https://javascript.info/event-delegation

You appear to be reading more into my post then I intended. The point I was illustrating is that there is no cruft in React.

Try and keep your posts factual.

> This kinda crap is why the gmail tab uses a GB of memory.

It isn’t. Ironically things like memory leaks are why pages use a ton of memory and in my experience everyone coding from scratch results in more of them, not less.

I really don’t agree. When I worked at Google, I filed a couple of bugs for memory leaks in the new gmail, and to my knowledge they still haven’t been addressed two years later, because there are a million dependencies and the thing is so complex no one can debug it, or even come up with a reliable repro.

Memory leaks, like bugs, tend to scale linearly with code size. You better believe your 100k line framework has more leaks than my 1000 line script.

Strong disagree. Frameworks are almost always going to be better profiled, better tested and have more eyes than any home crafted code. The number of lines isn’t really that relevant.

Well, the thing is… for any non trivial web app, you do need a framework (spa or Unpoly like). The question here is if you use an existing one or end up writing your own.

I don’t buy the “just use html, js and css”… giving the same developer skills, without a framework that becomes a mess much sooner than with one. Unless you’re just building a small landing page or todo app.

Reply on news.ycombinator.com