3 ms·

I wonder why this type of deployment is not more popular - pushing all resources inside a single HTML file, with a script tag, and inline resources as blobs.

snowflaxxx 4mo ago
You just described the Macaroni plugin system — plugins are literally appended as <script> tags before the closing </html> tag.
- account42 4mo ago
  Note that you don't actually need a closing </html> tag.
  - snowflaxxx 4mo ago
    The closing </html> tag is mandatory because Macaroni Messenger plugins are inserted immediately before it. This is the convention defined by the plugin system.
andai 4mo ago
I do this whenever possible. As a separate issue, I also aim for <50KB whenever possible, e.g. I made a multiplayer browser game in 32KB and a LLM UI in 20KB. That might just be an aesthetic choice on my part, but I often find that I am able to implement all the features I need in surprisingly few lines of code. e.g. the first version of my LLM UI was 200 lines and quite usable for my purposes. And my OpenClaw clone was 50 lines. Just a Telegram wrapper around Claude, but turns out that's all I needed.[0] Also no dependencies, frameworks, libaries etc. Not a hard rule, but I find that they add negative value about 90% of the time, at least at my scale. There are dozens of us! :) [0] Of course, "Claude Code" isn't 50 lines. Except, it turns out you can replace it in about 50 lines. From the SWE-bench folks: https://minimal-agent.com/ https://minimal-agent.com/ To this I added the missing outer loop (so it's actually an agent a human can use) and vendored in a microscopic llm lib (yay no deps). https://gist.github.com/a-n-d-a-i/bd50aaa4bdb15f9a4cc8176ee387b212#file-agent-py-L110 https://gist.github.com/a-n-d-a-i/bd50aaa4bdb15f9a4cc8176ee3...
- pepa65 4mo ago
  Would be nice if you could make a version people can run in their browser..!
janilowski 4mo ago
It's very impractical. - you get a slower first load (cannot progressively fetch resources as they're needed) - can't reuse a stylesheet, script or image on a different page (each has to have their own copy) - can't cache commonly used files - can't make granular changes to specific parts of the code. user has to reload everything each time. - can't set a proper content security policy And many more! It's cool for a tiny demo but for anything serious you wouldn't want a single (extremely ugly) HTML file.
- voidUpdate 4mo ago
  > "can't reuse a stylesheet, script or image on a different page (each has to have their own copy)" Not a problem if you're deploying a single file
- hnlmorg 4mo ago
  I'm not advocating this development approach, but I also think some of your reasons aren't particularly robust when scrutinized. > can't reuse a stylesheet, script or image on a different page (each has to have their own copy) Isn't the point of a single HTML file that you don't have different pages that would need to reuse those assets? > can't cache commonly used files You can still cache the HTML. > can't make granular changes to specific parts of the code Pretty sure text editors can edit text regardless of whether it's a single file or multiple files. > can't set a proper content security policy I'd have thought a single page HTML file could negate the need for a CSP since you no longer have any resources accessible via a URI that you need to limit access to. > you wouldn't want a single (extremely ugly) HTML file Ugliness a subjective. --- I think your first load point is the strongest one. But I'd also throw in "it's harder to develop a good single page HTML" You could probably mitigate some of that difficulty by having a build script (like static site compilers) but then you have to ask yourself if you're introducing more complexity than you're attempting to solve.
  - notpushkin 4mo ago
    If you need a build script, your app is probably too big to be a single .html already. > You can still cache the HTML. But then any time you update any part of the app, the user has to re-download the whole thing. It is also a problem with many traditional frontend builds, but if you carefully split it into chunks, you can update parts of the app while most of it stays cached. See e.g. Linear’s approach to vendor dependencies: https://performance.dev/how-is-linear-so-fast-a-technical-breakdown#linears-bundler-arc-parcel-rollup-vite-rolldown https://performance.dev/how-is-linear-so-fast-a-technical-br... --- The strong point of single .html apps is, of course, that you can run them locally without setting up a web server or anything, and deploy anywhere you want by just uploading it. But it is a fairly niche thing IMO.
