>If you have to run javascript it is not a static page anymore. I've seen a lot of this particularly weird overloading of "static HTML" lately. Static HTML, or static webpage, is meant to describe the experience from the person who is trying to look at the page. It does not describe the experience of the dev.

I don't think this has been the common meaning of "static page" for at least 10 years.

From Wikipedia [0]:

>A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored

Static refers to the fact the files are served without any application-level processing on the server side beyond simple file serving. A page can depend on CSS/JS/WASM and still be a static page.

[0] https://en.wikipedia.org/wiki/Static_web_page

>A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored"

Right. "exactly as stored" It doesn't matter who or what wrote the HTML. I could do it by hand or maybe use a WYSIWYG editor to make it or maybe it's generated by a script. The point is that there's an html file sitting on disk and the server delivers it without modification and it's viewable in the browser as it. It's just the webserver sending the contents of the file.

Whereas this "Password protected a static HTML page" cannot be viewed in the browser without a "web application", the javascript, dynamically changing the file. It's pretty clear cut. So it fails the test of the very link you posted:

>in contrast to dynamic web pages which are generated by a web application

>>A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored"

>Right. "exactly as stored" It doesn't matter who or what wrote the HTML. I could do it by hand or maybe use a WYSIWYG editor to make it or maybe it's generated by a script.

Yes, agree.

>The point is that there's an html file sitting on disk and the server delivers it without modification and it's viewable in the browser as it.

No, I don't think that's the widely understood interpretation of "static web page."

Even the definition you agree with just says the file is delivered as-is. It says nothing about how the browser renders the page.

It's really not "clear cut." By the definition which you agree with, an HTML file containing JavaScript is served to the client without modification, and is viewable in any modern browser with a functioning JavaScript engine. The "web application" in reference is a server-sided application which controls and renders the content, as can be assumed based on context from the rest of that page. Namely:

> Any personalization or interactivity has to run client-side, which is restricting.

The title says “static HTML page” not “static web page”.

JavaScript is not HTML.

Neither is CSS, if you want to be pedantic.

I agree

OP said static HTML page though, that very much means something only using static as opposed to dynamic HTML.

https://en.wikipedia.org/wiki/Dynamic_HTML

"DHTML allows scripting languages to change variables in a web page's definition language, which in turn affects the look and function of otherwise "static" HTML page content after the page has been fully loaded and during the viewing process. Thus the dynamic characteristic of DHTML is the way it functions while a page is viewed, not in its ability to generate a unique page with each page load.

By contrast, a dynamic web page is a broader concept, covering any web page generated differently for each user, load occurrence, or specific variable values. This includes pages created by client-side scripting and ones created by server-side scripting (such as PHP, Python, JSP or ASP.NET) where the web server generates content before sending it to the client."

I think "static" and "dynamic" can reasonably be used to describe both server-side and client-side behaviour, and I don't think that the dual meaning is particularly new.

Yes, "Dynamic HTML" vs "Static HTML" to refer to JS-dependent and JS-free pages respectively has been around since the dawn of javascript, but my copy of the 1996 O'Reilly CGI Programming on the World Wide Web by Gundavaram contains sentences like

"Virtual, or dynamic, document creation is at the heart of CGI" (p.4)

"A common use for [server redirection] is to return a generic document that contains static information. [...] Suppose you have an HTML file (thanks.html) like the one below, that you want to display after the user fills out one of your forms: [...] You could use the programs discussed earlier to return static documents, but [...] it is much quicker and simpler to [redirect with a "Location" header]." (pp.44-45)

...without mentioning javascript anywhere.

I think your definition of a static web page is different from the common one?

In my head, a static page is something that's served verbatim, without some backend generating it or inserting things into a template.

Wikipedia seems to agree with that view: https://en.wikipedia.org/wiki/Static_web_page

That's exactly what I said. It doesn't matter if I wrote the HTML by hand or I had a perl, or bash, or compiled c program make it. It's just an HTML file.

HTML includes the content of style and script elements (among many others) and the results of whatever they do.

The combination of all of these direct a browser in how to render a page.

Traditionally, a static site or static page is one whose data can be delivered to the client directly as stored, with no server-side alterations or generation.

This is/was a meaningful distinction because a server that can stream stored data is fundamentally much simpler than one that executes programs. Such a server can run in different contexts, be optimized in different ways, and satisfies constraints that allow further optimizations downstream.

You're incorrect

CSS and JavaScript and images are also static, it doesn't have to be just HTML

If you have a perl or bash or c backend generating html in response to http requests it's not static

You're assuming this is a backend. It is not. Do you consider generating an HTML file in a WYSIWYG editor like, say, "Dreamweaver" that outputs an .html no longer static because it was made by a program? That's absurd.

