4 ms·

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

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.
  - calebm 4mo ago
    https://fuzzygraph.com https://fuzzygraph.com is a 1.4Mb Single HTML file that I have a build script for (https://github.com/calebmadrigal/fuzzygraph https://github.com/calebmadrigal/fuzzygraph).
    - Barbing 4mo ago
      Pretty graph! iOS Safari, takes just under a second probably to load each time I pan across the graph. Wonder what it’d take to bring it all the way to smooth scrolling—too demanding on resources? Looking again, figure it has to do all the math again with each pan/drag, so minor latency makes sense.
    - notpushkin 4mo ago
      Alright, this is pretty cool. I don’t see any reason for it to be a single-file web app, though! Going through your article on the topic [0], I think the only strong point that SFWAs have which SPAs don’t is: “you can download and run them completely offline”. This highlights the best use case for SFWAs – it is something that you might want to download and run offline. Hypervault [1] is a better example here, IMO. SFWAs do have drawbacks, mainly the inability to cache things independently (it’s all-or-nothing), or to download things in parallel. So basically it boils down to two questions: • Is my app something users would want to run offline? • Will I update it frequently enough for the cache problem to matter? And it’s up to you to find the balance here. [0]: https://gods.art/articles/single_file_web_apps.html https://gods.art/articles/single_file_web_apps.html [1]: https://gods.art/articles/single_file_web_apps.html#hypervault https://gods.art/articles/single_file_web_apps.html#hypervau... --- Actually I’ve just thought of something. If it still makes sense to distribute your app as an SFWA, but you have to use a bundler, you can have the best of both worlds by making two builds: one as an SFWA, and one as a “traditional”, chunked static SPA. It should be fairly easy (just make two different configs, building from the same source).
      - calebm 4mo ago
        The biggest thing for me is how durable it is as an SFWA (avoiding software rot)
tiborsaas 4mo ago
In this case, it's 45kbyte over the network. Instead of very impractical, we might agree that it can be not ideal for many apps, but it's an interesting and valid way of "packaging" a tool / service. If someone chooses this deployment method, it's likely that they have the ability to design with minimal resources.
- snowflaxxx 4mo ago
  My take: hitting three API endpoints doesn’t require a bundler or 400 MB of node_modules — most apps, especially hobby single‑page projects, can and should be built without a framework.
pepa65 4mo ago
This is an example of a single html-file that I serve: https://basketball.4e4.in https://basketball.4e4.in It weighs in at around 30 KB including a favicon, and it's quite functional.
- Barbing 4mo ago
  Nice. Is the spacing like this on your end? Some overlap- https://i.ibb.co/3m9JKmC1/Clock-Alignment.jpg https://i.ibb.co/3m9JKmC1/Clock-Alignment.jpg

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.
- calebm 4mo ago
  https://fuzzygraph.com https://fuzzygraph.com is a 1.4Mb Single HTML file that I have a build script for (https://github.com/calebmadrigal/fuzzygraph https://github.com/calebmadrigal/fuzzygraph).
  - Barbing 4mo ago
    Pretty graph! iOS Safari, takes just under a second probably to load each time I pan across the graph. Wonder what it’d take to bring it all the way to smooth scrolling—too demanding on resources? Looking again, figure it has to do all the math again with each pan/drag, so minor latency makes sense.
  - notpushkin 4mo ago
    Alright, this is pretty cool. I don’t see any reason for it to be a single-file web app, though! Going through your article on the topic [0], I think the only strong point that SFWAs have which SPAs don’t is: “you can download and run them completely offline”. This highlights the best use case for SFWAs – it is something that you might want to download and run offline. Hypervault [1] is a better example here, IMO. SFWAs do have drawbacks, mainly the inability to cache things independently (it’s all-or-nothing), or to download things in parallel. So basically it boils down to two questions: • Is my app something users would want to run offline? • Will I update it frequently enough for the cache problem to matter? And it’s up to you to find the balance here. [0]: https://gods.art/articles/single_file_web_apps.html https://gods.art/articles/single_file_web_apps.html [1]: https://gods.art/articles/single_file_web_apps.html#hypervault https://gods.art/articles/single_file_web_apps.html#hypervau... --- Actually I’ve just thought of something. If it still makes sense to distribute your app as an SFWA, but you have to use a bundler, you can have the best of both worlds by making two builds: one as an SFWA, and one as a “traditional”, chunked static SPA. It should be fairly easy (just make two different configs, building from the same source).
    - calebm 4mo ago
      The biggest thing for me is how durable it is as an SFWA (avoiding software rot)

tiborsaas 4mo ago

In this case, it's 45kbyte over the network. Instead of very impractical, we might agree that it can be not ideal for many apps, but it's an interesting and valid way of "packaging" a tool / service. If someone chooses this deployment method, it's likely that they have the ability to design with minimal resources.

snowflaxxx 4mo ago
My take: hitting three API endpoints doesn’t require a bundler or 400 MB of node_modules — most apps, especially hobby single‑page projects, can and should be built without a framework.

pepa65 4mo ago

This is an example of a single html-file that I serve: https://basketball.4e4.in https://basketball.4e4.in It weighs in at around 30 KB including a favicon, and it's quite functional.

Barbing 4mo ago
Nice. Is the spacing like this on your end? Some overlap- https://i.ibb.co/3m9JKmC1/Clock-Alignment.jpg https://i.ibb.co/3m9JKmC1/Clock-Alignment.jpg