That's not fair. Sure, if there's an experienced dev who _values_ efficiency on the team, who pushes for the site to be more efficient or builds it more efficiently to begin with, the page would be better off. But it's mostly about incentives. If management doesn't care, they will likely not react well to programmers spending time making the site more efficient instead of spending half the time to just get it running and then crunching through their backlog.

It usually requires less time, not more, to create a slim and efficient page.

Definitely not true in my experience, and I would think if it were true, most pages would be "slim and efficient". Where is the business value in doing anything else at that point?

The GP might not always be true, but no, we would not have slim and efficient sites, because of push web developers get to include all kinds of unnecessary tracking and in general bloat on websites.

> Where is the business value in doing anything else at that point?

You think developers prioritize business value? That isn't how employment works.

Static html sites are so easy. You can write one by hand in five minutes and it can run on a toaster. There’s more business value in ads and dark patterns.

Nothing prevents adding adds, trackers and dark patterns in a static website, I would assume most of it is served by 3rd party servers that handle the dynamic widgets. Isn’t that easy to insert in an otherwise the static site?

To be clear, not saying this is a good thing, just don’t see what prevents avoiding much of the bloat on top of that which supposedly adds “business value”.

The "business value" is that it is easier and cheaper to find a handful of scriptkiddies who think everything has to be done in JS, run after the latest hype, and don't even know you can send a form using plain HTML, than it is to get competent, educated devs who know when JS or even a frontend framework is the right tool for the job.

but can it do feature x that generates more $$$ ?

True but only if you know how to. Also slim will 99% of the time be less code too.

It's very situational. If you're talking about writing a static site generator or handcoding a web page, that's mostly true, although if you're trying to not just be efficient, but as efficient as possible, things like optimizing assets are a small but additional step.

If you're maintaining a web app over a period of years, it takes at least some effort and time to keep it slim and efficient because small inefficiencies here and there start to accumulate and these tend to be more demanding even in the best case.

There are some antifeatures that Dan Luu identifies, like dynamically unloading content, that probably take a considerable amount of time to implement while degrading both the user experience and efficiency, but I doubt avoiding those is enough to ensure good performance on more complicated projects.

"it's better for the company that I don't try, my time is expensive and any minute not spent on a feature is a waste of my salary" - is a common justification that I hear all too often.

"It's better for the company that I don't try" seems like a convenient take for a dev without the skills to have. I'd argue that performance is a feature, and if someone can't deliver it their salary is being wasted already.

Performance is a feature and management often doesn't care to optimize for it. If the market valued performance more then we would probably see competitive services which optimize for performance, but we generally don't. I'm sure there's plenty of developers that could deliver improved performance, it's just a matter of tradeoffs.

Maybe the people who care this much about performance should start competing services or a consulting firm which optimizes for that. Better yet, they could devote their efforts to helping create educational content and improved frameworks or tooling which yields more performant apps.

One issue is, that the caring about performance is often not visible. How does management accout for or measure how annoyed people get visiting their bloated websites? How many people do not know better, how fast and snappy a not bloated website can be, because they apend all their time on Instagram, FB, and co? Even if a company does measure it somehow via some kind of truly well executed A/B test, other explanations might be reached for, to explain why a user left the website, than the performance.

Isn't that what the tracking stuff is supposed to track? Measure things like how 'annoyed' people get by bounce rate and whatever other relevant metrics.

Yes, but how do you determin the actual reason for a bounce? The test would need to have all the same starting conditions and then let some users have a better performing version or something like that. But at that point one would probably rollout the better performing version anyway. Maybe artificially worsen the performance and observe how the metrics change. And then it is questionable, whether the same amount by which performance decreased would have the same effect in reverse, if the performance increased by that amount. Maybe up to a certain point? In general probably not. In general it is difficult, because changing things to perform better is usually accompanied by visual and functionality changes as well.

Add a 500ms delay for group A and compare to group B who don't have the delay. After a week of this compare the sales figures.

I doubt a company would be willing to deliberately risk losing sales by testing a worse version. AB tests are great in theory, but in practice, to test the current slow system against a faster one, you have to do the optimization work which the test is supposed to justify. That’s why AB testing is often used for quick wins, pricing points or purchase flows, but rarely the big costly questions.

Surveys could be used to explain the bounce rate, but getting feedback from people who leave is one of the hardest the recruit well for. Usability tests could help with that though.

Performance is not a feature. Decisions about performance are part of every line of code we write. Some developers make good decisions and do their job right, many others half-ass it and we end up with the crap that ships in most places today.

This “blame the managers” attitude denies the agency all developers have to do our jobs competently or not. The manager probably doesn’t ultimately care about source control or code review either, but we use them because we’re professionals and we aim to do our jobs right. Maybe a better example is security: software is secure because of developers who do their jobs right, which has nothing to do with whether or not the manager cares about security.

I can agree to a point, but it's not very scalable. Imagine if the safety of every bridge and building came down to each construction worker caring on an individual level. At some point, there need to be processes that ensure success, not just individual workers caring enough.

Secure software happens because of a culture of building secure software, or processes and requirements. NASA doesn't depend on individual developers "just doing the right thing", they have strict standards.

