> I haven't seen GitHub break a working URL that they have hosted in the 17+ years since they first launched.

Nice post! This is only a nit: They did break working URLs at least once sometime between 2020 and 2023. Until 2013, GitHub served GitHub Pages from the USERNAME.github.com subdomains. Understandably, this was a security nightmare, due to which in 2013 they made the switch to USERNAME.github.io for GitHub Pages.

For several years they took care of automatically redirecting something like <http://newmerator.github.com/> to <http://newmerator.github.io/>. But if you click on those links now, you'll find that the former does not work anymore.

You can read more about it at <https://github.blog/news-insights/product-news/new-github-pa...>. The example link I've shared in the previous paragraph has been picked from this article.

In fact, <https://web.archive.org/web/20200000000000*/http://newmerato...> shows that the redirection worked until at least Feb 2020. But by Nov 2023, the redirect was already broken.

I'm disappointed that they eventually broke those redirects. They still have a much better record than most though!

> If you want to create completely free software for other people to use, the absolute best delivery mechanism right now is static HTML and JavaScript served from a free web host with an established reputation.

Ahm, I doubt that the FSF and many others share this bold opinion - the benchmark for free software and distribution infrastructure is still GNU/Linux in distros like Debian. Probably BSD comrades can suggest something similar. Distributing free software for more than 30 years and beyond, mostly on top of C, is something I would recommend far more than "free web-hosted" HTML/Javascript.

I don't disagree with you, but one interesting consideration is that embedding it in a web page seems better than most other distribution mechanisms if you want average people to use it.

Even among a technical crowd, most folks don't want to install some random library or another Electron-based app to test your pet project.

And if you want to release a library, or if your program depends on tons of libraries, then a webpage doesn't make sense.

> the absolute best delivery mechanism right now is static HTML and JavaScript served from a free web host with an established reputation.

It can be, depending on the nature of the software. However, for a heaping ton of software (such as libraries or software that is meant to be used without internet access) it can be the worst option.

The real answer, as always, is that there is no universal one-size-fits-all solution to this.

you do not need the internet to open a ".html" file. With some "importmap" gymnastics you can embed images and libraries inside that file, all without the internet, offline-first

https://bsky.app/profile/chrisshank.com/post/3llmhyr33q22x

Even so, you have to run a webserver and then run a browser separately and let the app sort of envelop you in this bubble made of norms that don't jive with the rest of your OS. Like, good luck making it append logs to a file without writing a third component that you now have to manage the state of in addition to the first two.

For the majority of things I do I just want to shove data in one end and get data out of the other end without ever having to build a UI or wondering if it's "up" or "down".

Back in the day Internet Explorer could save a webpage. It would store an HTML page and a folder with all the images in it next to the HTML page.

And somehow they were linked. Deleting one deleted the other.

You could open the HTML page from your disk, in Internet Explorer. No internet required.

Update: they weren't linked at the filesystem level. Explorer.exe tracks .htm/.html and a folder_ together: https://learn.microsoft.com/en-us/windows/win32/shell/manage...

no you don't need to run a webserver, it works from a file domain directly. But true its not a CLI. Been thinking about whether that is possible though.

> you do need some sort of layer that parses the html and JS and executes the JS

A web browser?

I have taken a similar approach for the few modest games and fun tools I've developed. Twenty years ago, I would have likely turned to C or Perl, carefully weighing their pros and cons for maximum portability. But these days I just whip up an HTML page with some CSS and JavaScript. My tools are not performance intensive, so this approach has served me well. Perhaps, one day, I'll use WASM for similar projects when performance becomes a concern.

I have found HTML5 Canvas and JavaScript to be very effective for writing small games. If sound is needed, there is Web Audio available too, right within the web browser. It is quite possible to write simple games without using any external JS libraries by sticking to first principles only: drawing simple shapes with fillRect(), implementing simple collision detection algorithms, generating simple tones using OscillatorNode, etc. Here is one such game I wrote sometime back: <https://susam.net/invaders.html>.

