‹ BackHN Continuity

Thread

Once Claude can measure something, it can make it faster

231 points · 153 comments · matthieu_bl

  1. smy20011 · · 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 · · 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. pennomi · · 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.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.