> If the market valued performance more then we would probably see competitive services which optimize for performance, but we generally don't.

I believe there is some nuance to this due to the winner-takes-all nature of modern software services. There simply isn't a lot of choice for users or switching is expensive so companies don't do it and employees are forced to suffer through horrible performance.

Or switching happens for 90% of the feature and is called good enough, which results in now having 2 systems to maintain because the old deprecated one actually still has critical edge cases depending on it…

Usually bad web software correlates with bad content. Therefore having a slow device is an excellent filter helping to avoid garbage.

Unfortunately the modern web has consolidated to a point where you need to use them. For example, small local businesses that don’t have a web site but do have a Facebook page.

Having only a facebook page and forcing people on that toxic platform, is a strong indication that they do not value freedom (of the web) and ethics. Again a good filter for business / people I want to avoid.

> is a strong indication that they do not value freedom (of the web) and ethics.

I don't think the average barbershop/restaurant owner will care about that, for instance? They just wanna set up a Facebook/Instagram and done, they can now instantly receive messages from clients to make reservations and also share their stuff with posts. I bet they don't even know they can make a website.

Also, every time they end up getting a website, it's powered by Wordpress hosted in the slowest server you can imagine. And it will end up redirecting you to a propietary service to make your reservation (Whatsapp, Facebook, Instagram...)

At least that's what I see in Europe and south america, I have no clue how it is everywhere else.

I don’t think lack of technical skill implies not valuing freedom. There isn’t really alternatives that are as easy to use and have their clients already on it. They are as much a captive audience as anyone else.

seems fair to correlate "small local businesses that don’t have a web site but do have a Facebook page" with "bad content"

My local butcher provides good content without being terminally online.

Unfortunately this means needing to use Facebook to find out if they’re open on a national holiday.

idk if "only facebook" is worse than no online presence at all

A friend of mine who was a barber asked me how much it would cost to build him a website and I said I would do him a basic 3 page site for free, although he would need to let me know if his opening hours had changed or he needed to tell customers he was on holiday, etc.

He said, with no irony whatsoever, that he didn't realise it would be so complicated and decided not to take me up on the offer. I suspect this attitude is not the unusual with one-man businesses that have survived just fine thus far?

You are right.

I browse the web on Firefox with uBlock Origin, 3rd party cookies disabled, and so on.

So I am missing the bloat most people talk about.

But still apps like Clickup are really slow. It's just bad software.

Probably a bit of both.

Client Side Rendering ( Regardless of Frameworks ) is hip, and gets more media attention. Sometimes backed by VC. It is new, it is complex. And fits both the hype cycle, software engineers complexity attraction, and Resume Driven Development model. And just like the article stated, it is suppose to bring so many good things in its idealogy to the table.

Since majority of software developers wants to works on it, so their Resume gets a tick and could jump to another job later. Management now faces lots of application for these technology and zero for old and boring tech.

>great web programmers who don’t know much (and appear to not WANT to know much) about efficiency.

Remember when Firefox OS developers thought $35 dollar Smartphone will one day take over the world and CPU will be so much faster due to Moore's law, performance will soon becomes irrelevant.

I mean that is like Jeff hates Qualcomm, without actually understanding anything about Mobile SoC business nor the CPU behind it. And how ARM's IP works. A lot of people dont want to know "why" either.

A more accurate description and also a general observation. Most software developers and especially those on Web Development have very little understanding of hardware or low level Software engineering. Cloud Computing makes this even more abstracted.

I have worked with such people. When I asked them specifics about the "result" (HTML, CSS, JS) they looked at me as if I was talking another language. They came from javascript framework world, and there they didn't really think all that much about that.

My philosophy is nearly completely different, I ask myself what the minimum maintainable code is that would produce the equivalent of a well hand coded HTML+CSS+JS website. Usually the result is magnitudes smaller.

