Hacker News Reader

Comment by dlisboa | Hacker News Reader

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.

View on HN

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.

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.

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.

> 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.

> Do people do that on a regular basis?

They can now.

https://www.checklyhq.com/blog/agentic-rewrite-nodejs-to-go/

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.

Nowadays though, that old way is working very well, because of all the things that were added to HTML and CSS, making things, which used to be annoying or difficult mostly easy.

LLMs change the calculus on DRY in some cases. I would say it's still very much a no-no on the frontend side of things. Code repetition is directly correlated with bad loading performance. When you're optimising for people on slow mobile connections, your HTML/JS/CSS being 500KB instead of 1.5MB matters a lot.

That only matters in context: if this repetition allows you to forego React and a zillion JS libraries you’re better off in the end performance wise.

I have never seen a single website where performance downgrade was caused by HTML.

However I’m not advocating for it, just making the case that it’s very hard to do worse than we’re currently doing with front end development.

> do LLMs change the calculus for DRY?

Yes it makes it insanely easy to refactor duplicated logic into shared and tested modules. Why would you go the other way?

Components as in React, Vue, etc requires a complete overhaul in frontend rendering, many dependencies, changes in deployment and even have an impact in organizational structure.

If one wants to do server side rendering with HTML templates like the old days there is no real “components” way of doing it (although declarative Shadow DOM is coming along). Partials are not the same thing.

In that scenario some repetition can give you the benefit of keeping a clean stack with no client side rendering.

Have you tried Astro? It lets you do exactly that: server-side rendering with HTML templates in component form, with css scoped to the component. No shadow dom needed, no JS frameworks either.

Astro is still fundamentally different, it's not server-side rendered in the sense of dynamic pages. I can't, in a language agnostic way, use Astro to receive a request, get data from the database and render an HTML representation of this data. This won't work in a Go, Rust, or whatever server. Astro at a minimum requires its own compiler to build the static assets, a server to serve them, and a custom API to answer the calls so it can build the dynamic part of pages.

What about Phoenix live view?

Reply on news.ycombinator.com