3 ms·

Can anyone please explain what happened to the idea of making static sites the old fashioned way? Pure HTML, CSS, and vanilla JS. And a few files organized in

Can anyone please explain what happened to the idea of making static sites the old fashioned way? Pure HTML, CSS, and vanilla JS. And a few files organized in a few folders. And upload. Why must even a static site in 2024 require Python, libraries, framework dependencies, build steps, etc?

Seb-C 3y ago
Because even in 2024 there is still the unavoidable need not to repeat huge chunks of code such as the page layout, menus, headers and metadata in every single page of the website. And because even in 2024, good SEO requires that the content be directly in the HTML source, even without JavaScript. Also there is no such "old fashioned way". The old fashioned way was to use frames, server side includes with Apache (before PHP became popular), or have WYSIWYG tools do it for you.
- Solvency 3y ago
  I'm referring to the old fashioned way. Is iframe not cool enough? SSI not leetcode appropriate? All of these methods worked fine on 2001.
  - deleted 3y ago
    [deleted]
  - Seb-C 3y ago
    Iframes have a pretty bad UX and are ugly and difficult/impossible to properly integrate in any decent design. Also it does not work well with touchscreen and responsive designs. SSI nowadays requires a host with a specific server stack and configuration. Meanwhile, with purely static files it's easy to find high quality hosts or CDNs, even for free. For simple sites, it's much easier to pre-generate the static content and then upload the output files (Web 1.0), rather than dynamically generate it for every HTTP request sent to the server (Web 2.0).
- deleted 3y ago
  [deleted]
forgotpwd16 3y ago
Because writing text in plain text files and maybe having markdown for formatting is more preferable than shoving it in HTML files. Also reducing redundancy is nice, e.g. having header in its own file rather copied in every page.
afavour 3y ago
Very few people ever did that, especially at any kind of scale. There were different answers, certainly: server side includes via cgi-bin, using PHP to bolt together string templates etc. It’s always been a pain to do something like maintain consistent navigation across multiple statically rendered pages. Very easy to look back with rose tinted glasses but previous solutions were often worse for the user, e.g. shared navigation created entirely in JS. Hell, I remember sites that used a shared Flash file!
- Solvency 3y ago
  What's wrong with rendering a navbar with a simple iframe? Or SSI? Or JS .innerHTML? Or PHP echo?
  - afavour 3y ago
    iframe: not good for accessibility, doesn't resize to fit content SSI: requires you to have a server to run the include on. Means you can't use something as cheap as an S3 bucket JS innerHTML: bad for SEO PHP echo: nothing wrong with it at all, but again, requires you to be running on a server, keep it up to date, etc etc
