8 ms·

The deskilling of web dev is harming us all

83 points by loop22 2y ago

sonthonax 2y ago
> Service workers, which require a completely different mode of thinking from the rest of front-end development and have more in common with web server programming than DOM manipulation. This is spoken like a true front end developer who's never used a thread before.
- deleted 2y ago
  [deleted]
calderwoodra 2y ago
Find a few good tools, understand why they're good, use them extensively and pick up others when needed (i.e. when you switch jobs or face a new problem). It's really not that hard...
isaacremuant 2y ago
Hard to sympathise. Generalizes like mad. Stop being a full stack. Have something you do well and you should have little problems in this industry. There's so much work an opportunities.
- anonzzzies 2y ago
  > There's so much work an opportunities. Many of them suck though. I get hired as a troubleshooter usually: that makes the most and it’s nice, get to see many companies etc. I work with people who are hired for frontend, backend etc; a month or so in, they will be asked things like ‘so devops, is that something you can do?’ Etc. And that is if it’s not in the actual job offer; ‘frontend expert wanted with 4000 years experience in everything’. I usually leave after 3-6 months as I ask a lot of money, but I have been asked to advice and help on Windows upgrades, printer emergencies and more.
  - isaacremuant 2y ago
    Well then you're not selling yourself well. Stop taking shit jobs. Brand yourself better.
    - anonzzzies 2y ago
      I have always just done exactly what I want; I just see people around me who get roped into crap.
dj_mc_merlin 2y ago
I feel like the deskilling of web dev is that the web dev in this article doesn't feel competent enough to learn HTML, CSS _and_ Javascript at the same time.
txdv 2y ago
This went from CSS framework bad to capitalism is bad really quick
- deleted 2y ago
  [deleted]
- cess11 2y ago
  The article doesn't refer to capitalism. What in the article are you identifying as references to capitalism?
  - txdv 2y ago
    > And nothing coming out of either the US or Europe comes close to addressing the true problem, which is that these companies are simply too big. The tech industry will never be a genuinely free market as long as big tech companies are allowed to be as big as they are today. What we have today is a centrally-planned economy by MBA sociopaths, operated as a looting ground for the rich. It will never function on normal competitive, supply-and-demand market principles. Because, even though a healthier market is the only thing that has a hope of a return to the fast-growing tech industry of prior decades, it would also require big tech companies to accept a smaller slice of the overall pie and allow new competitors to grow. Why do that when you can strangle the market and keep the entire corpse for yourself?
    - cess11 2y ago
      OK, and you consider oligopolies like these capitalistic, as well as assume that the author does too?
  - tmaly 2y ago
    I would not even qualify the gripes about big tech in the article as being capitalism. What we have today is something closer to corporatism.
  - mablopoule 2y ago
    I do agree with the grandparent, I was a bit surprised too in the last paragraphs that the article's solution to frontend overengineering is to unionize. Though true, the articles doesn't go into 'capitalism = bad'.
brigadier132 2y ago
I would absolutely hate working in an environment where I had to wait for someone to write the css for me before I could ship code I wrote. > These are all distinct specialities and web dev teams should be composed of cross-functional specialists. I completely disagree and also thankfully this will never happen because it's completely impractical.
Xenoamorphous 2y ago
I think the “full stack” trend is harmful. Yes it sounds nice in theory but there’s so many things to learn both in front and back end parts that I’m yet to meet a true “full stack web dev” even if they all claim to be. Yes a guy who’s done backend all his career can write some basic HTML and CSS and some JS. And some frontend guy can write a simple server side code that writes and reads from a datastore. But they’re not “full stack” in my eyes, there had to be some balance in terms of knowledge in both areas; 60-40 would be ok, but 90-10 is not. When I joined the company I work for over a decade ago there were backend guys doing frontend; yes they delivered something but frontend quality was poor. Now it’s the opposite, frontend guys doing backend (and of course they don’t want to deal with SQL so NOSQL it is); same thing. Nothing beats a frontend and a backend dev (or multiple) working in tandem, IMO.
- sgarland 2y ago
  I have been saying this for years. The opinion has become even firmer since moving into DB specialization – the horror show of schemata and queries that even dedicated backend teams dream up is unreal. I don’t even really blame them; relational databases are hard. Yes, anyone can install Postgres (or spin up a managed service) and get decent results for quite some time, but at scale you absolutely have to know what you’re doing. There is a reason that DBAs were a thing, and the SaaS industry is slowly realizing that they shouldn’t have abandoned that role.
  - deleted 2y ago
    [deleted]
  - rrr_oh_man 2y ago
    > at scale you absolutely have to know what you’re doing There's a lot of runway you hit that magic scale: https://news.ycombinator.com/item?id=39276069 https://news.ycombinator.com/item?id=39276069
    - sgarland 2y ago
      Yes, but the runway is a good deal shorter if you’re doing things as most dev teams without RDBMS knowledge do. The biggest three issues unfortunately build on each other: Using JSON when you really should be properly normalizing your schema (or using a DB better suited for JSON). Using UUIDs – especially UUIDv4 – for any indexed columns, especially as PKs. Using Postgres for no actual reason other than it’s popular. MySQL / InnoDB is a clustering index RDBMS, which can have massive performance improvements over others IFF you build your schema around it. If you use anything non-k-sortable (e.g. UUIDv4) as your PK, it suffers massive performance degradation instead. So you use Postgres instead, and think you’re immune. Wrong – its MVCC implementation means you’ll have approximately 7x read amplification for Visibility Map lookups under the same circumstances, and huge amounts of WAL bloat, which can also lead to increased network latency. JSON[B] in Postgres is frequently TOASTed due to its size. The overhead from TOAST/DETOAST isn’t small, and you also have to deal with difficulties indexing the column, and you can’t as of yet do a partial update to a JSON column. MySQL can do partial updates, doesn’t have TOAST, and has better (still annoying) strategies for extracting scalars from them to be indexed as a quasi-sidecar lookup, but it lacks GIN/GiST index types. I’ve personally ran a single MySQL instance with over 100K QPS, and it had the plenty of runway, and a ton of vertical scaling left. This was with very careful tuning, and a suboptimal schema. I’m sure it could go far higher if everything was done correctly from the start.