One of those people asked me how I did realtime list filtering on 1000 table rows and still have it load fast ans perform well on mobile. While that isn't really a feat, all I sid was deliver the whole data on the first request and then hide non-filtered data dynamically. That means the webserver didn't have to do anything wild, orher than deliver the same cached data to everybody who filters that list and because this was the only javascript going on on that site it was (to them) unusually performant. If you look at a comparable table row from their solution (some framework, didn't have much insight into it) the resulting html was 80% boilerplate that they didn't even use.

Web development is too entrenched and many wandered too far from the essentials of web technology.

About 5 years ago I applied for a job at a company that enabled people in rural Africa to more easily sell the goods they produced (farmers, basket weavers, what-have-you).

If you mainly target people in the US or EU, there's perhaps something to be said for not optimizing too aggressively for low-end hardware and flaky low-bandwidth high-latency connections. But if you're targetting rural Africa fairly aggressive optimisation seems like a no-brainer, right?

Their homepage loaded this 2M gazillion by gazillion pixel image downscaled to 500 by 1000 pixels with CSS. It got worse from there. I don't recall the exact JS payload size, but it was multi-MB – everything was extremely frontend-heavy, which was double ridiculous because it was mostly a "classic" template-driven backend app from what I could see.

I still applied because I liked the concept but the tech was just horrible. I don't really know why it was like this as I never got to the first interview stage, but it's hard to image it's anything other than western European developers not quite realizing what they're doing in this regard.

The website was never intended for people in rural Africa, it was intended for donors and governments in Western countries, so that the company could get juicy grant money and pay themselves to pretend to empower African farmers.

Believe it or not people outside the US actually buy and sell things too! Africa is a primarily mobile first continent with the fastest growing mobile infrastructure and 100 million new handsets sold a year (and that is predicted to double by 2025).

You better believe that I believe it. However, if they were actually trying to get rural people work bad internet connections as customers, they would make a website that was fast and efficient.

we need some html tag or attribute for slow network detection.

instead of this nasty js feature detection that 99% of time no one does.

prefers reduce motion was a good start. although its rarely respected.

Should be easy enough for the server to detect when the connection is slow. That could be done now without having to update the clients and give them more things to process.

The whole point of hierarchical organizations is that those higher up have more influence than those at the lower tiers. Cutting the blame in half doesn’t make sense.

Having worked with the "big scary companies", I can say they are 100% to blame. It doesn't start with the developers but rather the budget. Unless folks at the top are tech savvy and/or have an engineering background, they typically only budget for new features and either under-budget or don't budget for maintenance and tech debt removal. And when they do budget for maintenance, it's handled almost exclusively by "maintenance teams" that are offshore and cheaper.

So you have a feature team that works on a feature for 6 months, does a 1 hour "KT Session" with the offshore maintenance team and hands them the code. The offshore team has some information on the feature but not enough to really manage existing tech debt, just to keep the lights on. And on top of this they know they are the lowest totem on the pole and don't want to get fired so they don't go out of their way to try and fix any existing code or optimize it, again just enough to keep the thing working.

Then this cycle repeats 100-1000x within an org and pretty soon you have a scenario where the frontend has 2M lines of code when it really should be 250k max. A new feature team might come on with the brightest engineers and the best of intentions, but now they have to work within the box that was setup for them. Say they have a number of elements that don't line up with their feature mockups. The mockups might be incorrect, there might have been an upgrade to the UI kit, or the existing UI kit might need refactoring. Problem is none of that is budgeted for so the team is told to just copy the components and modify them for their own use. And of course on handoff to maintenance team, the new team does not want to mess with the existing feature work so they leave it as is. Management is non-technical so they don't know the difference, and you end up with 50+ components all called "Button" in your codebase from years and years of teams constantly copy/pasting to accommodate their new feature.

People who never worked with some of the bloated sites often forgot third party in the bloating.

Marketing team mandating inclusion of at least one "Tag Manager" (if they are especially bad, there will be multiple).

A "Tag Manager" is a piece of JS that is installed together with an API key in the site... and then it downloads whatever extra JS that was configured for given API key. The actual site developer often has absolutely no control over it (the closest I got once was PoC-of-PoC where we tried to put even inclusion of tag manager behind an actually GDPR-compliant consent screen).

Marketing team gets to add "tags" (read, tracking, chat overlays, subscription naggers, whatever), sometimes with extra rules (that also take time processing!), all without involving the development team behind the site.

So marketing department is responsible for web being such a sad and painful experience?

Not the only department.

But consider how much of the bloated JS tends to be from external parties, and pretty much everything that isn't CDN-ed frameworks will be stuff either required by marketing, or flat out added through the use of a tag manager.

money is the top reason for ppl doing stupid shit, yes

Blaming tag managers and marketing departments is quite common and yes while they are problems on some sites many developers overlook the impact of their technology choices e.g. client side rendering, JS based components etc

There's a reason why I speak of "third party", though I guess it might be unclear in english - my bad.

There are three parties involved in the bloating. Management prioritising certain things is one. Developers (including here both programmers and designers and others etc.) not caring enough or otherwise making choices that lead to bloat is second. Marketing team with power to require problematic things added or just going crazy with tag manager is third.

All three are involved in the "bloating crisis".

Is it really hard to believe that the solutions on offer are usually giant piles of steaming crap that do way more than they should but are nevertheless easy to get set up and get going? When programming ecosystems get big, they accumulate a ton of ways of doing things and people keep trying to put a layer on top on top of a layer on top of a layer (like floors in an old house). It doesn't matter if a thing underneath is O(n); someone will put another O(n) thing on top of that that represents all its data as strings and uses regex or horribly-inefficient JSON or something. Very few people ever think things from the ground up.

> there is a large cohort of not that great web programmers who don’t know much

I think you mean “programmers” not just “web programmers”. I’ve worked with plenty of bloated over-engineered Java and C# codebases that take several minutes to start on a very fast developer machine with 32 gigs of RAM. Sometimes, the worst offenders use “lower level” languages! The performance averse problem is endemic in the entire field, not just in the web.

>I like how most people blame bosses or scary big companies.

It ALWAYS starts at the top, no matter how you slice it. Why are the incompetent devs there in the first place?

It might also be people not willing to admit that they don’t know how to optimize website performance. And if you have a somewhat complex web app it can be complicated, especially if your stack doesn’t help you (looking at you React).