7 ms·
I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people. I understand that there's a good living to be
by kristianc 5mo ago
I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people. I understand that there's a good living to be made from knowing browser quirks, hand-rolling accessible components, mastering CSS specificity, but this is largely accidental complexity. More people building things is straightforwardly good, and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make.
You can argue that abstractions hide consequences that fall on users who didn't choose them, but I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well.
- sdevonoes 5mo agoMost of software engineering is accidental complexity. Sharding, buffering, caching, load balancing, contention, async, functions, classes, recursion… Big corporations behind LLMs are taking it all.
- dannyw 5mo agoThere's a huge difference between everything you mentioned, and dealing with 'browser quirks' like: <!DOCTYPE html> <!--[if IE 8]> <html lang="en" class="ie8 no-js"> <![endif]--> <!--[if IE 9]> <html lang="en" class="ie9 no-js"> <![endif]--> <!--[if !IE]><!--> <html lang="en" class="no-js"> <!--<![endif]--> The points the author made simply aren't good arguments. Yes, frontend development was harder during those days, but not harder in a good or rewarding way.
- layer8 5mo agoThat’s not what accidental complexity means. Accidental complexity comes from design errors that could have in hindsight been avoided, meaning that if those errors hadn’t been made (made by accident, literally), there wouldn’t be any accidental complexity. The items you list aren’t accidents that could be avoided, they are necessities in achieving relevant goals.
- sevenzero 5mo agoSharding, buffering, caching, load balancing are mostly issues 99% of devs will never have to work on. It gets relevant on high load pages, but most stuff out there wont ever need it.
- Filligree 5mo ago> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well. To make the obvious counterargument, “then you shouldn’t be creating websites at all”. I don’t actually believe this, but I know people who do. Some would add “shouldn’t be allowed to”.
- bakugo 5mo agoI wonder what went so wrong that "if you don't understand [thing] you shouldn't be building [thing]" is now considered a controversial statement.
- kristianc 5mo agoThat's not what I said, I said I likely understand it less than a 635B parameter LLM, and that using the LLM as a shortcut to that knowledge is something I'd consider perfectly acceptable. I might even become better at it through using the LLM.
- layer8 5mo agoYou need a certain understanding to be able to judge whether the output is adequate. I think the argument is against people who lack that understanding.
- fwip 5mo agoWell, there's degrees of understanding, as well as degrees of seriousness of the project. You can also learn a lot by building something. Some people are writing the Netflix homepage (where an outage costs millions of dollars), and some people are writing a blog for three readers.
- mathgeek 5mo agoIf you're building bridges, this shouldn't be a controversial statement. Same if you're building cryptography software. It's debatable if the same should apply to the vast majority of software that is less critical.
- 5mo ago
- customguy 5mo ago> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well. No, other people did. They wrote about it, and LLM can sometimes use that. Once they no longer write about it, what then? > More people building things is straightforwardly good, and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make. That I agree with. The more the merrier, all else being the same. And if "AI" trickled into everything because of the undeniable improvements it leads to, the situation and most of the sentiments would be very different, I think. But even then, people aren't entitled to the knowledge "created" by doing the work. If attribution and compensation were tackled in earnest, if you could only train on the materials of the people you pay to produce those materials, it might be much quicker and cheaper to just learn CSS.
- aspenmartin 5mo ago> No, other people did. They wrote about it, and LLM can sometimes use that. Once they no longer write about it, what then? It can read the code? Historical discussions around it? Commit histories? > But even then, people aren't entitled to the knowledge "created" by doing the work. If attribution and compensation were tackled in earnest, if you could only train on the materials of the people you pay to produce those materials, it might be much quicker and cheaper to just learn CSS. OSS code and people’s public writings are available to anyone all the time. Common Crawl, the open source web crawl dump, has been around for over a decade. No one had any problem with these systems being developed on them, until they finally started to become useful, so what’s the sort of legal or ethical framework you’re pointing to?
- oblio 5mo ago> It can read the code? Historical discussions around it? Commit histories? And if everyone bunkers up and all that open content dries up starting in 2026, let's say, what happens?
- kristianc 5mo agoIt won't happen, for two reasons. One is that great deal of open-source software and hobbyist knowledge sharing has never been driven by financial reward anyway and people will continue to do it anyway. Finer grained controls over opt-outs would be great (the equivalent of a search engine 'nofollow' would be great and will hopefully come with time). Many kinds of technology faced this kind of tragedy of the commons argument in the past and it never bears out. Printing presses copied manuscripts, search engines copied and indexed web pages, open-source software was incorporated into commercial products, Wikipedia repackaged knowledge produced elsewhere. In almost all cases the total amount of creation increases because the technology lowered costs, expanded audiences, or created new forms of value. The speed of creation of new 'View Source' outpaces the number of people pulling back.
- gobdovan 5mo agoIt doesn't seem to me that the author is saying 'AI bad, abstraction bad, knowing browser quirks GOOD'. Looks to me like someone making a specific claim about a trend where having an easier time getting off the ground can lead to a lower ceiling. I'd read it kind of like 'The man and the butterfly' story. Or the Kant passage about how doves might wish air didn't exist, without realising that friction is exactly what permits them to fly.
- Zababa 5mo agoIt really depends, up until recently (January) reading all the Temporal doc and doing the courses allowed me to frequently suggest to the current frontier model things they didn't remember. I don't know if this changed recently.
- m132 5mo agoThe problem is, mastering accessibility, intuitiveness, compatibility, responsiveness, scalability, architecture, performance, and all those other less immediately visible, "forward-thinking" parts of UX/software development has always been difficult. Ultra high-level frameworks and now LLMs have, on the other hand, made it even easier to botch all of these and quickly roll out a half-baked MVP. The gap between "acceptable" and "decent" has thus been widening. As a protagonist of "decent", you have it increasingly harder competing against those pushing for "acceptable". And the push is understandable as well, it's MVPs that make money and details only "increase customer satisfaction" at best (and these days, who even cares about customers?). The end result is more crunch and a sharp decline in software quality, maybe even job satisfaction in general. As an (unfortunately anecdotal) example, I started to find myself fixing up broken websites or removing elements that get in the way with dev tools and uBlock every once in a while, and have heard from other people on here that they have been doing the same (https://news.ycombinator.com/item?id=47042747 https://news.ycombinator.com/item?id=47042747). All to restore basic functionality of websites I go on. This was never required back in the day, Flash and early web browsers didn't even have the option to do this. Another, less anecdotal example from a while ago: https://news.ycombinator.com/item?id=47390945 https://news.ycombinator.com/item?id=47390945 It gets worse when you realize that most of the money saved through these cuts only benefits the very top of the hierarchy.
- hnthrow0287345 5mo agoThis is why the 'craft' should be left to open source for most commercial software. The business reality just doesn't care for it. Only when you have a PR problem does the business switch back to signalling quality, like Microsoft, although it remains to be seen if they still have the quality part. Most of the craftspeople get to say 'told you so' but also it looks like a sinking ship to them. Once the PR problem is gone, it's back to shipping at the expense of quality. This cycle conflicts with the idea of a craft, which is that you should do it that way all/most of the time. The business will stop caring about quality long enough that your skills will erode, making it a bad mix. Trying to practice a craft where you aren't in control of this cycle is corrosive to the spirit.
- hombre_fatal 5mo ago
- dannyw 5mo agoI used to make a living doing frontend development, and quirks and knowing idiosyncrasies is a burden to your craft. Yes, it meant there were higher barriers to entry, but it also resulted in a lot of broken websites, and I can tell you it was never fun nor rewarding. I think the original author has a much stronger thesis around AI devaluing the craft of coding, but his specific examples don't stack up.
- trjordan 5mo agoTotally. Every "we're losing our craft" article has the same gloomy shape. That's enough of a bummer, but they also argue against themselves halfway through. This one, for instance: > But exactly which details are deemed “unimportant” is a very consequential and sometimes subjective decision. And eventually, the details always leak through. Right, so you're saying this new technology will still reward deep technical understanding, because there's no way around it. I agree. Why is the whole tone of this thing "AI is making my craft a cheap commodity?" Websites are largely better, technically, than they were 10 years ago. They're more full-featured, they're faster, SSL/a11y/responsiveness are stronger defaults. Content mills / SEO / news sites are a separate, terrible failure mode of ads and corporate incentives. That's not React's fault!
- knuckleheads 5mo agoA craftsman's pride is an industrialist's nightmare! Software has been transitioning from a craft into an industrial process for the last two decades or so, and the software craftsmen of all stripes understandably do not like this!
- acedTrex 5mo agoYa it's definitely been an ongoing process. LLMs have just accelerated it.
- knuckleheads 5mo agoI am not joking when I say that software craftsmen lost the war when tabs vs spaces was obviated as a point of contention by CI enforced formatting and linting around broader community standards.
- randlet 5mo ago> Software has been transitioning from a craft into an industrial process for the last two decades or so This seems like a good insight and it feels true to me as well. My guess is the absolute number of people who treat it like a "craft" is higher than 20 years ago, but as a fraction of all developers it has shrunk dramatically.
- sevenzero 5mo ago>...and if some of those things are slower or less accessible, that's a tradeoff people are entitled to make. It depends. My country (Germany) introduced accessibility laws recently which enforces you to build everything public with accessibility in mind. If a page doesn't meet the expected standard you can get extremely high fines.
- carlosjobim 5mo agoThat makes a lot of sense! I suppose that BMW has been fined billions for making motorcycles that blind people can't drive safely?
- sevenzero 5mo agoSir this post is about front end development/products.
- Forgeties79 5mo agoYesterday we saw on the frontpage that LLM’s can’t even accurately assess if California produces literally all the almonds in the world. The really weird gaps and inconsistencies just make it to untrustworthy. I spend so much time vetting all the outputs that it often cancels out the time it saves me, and I find enough errors that I don’t have an incentive to streamline things/not vet it.
- madeofpalk 5mo ago> this is largely accidental complexity. Is it? I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem. Sure, the browser is slightly more difficult due to maintaining backwards compatibility and multiple implementations, but I’ve yet to see a better UI framework/language that has to deal with the other constraints of the web platform.
- traverseda 5mo ago>that has to deal with the other constraints of the web platform. Well there's your problem right there
- madeofpalk 5mo agoRight - but those constraints are inherent to the medium. Like basically unconstrained screen sizes from large desktops to mobile, with the user free to resize anywhere in between (and can't be constrained in the way that 'real' apps often are). Input methods of both fine mouse control, and course touch.
- troupo 5mo ago> I know hating CSS is a fun pastime for folks around here, but maybe it’s just that building good, rich user interfaces that people can use is an inherently hard problem. That CSS and web never really addressed did they? There's almost nothing in the web platform to build rich user interfaces. You can barely do styled text. CSS and HTML are literally littered with accidental, ad-hoc, badly thought-out and badly designed one-off solutions, often to problems no one asked for. There's a reason it took until 2026 to animate `height: auto`. There's a reason why `article` "semantic" element has to be used when you display product cards or widgets. There's a reason why CSS scoping has been stuck in limbo for 10+ years. There's a reason... The web is one of humanity's greatest achievements. But let's not pretend that it's not a textbook study in accidental complexity.
- mbgerring 5mo ago
- fny 5mo ago"Frontend's Lost Decade" has nothing to do with a11y or semantic HTML. The original talk argues performance went to hell because of React and friends, which is why we have electron CRUD apps that consume 2GB+ RAM.
- troupo 5mo agoAnd the irony is that the author of that talk spent that same decade busy shoving as much Javascript into browsers as possible. After all he's the originator and the main promoter of web components where every single thing including built-in browser functionality like form participation has to be done in Javascript. Edit: There's not just one lost decade of the web. There's the browser wars and IE stagnant dominance. There's the 2010s with millions of man hours spent on web components and starving other directions of resources or actively hindering them (e.g. scoped css was continuously postoponed because it's highly incompatible with Shadow DOM) while pushing everything into Javascript (and partly breaking JS e.g. with the bolted-on class-based OOP). It remains to see if Google's complete dominance breaks the web further
- emodendroket 5mo agoYou could argue that most users do not notice or care about this at all so it's a completely reasonable sacrifice to make to have rich applications.
- WarmWash 5mo agoPeople think they are upset about new technology, but what they are actually upset about is the general consensus being that the new technology has a better value prop.
- PaulHoule 5mo agoThe bit that goes unsaid about Electron is... why? If the goal is a legitimate app that has the lifecycle of an app that you start up and then shut down today the answer is "just write a web application" and then it "just works" on Windows, MacOS, Linux, iOS, Android, Meta Quest, etc. Mostly people get pissed about Electron because they have 15 Electron apps running in the tray burning up resources all the time and popping up stuff that covers the tray and other tray applications in those (very rare) cases that you want to interact with something in the tray. It's a tray problem, not an Electron problem. That is, people use Electron specifically because they want to made rude applications which march all over your desktop in muddy boots: Electron is not a framework for writing well-behaved, polite, x-platform applications; you don't need that, you have the web! Electron is a framework for making rude applications that inhabit your tray, pop-up distracting notifications, etc.
- sublinear 5mo ago> that's a tradeoff people are entitled to make The users are also entitled to hate your website or app. At what point do you admit you're just making excuses for cheap and sloppy work?
- smackeyacky 5mo agoExactly. Nobody wants smalltalk programmers or IIS whisperers. You just have to embrace the idea that your skills become worthless every five years and move on.
- mcmcmc 5mo ago> More people building things is straightforwardly good I still don’t understand this perspective, how is it good when a growing portion of stuff that’s built is straight garbage?
- emodendroket 5mo agoSuppose the choice is between software that does what you want, but isn't very optimized, and the software not existing at all, rather than between shoddy and beautiful software that both do what you want, and maybe it will make more sense to you.
- mcmcmc 5mo agoSo apply a false dichotomy and it will all make sense? Still not buying it. Not everything needs to be solved with software, and brushing off negative externalities as “not very optimized” is irresponsible
- emodendroket 5mo agoIt's not a false dichotomy at all. There wasn't a lot of junk clothing in the ancient world -- everything was made to last. The downside was it was very expensive and most people didn't have much. The episode with the guards casting lots to see who can have Jesus's robes in the gospels is rather difficult to understand for a modern audience.
- acedTrex 5mo agoI will pick the software not existing at all every time. Easily without a thought.
- emodendroket 5mo agoI think that's an absurd thing to believe, but if we've moved beyond "I don't understand" to "I don't agree" then my post served its purpose.
- cyanydeez 5mo agobeing able to increase both a11y and i18n even if imperfect are definitely a LLM value add; the problem is simply business. This doesn't make the heat->cash register bling.
- machiaweliczny 5mo agoYes it's still bad there's no viable headless UI in browser one can really style and it has all the a11y etc. but need extra library for selects that work etc. Invented work for no good reason. The real complexity is in diversity of devices though nowadays in the frontend.
- moron4hire 5mo agoMaking UI less accessible is specifically not a trade off people are entitled to make. Accessibility is a legal requirement. This is like arguing it's ok to use robot construction workers who forget to install wheel chair ramps because "gotta go fast".
- coldtea 5mo ago>I'm sure I'm not alone in feeling the "deep expertise" OP laments was actually deeply inconvenient to many people. And I'm sure I'm not alone in feeling that the convenience from ignoring the "deep expertise" and piling on hacks and lazy abstractions, all the way to modern multi-MB frameworks and Electron, is a regression. Of course no one gives a shit about things like the user's computer/memory utilization. Or degraded experience. Or wasted bandwidth. Or the extra energy costs per 8 billion people - and the environmental impact. >More people building things is straightforwardly good, Is more people building public infrastructure "straightforwardly good"? If it means worse roads, worse bridges, systems that fail? The same holds for software. And most things really.
- x0x0 5mo ago> feeling that the convenience from ignoring the "deep expertise" and piling on hacks and lazy abstractions But again, accidental complexity. The web platform is utterly rotten. So the people we should blame are chrome et al for not providing a standard lib or anything approaching a reasonable UI framework, which forces people to reimplement what a competent platform provides. Electron is an artifact of the richest companies in the world prioritizing their platform monopolies and trying to increase their stranglehold on businesses by forcing them to write platform specific code, which is hysterically expensive to build and maintain. When I'm confronted with writing for web then reimplementing for mac and win... the answer is electron. I don't think anybody likes building in Electron; it's just it's that or +200% (or more) eng headcount to build 3 apps, one per platform.
- coldtea 5mo ago>Electron is an artifact of the richest companies in the world prioritizing their platform monopolies and trying to increase their stranglehold on businesses by forcing them to write platform specific code, which is hysterically expensive to build and maintain. When I'm confronted with writing for web then reimplementing for mac and win... the answer is electron. And yet we could build native apps a plenty in the 90s and 2000s, with 1/100 the resources (tutorials, third party libs, native GUI frameworks, IDEs, etc) available, and 1/10th the target user base. It's not about "platform specific code, being hysterically expensive to build and maintain". It was more expensive in the 1990s and 00s too, but people built it and maintained it just fine. It's companies chosing convenience. Especially since it's not poor programmers and small software shops going for Electron. It's the biggest multi-billion to trillion dollar companies. Facebook uses this crap, Slack uses this crap, Adobe and Google use similar web-based UI crap (in what used to be native apps), and so on.
- Aurornis 5mo ago> the "deep expertise" OP laments was actually deeply inconvenient to many people This reminds me of the Upton Sinclair quote: “It is difficult to get a man to understand something when his salary depends upon his not understanding it.” LLMs feel threatening to anyone who had an edge by knowing how to navigate domains with a lot of weird and complex behavior. It’s nice to feel like businesses need you if they want to solve a problem. It’s scary when a cheaper solution arrives that does 70% of that deep knowledge navigation at 1% of the cost.
- dosisking 5mo agoAnd LLMs remind me of the video game Lemmings. Also reminds me of that episode of Star Trek TOS 'The Ultimate Computer' And the STTNG episode 'The Game' Einstein was correct, the only thing in the universe that is infinite is human stupidity. That is why I feel threatened by LLMs.
- acedTrex 5mo ago> More people building things is straightforwardly good No it's not, its the opposite actually its very bad and leads to far far more noise in the system to sort through to find value as someone who's competent.
- classified 5mo agoEach time you say that an LLM "understands" something better than you do, you also say that you're not actually qualified to judge the LLM's understanding.
- wiseowise 5mo ago> More people building things is straightforwardly good Is it? More than a decade ago there was a Cambrian explosion of software, Flash alone was the defining force of indie gaming industry. And now what? We have so much shit/shovelware that nobody wants to touch with a ten-foot pole.
- danielvaughn 5mo agoThat's all true - I taught myself how to code from 2009-2012 so I remember what it was like. However, around that time there was also deep focus on architecture, an obsessive focus on rendering performance and page weight. Everyone could recite the loading sequence that HTML pages used, we knew how many requests could be downloaded in parallel, how to best bundle assets for the fastest time to render, etc. So it was a mix of both pain and frustration on one hand, and a pride in one's work on the other hand. Both have been lost; good riddance the former, but I miss the latter.
- sershe 5mo agoSo I used to hand code async http request based UIs when this feature first appeared, write cross browser css, etc. before moving to work on distributed systems backend. These days I think a blanket ban on browser scripting would be a lesser evil. There are, roughly, 3 tiers of developers with regard to any such labor saving tech (js libraries etc.) People who could do a good job low level and can do it faster with libraries. People who couldn't, or couldn't be bothered, before the libraries, but can now accomplish things. That is the good part. And then there are the unwashed masses, who couldn't dream of accomplishing anything on low level but now can, and who at least in case of JavaScript far outnumber the previous category. Like when I messaged a webmaster whose side would download an uncached 3mb script blob on every page load (it was their script, not ads), to render few paragraphs of text, and they responded that it was by design and the script couldn't be cashed because some variables in it changed based on time, and that is so large because it contains features necessary for other pages that have more than text. I think we'd all be better served if these people pursued a more appropriate career, for example in the roadside trash pickup. It remains to be seen how it goes with llms, but personally I'm not optimistic.
- overfeed 5mo ago> I'd argue back that LLMs likely have a better understanding of a11y conventions than I do as well. Only because you've not invested time[1] to learn a11y, but that is par for the course: LLMs are pretty good at impressing people without a deeper understanding of a field with its statistically average outputs. My hot-take: one shouldn't oversee an LLM task whose output they are unable to evaluate. 1. And you don't have to! We have limited time, accessibility is broad, there are numerous standards, and screen readers can be unergonomic, to put it lightly. But a human has common sense, and can care. I doubt there's enough a11y training data to match a caring human testing and thinking through interactions. Sadly, human software QA is now threatened with extinction.
- overgard 5mo ago> More people building things is straightforwardly good Why is that straightforward? As an example, right now every year on Steam there are thousands of games released. A lot of them are just shovel ware that nobody ever plays, but it does end up hiding actual quality stuff in the noise. Same thing happens in app stores. Gatekeeping that limits opportunity is bad. But gatekeeping around quality is very good. Wanting your software to be written by someone who cares about software and has expertise is, to me, more straightforwardly good. Right now people are blaming vibecoding for decline in a lot of mature software products, whether that's fair or not (I think it's frequently unfair). I think there's a possibility that's going to morph into "AI First" companies being seen as poor quality brands. Already we see in games that when listed they have to disclose if AI was used or not, and if it was, it damages the credibility quite a bit.
- t-writescode 5mo agoWhile I strongly agree that heavy LLM usage in industries that actually collect customer data, or make important decisions is INCREDIBLY harmful (with quite a bit of unfortunate regularity), democratizing coding “for all” especially in small, narrow niches, is similar to democratizing art, singing, music, general creating. As long as it’s “for you” or “small time”, there really isn’t a problem at all. The only real downside so far to LLMs (ignoring environmental concerns) is when they’re heavily used and left unrestrained to go play with financial data, healthcare data, PII, anything with real consequences when it breaks. If a person is using it to automate their life. If a father is using it to help their kid with accessibility issues speak. If an artist is using it to help them write code so they can make a game. These are all good things. You might think it’s shovelware; but the creator of those things is now super excited that their vision was made or their niche issue was helped, when no one else would.
- overgard 5mo agoI have no issue with people creating things, but if you're going to ask strangers to look at it, I think it's reasonable that there's a bar to clear. I think the bar should be adjusted based on the influx of stuff. Right now there's too much stuff that isn't good, and it drowns out the good stuff. There are plenty of places where people can publish amateur works for their friends to see.
- afavour 5mo ago> this is largely accidental complexity. Less of an accident than a byproduct of the unique ecosystem the web lives in (which is a positive!) Compare to say, backend development. If I said database indexes are deeply inconvenient and that I shouldn't have to make them I'd get laughed out of the room and justifiably so. But by comparison when a developer says "I don't care to learn CSS" folks nod their heads in agreement.
- madrox 5mo agoI tend to agree. I believe most of these arguments, whether consciously or not, are rooted in sour grapes. If AI were already the norm, and someone came along and said, "hey! I've got a great idea! Instead of AI building all this stuff, what if we did it by hand?" and talk about all these amazing benefits to hand crafting code, people would largely say no thanks. As far as the abstraction argument goes, well, we've been creating higher order abstractions for a long time and called it good. I don't see why we should suddenly be against abstraction.
- TheOtherHobbes 5mo agoThat's an argument from assumption. The issue isn't whether AI is "building all this stuff" but how well it's doing it, how well the people using it are doing it, how expensive it really is, and whether there are observable objective benefits at the end - not just a subjective sense that some work is taking less time. The reality is probably bimodal. The people who are benefiting are benefiting a lot, but they're likely in a minority. The majority will be tokenmaxxing at great expense and spinning their wheels in real terms. But there's no hard research to prove that. Considering the huge sums involved, the absence is interesting.
- madrox 5mo agoCalling that an argument from assumption is fair. I am basing this on where I think the puck is going, but I don't think I'm wrong. The issues you mention are not unsolvable problems, and AI is very good at independently iterating and improving on an observable objective metric. Reality is certainly bimodal today, but that's because as an industry we're lagging behind capability. We're in the early days of the innovator's dilemma S-curve.
- acters 5mo agoAI consistently places animated objects behind a blur object which causes the browser to constantly repaint. Google's ai mode introduced one, some other websites clearly vibe codes included them too. At first it confused me why my GPU usage spiked and fans started blowing harder, but now I see it is a common mistake that AI makes but no one tests properly. It is possible a human can make this mistake but I sheldom experienced this ever in my life until now. I run 240hz monitors, and that meant the browser was trying to do 240 repaints per second. Blocking it with unlock origin is the only way. Ridiculous
- raincole 5mo agoI fully agree. The reason that LLMs seemingly defy No Silver Bullet is that the premise of that theory is flawed. Software development has been mostly accidental complexity, not essential complexity. Actually I believe even with LLMs' help, the accidental part still takes the lion's share of the total complexity.
- skydhash 5mo agoNot really. The issue is that inexperienced people, while trying to solve the essential complexity, are creating so much accidental complexity that soon the project either collapses or oscillates between bugs. LLM is just the highway to reach that state sooner.
- ifwinterco 5mo agoI disagree that what makes front end hard is mostly accidental complexity. Some of it is for sure (CSS, while I actually quite like it, isn't perfect). However it's fundamentally harder to get the basics right in front end than back end because: - You don't control the environment (meaning "browser quirks" are actually inevitable to some extent) - You don't control the screen size and resolution of the device (meaning responsive design is not accidental complexity, it's inherently a somewhat complicated thing you have to address) - Internal state is often visible to users (an API can be a complete mess internally as long as it returns the correct JSON in a reasonable time. Not so with frontend) Compare that to backend where you control everything except any external APIs you need to use, it's chalk and cheese. The reason the market doesn't value front end skills isn't because they aren't difficult or valuable - a really slick front end is worth its weight in gold. The reason is it's almost impossible to tell in a 1h interview if someone is actually good at front end or not, relative to back end coding tasks which are more deterministic
- ozim 5mo agoNot only deeply inconvenient but also a lot of times actually making more things worse. OP writes about doing stuff ”properly” and how “using frameworks” was somehow worse. Having a framework that is built by actual experts is much better than every “self proclaimed expert” building his own crooked thing. Being able to switch developers between projects easily is also good for developers. I can switch companies on a whim without having to learn “crooked way of self proclaimed specialists”.
- BrenBarn 5mo ago> More people building things is straightforwardly good It most definitely is not.