Hacker News Reader

Comment by TimTheTinker | Hacker News Reader

This got me thinking... someone should build a local service that hosts a library of static web apps for use cases like this. Essentially, apps that are something between bookmarklets and Electron apps. Might even make Electron unnecessary for a bunch of use cases.

It would be neat to visit /app/notepad, /app/kanban, /app/todo, etc. at a localhost port, with an index of apps at /. There could even be a /get-apps page that connects to an npm-like library of single-HTML-file apps available for download from a github.io static site backed by a public repo that accepts pull requests.

I'd love to see all the VC-funded glorified desktop utilities on the web become unnecessary.

View on HN

You're going down the todo-app / "second brain" rabbithole, which generates at least a few "start-ups" every month.

The deeper version of this is finding out about smalltalk and realizing that you could make a very configurable system that you could edit on the fly.

Salesforce is basically a smalltalk VM and dominates thanks to that

In what way is Salesforce a Smalltalk VM?

And if it is, why does it dominate "thanks to that"?

If you open up salesforce you have all these resource types and pages, but it's all fully customizable. There's a built-in programming language with many affordances to work in a dynamic environment (stuff like handling API changes), and you're basically able to point at a thing and get a breakdown of what it's like.

On top of this third party developers can build in stuff that is more or less first class to the system, and it can run on the third party systems but you can get away with using Salesforce's "compute". So you're shipping software for the Salesforce VM, so to speak.

I would recommend playing around with the system to see what's going on.

Please Explain

I love this idea and made a little MVP for it: https://github.com/alabhyajindal/local-webapps

There's a demo video on the Readme with setup instructions.

Tiddlywiki - the poster child for a complex app delivered as a single LOCAL web page.

Coming back to this a few days later... it looks like the fastest way to implement this idea is to host a local TiddlyWiki instance. There are so many TiddlyWiki plugins that fit so naturally into the ideas I had above -- kanban, todo, and the wiki itself, among many others.

I tried this Ruby script for local hosting and it's working great for now: https://gist.github.com/jimfoltz/ee791c1bdd30ce137bc23cce826.... Just make sure you have wiki.html located alongside the script, and navigate to /wiki.html.

The next evolution would be to get it running in RedBean reliably - and maybe even get it saving Tiddlers to the built-in SQLite instance. Simon Willison's work on saving Tiddlers to SQLite in Python might be a good reference: https://github.com/simonw/datasette-tiddlywiki

On a related note I wish there were an easy way to deelectronfy electron apps. I don't know, perhaps some sort of patch you could apply to get it to act like a normal web app. and a local server to provide the file access.

Mainly I am bitter because nobody has ported electron to openbsd yet, cross platform my ass.

Thinking about this more - this might be a perfect use case for Redbean. Backend mini-app user data could be stored in SQLite. The server could store the actual apps' static files in its internal zip archive. All of that could easily be managed with a sprinkling of Lua.

The mini-apps could store data in localStorage, but that would expose the data to other mini-apps. Maybe build an easy API that functions nearly equivalently against a Lua endpoint.

This might work....

...But I've not worked out how to get RedBean serving up files outside of the zip... I'll get there.

P'raps LUA could manage the security for different static apps.... as you say.

I'm not saying Redbean should serve files outside of the zip. The mini-apps would all be located inside the zip.

When downloading a new mini-app, the Lua script would add it to the zip archive itself -- it can do this as far as I can tell.

How about a native app collection called "Sidekick", which has a Borland bent?

Do you actually need a local server? Why not have a real url, but have the site use service workers to persist offline?

The only issue I see is if you clear your browser’s cache while offline

I'm not a web dev so I might be missing something. Theoretically you could just open .html files directly in the browser without any networking being involved, no?

In the past, yes, and you still could if you use old enough features, but nowadays browsers heavily restrict sites opened as just .html file. For example you could not use modules at all if they're in separate files.

That is at least until we get Isolated Web Apps and what ever the other proposals related to it alö called.

Is blocking access to local files a new thing? Considering the threat (you download a html file, open it in your browser and it tries accessing random files and exfiltrates them using JS), I would be surprised if this has worked in the past 10 years

You should be able to whitelist such files. After all the browser is supposed to be your agent, not your nanny.

The problem with these supposedly local, private web apps on other people’s domains is that they can start stealing your data any time the page is refreshed. The author can turn malicious (or was malicious to begin with), they can sell the app or let the domain expire, or they can be hacked. The only way to prevent that is to firewall/null route that domain entirely after initial load and audit, and then you can’t ever refresh the page.

The web platform simply doesn’t allow you to verify the checksum of an app and reject all further requests.

> The only way to prevent that is to firewall/null route that domain entirely after initial load and audit, and then you can’t ever refresh the page.

I mean, at that point, why not just grab the files are host them yourself?

Well that’s exactly the point. Having a directory of these static files you can self host with eyeballs on updates would be great.

A late edit for a brain fart: “and then you can’t ever refresh the page” should be removed since it can be served from service worker cache. You can’t refresh the page while allowing a connection to the server.

Why would I use that instead of OS native apps? I am failing to see the usecase / appeal.

One reason is because these minimal HTML-based apps would be extremely lightweight (just a few kb each), easy to author, and easy to change.

so... apache?

Maybe a small express service running on nodejs or bun.

> Essentially, apps that are something between bookmarklets and Electron apps.

You're talking about progressive web apps. MacOS / iOS / Android have them, and I started using them more recently. Essentially, they're just webviews wrapped in a native app.

PWAs have nothing to do with web views or native apps. They're just a collection of technologies (service worker, caching API, platform APIs, home screen installation, etc) that makes it possible to have offline available web apps that have a shortcut on your desktop/home screen. There is no web view or native app (outside of your default) browser involved.

Reply on news.ycombinator.com