Theodores 4mo ago
Or as an SVG file. I have an interesting experiment that puts a sprites sheet, CSS and even some scripting in the favicon file. Since every browser wants some type of favicon anyway, why not overload it with fun stuff? Sure the JavaScript won't load in CSS or favicon mode, but it can be loaded into the Dom as well as exist in the CSS. In my SVG file I have lots of CSS variables generated by the JavaScript, then saved as a big list in the SVG, enabling light/dark mode things. SMIL animation too. This experiment is based on what you described, an all in one HTML file. In that experiment the CSS was getting clumsy due to the amount of SVG I had in there, so I put the CSS in the SVG for fun. As for why, I am creating a modern version of an Embroidery sampler. These existed from centuries ago and served as a portfolio of sorts plus a reference on different stitches, such as how to do the alphabet. So my SVG sampler has examples of how to do tricky things in SVG, with all of it human drawable and readable, so no massive paths, just simple primitives, clipped, masked, transformed and cloned to create all my icons, logos and clipart. I hope to make SVG samplers a thing, so one SVG file and one HTML file to illustrate how it all works. To be honest it has been an excellent learning experience and I can now do so many things with just the MDN reference for SVG as my guide.
calebm 4mo ago
I've been trying to advocate for Single File Web Apps. I even tried to create a wikipedia page (https://en.wikipedia.org/wiki/Draft:Single_File_Web_Apps https://en.wikipedia.org/wiki/Draft:Single_File_Web_Apps), but it keeps getting rejected. I created a couple Single File Web Apps: https://fuzzygraph.com https://fuzzygraph.com and https://hypervault.github.io/ https://hypervault.github.io/.
- nashashmi 4mo ago
  1. Start an SFWA competition as a joke. Then watch the submissions come in. First year it will be a handful. Second year it will be heavy. 2. Publish sfwa articles on wikia. Blog the development process. 3. A show page for sfwa creations. Maybe the ideas above should be in reverse order?
  - calebm 4mo ago
    I have an article on sfwa's here: https://gods.art/articles/single_file_web_apps.html https://gods.art/articles/single_file_web_apps.html. Still hasn't been enough to get past the wikipedia pedants.

snowflaxxx 4mo ago

You just described the Macaroni plugin system — plugins are literally appended as <script> tags before the closing </html> tag.

account42 4mo ago
Note that you don't actually need a closing </html> tag.
- snowflaxxx 4mo ago
  The closing </html> tag is mandatory because Macaroni Messenger plugins are inserted immediately before it. This is the convention defined by the plugin system.

andai 4mo ago

I do this whenever possible. As a separate issue, I also aim for <50KB whenever possible, e.g. I made a multiplayer browser game in 32KB and a LLM UI in 20KB. That might just be an aesthetic choice on my part, but I often find that I am able to implement all the features I need in surprisingly few lines of code. e.g. the first version of my LLM UI was 200 lines and quite usable for my purposes. And my OpenClaw clone was 50 lines. Just a Telegram wrapper around Claude, but turns out that's all I needed.[0] Also no dependencies, frameworks, libaries etc. Not a hard rule, but I find that they add negative value about 90% of the time, at least at my scale. There are dozens of us! :) [0] Of course, "Claude Code" isn't 50 lines. Except, it turns out you can replace it in about 50 lines. From the SWE-bench folks: https://minimal-agent.com/ https://minimal-agent.com/ To this I added the missing outer loop (so it's actually an agent a human can use) and vendored in a microscopic llm lib (yay no deps). https://gist.github.com/a-n-d-a-i/bd50aaa4bdb15f9a4cc8176ee387b212#file-agent-py-L110 https://gist.github.com/a-n-d-a-i/bd50aaa4bdb15f9a4cc8176ee3...

pepa65 4mo ago
Would be nice if you could make a version people can run in their browser..!

janilowski 4mo ago

It's very impractical. - you get a slower first load (cannot progressively fetch resources as they're needed) - can't reuse a stylesheet, script or image on a different page (each has to have their own copy) - can't cache commonly used files - can't make granular changes to specific parts of the code. user has to reload everything each time. - can't set a proper content security policy And many more! It's cool for a tiny demo but for anything serious you wouldn't want a single (extremely ugly) HTML file.

