This is a good discussion: do LLMs change the calculus for DRY?

A major point of components is having a single place where you can change design and behavior across your entire codebase. With LLMs you can with very good accuracy tell them to change the look of "all buttons that are confirmation buttons in modals but not in the login modal". Doesn't matter if there are 10 such buttons or 1000, it'll take a few seconds for them to accomplish it.

I'm slowly forming the opinion that nowadays having copy-and-pasted "components", with their whole HTML just repeated over and over, is now a much less worrying thing in a codebase. Even a bloated CSS can be quickly fixed by a LLM.

And like you said: you eliminate the build phase entirely and frontend development ergonomics goes back to how it was in the early 2000s.

▲

nightski 2 hours ago | parent | next [-]

So you enjoy reviewing your entire code base and relying on an extremely detailed regression suite just to make simple changes? I don't think AI changes good engineering at all, it just changes who or what is doing it.

▲

dlisboa 2 hours ago | parent [-]

It definitely changes some aspects of good engineering.

I'm not a huge AI person but it's obvious a host of great tools we've built to deal with our challenges would not have been significant if we had LLMs.

A very crude example: to translate code into a different language someone would need to write a tokenizer, a parser, an AST and finally a translator. All significant engineering challenges, taking days to finish. Nowadays you can tell an LLM to do that in minutes.

Staying on topic: we could easily argue that CSS wouldn't have existed if LLMs existed and could create table layouts from pasted images in a chat window.

▲

nightski 2 hours ago | parent | next [-]

I disagree about your last statement. That only covers the initial creation/generation phase. It ignores the engineering aspect of maintaining that design through the entire lifecycle of the product. How do you evolve that table design?

Sure an LLM can update every table in your project every time you make a change, just as a human could. It also can make mistakes and burn significantly more tokens doing so. Or, it could update one component with a one line change and be done. Easy to verify, less change for mistakes.

Engineering is a discipline and does not change dramatically with the advent of outsourcing it to agents.

▲

skydhash an hour ago | parent | prev [-]

> to translate code into a different language someone would need to write a tokenizer, a parser, an AST and finally a translator. All significant engineering challenges, taking days to finish. Nowadays you can tell an LLM to do that in minutes.

Do people do that on a regular basis? The most recurring case of building the above is when someone wants to include a language into a project and they usually don't bother with a translator. The second case is when transpilling (ex. LESS to CSS) and that's more akin to macro and other preprocessing tricks than a full blown translation.

> we could easily argue that CSS wouldn't have existed if LLMs existed and could create table layouts from pasted images in a chat window.

All current UI and Document conceptual models include styles (either as direct properties or separate models) and some does include named styles. The novel aspect of CSS is the Cascading concept, not the styling part. And cascading is obvious when we consider that there was supposed to be user stylesheets for documents. I read epub and user stylesheets (created from UI) is crucial.

	▲	dlisboa an hour ago \| parent [-]
		> Do people do that on a regular basis? They can now. https://www.checklyhq.com/blog/agentic-rewrite-nodejs-to-go/

▲

raincole 2 hours ago | parent | prev | next [-]

Frontend development in the early days was nightmare. I don't know why people pretend there was some kind of golden age but there really was not.

You could still develop frontend in the old way. Most browsers are very good at supporting old websites. But on one wants that.

▲

lemagedurage an hour ago | parent | prev [-]

[dead]