edlebert 2y ago
This is sarcasm, right?
bambax 2y ago
> Framework skills are perishable, but are easily just as complicated as the foundation layers of the web platform and it takes just as much – if not more – effort to keep them up to date. That's so true. For my own projects I try to not use any framework at all (or sometimes still use Backbone, which is entirely deprecated but simple, and that I know well enough). But of course, as an employee many times you don't have a choice. I was recently part of an Angular team (Angular 2). That was one of my most unpleasant experiences. Angular seems to revel in complexity for complexity's sake. And it's often not needed at all. In that case it was used for displaying information that lives server side and is constantly updated there (live inventory). Why would they need a big client for that?
- bdlowery 2y ago
  > I try not to use any framework at all Aka “I like living in 1999” Lol
deadbabe 2y ago
There’s more to life than web dev. Backends for instance.
deleted 2y ago
[deleted]
steveBK123 2y ago
As a backend guy I uhh.. have long been of the opinion that web dev was always on the slippery slope of deskilling. I remember working on a project where I was lone backend guy doing data storage/retrieval/aggregation/caching/entitelement/etc all behind a discoverable API that fed the UI everything it needed in a handful of calls. Meanwhile the web dev guy took 6 weeks of iteration to create a date selector that wasn't awful. Felt like they were too busy getting stuck gluing together frameworks they didn't understand and thus couldn't integrate well, and not simply writing a little code. When he finally got it working, it was still awful. You had to select start date, start time, end date, end time.. and if you didn't proceed in the prescribed order the other selector boxes would reset and go wonky, lol.
- BehindBlueEyes 2y ago
  Sounds like you worked at squarespace... The date picker of their events creation feature works just like that, among other problems with their date selection support like not handling recurring dates...
