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.
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.
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.
You think developers prioritize business value? That isn't how employment works.
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”.
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.
Unfortunately this means needing to use Facebook to find out if they’re open on a national holiday.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
It ALWAYS starts at the top, no matter how you slice it. Why are the incompetent devs there in the first place?