voidUpdate 4mo ago
> "can't reuse a stylesheet, script or image on a different page (each has to have their own copy)" Not a problem if you're deploying a single file
hnlmorg 4mo ago
I'm not advocating this development approach, but I also think some of your reasons aren't particularly robust when scrutinized. > can't reuse a stylesheet, script or image on a different page (each has to have their own copy) Isn't the point of a single HTML file that you don't have different pages that would need to reuse those assets? > can't cache commonly used files You can still cache the HTML. > can't make granular changes to specific parts of the code Pretty sure text editors can edit text regardless of whether it's a single file or multiple files. > can't set a proper content security policy I'd have thought a single page HTML file could negate the need for a CSP since you no longer have any resources accessible via a URI that you need to limit access to. > you wouldn't want a single (extremely ugly) HTML file Ugliness a subjective. --- I think your first load point is the strongest one. But I'd also throw in "it's harder to develop a good single page HTML" You could probably mitigate some of that difficulty by having a build script (like static site compilers) but then you have to ask yourself if you're introducing more complexity than you're attempting to solve.
- notpushkin 4mo ago
  If you need a build script, your app is probably too big to be a single .html already. > You can still cache the HTML. But then any time you update any part of the app, the user has to re-download the whole thing. It is also a problem with many traditional frontend builds, but if you carefully split it into chunks, you can update parts of the app while most of it stays cached. See e.g. Linear’s approach to vendor dependencies: https://performance.dev/how-is-linear-so-fast-a-technical-breakdown#linears-bundler-arc-parcel-rollup-vite-rolldown https://performance.dev/how-is-linear-so-fast-a-technical-br... --- The strong point of single .html apps is, of course, that you can run them locally without setting up a web server or anything, and deploy anywhere you want by just uploading it. But it is a fairly niche thing IMO.

Theodores 4mo ago

Or as an SVG file. I have an interesting experiment that puts a sprites sheet, CSS and even some scripting in the favicon file. Since every browser wants some type of favicon anyway, why not overload it with fun stuff? Sure the JavaScript won't load in CSS or favicon mode, but it can be loaded into the Dom as well as exist in the CSS. In my SVG file I have lots of CSS variables generated by the JavaScript, then saved as a big list in the SVG, enabling light/dark mode things. SMIL animation too. This experiment is based on what you described, an all in one HTML file. In that experiment the CSS was getting clumsy due to the amount of SVG I had in there, so I put the CSS in the SVG for fun. As for why, I am creating a modern version of an Embroidery sampler. These existed from centuries ago and served as a portfolio of sorts plus a reference on different stitches, such as how to do the alphabet. So my SVG sampler has examples of how to do tricky things in SVG, with all of it human drawable and readable, so no massive paths, just simple primitives, clipped, masked, transformed and cloned to create all my icons, logos and clipart. I hope to make SVG samplers a thing, so one SVG file and one HTML file to illustrate how it all works. To be honest it has been an excellent learning experience and I can now do so many things with just the MDN reference for SVG as my guide.

calebm 4mo ago

I've been trying to advocate for Single File Web Apps. I even tried to create a wikipedia page (https://en.wikipedia.org/wiki/Draft:Single_File_Web_Apps https://en.wikipedia.org/wiki/Draft:Single_File_Web_Apps), but it keeps getting rejected. I created a couple Single File Web Apps: https://fuzzygraph.com https://fuzzygraph.com and https://hypervault.github.io/ https://hypervault.github.io/.

nashashmi 4mo ago
1. Start an SFWA competition as a joke. Then watch the submissions come in. First year it will be a handful. Second year it will be heavy. 2. Publish sfwa articles on wikia. Blog the development process. 3. A show page for sfwa creations. Maybe the ideas above should be in reverse order?
- calebm 4mo ago
  I have an article on sfwa's here: https://gods.art/articles/single_file_web_apps.html https://gods.art/articles/single_file_web_apps.html. Still hasn't been enough to get past the wikipedia pedants.