deleted 2y ago
[deleted]
zx8080 2y ago
A honest question. Could someone tell why is CSS getting more and more complex (other than Google and Co. want to protect their browser's market share and hold control of it)?
- brigadier132 2y ago
  CSS is easier than it's ever been
- konfusinomicon 2y ago
  because people got tired of slicing up drop shadows into 8 meticulously placed transparent PNGs
- err4nt 2y ago
  It's not getting more complex, because the easy stuff you have always been able to do is still there the exact same, as easy as it's always been. There is more of CSS now, so you have more power to express styles for more mediums in better ways, but you only need to use what you want so you don't need to make things complicated at all.
madeofpalk 2y ago
I'm curious about what the author of this article expects? That all APIs remain frozen in time forever? That new APIs are only something that happens in the frontend? > The framework knowledge itself is also perishable. Not because your memory or physical coordination deteriorates (though that happens too), but because frameworks change more and faster than the underlying platform. > But the React skills I have are all out of date and obsolete. I would effectively have to start from scratch even if I wanted to get back into React work. Everything React has changed in ways that are fundamentally incompatible. I'm lost as to what the author is talking about. I've been using React for... 9-10 years now. There's been two API changes to React in that time - functional components and hooks. Neither of these are rocket science, and they're also able to be completely ignored and you can stick to your existing knowledge if you so chose to. I don't feel like 2 API changes in 10 years is that radical.
Havoc 2y ago
>CSS >HTML >JavaScript > in a sensible industry, would each be a dedicated field. I get that webdev is a maze of frameworks, but that's just ridiculous.
- threatofrain 2y ago
  HTML has been stagnant for so long that as a document-oriented language... it doesn't even have a table of contents element! Or a bibliography!
  - err4nt 2y ago
    HTML Custom Elements would allow you to define and provide support for your own <table-of-contents> element, so you could use it, and all browsers would understand it, and dev tools and CSS and JavaScript and all other HTML would work fine with it.
    - threatofrain 2y ago
      All that can be done without semantics. But HTML is also a document-oriented semantic language. Your way would just have idiosyncratic elements, which is little different than a div from the perspective of the rest of the world.
      - err4nt 2y ago
        I think what you're calling "my way" is just what HTML is designed to be in its own specification. Custom elements have been in the spec for over a decade and are supported everywhere, they're as legit as any other part of standard HTML.
        threatofrain 2y ago
        To descriptively move the needle on the semantics of custom elements you must first move the world. Any semantics you attach to your custom elements really is just your semantics. If you want this to change then start persuading everyone that your custom elements ought be semantically observed. Until then, a custom element is just a div. Semantically opaque. When we have actual consensus on elements and semantics, that enables very rich clients that can provide an alternative view over the same information, regardless of prior styling. For example, imagine if hovering over any time element will also show you a visual ticking clock or calendar. We wouldn't be able to do that if we didn't have consensus on the semantic meaning of time as something more than a valid token for a parser.
brhsagain 2y ago
I dunno. On the one hand I hate “web dev” more than anyone. I think it has led to such an astronomical decline in software quality that if you described it to someone from the days when computers were 1000x slower, they straight up wouldn’t believe you. That said… the article doesn’t really ring true to me. What he is saying about the complexity of each part of the stack (http, html/dom, css) is technically true, but that’s not really how it washes out in practice. This whole “CSS is a complex graphics engine!” “HTTP is a protocol you could write a whole dissertation about!” sounds like an argument being made by someone trying to make a rhetorical point about web. In practice for most of web dev you don’t need to understand the deep nuances of CSS or HTTP or whatever. Yes, there is a large breadth of material you have to learn but the depth you actually need in any one area is much less than the author is trying to imply. And yes, web is trash, but for different reasons. In fact some of those reasons are the opposite of what the author is saying. He says that each part of the stack is so complex it should be a separate specialty. But the real problem is the very fact that things are so complex. Rather than accept that complexity and subdivide the field into different disciplines, we should get rid of all this unneeded complexity to begin with.
- sgarland 2y ago
  > On the one hand I hate “web dev” more than anyone. I think it has led to such an astronomical decline in software quality that if you described it to someone from the days when computers were 1000x slower, they straight up wouldn’t believe you. Nearly all of this, IMO, can be explained by a lack of passion. I grew up on computers, starting in the 90s. I didn't have internet access until near the end of the decade, and it was slow dial-up. If you broke the family computer, you had to figure out not only how you had broken it, but how to fix it. When I found Linux (Gentoo, obviously, because it's way more fun to spend days tweaking CLFAGS than to use the software), I was also thrust into forum culture, which was rife with RTFM. You quickly learn either to search and read docs, and demonstrate a modicum of capability and effort, or you lose interest and do something else. This is not the case now. Even before the advent of LLMs, it wasn't that hard to find the answer to most of your questions on SO. The rise of cloud computing means that you don't have to know how to run a computer, you just have to know how to talk to an API – and even then, only at a surface level. You can pretend that TCP doesn't exist, have no idea how disks magically appear on-demand (let alone what a filesystem is), etc. Databases, which used to be magical black boxes that you accessed via queries carefully written by wizened graybeards, are now magical black boxes that you abuse with horrifying schema and terrible queries. Worse, you don't even have to know their lingua franca, and can commit your crimes via an ORM, which probably sucks. And for all of this abstraction, you are paid handsomely. The difficulty in landing your first job is tremendously high, sure, but the payoff is enormous. Once you're in, you'll find that the demands of most businesses is not to upskill, but to push features out faster. Grow the user base, beat others to market, and dazzle VCs. No one has time for doing things right, because that slows down velocity. This is aided and abetted by Agile, specifically Scrum. Aside from maintaining the cottage industry of Agile consultancies, it's designed to turn software production into a factory, where no one person really needs to know how to do anything tremendously complex. Instead of insisting that people learn how to do difficult things, we spend hours per week breaking down tasks into bite-sized increments with absurd abstractions of time. "Thought leaders" deserve a callout here as well for their contributions to this mess. Microservices are a great example. A potentially useful architecture in some circumstances has been turned into gospel that people buy into without question, and apply everywhere regardless of its utility or fit. If you're lucky, someone eventually notices that rendering a page seems to take a lot longer than it should, but more often than not this is met with a shrug, or at best blaming the DB and paying AWS for a larger instance. Multiple network calls that each have to traverse N layers of routing and queues is slower than calls within a single process? Color me surprised. When you combine the allure of a high-paying job that has little barrier to entry with no business incentives to do things differently, you get what we have today.