cpach 3y ago
It’s a matter of preference. IMHO, Markdown is a simpler and more pleasant format for writing/editing. The conversation to HTML is automated, so I don’t really need to think about it.
thiht 3y ago
Because doing it this way sucks. I used to do it this way a decade ago when I was learning and it was hell to maintain and keep consistent. It's the reason why I learned PHP in the first place (stuff like `include('header.php')` blew my mind!), because I was aware of the problems and went looking for a solution.
forgotmyinfo 3y ago
Fads and lack of education? HTML is better than ever, and authoring it isn't that bad. I do it for my own personal site, and I haven't keeled over yet. It's still allowed!
zen928 3y ago
Because we didn't want a markup language for hypertext to be the same construct we write blog posts / documentation / etc. in, we wanted consumable human-readable DSLs with no explicitly linked connotations to a browser engine (WYSIWYG renderers, markdown) The compromise between functionality and convenience since then has been creating frameworks that do these types of post-build steps to give modern functionality (templating, search, accessability options, dynamic theming, reusable custom components, ...) without compromising that idea, while still allowing flexibility on the presentation. Some go too far in either direction and lose the intent, some barely need that flexibility at all and would better be served with pure html.
jrm4 3y ago
I'll slightly modify your argument; because Pure HTML does suck: Why don't people make static sites with a simple "Markdown-or-Similar to HTML" converter, CSS, and vanilla JS...etc? (This is what I do, btw -- http://zim-wiki.org http://zim-wiki.org + a template)

Seb-C 3y ago

Because even in 2024 there is still the unavoidable need not to repeat huge chunks of code such as the page layout, menus, headers and metadata in every single page of the website. And because even in 2024, good SEO requires that the content be directly in the HTML source, even without JavaScript. Also there is no such "old fashioned way". The old fashioned way was to use frames, server side includes with Apache (before PHP became popular), or have WYSIWYG tools do it for you.

Solvency 3y ago
I'm referring to the old fashioned way. Is iframe not cool enough? SSI not leetcode appropriate? All of these methods worked fine on 2001.
- deleted 3y ago
  [deleted]
- Seb-C 3y ago
  Iframes have a pretty bad UX and are ugly and difficult/impossible to properly integrate in any decent design. Also it does not work well with touchscreen and responsive designs. SSI nowadays requires a host with a specific server stack and configuration. Meanwhile, with purely static files it's easy to find high quality hosts or CDNs, even for free. For simple sites, it's much easier to pre-generate the static content and then upload the output files (Web 1.0), rather than dynamically generate it for every HTTP request sent to the server (Web 2.0).
deleted 3y ago
[deleted]

forgotpwd16 3y ago

Because writing text in plain text files and maybe having markdown for formatting is more preferable than shoving it in HTML files. Also reducing redundancy is nice, e.g. having header in its own file rather copied in every page.

afavour 3y ago

Very few people ever did that, especially at any kind of scale. There were different answers, certainly: server side includes via cgi-bin, using PHP to bolt together string templates etc. It’s always been a pain to do something like maintain consistent navigation across multiple statically rendered pages. Very easy to look back with rose tinted glasses but previous solutions were often worse for the user, e.g. shared navigation created entirely in JS. Hell, I remember sites that used a shared Flash file!

Solvency 3y ago
What's wrong with rendering a navbar with a simple iframe? Or SSI? Or JS .innerHTML? Or PHP echo?
- afavour 3y ago
  iframe: not good for accessibility, doesn't resize to fit content SSI: requires you to have a server to run the include on. Means you can't use something as cheap as an S3 bucket JS innerHTML: bad for SEO PHP echo: nothing wrong with it at all, but again, requires you to be running on a server, keep it up to date, etc etc

cpach 3y ago

It’s a matter of preference. IMHO, Markdown is a simpler and more pleasant format for writing/editing. The conversation to HTML is automated, so I don’t really need to think about it.

thiht 3y ago

Because doing it this way sucks. I used to do it this way a decade ago when I was learning and it was hell to maintain and keep consistent. It's the reason why I learned PHP in the first place (stuff like `include('header.php')` blew my mind!), because I was aware of the problems and went looking for a solution.

forgotmyinfo 3y ago

Fads and lack of education? HTML is better than ever, and authoring it isn't that bad. I do it for my own personal site, and I haven't keeled over yet. It's still allowed!

zen928 3y ago

Because we didn't want a markup language for hypertext to be the same construct we write blog posts / documentation / etc. in, we wanted consumable human-readable DSLs with no explicitly linked connotations to a browser engine (WYSIWYG renderers, markdown) The compromise between functionality and convenience since then has been creating frameworks that do these types of post-build steps to give modern functionality (templating, search, accessability options, dynamic theming, reusable custom components, ...) without compromising that idea, while still allowing flexibility on the presentation. Some go too far in either direction and lose the intent, some barely need that flexibility at all and would better be served with pure html.

jrm4 3y ago

I'll slightly modify your argument; because Pure HTML does suck: Why don't people make static sites with a simple "Markdown-or-Similar to HTML" converter, CSS, and vanilla JS...etc? (This is what I do, btw -- http://zim-wiki.org http://zim-wiki.org + a template)