I'm all for writing more vanilla JavaScript in place of the convoluted and bloated React monsters we seem to have settled on as an industry these days.
I disagree with this article's argument that LLM tooling will hurt us here because this modern-modern style of coding is under-represented in the training data.
First, why do people use React (plus a thousand npm packages, which is where the real bloat comes from) to build a web application? It's because abstractions let you work faster.
If I'm using a tool like Copilot and it autocompletes the following:
' '.repeat(Math.max(0, 10 - str.length)) + str
I've saved myself from having to go and npm install left-pad.
I've already seen this effect in my own work: I'm much more willing to do things the slightly less convenient way in JavaScript rather than turning to a library when I don't have to type out those extra characters myself.
I'm back to writing code like in the jQuery days only with native browser APIs in place of jQuery and my developer experience is SO much less frustrating!
Baldur's larger point is that LLMs won't be able to help you with new cutting-edge browser features. I don't this matters, because of how web standards work. I won't use a new platform feature until it's supported by ~95% of deployed browsers according to https://caniuse.com/ which normally takes a couple of years. Coincidentally that's about how long it takes for new LLMs that know about these features to emerge!
If you don't know about these features, LLMs probably won't help you much. They're not replacements for staying on top of your craft. But if you DO stay on top of what's possible and know how to effectively use and prompt LLMs they'll be enormously useful here.
One example: I've started writing Web Components now, because thanks to Claude I don't have to remember the trivia of how the syntax works.
So my conclusion is the opposite of Baldur's. We both want developers to write more fast performing vanilla JavaScript and less bloated library-laden monsters, but I see LLMs as a powerful ally in helping us get there.
I feel like you've accidentally made the article's point here.. if you want left pad:
str.padStart(10)
Which has broad browser compatibility[0] and 97.27% real-use support[1].
In some ways you're skipping the library step (no `npm install`) but you're also embedding library fragments in your code via these generated answers. If there are security implications or bugs in those fragments, or they're outdated - you're unlikely to see/be notified. If you used a library you'll see updates / notifications or dependency warnings in your build pipeline (depending on your setup). Those updates aren't risk free (protest-ware, abandon-ware, malicious updates) but if it's an area you're not familiar with/don't wish to research they provide more value than solves it for now.
Perhaps, but great from the "everyone knows the issue" point of view :D 2016 is far enough back I suppose there are going to be devs who don't know the reference (they've never had the pleasure of IE support, more's the pity)
I guess it depends on how and why they are used by the developer. Most of the code I write isn't bleeding edge stuff, and using a copilot as a thought partner is pretty useful.
There really is a market niche for "just make some stuff" that LLMs are great for.
If the client wants "something" and an LLM provides a significant percentage of "something" that looks good enough for the developer to get paid, that is definitely value for the developer. Might not be valuable for the client, but I'd claim the state of the industry before LLMs was generating plenty of software that wasn't actually valuable for the client anyway.
I disagree with this article's argument that LLM tooling will hurt us here because this modern-modern style of coding is under-represented in the training data.
First, why do people use React (plus a thousand npm packages, which is where the real bloat comes from) to build a web application? It's because abstractions let you work faster.
If I'm using a tool like Copilot and it autocompletes the following:
I've saved myself from having to go and npm install left-pad.I've already seen this effect in my own work: I'm much more willing to do things the slightly less convenient way in JavaScript rather than turning to a library when I don't have to type out those extra characters myself.
I'm back to writing code like in the jQuery days only with native browser APIs in place of jQuery and my developer experience is SO much less frustrating!
Baldur's larger point is that LLMs won't be able to help you with new cutting-edge browser features. I don't this matters, because of how web standards work. I won't use a new platform feature until it's supported by ~95% of deployed browsers according to https://caniuse.com/ which normally takes a couple of years. Coincidentally that's about how long it takes for new LLMs that know about these features to emerge!
If you don't know about these features, LLMs probably won't help you much. They're not replacements for staying on top of your craft. But if you DO stay on top of what's possible and know how to effectively use and prompt LLMs they'll be enormously useful here.
One example: I've started writing Web Components now, because thanks to Claude I don't have to remember the trivia of how the syntax works.
So my conclusion is the opposite of Baldur's. We both want developers to write more fast performing vanilla JavaScript and less bloated library-laden monsters, but I see LLMs as a powerful ally in helping us get there.