thih9 2y ago
> Testing, irrespective of the language or platform, is yet another complex specialisation we all just pretend doesn’t exist. Speak for yourself, me and my team use a CI and always add or fix tests right before merging any PR. (this is a joke, test suite is most useful when it’s part of the dev process and not an afterthought as I’m implying above)
yousif_123123 2y ago
I don't fully disagree, but this might be subjective. For me as a full stack developer working with small teams/startup, I actually don't consider myself full stack. I just want to be able to do whatever it takes to make a product and ship features. Does it need a websocket server? I'll learn how to do that. Does it need advanced client side caching? I can do that, etc. To some extent "product development" is both art and engineering. In the engineering side, you can think of html and CSS and http and testing as different things requiring a multidisciplinary team.. but if you think just in terms of "building the thing", I like to feel that I can get it done with whatever technology needed. That's why I got into programming in the first place. Not to write code and be an "engineer", but to make the computer do cool things. AI does expand the capabilities of someone that wants to get things done. I have written in languages that I don't have experience with, and recently was exploring a neo4j db with cypher queries written with ChatGPT (I have only MongoDB experience), something that would've taken me hours to learn. Still, having experts in specific areas in a team can be very helpful (both to get technically difficult things done but also to have others learn from them). I just don't want to be 1 part of a team specializing in my limited domain, where I start to care more about the technical part than the actual value delivered or user experience.. I think what might cause me to burnout is too much specializing, too much bureaucracy, people telling me I can't do this, we need to hire a staff level person to this thing etc..
wlindley 2y ago
"De-skilling" would be a better way to write this. I was halfway through before realizing it wasn't about "desk-killing" or the pretending that workers are incorporeal gossamer entities that do not have to physically interact with the real world. (a/k/a "remote work")
onion2k 2y ago
Judging by many websites, I think a lot of new web developers choose to tackle the problem of having too much to learn by not bothering.
mediumsmart 2y ago
Easy to fix. Every client should have the delivered site go through pagespeed.web.dev and when there are 4 green circles around the four 100s the webdesigner gets paid provided the client likes the site. This is not an OR gate
ilaksh 2y ago
My take on this is that we have multiplied the number of potential ways to build a web application continuously for decades. And now there are a combined 10,000 (pick a number) viable (but not trendy) ways to make a web application. The interesting thing to me is that ultimately businesses don't care how it works. They just want it to work. Which means that you can pick a small framework or two across the frontend and backend and configure or train an AI system on only a tiny fraction of the sum total of web development knowledge and have an effective automated web development system. Looking at the trajectory of gpt4 to gpt-4o and Llama2 to llama3, the prevalence of multimodality, improved reasoning ability as models get bigger, strong investment in hardware research, etc. I've been doing web development in some capacity since the late 90s and focused on leveraging generative AI for the last two years. I don't see how any reasonable person can follow this stuff closely and not anticipate AI systems that can literally do the entire job of a small web development team, within just a few years. It was actually possible to build a version of that two years ago, and some of the latest attempts are very polished, if lacking in some level of functionality. But that is coming. Every single job that we have today will be automated. I assume they means that people will be left basically herding swarms of AI agents. For a few years. But it won't be very long before you really need an AI to control your agent swarms or even understand what they are doing.
deleted 2y ago
[deleted]
5350-uiop-1130 2y ago
"The ongoing labour arbitrage – the deskilling of developers – can only be addressed with collective bargaining and union action." web dev does feel more like cheap labor work tbh. aside from a few exceptions. mostly tedious grunt work.
mablopoule 2y ago
This article hit close to home (maybe not the last part). In my last few jobs, I'm horrified at how (mis)treated CSS and HTML is. <rant mode on> Very recently, I had the displeasure of coming back from a 3-weeks long vacation and discovering that the rest of the team added Angular Material on the project, and started to sprinkle it everywhere in the code. Despite me (the only front-end guy in a team otherwise constituted only fullstack devs that are really more backend devs dabbling in frontend) asking them to not add Angular Material or any 'UI library', because this project is very simple, a mobile-only classic layout with a few simple forms. Nothing in the designer's mockup for this project looked like Material Design, nothing; But since Angular Material is marketed as basically being part of Angular, then they told me that it was "good practice", and "a way to save time". As a result, instead having a clean DOM with a few classes and basically just a border-radius on the buttons, they did tons of ugly CSS to overwrite the Material styling that they themselves added, all in the explicit aim for them to avoid doing any CSS at all, ironically. Just to reiterate, it's really a super simple app with a sticky header and footer, some form with a few borders, and some rounded buttons. I already did for them the main layout (it was basically a dozen or so CSS lines), but they ignored it all to add underneath tons of stupid Material components. I mean look at this crap: https://material.angular.io/components/toolbar/overview https://material.angular.io/components/toolbar/overview <mat-toolbar> is a component that was actually imported in the project, which: - does not have any JS behavior - does not handle positioning (you can do it yourself with flex! How powerful!) - does not have any ARIA role attached. - but DO have a default color and background, thanks to the customizable Material palette! In other word, it's a fucking <div> with a default background, but props to the Angular Material marketing and the mountain of content marketing out there to brainwash hordes of webdev into thinking that it's simpler to import an external dependency than to specify a background in one class. Another example, here is the doc for the '<mat-divider>' component: https://material.angular.io/components/divider/overview https://material.angular.io/components/divider/overview I understand why a Google designer would specify such element in a plateform-agnostic way, but for everyone else who's working in a web project that only used Material to 'save time', then why the hell would you import and use this component instead of just using the native <hr> tag available since the nineties ? It's easier I guess, oh except for the planned migration to Material M3 that you will have to do in a few years if you want to be able to upgrade to the latest version of Angular, but I guess that adding some borders and some margins is just incredibly hard. <rant mode off/> The saddest part of all is that I love doing frontend dev in general, and as the articles point out the fundamentals of HTML/CSS/JS are incredibly stable and retro-compatible, yet all the ecosystem keep piling layers and layers of crap all in the sake of 'DX' and of 'good practice' (that seems to change every 6 months). I do believe in the CSS case is that it looks too simple, deceptively even, so one can dabble in it without knowing the fundamentals, and so I believe that looks like CSS is broken the first time a junior dev has something with "position: absolute" that isn't positionned the way they expect, or when they find themselves coding in JS something that could be done with a handy CSS selector, out of ignorance of the available selectors. As a result of this apparent simplicity of CSS, I think that there is a general reluctance to 'respect' the language enough to try to learn it really, which makes for more piles of broken CSS riddled with !important, and thus more people believing that CSS and HTML is fundamentally crap. EDIT: I'm not critizising Angular Material in particular. I the React ecosystem I actually saw some 'UI component library' proposing elements to have bold or italic text. Yeeesh.
luke-stanley 2y ago
It starts off as articulate and then, I felt the arguments were less clear. It seems perhaps ungrounded. It's nice they have energy in a way but it also seems vaguely conspiratorial, rather than emergent. I've nothing against people seeking a better lot in life and collaborating or pointing out typical flaws and rent seeking. I wish the perspective was easier to follow, I'm curious.

