Links on carburo’s weblog

What I've learned about writing AI apps so far (link)

Tue, 21 Jan 2025 21:32:26 -0500

Citing Laurie Voss:

Is what you’re doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it’s probably going to be great at it. If you’re asking it to convert into a roughly equal amount of text it will be so-so. If you’re asking it to create more text than you gave it, forget about it. The rest of this post is really just examples of this rule in action.

It’s easy to argue that as LLMs get bigger context windows and agent tools get more sophisticated that the ability to replace a whole human will show up: after all, LLMs are good at turning text into less text. How much text do you need to replicate everything a human knows? I don’t know but it’s a lot more than any LLM can handle right now. In the meantime, your attempts to replace humans with LLMs are going to suck. Let your app augment and accelerate a human, I’ve seen that work lots of times and be very effective.

Original article

Moving on from React, a Year Later (link)

Mon, 20 Jan 2025 18:30:00 -0500

Kelly Sutton shares their experience after a year of replacing React with a JavaScript-light approach.

One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.

While there are examples of well-built SPAs, the opposite are far more common. On the other hand, traditional server-rendered applications can provide great experiences by taking advantage of platform features like back/forward cache and view transitions. The reality is that most web applications don’t need the added complexity of managing everything with JavaScript. If you are not building something with Figma’s level of complexity, it’s probably not worth it.

These liabilities become realized costs when we need to change the code. Change comes with risk, and changing untested code has a higher regression risk. We can compensate for riskier changes with moving more slowly or methodically. Moving more slowly is fine in many cases. But when compared to a world where that change isn’t risky (server-rendered ERB), we are suddenly paying a very pricey tax for making changes in JavaScript.

I’ve frequently seen this on many teams, and I’ve experienced it myself. Changes in JavaScript are far more expensive and difficult to make than changes to the logic you have in your server-side code.

Original article: Moving on from React, a Year Later

Reckoning: Frontend’s Lost Decade (link)

Sun, 19 Jan 2025 15:53:00 -0500

Some uncomfortable truths about the state of web develoment. The current generation of JavaScript frameworks tried to overcome the platform limitations by re-implementing everything in a scripting language. It shouldn’t be a surprise that this ended up worsening the experience for users in low resources devices. The web platform has advanced so much in the last decade that it’s a shame that most of the focus hasn’t been put in ways to overcome this limitations. There might be some hope with new frameworks like Astro or Eleventy shipping JavaScript-free experiences by default and even React trying to move more of the work to the server. However, a future where progressive enhancement and taking advantage of the platform is the norm seems distant to me.

YouTube Link: Reckoning: Frontend’s Lost Decade