Also, by embedding all CSS and JavaScript into a single HTML file, the game/tool becomes instantly portable. All we need to do is host the HTML file somewhere, or send the file to someone, in order to share the game. Even when it is hosted on a website, savvy users can curl/wget it, or simply perform "Save Page As" to download it and run it as a local app!

Further, if the HTML is written and formatted neatly (rather than being bundled or minified), the endangered subspecies of developers who still like to "View Source" can easily copy, edit, and customise the code to suit their own needs, and see their changes take effect instantly.

This feels...bad in a way.

Like, I feel like there's probably some importance in reinforcing the idea of "this is valuable enough such that you should take a copy for yourself that you can keep forever if you want, on your machine, to do with whatever you want."

Makes it feel more valuable or important? Something like that.

Another nice thing about distributing apps as static HTML and JavaScript is that there not much extra work needed to turn them into apps people can download and run offline.

> My top choice for this kind of thing in 2025 is GitHub, using GitHub Pages. It's free for public repositories and I haven't seen GitHub break a working URL that they have hosted in the 17+ years since they first launched.

As someone who's interested in keeping online things around for a very long time, GitHub's owned by Microsoft now, and Microsoft's needs can change at any moment.

Unfortunately, I can't think of a better alternative for people who "lose interest" in their projects, short of non-profit organisations like Internet Archive or Apache Foundation taking over.

Maybe the best solution is to just have mirrors of the Git repo and pages hosted elsewhere like GitLab, and let search engines do the work of finding the software for anyone interested.

As an option maybe, but why promote to store software on someone else's computer? That same static site could work locally on a browser as well.

Unfortunately, browsers have collectively decided that end-users are stupid and can't be trusted. Very few features work over the file: protocol. There's no local-https server that I can teach a non-tech-savvy user to use.

It's a bit heavy handed, but the VSCode "Live Server" plugin is the closest I've come. If I set code as the default file association for `.html`, then it's just one extra click to get it open in a browser with a local server.

This isn't going to work for everyone, but if you're dealing with non-tech-savvy but mostly-able-to-use-a-computer users, it can, and it being graphical seems to be less of a hill than if I tell people to run `python -m http.server` in the terminal (because, "what is a terminal"...)

There are multitude of ways to package a website for a local computer, Electron and ton of more lightweight alternatives. Actually it's the most popular way to make desktop software nowadays.

It may be unfortunate in some sense, but they aren't wrong. And even smart end users shouldn't incur that much constant risk of malware, given how many threat actors are out there.

> My top choice for this kind of thing in 2025 is GitHub, using GitHub Pages. It's free for public repositories and I haven't seen GitHub break a working URL that they have hosted in the 17+ years since they first launched.

Does JS and Pyodide work on GH papges? Last I checked it only serves static pages.

Tangent: What if I want to release a Python project to the world but keep it closed-source? Can we obfuscate code in Pyodide?

Yes. Static pages can include frontend JavaScript, including WebAssembly + Pyodide. You'll likely just have a build step that produces the actual JavaScript bundle you'll be serving statically.

As for obsfucation, you could precompile to Python bytecode (.pyc files), and then to obsfucate that further you could e.g. pyminify before the bytecode compilation.

There's also pyarmor, but as of 2022 [1] that was unsupported.

[1]: https://github.com/pyodide/pyodide/discussions/2325

Unfortunately even though WebAssembly assets can be served statically, you need certain headers to be set to use SharedArrayBuffer, which as far as I can tell is not possible on GH Pages[1]. Pyodide seems to use SharedArrayBuffer for at least some functionality.

[1] https://github.com/orgs/community/discussions/13309

Oh that's really disappointing. I've been loading Pyodide from a CDN so I hadn't noticed that.

The one downside of GitHub Pages generally is the lack of custom header control - you can't serve proper HTTP redirects for example.

HTML + JS + static files is a great combination. Microsoft introduced Hypertext Applications[1] in 1999, but they were probably too far ahead of their time.