83 points by loop22 2y ago

> Service workers, which require a completely different mode of thinking from the rest of front-end development and have more in common with web server programming than DOM manipulation. This is spoken like a true front end developer who's never used a thread before.

deleted 2y ago
[deleted]

calderwoodra 2y ago

Find a few good tools, understand why they're good, use them extensively and pick up others when needed (i.e. when you switch jobs or face a new problem). It's really not that hard...

isaacremuant 2y ago

Hard to sympathise. Generalizes like mad. Stop being a full stack. Have something you do well and you should have little problems in this industry. There's so much work an opportunities.

anonzzzies 2y ago
> There's so much work an opportunities. Many of them suck though. I get hired as a troubleshooter usually: that makes the most and it’s nice, get to see many companies etc. I work with people who are hired for frontend, backend etc; a month or so in, they will be asked things like ‘so devops, is that something you can do?’ Etc. And that is if it’s not in the actual job offer; ‘frontend expert wanted with 4000 years experience in everything’. I usually leave after 3-6 months as I ask a lot of money, but I have been asked to advice and help on Windows upgrades, printer emergencies and more.
- isaacremuant 2y ago
  Well then you're not selling yourself well. Stop taking shit jobs. Brand yourself better.
  - anonzzzies 2y ago
    I have always just done exactly what I want; I just see people around me who get roped into crap.

dj_mc_merlin 2y ago

I feel like the deskilling of web dev is that the web dev in this article doesn't feel competent enough to learn HTML, CSS _and_ Javascript at the same time.

txdv 2y ago

This went from CSS framework bad to capitalism is bad really quick

deleted 2y ago
[deleted]
cess11 2y ago
The article doesn't refer to capitalism. What in the article are you identifying as references to capitalism?
- txdv 2y ago
  > And nothing coming out of either the US or Europe comes close to addressing the true problem, which is that these companies are simply too big. The tech industry will never be a genuinely free market as long as big tech companies are allowed to be as big as they are today. What we have today is a centrally-planned economy by MBA sociopaths, operated as a looting ground for the rich. It will never function on normal competitive, supply-and-demand market principles. Because, even though a healthier market is the only thing that has a hope of a return to the fast-growing tech industry of prior decades, it would also require big tech companies to accept a smaller slice of the overall pie and allow new competitors to grow. Why do that when you can strangle the market and keep the entire corpse for yourself?
  - cess11 2y ago
    OK, and you consider oligopolies like these capitalistic, as well as assume that the author does too?
- tmaly 2y ago
  I would not even qualify the gripes about big tech in the article as being capitalism. What we have today is something closer to corporatism.
- mablopoule 2y ago
  I do agree with the grandparent, I was a bit surprised too in the last paragraphs that the article's solution to frontend overengineering is to unionize. Though true, the articles doesn't go into 'capitalism = bad'.

brigadier132 2y ago

I would absolutely hate working in an environment where I had to wait for someone to write the css for me before I could ship code I wrote. > These are all distinct specialities and web dev teams should be composed of cross-functional specialists. I completely disagree and also thankfully this will never happen because it's completely impractical.

Xenoamorphous 2y ago

I think the “full stack” trend is harmful. Yes it sounds nice in theory but there’s so many things to learn both in front and back end parts that I’m yet to meet a true “full stack web dev” even if they all claim to be. Yes a guy who’s done backend all his career can write some basic HTML and CSS and some JS. And some frontend guy can write a simple server side code that writes and reads from a datastore. But they’re not “full stack” in my eyes, there had to be some balance in terms of knowledge in both areas; 60-40 would be ok, but 90-10 is not. When I joined the company I work for over a decade ago there were backend guys doing frontend; yes they delivered something but frontend quality was poor. Now it’s the opposite, frontend guys doing backend (and of course they don’t want to deal with SQL so NOSQL it is); same thing. Nothing beats a frontend and a backend dev (or multiple) working in tandem, IMO.

sgarland 2y ago
I have been saying this for years. The opinion has become even firmer since moving into DB specialization – the horror show of schemata and queries that even dedicated backend teams dream up is unreal. I don’t even really blame them; relational databases are hard. Yes, anyone can install Postgres (or spin up a managed service) and get decent results for quite some time, but at scale you absolutely have to know what you’re doing. There is a reason that DBAs were a thing, and the SaaS industry is slowly realizing that they shouldn’t have abandoned that role.
- deleted 2y ago
  [deleted]
- rrr_oh_man 2y ago
  > at scale you absolutely have to know what you’re doing There's a lot of runway you hit that magic scale: https://news.ycombinator.com/item?id=39276069 https://news.ycombinator.com/item?id=39276069
  - sgarland 2y ago
    Yes, but the runway is a good deal shorter if you’re doing things as most dev teams without RDBMS knowledge do. The biggest three issues unfortunately build on each other: Using JSON when you really should be properly normalizing your schema (or using a DB better suited for JSON). Using UUIDs – especially UUIDv4 – for any indexed columns, especially as PKs. Using Postgres for no actual reason other than it’s popular. MySQL / InnoDB is a clustering index RDBMS, which can have massive performance improvements over others IFF you build your schema around it. If you use anything non-k-sortable (e.g. UUIDv4) as your PK, it suffers massive performance degradation instead. So you use Postgres instead, and think you’re immune. Wrong – its MVCC implementation means you’ll have approximately 7x read amplification for Visibility Map lookups under the same circumstances, and huge amounts of WAL bloat, which can also lead to increased network latency. JSON[B] in Postgres is frequently TOASTed due to its size. The overhead from TOAST/DETOAST isn’t small, and you also have to deal with difficulties indexing the column, and you can’t as of yet do a partial update to a JSON column. MySQL can do partial updates, doesn’t have TOAST, and has better (still annoying) strategies for extracting scalars from them to be indexed as a quasi-sidecar lookup, but it lacks GIN/GiST index types. I’ve personally ran a single MySQL instance with over 100K QPS, and it had the plenty of runway, and a ton of vertical scaling left. This was with very careful tuning, and a suboptimal schema. I’m sure it could go far higher if everything was done correctly from the start.

