*However HTML is not easy. I get it. Most of us here can write it with one hand tied behind our back. But the problem with html is that it gives me choices. Writing is hard enough that I have to use a minimalist text editor just to not be distracted.
When I write and think of a trivia fact, HTML tells me that I can nest it as a side comment in a separate div. In fact, I should use an <aside> tag and style it differently. It would be nice if it could hover on the side of the page without breaking the flow of the content. Ah mobile. I should have it render differently on mobile. Maybe it should be collapsed at first, but then the user can click to expand it...
I use markdown so I only have to think of titles and bulleted lists. If I have to add something complex, I'll turn to html, but it is not my default.
In the case of writing, I don't want to think about html.
Or I could use a static site generator and put it in the navbar file and run a command to have it inserted on every page.
The author of this blog has dealt with this issue by having no site navigation.
Well, don't, they're deprecated. But you could.
It's mind boggling that it doesn't exist. XML has it - I can resuse the same image with a tag, but not HTML??
Why can't we have the same logic of SSI implemented in the browser?
Probably the perfect being the enemy of the good again.
This experiment by Jake Archibald looks interesting in this area. https://github.com/jakearchibald/streaming-include
For a blog, you've probably a basic style sheet for this already and adding to this on the fly in order to express your ideas is a nice option.
https://www.w3.org/International/questions/qa-b-and-i-tags
And I think the history here is pretty hilarious.
- Classic html: <b> and <i> mean bold and italics.
- Then the semantic folks took over, deprecated these tags, and say you have to use <strong> and <em> instead.
- Now with HTML 5 the <b> and <i> are brought back, but they don't mean bold and italics. They have new semantic meanings that sound like hilariously over-engineered attempts to pretend that they have some higher purpose that fundamentally really just means bold and italics.
What I think the committees must have missed is that presentation and semantics are not separable; in many ways the presentation is the semantics. Bold text itself gives meaning to the boldness, inferred by readers and authors, based on how the boldness looks to them.
Paragraphs, lists, citations and tables are fairly manageable. Arguably, though, those things are exactly what Markdown excels at.
That said, once the templating/boilerplate stuff comes into play, the author is like half a step away from trying to recreate PHP, which originally stood for Personal Home Page. Like, he’s even using PHP for his RSS feed!
Like, I’m not opposed to these thought experiments in the slightest — but I can’t help at the irony that most of these “simple” website engines (not talking about this approach specifically) almost always lead us back to our earliest CMS implementations.
I’m in my 30s. I literally grew up on pure HTML. But as much as I abhor how bloated current CMSs are, I also shudder when I remember how hard it was to create and manage HTML (and later, HTML and CSS) files by hand to update/maintain anything but the most basic website.
I didn’t suggest that; I suggested something like the following:
cp -r "$1" "$2"
sed -i '...' "$2/index.html" # remove old text
Of course, if I want an RRS feed, I need some dynamic generation. But I also think it stops there.
But I guess my broader point is that if I have to create a shell script to quickly generate the boilerplate file stuff for a new post/page, I’m _basically_ already doing what early PHP was designed to do. And at a certain point (and again, I’m not talking about you specifically, just the movements around this so-called simplicity more generally), we’re reinventing stuff that was literally created 25 years ago for these very reasons.
I’m hardly innocent of this either. As much as I hate them, I fantasize about and start working on a new CMS or SSG at least twice a year, only to inevitably abandon my efforts once boredom/frustration sets in.
Or static generation? (e.g. I rolled my own)
I probably first came across it at PHP 3, it was quite a step up from SSI for my frame based site.
BUT! I don't like to write formatted texts in HTML sources - too hard to consume it while writing.
Markdown (a.k.a. poor man WYSIWYG) is not that good either. Still palliative.
So I did html-notepad ( https://html-notepad.com ) - WYSIWYG editor. For myself and my wife primarily.
I am writing stuff for publishing in it and pasting to WordPress and other destinations.
WYSIWYG HTML editing cannot be used for web site creation/design. But for formatted texts, content islands in HTML, it is perfectly adequate.
Yet.
While 90% of formatted text editing tasks can be done in WYSIWYG, there are tasks that are more convenient to do in source form. I use source view in html-notepad with sync of caret position between source and WYSIWYG view - quite handy if you would ask me.
Sciter, "an embeddable HTML/CSS/scripting engine", looks especially interesting, I had never heard of it and am intrigued by its compactness. http://sciter.com/ , https://github.com/c-smile/sciter-sdk .
@c-smile / Andrew: are you (or other devs) still progressing on Sciter+Node? Previous discussion: https://news.ycombinator.com/item?id=18746408 / https://terrainformatica.com/2018/12/23/sciternode-versus-el...
Instead I am making efforts to add ES7 features to the Sciter's script. So there are arrow functions, destructuring assignment, Node's file functions, etc. now. More of those to come - Sciter uses same libuv library for asynchronous IO as Node so porting of all NodeJs runtime is just a matter of time (and practical need).
> I had never heard …
Well Sciter is 12 years old. Originally it was a "secret" UI engine of Norton Antivirus. Symantec uses it since Norton AV 2007 and other their apps, check this: https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o.... Use of CSS is quite convenient in UI of desktop applications. All these years they do not change UI drastically - just modernizing look-and-feel by CSS.
Since then pretty much all serious antiviruses are using the engine for their UI. My estimation (based on customers' survey) is that Sciter code runs on 500 mln PCs and Macs now . That, I think, is comparable with, for example, current FF installation base.
The app is still buggy in dusted corners though. Cleaning them time to time.
I deliberately remove all inline styles while pasting and loading: https://github.com/c-smile/sciter-sdk/blob/master/notepad/re...
Browsers and apps like MS Word put too much garbage in HTML/ clipboard.
I love his answer to this one. Just don't and you end up with blog posts that are like a time capsule. This is a benefit in my books and something that might actually shift the scale in favor of writing my blog in HTML next.
But I'd also want to have a list of posts somewhere, a link to posts about the same subject matter as this one, and working contact info everywhere. I'd still want some things to be generated. And maybe an option to have comments on some posts.
Also, like I assume everyone else does, I version my source documents and html using git. So I can see what it looks like at any point in time if I want to take a trip down memory lane.
But the whole static site generator thing is hilarious when you look at it, and classic developer territory. "I'm gonna install a gazillion tools to write some words on the web" - fine if you're learning stuff by doing it but for god's sake don't go suggesting it's "easy"...
Depending on the generator you chose, it might be a single binary rather than a gazillion of tools.
This is exactly what I’ve come to realize. Static site generators are not at all as simple, easy or intuitive as you might think.
I spend most of the time on writing, editing, then programming, and only then typing the text and doing the layout. The last 5% of that could be automated, but then I wouldn't be able to write things down from my phone while traveling, or directly from my CHIP when exploring ARM-related things.
Another way, seldom mentioned, is JavaScript. Just include some script tag, which inserts the HTML at the top, bottom, or wherever. An advantage it has over Server Side Includes is that it is cached.
And also, isn't a HTML IDE the equivalent of a static site generator except lacking any of the actual features that make generators appealing?
Obviously a blog at scale isn't going to do this, but I do think there's value in what the author is trying- where each post is styled and formatted independently with care instead of unceremoniously dumped in with a one-size-fits-all stylesheet.
I've redone this page several times because the plots for it evolved on other pages, and I re "copy-pasted" the code back then: https://wordsandbuttons.online/interactive_guide_to_homogene...
>>HTML is unpleasant to write.
>This is the only real reason.
This seems like a huge overstatement. His point about each page being a snapshot in time strikes me as a bug, not a feature, but to each his own. My biggest qualm besides this is that working without a template will make nontrivial isomorphic rendering and rehydration way more developer-time intensive, and I think we should be embracing this strategy for any behavior that can be implemented both with and without page reloads -- even if you don't like shwanky JavaScripts, subsequent page loads will be faster if you just have to update the necessary changes rather than the whole page. Finally, raw HTML isn't the cleanest format to write in. I don't want to be tied to a WYSIWYG, I'd rather be able to access my editor from anything with an ssh connection, and I don't want every text file I deal with to start with a bunch of repetitious boilerplate (headers and such). I'd rather write in a cleaner format for data and let the computer deal with fitting it into the template.
I don't think that HTML being unpleasant is a good reason not to write in it. If you're writing in something that compiles to HTML you should probably understand the model directly underneath you.
What are you talking about? This is static HTML and static CSS. There’s no isomorphic rendering ir rehydration. It already is “rehydrated”. And it will take significantly less time to download than for dozens of kilobytes of JS to do the same thing.
Step 1: client requests page.
Step 2: static HTML is delivered.
Step 3: static HTML begins rendering on client.
Step 4: client requests JavaScript attached to bottom of HTML document.
Step 5: JavaScript is delivered.
Step 6: JavaScript begins execution.
Step 7: JavaScript goes through the document replacing normal anchor links with elements that have click events which request only the content, and not the template, for subsequent pages[0].
Step 8: user clicks a "link."
Step 9: client requests content.
Step 10: content gets delivered.
Step 11: client updates part of the page and the URL bar, but doesn't cause a whole page refresh.
[0]Exception: you can give yourself hooks for a template change if you want, and even a significantly different layout on the same site will often have some common factors like footers and background.
I'm definitely going to look at Emmet, though. Thanks to all for mentioning it!
[1]:https://motherfuckingwebsite.com/ [2]:http://bettermotherfuckingwebsite.com/ [3]:https://thebestmotherfucking.website/
It is basically a text file in a basic font being rendered on the screen. You might as well use notepad instead.
What's the point of not using CSS to make it look at least half decent? What does this improve other than the elitist standpoint that websites should be no more than an unstyled text document because this is what it was 25 years ago?
I truly do not understand the constant pushback against things looking aesthetically pleasing on HN. Not everything has to look like a console terminal spit out some text.
I would be _really_ interested to see someone use modern web platform features like HTML imports, web components, JS modules, or something else to achieve the above features _at run time_ while enabling one to write in nearly pure HTML.
I had a similar thought though, and I think that custom components should still make it possible.
Browsers have native, built-in components like <select>, <select multiple>, <input type="button">, <input type="date">, etc. Styling and behavior of those is self-contained, with a public API.
The idea behind web components was to provide a built-in way to build your own self-contained components - something people have been doing for a long time with tons of <div> elements. But it's always been a challenge because doing that well requires adopting some consistent approach (usually through a library) that builds its own mechanisms. And there are many different libraries, and they all have different approaches. Wouldn't it be better to provide a standard mechanism for defining custom components and abstracting their styling/behavior?
Web components and other modern web tech could eliminate the need for libraries like React to build complex web apps with custom controls.
I still keep my personal blog written in plain HTML with a wee bit of CSS to give it personality. It just works so well!
Of course, working out how to make this convenient to use is going to be the tricky bit...
Maybe mine was more like a nanoblog...
But, uh, kinda feels like the author's "reasons" aren't balanced in terms of comparing "maintaining a website by writing HTML directly" to "maintaining a website by using a static-site generator".
e.g.:
"But how can I then keep the style and layout of all my posts and pages in sync?" Simple: don’t! It’s more fun that way. Look at this website: if you read any previous blog post, you’ll notice that they have a different stylesheet. This is because they were written at different times. As such, they’re like time capsules.
...But if someone wanted to maintain/update consistent styles across a website with only HTML files, then this would be a point in favour of a templating system over writing in HTML directly.
Finally, you constantly have to work around the limitations of your static site generator. Let's say you want your site to have a specific directory structure, where pages are sorted under various categories. With Jekyll, this is practically impossible, and even though you technically can get it working if you really try, it is only through much effort and with a source code that is organized much more unintuitively than if you just wrote it directly in HTML.
While it's fair to say that you have to learn the idiosyncracies of a SSG to use it, I'm not sure this is a fair criticism of Jekyll.
Seems that page output is determined by a 'permalink' key. https://jekyllrb.com/docs/permalinks/ (Found through a quick search for "jekyll structure").
As to writing practical web pages, I'm working on it, ;) The pages/blog you see on sgmljs.net are completely produced by SGML.
I respect this guy anyways. He wanted the simplicity and it's ok. I've see one of his posts has no CSS styling, and this is product of manual editing, you lose consistance.
The only caveats I see on this websites is, when they setup the width of the content. I love fluid pure HTML websites.
> The only caveats I see on this websites is, when they setup the width of the content. I love fluid pure HTML websites.
Hm, thanks, I might change that.
That should be pretty easy to program into a Makefile.
> Second, you have to extract the title from the content somehow
Or just "cat headerfront $PAGE/title headerback $PAGE/body footer > $PAGE.html".
Like yeah, there's some upfront complexity, but nowhere near the complexity of manually editing these things on each and every page. Once you have these programmed in and scripted out, you get 90% of the useful stuff a SSG does for you with 10% (at most) of the moving parts.
That was years ago when I did that. I won't do it again.
While I do not have issues with using some well-developed library, depending on whose library it is, we are more likely to only use it till we develop our own.
What I find really helps for writing HTML in HTML is to use sections, articles, headers, blockquotes and so forth to structure your writing. WYSIWYG editors never allow you to do this properly. They are 'what you see' rather than 'what you mean'. There is a difference.
Blocks of text should be like procedures in code, in a section, aside or other HTML sensible element and with a header at the top.
If you enforce this writing style it becomes much easier to have super-neat documents. It is just a pity you can't do this with WYSIWYG or some markdown thing. Really HTML is the ultimate.
HTML is still a bit burdened with presentation vs semantics, although CSS has obviously helped a great deal.
But I’ve never felt any need to take advantage of the Jekyll features. Pushing html of any sort to the gh-pages branch is trivially easy.
The way to frameworks or generators was caused because of the site look changing. Doesn't matter on which page you are, you have always a menu provided with lots of links. The "Back"-button is not seen today anymore. How I miss these days guys, this is why I love exploring neocities from time to time :).
I don't really like the menu idea though. I prefer plain content with just a bit of links in the footer, like this: https://wordsandbuttons.online/programmers_introduction_to_l...
If HTML had some kind of templating functionality so that you could trivially reuse, say, a header or a footer then lots more people would write HTML in HTML.
One of my friend just did her website all alone, and it's amazing: http://ivana.su - best page of the internet.
There isnt really a way to hack into a HTML only site. With a CMS however thats different.
You know what? This is _great_. I think the idea of each page having it's own self-contained snapshot of where the site was at when you read it is a great idea.
But I went a bit further, I do write HTML by hand in vim (plus some python scripts when applicable). Writing HTML is not that bad once you get used to it. My pages are not plain text anyway. They are mostly interactive things written in JavaScript. Since I spend considerable time coding, it doesn't bother me to spend five minutes putting tags here and there, too.
Coming up with the design decisions takes much more effort than typing in the actual tags.
And yes, I do have an RSS. It's also updated manually since it's again an effort too small to automate.
That said, I'm a man of convenience. Mixins are too much of a niceity to throw out so I wrote some small apache cgis to dynamically compile pug (aka jade) and stylus. I typically write directly on the server just using vim. Certainly not the work flow for everyone, but I quite like the experience.
[1] http://jjcm.org/blog/anatomy_of_a_surreal_photoshoot/ [2] http://jjcm.org/blog/how_to_play_pa/
I write in asciidoc and I find this trade off is well worth it. It means I can write more easily, I can future-proof my documents (if html versions/practices change, I just export them again) and I can output in multiple formats instead of just publishing to the web.
I don't understand what he means by "keeping track of two sources". I have one source: asciidoc documents. I output that into one format (today, typically) HTML. I have a script that just adds a header/footer to each one and sync to s3 bucket.
If asciidoc dies I can convert them to reStructuredText, Markdown, or whatever format is popular next. My mark-up is very simple, headers, bold/italic/underline, bulleted and unbulleted lists, etc. So my "source" documents are simple to convert between formats.
I find this gives me the best combination of ease-of-writing, flexibility and future-proofing.
The main abbreviation-expanding stuff is enabled in VS Code by default, and you don't need to read all to documentation to get started, just the basic few things.
Looking back now - MS Frontpage was way ahead of its time dealing with this abstraction of generating html - you saw the source change which the browser (unfortunatley just ie - but that's what we had) would render when you made an edit
Otherwise I adore the idea and I find it lovely! :)
[1] https://git.uberspace.net/homepage/tree/tools
https://web.archive.org/web/20011102031149/http://www.mighty...
It still has a pretty writing experience if you're going beyond just paragraphs and the occasional emphasis. Take inserting hyperlinks as an example, I've yet to see a UI that makes that easy enough, highlighting text and then invoking a pop up window is often a bit wasteful and harder to automate (e.g. inserting the current selection or the top-most browser's content). At least with a WYSIWYG editor the content won't be littered with a huge blob of computing ephemera, but having the URL hidden also means that you can't just grab it if you want to repeat the link.
Now the problem is that modern HTML authoring often isn't about regular text, but about creating some kind of hierarchical structure that serves as the content for some pretty involved navigation or data manipulation histrionics. Which means plenty of elements, plenty of nesting, with comparatively little content. And that runs into all the areas that made XML the horror that it is.
In a perfect application of "This is normal now", people are actually quite content with being in this burning room of tags and attributes, as long as the IDE helps creating this mess. JSX, Emmet, templates -- it really reminds me of the early days of Java, where everything was just solved by the IDE or code generation tools (getters/setters, DI etc.).
https://github.com/acdha/simple-cloud-site/blob/master/simpl...
I like the approach of using the same data values (schema.org microdata, meta headers, etc.) which other things use to keep you honest about that: e.g. https://chris.improbable.org/2014/8/25/adventures-in-unicode... extracts to http://microdata-extractor.improbable.org/extract/?url=https... without any need to be careful updating the system because if it didn't, the missing data would be immediately obvious.
Adding a new note to Dercuano just involves writing a new Markdown file in the markdown directory, so as with HTML, there's no threshold. Actually, there's less of a threshold: with HTML nowadays, I have to add stylesheet links, and meta tags so browsers don't interpret it as ISO-8859-1, and more meta tags so phones display the text at a readable size, and a <script> tag to add the table of contents... with Dercuano, I just start writing text. By default, the title is generated from the filename, or from the <h1> if the Markdown starts with one.
Why not just copy and paste? Well, aside from reducing the download size, sometimes I want to improve something for all the pages at once. Fonts, for example. There's always the risk that that will break some existing page, but I think the grain size where that's the dominant part of the tradeoff is somewhat larger than the million-word size of Dercuano.
I mention this not because I want you to use the Dercuano software (although you're welcome to and it's in the public domain so you're legally protected) but because I want you to know that writing your own is an easy weekend project.
I do have a static site generation step, though, which takes in my raw html, wraps it into posts, builds index pages, adds srcsets to images, and generates RSS feeds: https://github.com/jeffkaufman/webscripts/blob/master/makers...
There are bits that are pretty hacky, but being able to put anything directly into the html, just the way I want it, is much better than messing with various converters. Simple HTML is really fine to write in.
Or you could just spend 15 minutes trying to patch your existing site generator to suite your needs. This article sucks. Downvote.
Keep interface in another format/language is a good practice. HTML is just the compiled output (or implementation details), which we should not keep aware of.
