Writing HTML by hand is easier than debugging your static site generator
The blog author discusses challenges of static site generators versus manual HTML coding, citing setup complexities and advocating for simplicity, stability, and control in website management. Emphasizes static data benefits.
Read original article
The author of the blog "the logic grimoire" reflects on the challenges of using a static site generator compared to hand-coding HTML. They express frustration with the complexities of setting up and maintaining a site generator, highlighting issues with system dependencies and configurations. The author argues that maintaining a website as a folder of HTML files offers simplicity and ease of use, especially when transitioning to new environments. They emphasize the benefits of static data over dynamic code for long-term maintenance, advocating for validated formats to avoid constant changes and potential breakages. The preference for manual HTML coding is driven by the desire to have more control and stability in website management. The post originated from a discussion on Mastodon.
Related
The demise of the mildly dynamic website (2022)
The evolution of websites from hand-crafted HTML to PHP enabled dynamic web apps with simple deployment. PHP's decline led to static site generators replacing mildly dynamic sites, shifting to JavaScript for features like comments.
Curating my corner of the Internet with a freehand web editor
The article reflects on the decline of personal websites in favor of commercial platforms, advocating for unique web design. It discusses limitations of current tools and introduces Hotglue as a freehand web editor promoting creativity and individuality.
Exposition of Front End Build Systems
Frontend build systems are crucial in web development, involving transpilation, bundling, and minification steps. Tools like Babel and Webpack optimize code for performance and developer experience. Various bundlers like Webpack, Rollup, Parcel, esbuild, and Turbopack are compared for features and performance.
Surfing the (Human-Made) Internet
The internet's evolution prompts a return to its human side, advocating for personal sites, niche content, and self-hosted platforms. Strategies include exploring blogrolls, creating link directories, and using alternative search engines. Embrace decentralized social media and RSS feeds for enriched online experiences.
Microfeatures I love in blogs and personal websites
The article explores microfeatures for blogs and websites inspired by programming concepts. It highlights sidenotes, navigation tools, progress indicators, and interactive elements to improve user experience subtly. Examples demonstrate practical implementations.
42 commentsAnd since I'm already there, I do also like scss + file watching / hot reloading. Though would happily live without it, if there was a 'native' solution to e.g.
<html>
<% include './header.html'>
<body>
...
</body>
<% include './footer.html'>
</html>Might be true until you need to create those lovely RSS feeds by hand…
> Do you enjoy debugging programming language installations? What about the language’s package ecosystem?
No and that is why I switched from Jekyll to the single binary SSG Hugo. Zola works the same way, single binary.
- It's fun to play around with static site generators as a technical person
- It's very annoying to actually write content (As you link images by using the file name, no nice editing interface, using a markdown editor is clunky as features of the blogging software (Embedded videos tags etc.) are not supported
- It's impossible for non-technical people to use it. My main reason why I would never introduce a static site generator for documentation at work again.
- You still need some kind of tooling to generate RSS feeds, sitemaps, pagination, so I've settled on https://getkirby.com for now which has a nice editor interface but is file based and doesn't need a database. Makes it easy to backup and move between hosts if needed.
The author is referring to a particular generator, which I agree can be a ridiculous process.
Sure, I could have a dynamic site (ROR, or Express or whatever) but static is easier to serve, and changes are quickly diffed except once a month when the structure is updated.
If was just doing a small site, sure, but anything substantial requires something better.
I don't know about your static generators, but my 40 lines of bash are very easy to debug!
Astro is only as complex as you make it. It lets you write JSX-like syntax that compiles to static HTML. I use it for my personal site.
[0]: https://astro.build/
[1]: https://sjer.red/
[1]: (source code) https://github.com/shepherdjerred/sjer.red
Theming, shared blocks, etc. are all handled just fine by using includes. If those are stored in Jinja2 templates or HTML files that use SSIs is pretty irrelevant to me.
As long as I can write in Markdown, I'm happy.
Switching to a generator that ships as a single binary largely resolved this for me.
With https://www.getzola.org and similar you only need worry about installing the same version as the one that's building your site in production.
Yes, it _is_ easier to write plain ol HTML. But how do you handle consistency by hand writing each page? How do you scale your site or add * number of posts or headers and footers that do things like show the latest post? If you update a link somewhere, how do you ensure all the links pointing to it are valid?
We don’t do these things because we’re masochistic. We do them because they, on the net, make things easier. I suspect this sentiment is some kind of new version of the Eternal September, where people previously unexposed to the hardships of creating functional websites think we somehow missed something in our slow march toward where we are now.
I happen to have a hand built static site. It had two pages. When I built the second page, I took the first html file, copy pasted it into a new path and made the changes. That works splendidly for a two page site. But most sites are not this way, I imagine.
Most of Pelican’s code was written by other people, and yet I have spent almost zero time debugging that code, much less my own. After taking advantage of Pelican’s rich plugin ecosystem and adding a handful of useful plugins, I continue to be amazed by how much time this publishing system saves me, and how little time I must spend to keep everything running smoothly.
What it would take to accomplish this by writing HTML by hand instead… I simply can’t fathom it. But once again, that’s just one person’s experience, and YMMV.
[1]: https://github.com/geolessel/vox
[2]: https://fly.io/phoenix-files/crafting-your-own-static-site-g... - HN: https://news.ycombinator.com/item?id=40850021
This means that a "custom buggy sitegenerator" is never a bad dependency to have.
That's why I never use ANY tools like this without getting them working in something like GitHub Actions (which is effectively free these days, and all the good LLMs know how to write YAML workflow files for it.)
If you outsource the running of these tools to a CI service you don't have to worry about setting them up on new machines.
For something like a marketing site, the homepage is usually custom enough that you wouldn't repeat yourself much. Throw in an about us or contact page and you'll be fine. Much past that and I want partials for basics like the header and footer, and likely a few layout components.
Debugging a static site generator should be a thing in my opinion. When you gave to debug an SSG it's because the tool has to much magic built into it like automatic data pipelines, opinionated front-matter schemas, etc.
Right now the problem I have is that text that's been marked up as HTML suddenly then becomes harder to wrangle around than it was to put it into HTML in the first place.
I want an editor where I can "select all <p>" or "search and replace all <h2> tag names with <h1> tag names while leaving attributes intact" and other ways of reasoning about HTML as HTML in my editor.
The only drawback is that I can't really help people when they ask me for an SSG recommendation since most people won't want to do the same. I recently suggested to someone that they use Jekyll (after I did a small amount of research) but reading these comments makes me worried that was a mistake lol
writing html by hand is easier if you post infrequently, you only post basic text content and you're the only contributor. if you're posting daily, or you're sharing photo galleries, or you're trying to manage contributions from multiple authors, or you have any styling more than the absolute most basic stylesheet, then you're going to last about a day before you start trying to automate things again.
And servers which do not have any backend. Even apache2 SSI isn't enabled by default.
A standard default templating system on static content hosters would help.
The benefit was making sure the links all worked and common page elements like the site navigation, header, and footer were all consistent.
Many folks in that era would use an IDE like HomeSite, FrontPage, and DreamWeaver... these would have template features that you would generate your site from. These tools were very much like using my script only slow and expensive.
I do get where the author is coming from though. There are some static site generators that pack more features and require more configuration than a space command centre. I don't get the appeal of those. The key is to keep it as simple as possible.
how many of the dependencies will still be maintained? will it still even build?
back in the day tools like jQuery were a godsend for ironing out the browser incompatibility but now standards are much better.
well supported tools like that were a great abstraction point to help simplify the codebase and provide consistent functionality in an ever changing landscape of web standards and browser compatibility.
today we have the opposite problem. we have a incomprehensible mess of middleware designed to help out in some way or another but when you add it all together you end up with a 10MB hello world with 3,000 npm dependencies.
recently I decided to write a PWA using only hand rolled HTML and JavaScript and it was a pleasure. the only dependency I had to add was Nosleep.js for safari. it was extremely satisfying compared to dealing with a more modern toolchain.
Related
The demise of the mildly dynamic website (2022)
The evolution of websites from hand-crafted HTML to PHP enabled dynamic web apps with simple deployment. PHP's decline led to static site generators replacing mildly dynamic sites, shifting to JavaScript for features like comments.
Curating my corner of the Internet with a freehand web editor
The article reflects on the decline of personal websites in favor of commercial platforms, advocating for unique web design. It discusses limitations of current tools and introduces Hotglue as a freehand web editor promoting creativity and individuality.
Exposition of Front End Build Systems
Frontend build systems are crucial in web development, involving transpilation, bundling, and minification steps. Tools like Babel and Webpack optimize code for performance and developer experience. Various bundlers like Webpack, Rollup, Parcel, esbuild, and Turbopack are compared for features and performance.
Surfing the (Human-Made) Internet
The internet's evolution prompts a return to its human side, advocating for personal sites, niche content, and self-hosted platforms. Strategies include exploring blogrolls, creating link directories, and using alternative search engines. Embrace decentralized social media and RSS feeds for enriched online experiences.
Microfeatures I love in blogs and personal websites
The article explores microfeatures for blogs and websites inspired by programming concepts. It highlights sidenotes, navigation tools, progress indicators, and interactive elements to improve user experience subtly. Examples demonstrate practical implementations.