Comment by zahlman | Hacker News Reader

Comment by zahlman | Hacker News Reader

> It’s become readily apparent that LLMs are really quite excellent at building Software for One. Personal apps that side-step all of the complexity and accountability of enterprise software and are custom fit for a single person’s workflow.

> …

> However most of our existing examples of pluggable software are local software: AI agents, developer IDEs, mods for video games, Blender add-ons, CAD extensions. These tend to be professional tools with a high barrier to entry. The web is the most successful software distribution system in the world. It shouldn’t be left behind. My hypothesis is that there is a new opportunity for Extensible Software on the web.

I don't follow. If this is really supposed to be "software for one", why would it need to be on the Internet? Why does it need a client/server model? Why do I care about "distribution"? People develop for web because native development gets painful when there are many flavours of "native". But you only use one of them yourself, and the LLM isn't bothered by its quirks.

Why not just work on designing pluggable local software that isn't so "professional"?

Data point of 1 but I prefer all my personal software to be web based so I can easily access it from my phone, laptop, and desktop and not worry about syncing things or installing or updating when I switch devices. Also makes it trivial to extend access to family members as needed.

It's very rare that I reach for local software these days.

Pity. Local software runs faster and feels native on the computer. And you can use local files.

I’m keen to build up a better local stack for building local programs more easily, running them over the internet without installing and syncing data.

I don’t want to need the cloud to make my computer work.

Who said anything about cloud?

I run all my apps on my desktop and access them over tailscale. All web apps and I install on phones as PWAs. Super ergonomic.

As for this:

> Local software runs faster

What? Why? Is this some assumption about network requests?

None of my personal software ever has a loading spinner or lag. If it's designed well, each interaction should fit in a single TCP packet so network round trip is imperceptible.

If your web software is slow, that's a choice you've made. Plenty of slow local software around to balance the scales too.

EDIT: Using local files with a web stack is also easy these days. The only con of web software is lacking that native aspect. But native appearance is rare anyway these days with every company just shipping electron bloatware.

> Is this some assumption about network requests?

No. It’s a claim about the amount of work the computer has to do to show UI. Native programs are simply mmapped into memory then executed. They can start instantly. Web software needs a browser engine. And a JS runtime. And a dom. And - usually - needs to wait for a bunch of network round trips.

Tauri - a rust web view wrapper - once bragged that it only needed 25 thousand syscalls to run hello world, vs the 100 thousand that electron needs. I think they’re both totally nuts. Modern computers are fast enough to absorb the necessary performance hit. But why make the UI slow for no reason?

With websites, the UI still usually ends up looking kinda bad. You can make much nicer UIs by using native controls. And you have access to more APIs! I made a conference schedule iOS app the other day which integrates with the native iPhone calendar. You star an event and it gets automatically added to your system calendar. Beautiful.

The only downside is the native ui frameworks aren’t as good. And they force you to rewrite your app N times for N platforms. But that’s just a tooling problem. I’m a big fan of frameworks like day which let me write once and deploy everywhere, while using system UI components. https://daybrite.dev/

Ah ok. When I talk about fast I am usually referring to user perception rather than clock cycles spent. Users won't notice 1ms vs 10ms but will notice 100ms or 1000ms.

For me, it's a law of diminishing returns thing. I would (and have) hand roll assembly if I want actual speed.

But we are talking about personal software. Write once, run everywhere browser's exist with essentially no tooling or complexity or deployment concerns.

What does writing everything in rust get me instead that is worth the significant increase in effort and dev time and deployment?

> Users won't notice 1ms vs 10ms but will notice 100ms or 1000ms.

I just don't see any software made with web tech that loads in less than 100ms. Here in Australia, it usually takes longer than that for a single packet to get to the US and back.

The Fastmail iOS app is an embedded web app. A fresh launch on my iphone takes about 3 seconds before emails become visible on screen. On my desktop computer, Spotify loads in about 3 seconds. Discord loads in ~12 seconds. These are all packaged web applications, which can store and cache whatever data they want. And we're talking startup times of several seconds.

There's also ram usage. I just opened spotify out of curiosity on windows. Spotify - as I understand it - uses the platform native browser. Just being open - not even playing anything - spotify sits at about 650-800mb of ram. The DDR5 ram sticks I have currently cost about $30 AUD per gigabyte. So, spotify is reserving about $20 worth of my ram the whole time its open. I can afford that. But I didn't buy all this ram so spotify engineers could be slobs with it. According to a quick google search, Winamp 2 used 4-10mb.

There exist pure native apps which also launch slowly and use a lot of ram. Davinci resolve also takes several seconds to launch. So does intellij. But these are much more complex programs than a music player or chat app.

If you're making tiny apps for yourself, I can definitely see the appeal of using web technology from a deployment standpoint. But if it were up to me, we'd port the web's software deployment model to work with native programs. Make native software as good as web dev and cut the browser out of the picture entirely. If ram costs 5x as much, I wanna see my software start using 5x less RAM when it runs. I just don't see that happening in the browser.

In my case it's "software for the home" but then I work from home and it's stuff I actually use to help me in my day to day work.

And I had "software only for the home" way before coding with LLMs were a thing and... It's just convenient when it's in a browser. Especially now with technologies like SSE push (where I hardly need any JavaScript anymore).

Also "software for one" can be "software for the home" but also "software for the SME" and the home has Linux PCs, an iOS tablet, an Android tablet, Android phones and the wife is on a Mac Mini.

Also even if it was really "just for me", something has to be said about an app one can access when not at home (which is easy to do when it's a webapp).

> Why does it need a client/server model?

I just use SSE push now: hardly any JavaScript and it works totally fine. Sure it's technically client/server but it's not crazy complicated either.

I've worked on medium-sized desktop Java apps (a few hundreds of thousands of lines of code) that were running on the three usual suspects: Linux, OS X and Windows.

Well... I much prefer to write webapps.

Wife and I have got a SME we run together and we use a Webapp I made to do so (now with the help of LLMs too, but I made the app before LLMs).

Don't get me wrong: I consider JavaScript to be one of the suckiest language ever invented and the amateurism of its ecosystem makes me want to vomit. It's not a love-letter to JavaScript: but browsers are very convenient.

Smalltalk also had extensibility for one. But it largely missed the explosion of collaboration when open source code became shareable and people can work on it together.

People also shared Hypercard apps.

I think it is less about client/server and more about how ideas can be shared. Sometimes, data might be shared.

Because there is no matchmaker- someone who finds people who have the same problem- and would be happy to buy it from you- on the condition it works for them so a refund is possible.

No huge company, no huge PR department, just one hobbyist/professional selling a ugly, rough around the edges tooling to other hobbyist/professionals.

I think the real thing is that software for one _business_ is very much in demand (and a bunch of SaaS exists as a release valve for those use cases). And that stuff is hard to get working

Reply on news.ycombinator.com