Thread

1. smy20011 · 1790195297 · focus · HN ↗

   The way Claude did it is fight entropy with entropy.

   "Add a static composer into the HTML" <- This seems like something can be done with SSR?

   "For faster navigations, we kept the composer mounted between conversations" <- Your SPA should cache this between pages, why fetching it every time? Or you need better routing for your react components.

   "cheap first-character check before the regex" <- Should we cache compiled Regex instead?

   I think even 1.3 sec to load the front page is unacceptable. Something need to be reworked from basics (SSR, chunk-based rendering) to solve the problem. Focusing on invidual benchmarks may miss the opportunity.

   1. rustystump · 1790196428 · focus · HN ↗

      The amount of complexity added for the gains is depressing. I am confident a human and about 5 minutes with chrome debugger would yield better results with a fraction of the complexity at a fraction if the cost and in a fraction of the claude baby sitting time.

      Reading this shows the authors have a profound lack of fundamental understanding on how to effectively optimize in the web domain.

      This isnt claude being bad but how wild it is watch people from the cutting edge of ai brag about pretty mediocre gains.

      1. adamddev1 · 1790197191 · focus · HN ↗

         When people talk about AI being able to handle everything I keep wondering, have these people built anything complex, novel or serious? Just because people can see a website or a simple app improved, does that mean that all code can be handled by LLMs? It's like people are totally forgetting a whole category of careful, well-thought out programming for the critical parts.

         1. whatisthiseven · 1790198747 · focus · HN ↗

            Yes, what you are seeing are amateur developers that barely understand the tools they are using either giving LLMs poor instructions, or totally taking whatever it says at face value, then not bothering to put in further effort.

            If they just kept prompting it, or maybe used a different thinking level, it could have identified and solved this problem. Sometimes an engineer would look at a system and say "the current approach isn't delivering the desired engineering requirements. Maybe we need to rethink".

            Either engineer or LLM could take that sentence and run with it. OP of the article clearly can't do either.

            1. theolivenbaum · 1790199354 · focus · HN ↗

               You're missing the point where: in complex systems, sometimes optimizing code is both a high effort undertaking, and can totally not pay off. Having done hundreds of such exercises on our software over the years, it's liberating to have an idea of how to make something faster, being able to validate it without the fear of having to throw it all in the trash if it fails after days of work. What is still important is being able to provide proper guidance - we even built new tools to allow an AI agent to analyze memory usage in more depth, and instructions on how to benchmark in cloud environments where shared CPU usage and VM reallocation happen all the time and confuses the AI all the time with measurements

               1. kanzure · 1790213915 · focus · HN ↗

                  Also, not every task is worthy of applying (human) galaxy brain consideration. Sometimes a task is satisfied by cheap + dumb work.
            2. crooked-v · 1790205572 · focus · HN ↗

               > the current approach isn't delivering the desired engineering requirements. Maybe we need to rethink

               I'm reminded of the times I've tried to let Claude fix some well-documented bug in the background, and it ends up burning 4 million tokens and 20 self-review cycles re-writing the same set of code a dozen times with ever more complex unit test mocks / overcomplicated regexes / giant comments restating the same thing the code does, when the actual fix turned out to be "change three to ten lines to do something in a slightly different way that avoids the problem entirely".

      2. josephg · 1790214466 · focus · HN ↗

         > I am confident a human and about 5 minutes with chrome debugger would yield better results

         It really depends which human. I've worked with very few engineers who were good at this sort of optimisation work. A depressingly large percentage of people who make websites for a living don't really understand how http requests are really processed, or how to read and use the chrome profiler and benchmarking tools.

         Claude isn't as good at optimisation work as someone who really knows what they're doing and goes deep on a problem. But I'm optimistic that it will help plug a capability gap in teams which don't have this sort of expertise on hand.

         (That said, the chance that people actually learn this stuff is going to also go down if people get used to outsourcing this work to claude.)

         1. bluGill · 1790214739 · focus · HN ↗

            The job of making a website is a large part something that should be given to people who have majors in art, English, and similar things. Well, there is some value in an engineer to build the whole site, but that's more of a framework task. The vast majority of the content is not an engineering thing to do. It is a job of people who are experts in language, art, journalism, those types of things that have very little to do with engineering.

            In short, if most of the people working on your website could do those things you named, you have a problem that you have hired the wrong people for the job.

      3. latentsea · 1790217070 · focus · HN ↗

         >The amount of complexity added for the gains is depressing.

         This has kinda been my experience too. I find sometimes it works and gets OK optimizations, and sometimes it "optimizes" things but in a really wrong way. It doesn't apply 'taste' to the optimization process to know what's appropriate and what's not.

         The way this will play out is people without the expertise will wind up using it to 'optimize' things and the next poor bastard is left to deal with the fallout.

      4. jgtrosh · 1790226062 · focus · HN ↗

         It shows the author have a deep understanding of the fact that premature optimisation is the root of all success
      5. pennomi · 1790253165 · focus · HN ↗

         I’ve found the best workflow has been to ask Claude to profile everything and identify the problem spots, then I have to be the one to propose the correct architecture, then Claude implements it. If I let Claude run wild it will invent all kinds of weird, weird hacks that compound the complexity.
   2. crooked-v · 1790201452 · focus · HN ↗

      Even Next.js, for all that people are unhappy about its quirks, complexity, and random undocumented behavior and bugs (God help you if you ever want to try and actually use parallel routes as documented), can do all of this SPA stuff out of the box. Use `<Suspense>` appropriately on data loading, and everything static (including e.g. purely input-output components like editors) will load once and be re-used forever, and your Suspense-wrapped items will show a loading placeholder and only re-load when you intentionally re-trigger the data loading (which you can push down all the way to the level of individual buttons if you want).

Unofficial Hacker News client; not affiliated with Y Combinator.