edlebert 2y ago

This is sarcasm, right?

bambax 2y ago

> Framework skills are perishable, but are easily just as complicated as the foundation layers of the web platform and it takes just as much – if not more – effort to keep them up to date. That's so true. For my own projects I try to not use any framework at all (or sometimes still use Backbone, which is entirely deprecated but simple, and that I know well enough). But of course, as an employee many times you don't have a choice. I was recently part of an Angular team (Angular 2). That was one of my most unpleasant experiences. Angular seems to revel in complexity for complexity's sake. And it's often not needed at all. In that case it was used for displaying information that lives server side and is constantly updated there (live inventory). Why would they need a big client for that?

bdlowery 2y ago
> I try not to use any framework at all Aka “I like living in 1999” Lol

deadbabe 2y ago

There’s more to life than web dev. Backends for instance.

deleted 2y ago

[deleted]

steveBK123 2y ago

As a backend guy I uhh.. have long been of the opinion that web dev was always on the slippery slope of deskilling. I remember working on a project where I was lone backend guy doing data storage/retrieval/aggregation/caching/entitelement/etc all behind a discoverable API that fed the UI everything it needed in a handful of calls. Meanwhile the web dev guy took 6 weeks of iteration to create a date selector that wasn't awful. Felt like they were too busy getting stuck gluing together frameworks they didn't understand and thus couldn't integrate well, and not simply writing a little code. When he finally got it working, it was still awful. You had to select start date, start time, end date, end time.. and if you didn't proceed in the prescribed order the other selector boxes would reset and go wonky, lol.

BehindBlueEyes 2y ago
Sounds like you worked at squarespace... The date picker of their events creation feature works just like that, among other problems with their date selection support like not handling recurring dates...

deleted 2y ago

[deleted]

zx8080 2y ago

