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.
Using a dynamic script or application to generate a static html page that requires no JS execution is a static page.
Using a static HTML page and then hiding it behind javascript execution is explicitly not a static HTML page.
Use .htaccess. And if you can't, reconsider the choices you made that restrict your abilities so significantly.
>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.
>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.
"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 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.
> 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? An :after pseudoelement in CSS?
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
Using a dynamic script or application to generate a static html page that requires no JS execution is a static page.
Using a static HTML page and then hiding it behind javascript execution is explicitly not a static HTML page.
Use .htaccess. And if you can't, reconsider the choices you made that restrict your abilities so significantly.