Hacker News Reader

Comment by arkitaip | Hacker News Reader

I love this because it's a reminder that simplicity is just around the corner if we only are open-minded to rediscover old truths. No complex server software, no package managers, no git, no SSG bullshit - just basic HTML and CSS.

View on HN

Unfortunately basic HTML has one glaring problem: it has no concept of code reuse. No layout, no shared footers, nothing like that. Frames were probably HTMLs answer to reusing common elements, but oops, frames are a disaster. Instead it was so bad there were actually Apache extensions to reuse HTML (see server side includes).

Then compound this problem with something like a blog where you have hundreds of pages who all need to have their menus updated every time you post something, and yeah...pure HTML is just unacceptable.

IMO the solution is to design around these constraints, ie, don’t include a menu on your blog posts, just a link to the home page, which has a list of all the posts.

And then you've completely destroyed the point of hypermedia.

What do you mean? You can still like to other documents, just drop the idea of linking to the same list of documents on every page

That works, but it's not what users want. Granted this is personal anecdata, but I've spent years pushing back on client expectations in the name of architecting things in a way the web supports at the lowest levels, and it's been an exercise in failure. No user is going to accept that behavior in a blog, and frankly as a reader on the internet, I find that solution pretty lame as well. I absolutely agree with minimizing the impedance mismatch between how we develop and how the web actually works and the associated tool-chain simplifications that come with that, but at some point we have to accept that web tech just wasn't designed to do what we need from it and add some layers on top. The challenge is balance.

I am not sure what is so radical about this. Let's take Medium as an example (pulled some random article from the front page):

https://medium.com/change-your-mind/the-simple-40-minute-mor...

What we have is, essentially, a blog post that could be written in pure HTML, and a link to the user's profile, which looks like this: https://ashley-richmond.medium.com/ This is one of the most popular blogging platforms and follows exactly the hub-and-spoke navigation model that I described.

Now, I do what to clarify, what I proposed is how I would build a website using plain HTML. I would certainly not go so far as to claim that it is the best way to build any website, SSG's have many advantages, but what I'm saying is that if one is going to write a plain HTML website, the easiest way is to accept the fundamental limitations of that approach, including a hub-and-spoke navigation vs a navbar. If you're writing a plain HTML site, you're probably a bit iconoclastic and willing to accept breaking some standard practices.

By that point though, you're dropping actual useful website features. What if I want a consistent style across my pages? What if I like restyling the whole website & I don't want to manually edit dozens of HTML files to do that? What if I think a header bar or a "recent posts" section would be nice?

I'm not saying it's bad to design a website in plain HTML, but it is critically limiting, and I wouldn't recommend it over a simple generator setup. If you're really opposed to using a fully-featured SSG, it'd be pretty simple to write a shell script that uses mustache(5) [1] to plug html articles into a template. That's almost as simple and clean as plain html, but it's a real step up when it comes to what it lets you do.

[1]: https://mustache.github.io/mustache.5.html

I want to clarify -- what I'm describing is how I would design a simple website using plain HTML. I have no opposition to SSG's, but just want to present an option for what it would look like if you eschew them completely.

The HTML vocabulary doesn't have and doesn't need these because SGML, on which HTML is based, has entities and many other constructs for templating. In fact, both SSI in default config and embedded PHP use a (simplistic) form of SGML extension syntax (markup comments and processing instructions, resp.) for equipping static HTML with dynamic features, though SGML has much more powerful ones.

So are you suggesting the solution is we should write SGML and then have that converted to HTML to fill the role of a static site generator?

I was merely commenting on why HTML itself doesn't have the features you mentioned. But yeah, authoring HTML in SGML is the most natural thing given HTML's origins. It doesn't have to run as a static site generator since SGML can run right in the browser and in the web server backend (see eg my project here [1]). Though using SGML as static site generator from the command line or Makefiles is also extremely useful, and maybe the most appealing for developers or when static site hosting is desired ([2]).

[1]: http://sgmljs.net

[2]: http://sgmljs.net/docs/producing-html-tutorial/producing-htm...

This is a whole avenue of exploration I had never even considered, thank you very much for responding with this.

Correct - though as designed that's a tooling problem, not a spec problem. Consider the pre-web world: You don't have reusable components in your printer, you manage stylesheets and templates in your word processor.

The original assumption from TBL was there would be much richer tooling to allow everyone to compose HTML without knowing tags, but for various reasons that's not the direction Andreesen et al took Netscape. And third-party tooling (like SiteMill) end up focusing on developers and evolved into things like DreamWeaver.

Hence the mess we're in today: the world's greatest publishing platform, and it's near-impossible for non-technical users to start publishing directly to it as conceived. Good news for Wordpress and CMS vendors, but a road sadly not taken in so many other aspects

I am not a developer. I am simply someone who is fascinated by creating software and websites. I remember taking a HTML/CSS class in high school 12+ years ago and it was one of the most fun classes i've ever taken. Didn't really know i could make a career out of it at the time, but i wish i did. With that said, i love visiting websites that are pure HTML/CSS. They are fast to load and easy to read.

We always forget we move away from simplicity - this won't scale and if you want to make a global structural change you're now performing the operation as many times as you have pages.

I find myself coming back to a metaphor that was in the comments here yesterday - yes, this is a beautiful, stylistic self portrait, but if your job is to paint the whole house this is a terrible way to do it.

In the context of this post, i.e. publishing a small personal blog, simplicity works well.

Is it simple though? Copy & paste into a WYSIWYG editor is pretty error prone, and he's already talking about creating several shell scripts to keep things in sync. Seems a bit like re-inventing the wheel, no?

Well, most developers hate simplicity and simply love automation. From some point on automation usually becomes a process that's merely shifting complexity from a manual process to maintaining a growing software stack.

I'd say for a simple web blog managing its entries by means of html files on the server is a valid solution. I am not sure how the author maintains an index of his blog entries this way, but updating an HTML index page manually does not seem like a huge effort to me.

People see all of the simplicity through rose tinted spectacles.

Copy and pasting bits of HTML around was a chore and was prone to error.

No decent source control (the source control at the time was garbage and tbh was a relatively new concept in web dev) meant that you had no idea what you had done previously or why. I remember have lots of zip files with dates and README.txt in there.

No package managers meant that I had to keep track manually of scripts and CSS in folders.

Nah I don't think I will be going back to that madness thanks.

Reply on news.ycombinator.com