A honest question. Could someone tell why is CSS getting more and more complex (other than Google and Co. want to protect their browser's market share and hold control of it)?

brigadier132 2y ago
CSS is easier than it's ever been
konfusinomicon 2y ago
because people got tired of slicing up drop shadows into 8 meticulously placed transparent PNGs
err4nt 2y ago
It's not getting more complex, because the easy stuff you have always been able to do is still there the exact same, as easy as it's always been. There is more of CSS now, so you have more power to express styles for more mediums in better ways, but you only need to use what you want so you don't need to make things complicated at all.

madeofpalk 2y ago

I'm curious about what the author of this article expects? That all APIs remain frozen in time forever? That new APIs are only something that happens in the frontend? > The framework knowledge itself is also perishable. Not because your memory or physical coordination deteriorates (though that happens too), but because frameworks change more and faster than the underlying platform. > But the React skills I have are all out of date and obsolete. I would effectively have to start from scratch even if I wanted to get back into React work. Everything React has changed in ways that are fundamentally incompatible. I'm lost as to what the author is talking about. I've been using React for... 9-10 years now. There's been two API changes to React in that time - functional components and hooks. Neither of these are rocket science, and they're also able to be completely ignored and you can stick to your existing knowledge if you so chose to. I don't feel like 2 API changes in 10 years is that radical.

Havoc 2y ago

>CSS >HTML >JavaScript > in a sensible industry, would each be a dedicated field. I get that webdev is a maze of frameworks, but that's just ridiculous.

threatofrain 2y ago
HTML has been stagnant for so long that as a document-oriented language... it doesn't even have a table of contents element! Or a bibliography!
- err4nt 2y ago
  HTML Custom Elements would allow you to define and provide support for your own <table-of-contents> element, so you could use it, and all browsers would understand it, and dev tools and CSS and JavaScript and all other HTML would work fine with it.
  - threatofrain 2y ago
    All that can be done without semantics. But HTML is also a document-oriented semantic language. Your way would just have idiosyncratic elements, which is little different than a div from the perspective of the rest of the world.
    - err4nt 2y ago
      I think what you're calling "my way" is just what HTML is designed to be in its own specification. Custom elements have been in the spec for over a decade and are supported everywhere, they're as legit as any other part of standard HTML.
      - threatofrain 2y ago
        To descriptively move the needle on the semantics of custom elements you must first move the world. Any semantics you attach to your custom elements really is just your semantics. If you want this to change then start persuading everyone that your custom elements ought be semantically observed. Until then, a custom element is just a div. Semantically opaque. When we have actual consensus on elements and semantics, that enables very rich clients that can provide an alternative view over the same information, regardless of prior styling. For example, imagine if hovering over any time element will also show you a visual ticking clock or calendar. We wouldn't be able to do that if we didn't have consensus on the semantic meaning of time as something more than a valid token for a parser.

brhsagain 2y ago

I dunno. On the one hand I hate “web dev” more than anyone. I think it has led to such an astronomical decline in software quality that if you described it to someone from the days when computers were 1000x slower, they straight up wouldn’t believe you. That said… the article doesn’t really ring true to me. What he is saying about the complexity of each part of the stack (http, html/dom, css) is technically true, but that’s not really how it washes out in practice. This whole “CSS is a complex graphics engine!” “HTTP is a protocol you could write a whole dissertation about!” sounds like an argument being made by someone trying to make a rhetorical point about web. In practice for most of web dev you don’t need to understand the deep nuances of CSS or HTTP or whatever. Yes, there is a large breadth of material you have to learn but the depth you actually need in any one area is much less than the author is trying to imply. And yes, web is trash, but for different reasons. In fact some of those reasons are the opposite of what the author is saying. He says that each part of the stack is so complex it should be a separate specialty. But the real problem is the very fact that things are so complex. Rather than accept that complexity and subdivide the field into different disciplines, we should get rid of all this unneeded complexity to begin with.

sgarland 2y ago
> On the one hand I hate “web dev” more than anyone. I think it has led to such an astronomical decline in software quality that if you described it to someone from the days when computers were 1000x slower, they straight up wouldn’t believe you. Nearly all of this, IMO, can be explained by a lack of passion. I grew up on computers, starting in the 90s. I didn't have internet access until near the end of the decade, and it was slow dial-up. If you broke the family computer, you had to figure out not only how you had broken it, but how to fix it. When I found Linux (Gentoo, obviously, because it's way more fun to spend days tweaking CLFAGS than to use the software), I was also thrust into forum culture, which was rife with RTFM. You quickly learn either to search and read docs, and demonstrate a modicum of capability and effort, or you lose interest and do something else. This is not the case now. Even before the advent of LLMs, it wasn't that hard to find the answer to most of your questions on SO. The rise of cloud computing means that you don't have to know how to run a computer, you just have to know how to talk to an API – and even then, only at a surface level. You can pretend that TCP doesn't exist, have no idea how disks magically appear on-demand (let alone what a filesystem is), etc. Databases, which used to be magical black boxes that you accessed via queries carefully written by wizened graybeards, are now magical black boxes that you abuse with horrifying schema and terrible queries. Worse, you don't even have to know their lingua franca, and can commit your crimes via an ORM, which probably sucks. And for all of this abstraction, you are paid handsomely. The difficulty in landing your first job is tremendously high, sure, but the payoff is enormous. Once you're in, you'll find that the demands of most businesses is not to upskill, but to push features out faster. Grow the user base, beat others to market, and dazzle VCs. No one has time for doing things right, because that slows down velocity. This is aided and abetted by Agile, specifically Scrum. Aside from maintaining the cottage industry of Agile consultancies, it's designed to turn software production into a factory, where no one person really needs to know how to do anything tremendously complex. Instead of insisting that people learn how to do difficult things, we spend hours per week breaking down tasks into bite-sized increments with absurd abstractions of time. "Thought leaders" deserve a callout here as well for their contributions to this mess. Microservices are a great example. A potentially useful architecture in some circumstances has been turned into gospel that people buy into without question, and apply everywhere regardless of its utility or fit. If you're lucky, someone eventually notices that rendering a page seems to take a lot longer than it should, but more often than not this is met with a shrug, or at best blaming the DB and paying AWS for a larger instance. Multiple network calls that each have to traverse N layers of routing and queues is slower than calls within a single process? Color me surprised. When you combine the allure of a high-paying job that has little barrier to entry with no business incentives to do things differently, you get what we have today.

thih9 2y ago

> Testing, irrespective of the language or platform, is yet another complex specialisation we all just pretend doesn’t exist. Speak for yourself, me and my team use a CI and always add or fix tests right before merging any PR. (this is a joke, test suite is most useful when it’s part of the dev process and not an afterthought as I’m implying above)

yousif_123123 2y ago

I don't fully disagree, but this might be subjective. For me as a full stack developer working with small teams/startup, I actually don't consider myself full stack. I just want to be able to do whatever it takes to make a product and ship features. Does it need a websocket server? I'll learn how to do that. Does it need advanced client side caching? I can do that, etc. To some extent "product development" is both art and engineering. In the engineering side, you can think of html and CSS and http and testing as different things requiring a multidisciplinary team.. but if you think just in terms of "building the thing", I like to feel that I can get it done with whatever technology needed. That's why I got into programming in the first place. Not to write code and be an "engineer", but to make the computer do cool things. AI does expand the capabilities of someone that wants to get things done. I have written in languages that I don't have experience with, and recently was exploring a neo4j db with cypher queries written with ChatGPT (I have only MongoDB experience), something that would've taken me hours to learn. Still, having experts in specific areas in a team can be very helpful (both to get technically difficult things done but also to have others learn from them). I just don't want to be 1 part of a team specializing in my limited domain, where I start to care more about the technical part than the actual value delivered or user experience.. I think what might cause me to burnout is too much specializing, too much bureaucracy, people telling me I can't do this, we need to hire a staff level person to this thing etc..

wlindley 2y ago

"De-skilling" would be a better way to write this. I was halfway through before realizing it wasn't about "desk-killing" or the pretending that workers are incorporeal gossamer entities that do not have to physically interact with the real world. (a/k/a "remote work")

