Hacker News Reader

Comment by igsomething | Hacker News Reader

I had a contract once to save a government website that had serious performance issues, it was so unusable that people preferred to go in-person and wait 4h in a queue rather than try to fill the forms online.

The frontend was in React because the company that got the contract initially used React for everything. The frontend was a 5MB SPA, but it could've been (mostly static) HTML files with some interactivity for forms like TFA. Everyone working on the project agreed React didn't make sense, but we couldn't do anything about it because someone from the government IT department would have to admit they made a mistake. There was no budget for rewrites in the contract. The few times a developer attempted to remove any "React monstrosity" they got in trouble.

Sometimes developers care, but the people in charge don't, and in government environments every change must go through them first.

View on HN

> Sometimes developers care, but the people in charge don't, and in government environments every change must go through them first.

To be fair, the same thing happens in private companies. How many UI changes have people gone through that didn't actually make anything better and just made everybody relearn everything? We would have been better of scrapping many of those and let people continue to use what's already familiar, but that too would have to involve someone admitting failure, which is a hard thing to do for some people.

I've used many a government website in the Navy, and they were almost invariably bad, but it had nothing to do with React per se.

A very slow website I can think of had something like 200 GET requests required to load the landing page, and it used Liferay with Material Design Bootstrap. That was closer to the "style at the time". React is the style of this time, but you can write very slow websites in anything, I'm convinced.

> That was closer to the "style at the time".

So I tied an onion to my belt.

Ref: https://youtu.be/yujF8AumiQo

I’m curious if - and when - LLMs change this. They’re very good at web apps. And they’re great at rewriting existing stuff. Just give them a well scoped /goal and go get coffee.

Theres lots of open questions about the future of our profession in the age of AI. But, playing with opus and fable, I think the future will be bright for our users. There is no reason any more for teams to put out junk that’s worse than what an LLM can do.

Unfortunately the LLMs are trained on what we've made, and there's going to be a ton more React garbage[1] in the training set than there are carefully-crafted websites like the article describes, so I don't expect a decrease in overengineered, bloated junk. If anything, I predict that the fact that you can shit one out in less time than before will have a different effect: A modest increase in bloat since an LLM won't mind adding a half dozen redundant and competing ways to do the same things in a large codebase, combined with a shorter mean-time-between-full-rewrites.

I think most of us have seen incredibly creaky codebases that are too buggy to be maintained any longer, where we make the hard choice to wipe the slate clean and build a new one.

We might find those rewrites happening every 12-24 months instead of after a decade.

[1] Frontend people, I mean no disrespect -- just that React & friends are (ab)used for nearly every website now, even those which map perfectly onto the "Simple document viewing with occasional submission of incredibly simple form data" model that plain HTML has always been perfect for.

> Unfortunately the LLMs are trained on what we've made

This.

As I’ve pointed out in other posts, I work in two languages: Swift (my main language), for native app clients, and PHP, for backend work.

I have a lot of experience, with each language (12 years for Swift, and 25, for PHP).

My experience with an LLM, is that I get very good PHP, and fairly mediocre Swift. The Swift often looks like fancy tricks, that newer enthusiasts like to demonstrate. Lots of unnecessary threading, and complex, dogmatic, overengineered approaches to simple problems.

I suspect that this has a great deal to do with the availability of high-Quality public repositories. PHP is more than twice as old as Swift, and, by nature, is a much more open language.

It doesn't take that much effort to put guardrails around your prompt to solve problems in a certain way and with certain frameworks and excluding certain others.

Who will be doing that? Only a small minority of developers pre-ai cared to attempt using HTML, so I don’t see them urging Claude to create efficient and lean websites in the future either.

Claude is remarkably good at performance engineering and ports. It only takes one person on your team to ask claude to do a round of performance profiling and tuning. Or ask claude to take your react site and set up a server to render parts of your site as static, cache friendly HTML.

You barely need domain expertise any more. Just ask claude to make it go faster and it will.

You also need to ask Claude not to make any mistakes /s

You can order LLMs to use other patterns. I had an LLM recreate an app in a different stack with reasonable success

You can, if you know what you want.

Lol

Better than a lot of web dev teams at least.

Reply on news.ycombinator.com