No, that's static, that's why I said "in response to an http request"

It can be html, css, javascript, whatever.

'Static' means it's only made of static file that can be served by just a vanilla Web server (i.e. just by serving static files).

Lol no. If you HTML is generated, it's by definition not static anymore.

Otherwise, all of the React server side rendering is static HTML.

Oh, so when I make an .html file in Dreamweaver WYSIWYG HTML editor and save the .html file to my websever ~/www/ dir it is automatically not a static page anymore because I used a program to generate it? This is a very wild and weird interpretation of 'static site' that does not fit with existing usage.

You are the last person to have a say in that considering your incorrect take that JS can't be static. You're clearly misaligned with common usage of terms.

When javascript started being able to change HTML significantly the result was literally named "Dynamic HTML". So it is clear this is not a static HTML page. The only thing left to argue is weather it is a static web site. People who got into web dev after 2010 will say yes, people who watched HTML/JS evolve over it's lifetime will say no.

No, because React is dynamically generating the HTML on the fly.

If you pre-compile the HTML using something like Jekyll, so that the webserver is just serving HTML files without any dynamic/on-the-fly processing at request time, then it's considered static.

React server side rendering: most likely dynamic

React on the client side: static, as you still got the same files served, how they dynamically alter the page runtime doesn't count.

This is the most bizarre argument. Of course you can use build tools to generate static web pages.

The issue is whether they are being generated dynamically by a server. This project isn't. You run a build-tool once and then can post the .html page anywhere. It's static.

You can put client-side JavaScript fine in “just an HTML file”?

That is not correct. As long as the javascript is run on the client-side, it's a static page. Static simply means the files on the server are sent directly to the client. The client can then do whatever they want with the files.

The expression "dynamic" was trending a decade or two ago to vaguely refer to javascript+HTML5. It was never the opposite of "static" in this domain.

I would call any server side or client side code which alters the HTML non-static. A static HTML page is just an HTML file which is stored on the server and displayed as-is in the browser.

That’s not a generally accepted as the definition of a static page.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/Websit...

> You can use Amazon S3 to host a static website. On a static website, individual webpages include static content. They might also contain client-side scripts.

By contrast, a dynamic website relies on server-side processing, including server-side scripts, such as PHP, JSP, or ASP.NET. Amazon S3 does not support server-side scripting, but AWS has other resources for hosting dynamic websites. To learn more about website hosting on AWS, see Web Hosting.

Naturally Amazon doesn't care about client site code, as they are not in the browser business. But JavaScript is in fact typically called "dynamic" content. Insofar it is not static.

Exactly. I don't know where the confusion is, but I'm saying that it doesn't matter how the page is generated. It is sent to the website visitor as just HTML. When the user views it it is all there, just html. No changes.

For example, I have a perl script that generates a set of .html files every night to show new additions to my library. They are static .html files on disk and never modified before the user views them. Just because a perl script (not connected to the web server in any way) made it does not "taint" the HTML so it is not static. The program, or the person, that wrote the HTML does not matter. All that matters is that it's just static unchanging HTML.

Everyone is allowed to give their own meaning to words, but you can't expect to just change a widely agreed meaning to match it. "Static" means it is just a set of files. Not that the page is stationary. Do you think that a blink tag in a HTML page makes it non-static? A hover effect?

If your perl script is saving the HTML to the disk, then yeah, your website is static. If it's generating HTML on the fly, it's dynamic. That's the widely agreed upon meaning, and that's it.

Just a set of files? Awesome! I had no idea that unix itself was a static OS.

You're interpreting the title as "a static HTML page with password protection", but the way I understood it is "statically hostable version of a static HTML page with password protection", which seems to be exactly what this implements. I'm probably biased because I would have frequently had use for this, and all the paid offerings mention "private hosting of static pages", but I feel you're a bit uncharitable with your interpretation.

If you want to just have a free small private static page which is easily updated by public CI offerings this is a great solution, and the title transports this clearly.

> If you have to run javascript it is not a static page anymore

I understand static pages as files sent to a browser without having to be generated server-side.

Right. This concept has existed for decades, and people should figure out what it actually means before complaining.

This is nonsense semantics. Words and phrases change meaning over time.

It didn’t even “change meaning”

As far back as I remember (and I played with JavaScript when it was first introduced in beta for Netscape), a “static web page server” always meant that there was no backend server generating pages on the fly.

Disregarding what is or is not static, some thing like https://github.com/brandondong/css-turing-machine could be used to encrypt content that is decrypted successfully only when a matching set of elements are toggled without javascript.

Title is still accurate, the tool is for password protecting a static HTML page. The page starts out as a static HTML page. Then this tool generates something that has password protected it.