onion2k 2y ago

Judging by many websites, I think a lot of new web developers choose to tackle the problem of having too much to learn by not bothering.

mediumsmart 2y ago

Easy to fix. Every client should have the delivered site go through pagespeed.web.dev and when there are 4 green circles around the four 100s the webdesigner gets paid provided the client likes the site. This is not an OR gate

ilaksh 2y ago

My take on this is that we have multiplied the number of potential ways to build a web application continuously for decades. And now there are a combined 10,000 (pick a number) viable (but not trendy) ways to make a web application. The interesting thing to me is that ultimately businesses don't care how it works. They just want it to work. Which means that you can pick a small framework or two across the frontend and backend and configure or train an AI system on only a tiny fraction of the sum total of web development knowledge and have an effective automated web development system. Looking at the trajectory of gpt4 to gpt-4o and Llama2 to llama3, the prevalence of multimodality, improved reasoning ability as models get bigger, strong investment in hardware research, etc. I've been doing web development in some capacity since the late 90s and focused on leveraging generative AI for the last two years. I don't see how any reasonable person can follow this stuff closely and not anticipate AI systems that can literally do the entire job of a small web development team, within just a few years. It was actually possible to build a version of that two years ago, and some of the latest attempts are very polished, if lacking in some level of functionality. But that is coming. Every single job that we have today will be automated. I assume they means that people will be left basically herding swarms of AI agents. For a few years. But it won't be very long before you really need an AI to control your agent swarms or even understand what they are doing.

deleted 2y ago

[deleted]

5350-uiop-1130 2y ago

"The ongoing labour arbitrage – the deskilling of developers – can only be addressed with collective bargaining and union action." web dev does feel more like cheap labor work tbh. aside from a few exceptions. mostly tedious grunt work.

mablopoule 2y ago

This article hit close to home (maybe not the last part). In my last few jobs, I'm horrified at how (mis)treated CSS and HTML is. <rant mode on> Very recently, I had the displeasure of coming back from a 3-weeks long vacation and discovering that the rest of the team added Angular Material on the project, and started to sprinkle it everywhere in the code. Despite me (the only front-end guy in a team otherwise constituted only fullstack devs that are really more backend devs dabbling in frontend) asking them to not add Angular Material or any 'UI library', because this project is very simple, a mobile-only classic layout with a few simple forms. Nothing in the designer's mockup for this project looked like Material Design, nothing; But since Angular Material is marketed as basically being part of Angular, then they told me that it was "good practice", and "a way to save time". As a result, instead having a clean DOM with a few classes and basically just a border-radius on the buttons, they did tons of ugly CSS to overwrite the Material styling that they themselves added, all in the explicit aim for them to avoid doing any CSS at all, ironically. Just to reiterate, it's really a super simple app with a sticky header and footer, some form with a few borders, and some rounded buttons. I already did for them the main layout (it was basically a dozen or so CSS lines), but they ignored it all to add underneath tons of stupid Material components. I mean look at this crap: https://material.angular.io/components/toolbar/overview https://material.angular.io/components/toolbar/overview <mat-toolbar> is a component that was actually imported in the project, which: - does not have any JS behavior - does not handle positioning (you can do it yourself with flex! How powerful!) - does not have any ARIA role attached. - but DO have a default color and background, thanks to the customizable Material palette! In other word, it's a fucking <div> with a default background, but props to the Angular Material marketing and the mountain of content marketing out there to brainwash hordes of webdev into thinking that it's simpler to import an external dependency than to specify a background in one class. Another example, here is the doc for the '<mat-divider>' component: https://material.angular.io/components/divider/overview https://material.angular.io/components/divider/overview I understand why a Google designer would specify such element in a plateform-agnostic way, but for everyone else who's working in a web project that only used Material to 'save time', then why the hell would you import and use this component instead of just using the native <hr> tag available since the nineties ? It's easier I guess, oh except for the planned migration to Material M3 that you will have to do in a few years if you want to be able to upgrade to the latest version of Angular, but I guess that adding some borders and some margins is just incredibly hard. <rant mode off/> The saddest part of all is that I love doing frontend dev in general, and as the articles point out the fundamentals of HTML/CSS/JS are incredibly stable and retro-compatible, yet all the ecosystem keep piling layers and layers of crap all in the sake of 'DX' and of 'good practice' (that seems to change every 6 months). I do believe in the CSS case is that it looks too simple, deceptively even, so one can dabble in it without knowing the fundamentals, and so I believe that looks like CSS is broken the first time a junior dev has something with "position: absolute" that isn't positionned the way they expect, or when they find themselves coding in JS something that could be done with a handy CSS selector, out of ignorance of the available selectors. As a result of this apparent simplicity of CSS, I think that there is a general reluctance to 'respect' the language enough to try to learn it really, which makes for more piles of broken CSS riddled with !important, and thus more people believing that CSS and HTML is fundamentally crap. EDIT: I'm not critizising Angular Material in particular. I the React ecosystem I actually saw some 'UI component library' proposing elements to have bold or italic text. Yeeesh.

luke-stanley 2y ago

It starts off as articulate and then, I felt the arguments were less clear. It seems perhaps ungrounded. It's nice they have energy in a way but it also seems vaguely conspiratorial, rather than emergent. I've nothing against people seeking a better lot in life and collaborating or pointing out typical flaws and rent seeking. I wish the perspective was easier to follow, I'm curious.