Say a client asks for features A, B, C, D which reach the bar of complexity where someone from HN has to get involved. Now two things can happen, and in both cases the same feature set is delivered:
1. All of those features are implemented as a server side web app, with little to no JS a simple CSS stylesheet, and each page is under 100K and loads almost instantly. There is also a simple caching strategy (but not necessarily an obvious one) that speeds the application up further, and allows it scale. The DB design is good, proper indexes have been added, the queries have been thoughtfully planned, etc.
2. The features are implemented as a SPA, and a large framework has been pulled in. Many UI components also pull in other large dependencies. A CSS framework has also been added even though only 1% of it is used, and no attempt to tree shake the CSS or JS has been made. The page size is over 3MB. No DB optimizations or caching has been added, etc.
Note this is far from a straw man. 2. is by far the most common approach, even among "professionals".
Option 2 would of course be a SSR React MPA these days, not a SPA, so we have to worry about NPM supply chain attacks server-side too.
Option 1 can be done by one sensible person with intermediate PHP/Python knowledge, and maintained fairly easily and cheaply forever.
They're different jobs. You can take the interview for that option 2, and you can push for doing option 1 instead. What will end up happening is that they employ someone else.
(I speak as someone who spent a couple of months in the mid-2000s mostly writing a partial XPath implementation in Flash ActionScript, to be used in a single product to interface with one other 3rd-party system. It was a stupid idea from day 1 and definitely not mine, yet that was the job! The insanity is not new.)
> Option 1 can be done by one sensible person with intermediate PHP/Python knowledge, and maintained fairly easily and cheaply forever.
This a vast underestimate of the amount of knowledge it takes to do 1. well, for a project of any complexity. Doing the simple thing well is hard. Indeed, one of the reasons that option 2 has skyrocketed in popularity is because a larger number of mediocre devs can "get the job done" using that method.
> They're different jobs. You can take the interview for that option 2
What you are saying is that there is a lot of non-technical pressure to do option 2. I couldn't agree more. It doesn't make it any less absurd.
I agree to an extent, but a person who's managed to end up doing the simple thing (option 1) has a superpower! They're able to say "no". That makes simplicity much much more achievable. If you can't refuse to keep adding crap then yes, simplicity is very very hard.
I honestly think most people who are currently doing an option 2, and are capable of some restraint, would find it easier to do option 1. And if they were allowed, and if it paid as well or better than option 2, and if their career prospects were improved by doing it, they would.
Absurd is the right word, but that's just the world we live in. Why am I paid more than a doctor? Madness.
Arguably, option 2 soft-caps their technical progression because their day is spent untangling things, keeping up with dependency updates, and other makework that can spawn from not corralling complexity. However, in some sense, they have consciously chosen this approach, and associated with like-minded people.
Using a big brush here, but webdev has a LOT of this “just throw tons of libs at it and hope for the best.” I ran away screaming once I got a taste of that. It is antithetical to what I want out of my career. And it seems to breed a lack of rigor, exemplified by how many people complain of “slow tests” but refuse to refactor in such a way to make them faster. IOW, you don’t want fast tests as much as you want to bitch on Twitter.
Plus, long-term I believe option 2 is somewhat dangerous: there’s a huge pool of applicants looking to employ the same approach. Why pay a premium for those skills? What’s your differentiator?
> Using a big brush here, but webdev has a LOT of this “just throw tons of libs at it and hope for the best.”
My experience matches this. And not only that, many of them will passionately argue in favor of this approach, under mantras like "I ship" and "it gets the job done", and dismiss attempts at corralling complexity as fussy and wasteful.
Yep. I feel like I’ve watched the web lay waste to any sort of collective technical aesthetic. It’s a combination of huge numbers of new devs entering, SEO, and everyone chasing the short tail of devs who are 1-5 years into their career.
It almost feels like it is a bit gauche to actually talk about programming itself. Instead, you’re supposed to be talking about microservices vs monoliths, k8s, monorepos, or some other inanity. Though this is not exclusive to devs: guitarists write books on gear and then a few sentences on actual technique in most forums. Something about our platforms seems to actively resist deep content.
It’s been pretty alienating for me. I work with other technologists in R&D and that is great, but when I glance at industry, I see a ton of self-inflicted wounds paired with denial that there’s even a problem.
Say a client asks for features A, B, C, D which reach the bar of complexity where someone from HN has to get involved. Now two things can happen, and in both cases the same feature set is delivered:
1. All of those features are implemented as a server side web app, with little to no JS a simple CSS stylesheet, and each page is under 100K and loads almost instantly. There is also a simple caching strategy (but not necessarily an obvious one) that speeds the application up further, and allows it scale. The DB design is good, proper indexes have been added, the queries have been thoughtfully planned, etc.
2. The features are implemented as a SPA, and a large framework has been pulled in. Many UI components also pull in other large dependencies. A CSS framework has also been added even though only 1% of it is used, and no attempt to tree shake the CSS or JS has been made. The page size is over 3MB. No DB optimizations or caching has been added, etc.
Note this is far from a straw man. 2. is by far the most common approach, even among "professionals".