I wish there was some way to combine HTML + JS + brand agnostic cloud or local storage.

[1] https://en.wikipedia.org/wiki/HTML_Application

What some good example apps that use Pyodide? Looking for some good examples that are in people's hands right now. Lot of (web) apps I commonly see use React, Typescript and talk to a web service.

I'm not sure if they are "apps" per se, but both are these are running python code via pyodide in the browser:

https://marimo.app/ https://pydantic.run/

> My top choice for this kind of thing in 2025 is GitHub, using GitHub Pages. It's free for public repositories and I haven't seen GitHub break a working URL that they have hosted in the 17+ years since they first launched.

> A few years ago I'd have recommended Heroku on the basis that their free plan had stayed reliable for more than a decade, but Salesforce took that accumulated goodwill and incinerated it in 2022.

As someone building a new hosting provider with a free tier (https://val.town) it's so lovely to see folks like Simon value long-term stability. It makes it easier to make the business case to invest in it. At the end of the day, it's all about trust.

I like doing silly apps, basically just a bunch of SPAs, for either testing something or doing a favor for someone, and (sadly) I agree, the best way of distributing software right now for the vast majority of non-techy people is through the web.

I don't like javascript much, but the option to statically host something for free while solving real problems is... something else.

I know WASM has been here for a long time but last time I tried I still had some issues setting it up (maybe just skill-issues), but I'd like to live in a world where I could do the same stuff but with other languages. Maybe just the UI code in javascript, or at least, that's what I would wish for.

The really interesting thing about this article recommending flat html + js for hosting... is that it is written by the original co-author of Django. Yes, each tool has the right place etc, but still interesting nonetheless.

Am I missing something or is this entirely unrelated? Django is server-side technology. This is discussing a delivery mechanism for simple client-side software, not a full blown webapp that interacts with a database. You would need to supplement this with something like AWS Lambda or Cloudflare Workers, but that's a big step up in complexity from what's being discussed.

Nope, you aren't missing something. As I said, each tool has its job.

My first experience with Django was writing a small blog, which is now better served with the likes of Hugo. I am sure I am not the only one that has made a similar journey.

It's "unrelated", but the funny part is that all of that "full blown webapp that interacts with a database" complexity is being (perhaps not so explicitly) shunned and deemed unnecessary.

> Thanks to WebAssembly the set of potential software that can be served in this way is vast and, I think, under appreciated. Pyodide means we can ship client-side Python applications now!

Have any of you tried this? What's the overhead/performance like?

I use this for https://lite.datasette.io - server from GitHub Pages - and it works extremely well. The Pyodide Python distribution only adds a couple of MBs to the page load which is incredibly low IMO.

If your concern is infrastructure costs making the software no longer available, why choose a website approach in the first place? Distribute it so that users can run it on their computers and it'll work forever.

That's not the only concern though. The web is by far the most accessible way to distribute something, which is paramount in getting people to use it.

For the Java crowd, a similar tool to build real, modern single page apps in Java is Flavour:

https://frequal.com/Flavour/book.html

Can that be served from a static file?

SPPA: single page python app

Web browsers are just glorified JavaScript interpreters. Making Python a first-class citizen in the browser would be sweet.

I'm starting to do this now. I build an open source version and then offer an easy-to-use web interface for paid users.

On a side note, more and more people are actually doing just that, with a lot of "screenrecorders in browser", "ffmpeg in browser" etc, which are just scripts / c++ code compiled to WASM and bundled as html+js

> the absolute best delivery mechanism right now is static HTML and JavaScript served from a free web host with an established reputation.

Exactly, not only is that cross-platform and frictionless, but it additionally solves the trust issue since the app runs in a more secure browser sandbox.

This is also why I recently ported my fork of the FreeJ2ME emulator to the web (with help of CheerpJ which runs Java in browser), I believe this is the most future-proof way to preserve access to J2ME games: https://github.com/zb3/freej2me-web