My stack is HTML+CSS
blog.steren.fr
blog.steren.fr
Frontend performance is basically an iceberg[1]. We tend to look at the top and that's where the fashionable "silver bullet" currently is (whether Rust+wasm or HTML+CSS or a JS framework). Then we find deeper in the iceberg that even a `box-shadow` property[2] can ruin our day, and let alone images, YouTube and Twitter embeds, and all the things that make the web more interesting and powerful than a black page with white text.
Oh and it gets even more fun! A Lighthouse score in itself is an over-simplification. There's more to a great experience than the initial impression the site makes, like what happens to FPS when you scroll or click around[2]
[1] https://rauchg.com/2020/next-for-vercel#realistic
[2] https://ishadeed.com/article/new-facebook-css#using-an-image...
It turned out that embedded YouTube videos were pulling down something like 1mb of JS, just to show the thumbnail, before the user even clicked Play.
I ended up making a static thumbnail with a hover-over "play" icon that would replace itself with the real embed when it was clicked. Got the Lighthouse score up and saved all those unnecessary downloads. But it was pretty amazing to me that while one arm of Google is pushing for web performance, another is building this YouTube player that auto-downloads a megabyte of JS just to show a thumbnail.
- No JavaScript necessary
- All profile images turned into one massive sprite
- Minimal payload size
Here are what the tweets look like when rendered: https://umaar.com/dev-tips/feedback
Here's the code to achieve that: https://github.com/umaar/better-twitter-embed
https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
(I'm doing this all the time, also with perfect Lighthouse scores. That is, there's often also a bit of PHP involved for includes and setting some meta tags, and a bit of non-essential JS sprinkled in.)
You can have responsive images with vanilla <img>[0]. You can even lazy load images with just `loading="lazy"` attribute[1]. I'm pretty sure I can optimize more things.
I'm mostly agree with this blog post. Plain HTML+CSS is really good for simple webpages, like landing page or portfolio that requires less update. But for a blog with pagination? I don't think so. Imagine updating each page in plain HTML. SSG can help my life easier.
[0] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
This is where frameworks can be really helpful, and I wouldn't dismiss them. It gets quite tedious to keep up with the new attributes, cross-browser and cross-platform differences, image optimization CDNs and so on :)
If "I'm gonna restrict myself to HTML and CSS only" gets them 80% of the way to their performance goals then IMHO, that's a perfectly valid approach.
As far as images go, the reality is that most mainstream sites with image/video content are heavy sites with multi-second page load times, despite literal millions of dollars being spent on engineer salaries. In that context, does it really matter if a random blog decides to just use pngcrush and a dumb img tag for the occasional eye candy imagery, instead of whatever is the state of art multi-resolution technology?
> For example, vanilla `<img>` will ship the same image to every device,
As it should be, for simplicity's sake.
Designers trying to assert pixel-perfect control of layout is part of why the web sucks so much today.
Let the browser handle layout, that is one of the things it is designed to do!
Sending a high resolution image to a user with a low pixel density display is wasting their bandwidth and battery. Sending a low resolution image to a user with a high pixel density display isn't giving them the good experience they paid for when they bought a high end device.
Optimization is about giving all the users the best experience you can on a website. It doesn't necessarily change the design at all.
If you do this, then a browser/user/client that wants that information simply doesn't have it - you can't create bits from thin air.
If you leave the metadata in, then any browser that wants it can use it, and any brower that doesn't want it can ignore it.
I can code up a Greasemonkey script in a few minutes that will strip the width and height attributes from img tags, but nobody on earth can write a script that will magically detect what size the author wants them to be if they don't send that data to you.
The width and height attributes we have been discussing set the size that the image will be displayed at, which are not necessarily the size of the image transferred.
Those are two very different things. My statement holds - if an image has size (a, b), but the author wants it to render at size (c, d) but does not send that data, the client has no way of magically determining c and d.
Furthermore, even when the actual image size is the same as the width and height attributes, there's the obvious problem of you needing to completely transfer the image itself before determining the size, which blocks rendering (or forces you to re-compute layout a second time, which both increases latency and decreases throughput).
I think writing raw HTML can work fine for small pages, and arguably it can be better than Markdown for pages with a lot of design elements, like landing pages. But for the typical blog post, or especially if the blog post has code snippets that you want to have syntax-highlighted, a static site generator is way easier to work with.
With the pace of change, I do worry a bit about the longevity of some of today's static site generators, but the Markdown itself is pretty darn portable.
And even with Pandoc extensions you cannot really have an image inside <figure> with <figcaption> and alt text and title text.
I've got some older posts that use Jekyll's {% highlight %} directive, and I know that won't work if/when I change SSGs, but to me that's a small price to pay for not having to author those in raw HTML! :)
I've been through similar pains myself, but not in the last five years: there's been plenty of tooling to strict-format all content prior to starting any conversion, and plenty of tooling to convert from one flavour of markdown to another (although, mind you, sometimes that means converting away from markdown first, then converting that back to your new flavour).
https://github.com/commonmark/cmark
There is an example where you load it via shared library in Python, i.e. send a Markdown string and get back an HTML string.
I'm OK with ambiguity between implementations, but this one is a deal-breaker for me, and I've not encountered a Markdown implementation which doesn't do it.
I think it's just a faulty idea to begin with.
examples:
emoticons
urls with certain common symbols
code
textart
that,s just off the top
He could have the same scores/performance and still get the full advantages you mentioned.
But yes, handcrafting html is pointless at some point, especially if you have to update the contents every so often
It's probably about 2-4 hours for an experienced developer to figure out how to setup and maintain a static site generator assuming no unexpected problems, then get familiar with the syntax and structure, so hopefully the labor savings from using a static site generator is worth that.
I don't see how you can call yourself "lazyjeff" when you've just written this, tbh.
There goes your super-lean stack and we're back to square-one.
Nothing against a lightweight stack, but simplicity doesn't necessarily have to exclude functionality.
And if all you need are dynamic headers and footers, just wrap those in 'php include' tags and rename the files to .php. It's still HTML and CSS that's getting rendered.
> So... if I don’t use any templating system, how do I update my header, footer or nav? Well, simply by using the ”Replace in files” feature of any good text editor. They don’t need frequent updates anyway. The benefits of using a templating system is not worth the cost of introducing the tooling it requires.
Other people use static site generation, you use search and replace in your editor - not much of difference. Your approach is slower in long term, but with your on average 1 article per year it will take some time until you reach the threshold.
Far too often I see people spend days to save 2 seconds (and then proceed to not realize the savings over a long enough timespan)
Sure, I could just copy/paste/replace content as it changes. But I don't want to have to be doing that any time I decide I want to change or add something. And I'm known to be a source of human error.
I ended up going Node+Express+EJS for the includes and certain more dynamic content on pages. It works well enough, page sizes are still small. Also considered some static site generators but at the time they seemed like overkill for what I wanted. Maybe there's a tool out there that will compile to plain old HTML files that I'm unaware of, I don't keep up much on front-end things.
It's actually fairly powerful and you can get quite a lot done with it.
It's not that hard even with.
My stack consists of HTML/CSS, and a small program to stitch headers and footers onto documents generated with markdown.
If anyone would like to see it, it should be in the Sourcehut page linked in my profile. The program is a hacky (but functional) piece of garbage however.
E: Spelling
These days you can do the same thing with about 5 lines of Python.
And the user's time doesn't?
If you can shave off a bit of loading/processing time for every request you will have improved the experience for countless people. Sure, using just HTML+CSS is a bit extreme, but for many sites the removal of some social media embeddings/trackers and switch to static site generation could improve it by an order of magnitude.
Is there anything worth discussing here? The entire thesis of the post is "my blog is maintenance free". Ok, and? Is blog maintenance really a noteworthy topic?
How many times can blogs rephrase "use the right tool for the job"?
Please, folks, don't encourage people to post low-effort noise by upvoting comments like this.
As someone who blogs regularly, I'm more interested in the toolchain of people who HAVE done significant writing. I read blogs for at least a decade before I wrote one, and it's harder than it seems, and coercing a good result out of tools isn't easy.
In fact I just wrote a few of my own tools to fix the image problem, e.g. http://www.oilshell.org/blog/2021/01/blog-roadmap.html#unix-...
Basically, the author's strategy is not likely to last (though it's not impossible). My blog started out very minimal, but as you write, you bump into the need for more automation and tools. My site looks very simple and minimal, but there is a surprising amount underneath.
Funny comic: https://rakhim.org/honestly-undefined/19/
When I was writing those tools I often wondered if we should just go back to Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! I remember trying it briefly in the early 2000's. Although his blog also rotted due to CityDesk rotting! It's a hard problem.
That's an understatement. It's the kind of comment that should be in the grey. Comments that amount to pile-ons and smug dismissals—like the one above—are far more welcome here than they used to be.
> Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server!
Among the things that Microsoft first started pushing to GitHub around the time that they formed the .NET Foundation was Live Writer. <http://openlivewriter.com> Dave Winer's Frontier is open source, too, but has also rotted. Brent Simmons, the creator of NetNewsWire, set out within the last couple of years to recreate it as a modern Mac app, but dropped the project last summer.
> Although his blog also rotted due to CityDesk rotting! It's a hard problem.
I'm convinced that we've missed the obvious and have been doing it all wrong, due to predilection for certain systems and ways of working. If you have a personal homepage, you should have among the stuff hosted there a document that describes how your site is updated. This document should be less of a blog post than an SOP. But now make sure it's specified with enough rigor that you can feed the same document into a machine that can perform those steps automatically. The reason the "WordPress setup from 2004" works and "old-ass blogger.com site" work is because they're closer to this ideal than Jekyll or Hugo or the others are. The caveat is that the hosted services make it really hard to actually look over the procedures that the machine will run, and if they let you, then you'd find that they were spread out over multiple "documents".
Whatever the case, the thing not to do is to have this sort of thing live out-of-band elsewhere as a tool that requires its own configuration and setup (with both the tool and the configuration being subject to rot) accompanied (if at all) by a terse README. (Otherwise, if you're keeping that sort of thing elsewhere, then your homepage is not really a true digital home, is it? It's a Potemkin palace, and the place where those other things live is your real home.)
I think a simpler way to solve it is with the now standard "infrastructure as code" pattern. For example, use Github Actions and similar platforms to build your blog.
Basically check in a spec for a container (Dockerfile) into VCS. It's done off of your machine, and it will "never" rot. You still have the cloud portability problem, and the "shell scripts and YAML are gross" problem. But those are solvable, especially for the relatively simple case of building a blog. I'm working on that:
https://news.ycombinator.com/item?id=25343716
[1] I think it's funny that VC's use non-startup platforms for their own blogs, because they know that blog platforms do not last.
This is an example of the "predilection for certain systems and ways of working" that I referred to.
> it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?)
That's not really what I meant. My reference to WordPress was probably more misleading than I intended.
I really mean it when I say a human-readable document that's more SOP than blog post—it's not a metaphor. Consider a static site generator for an existing site, and consider the steps it performs on the input to produce the output. Specify these steps as a single, written document—one that you can print out, even. If you're doing it right (in contrast to how we "have been doing it all wrong" up till now), then you should be able to ask yourself, "Is this document suitable for publishing a copy of it on my site itself (or printing it out and dropping at the bottom of a filing cabinet)?", and you should be able to answer "yes".
(This is where the reference to WordPress came from—it's not exactly a "single document", but it is a bunch of PHP files that you could conceivably stitch together and consider to be one and which you can take a peek at so long as you're self-hosting. But even then it's not something generally available as another piece of content on your site, because WordPress doesn't "reveal itself" as such, i.e. there's no associated HTTP resource by default that's associated with the underlying WordPress-in-PHP engine itself, so its likeness as an example is strained.)
That still doesn't solve hosting and portability, but it's a separate matter from the authoring tools (etc) experiencing rot. In practice, this can be covered by the inclusion of an annex to the above SOP (or a completely separate set of procedures) that describes how to get your generated files onto whatever host you're currently using. (In software terms, this section would describe an "adapter" and its use.) Static site pages are already pretty portable by their nature, and you don't really move around enough to worry about it, really, but if you do move, then just document the new process by speccing out a new adapter.
The takeaway is that if these processes are too elaborate to be documented in this way, then it won't work. But if that's the case, then they're already too complex, period—which rules out Docker and pretty much anything else that's "standard" in the devops world right now. I've prototyped something like this, and describing the whole thing that fits into a document weighing <500kB without even trying is pretty easy. My prototype is actually currently at 109kB, but that just covers the build SOP. Albeit, that is both man- and machine-readable (i.e. machine-executable), so it's detailed to a high degree of rigor. That's one long document that includes stuff like formally describing how the SHA-1 algorithm works, how Markdown gets processed, how templates and includes work, and so on. The adapter doesn't really exist, though; since it's a static site, it's just a note that says, essentially, "use rsync; here's the hostname and the exact command-line flags". In the document specifying how building the content from source works, I punt on specifying YAML, because a drastically simpler subset (i.e. colon-separated, key-value fields on separate lines) was able to accommodate 100% of how my frontmatter already looked.
I don't think relying on underspecced and inscrutable commercial systems like GitHub Actions is especially simple, resilient, or healthy. It seems to be subject to exactly the sort of rot mentioned before. Basically, what you said about VCs' blogs.
I'm a programmer so when I hear "document on how to update something" I hear "untested set of manual steps". I don't understand why it isn't a shell script instead ...
----
I actually don't want to preserve an authoring experience forever. I expect that my authoring experience will change [1].
What I want to preserve is the data. Both the source data and the generated data. I have one git repository for each. And everything else is basically Unix tools that I can compile myself.
Ask me in 4 years about this stuff, or 10 years: http://www.oilshell.org/site.html
I bet it's all going to work, basically due to the "Lindy Effect". I can build everything from source even if people don't maintain it.
I actually wouldn't rely on Docker itself, I meant more a "spec for a container", but Dockerfiles now have multiple implementations like OCI.
The point of the shell layer is to NOT rely directly on Github Actions APIs, even while using the service. It's indeed a problem that all these cloud services have weird SDKs and command line tools.
However when you look UNDERNEATH these cloud services, you get a KERNEL and a SHELL. That is the "timeless API" I'm writing to. I already did that with continuous builds, and it would be similarly easy to port my blog toolchain to the MULTIPLE clouds this way, so I don't rely on one. (It wouldn't be easy for all problems, but it's easy for building static content.)
I realize this is all outside the norm and 99% of writers aren't going to use this toolchain. But it goes very well with the Oil shell project. Unix and document authoring are very closely related. Historically the first use of Unix was to create patent documents at Bell Labs.
I don't quite understand what you are getting at so I think you must have a much different use case. If you have an example then that would help. It seems like you might be talking more about a blog that lots of people are editing?
----
[1] Actually it JUST did after 4 years and at least a hundred posts. I used vim for 4 years, and now I switched to the online editor StackEdit because it has realtime preview. I wrote the last 2 blog posts in StackEdit and it worked great.
However the data remained exactly the same. Unix is data-centric, not app-centric. Apps are the things that rot.
Why "untested" and why "manual"? I mentioned "detail" and "rigor" more than once and that it's possible to take it and feed it into a machine that will "perform those steps automatically".
I don't think kernel+shell are all that timeless of an interface to write to. They only barely pass for being portable in the here and now. (Oilshell's existence as a project is a testament to that. Its breadth and the depth of the pitfalls it has to avoid is another one.) Most of the time portability is an illusion that comes from most people around a given project being part of the same technological subculture, so they happen to use a common implementation. When you stray outside of that is when you run into breakage that no one is otherwise aware of. See also <https://pointersgonewild.com/2019/11/02/they-might-never-tel...>.
> I don't quite understand what you are getting at so I think you must have a much different use case [...] It seems like you might be talking more about a blog that lots of people are editing?
Nope, the use cases we're talking about are the same. I don't know where the lots of people editing parts comes in.
What I'm talking about is conceptually very simple (maybe too simple, leading to an assumption that there's a lot more to it). It's a document that describes in detail, just like any other tech spec, precisely how to process a given input and turn it into a directory of static resources that you are used to dealing with, i.e., the output of a static site generator. The only difference between it and other specs is that in this document you specify things with enough rigor that you can effectively "execute" the specification itself. I've heard Rob Pike say in a few talks that some of the Golang backends come from a tool Ken wrote where they can feed in PDF manuals from microprocessor vendors and get a working Go assembler out of them, but I'm not intimately familiar with that tool. See also <http://www.moserware.com/2008/04/towards-moores-law-software...> where some RFC-style diagrams constitute a part of the implementation of a working TCP/IP stack.
> If you have an example then that would help.
I might do a short (? I'd hope) screencast next weekend if you're interested in providing some feedback. Asynchronously and pre-recorded, not live. My first assumption is that when you see what this is all about, then you're going to be pissed off. Based on your description of your current setup, though, that impression may not be accurate.
> Apps are the things that rot.
This is where my comments about "predilection for certain systems and ways of working" and how "we've missed the obvious and have been doing it all wrong" come from. In trying to solve these problems, there's way too much emphasis on apps, CI configurations, or whatever mindtrap is ensnaring people at the moment. The "obvious" approach I refer to is first adopting a mindset where it's an imperative to include a functional specification as described. I.e., add it to the set of things that you intend to publish on your site. Once you do this, it's hard not to notice that there's now an overlap between your data and the "app" you're using to publish it. So the second thing to do is to eliminate the part that's most susceptible to rot.
Hm if you have a concrete demo then sure I would watch it and give some feedback. (e-mail in profile) It sounds like literate programming for a shell script to me :)
The kernel + shell is the best we have, since there are multiple implementations going back years. For example FreeBSD and Linux are totally separate projects and codebases, and implement a very very large common subset (POSIX, which has absolutely everything you need for text processing and document authoring).
For example, I just tried out NearlyFreeSpeech, a very inexpensive pay-as-you-go hosting service, and I found it runs FreeBSD. If I really wanted to make my blog portable and timeless, I would port it to NearlyFreeSpeech, which I estimate would probably be one day of work (really, I only use the Python stdlib, etc.). But I'm comfortable enough that Linux is going to survive until in some form or another until I'm dead ... or if it doesn't, there will be some migration path for the bazillions of other users.
The point is multiple implementations: Unix has multiple implementations, CommonMark has multiple implementations, and so does HTML/HTTP. Those things aren't going away.
The reason that Spolsky's blog rotted is because he built it in a custom tool (which he wrote), which was built on VB6, which was built by a company which changed its strategy ... etc. The stack was too high, and too proprietary.
He switched to WordPress, but I'd argue that stack is too high too, even though it's more open source.
So I'm happy with my solution but sure I would look at different ones. But my feedback might be that it should be "tested" in the real world. Just like the HTML+CSS solution is NOT tested because the OP didn't actually write many blog posts with this toolchain!
This is the best of both worlds. You get an excellent dev experience with TypeScript, fast refresh, the world of React components (granted many don't work when reduced to being static HTML), and I can also opt back into React on a page by page basis if I have the need.
With Next's static site generation and export, the output is just HTML and CSS (and optionally JavaScript), no need for a server.
If anyone is curious, my personal site was done this way: https://mattgreer.dev
The MDX files are here: https://github.com/city41/mattgreer.dev/tree/main/pages/arti...
And I just now wrote a new post about how I did the static HTML: https://mattgreer.dev/articles/how-i-built-this-static-site-...
e.g. (with hypothetical <extends> and <block> tags)
template.html
<!doctype html>
<html>
<h1>My Fancy Blog</h1>
<block main/>
</html>
<extends "template.html">
<block main>
<body>
Hello world
</body>
</block>
XHTML does, it's XSLT.
For example:
<?xml version='1.0' encoding='ASCII'?>
<?xml-stylesheet type="text/xsl" href="stylesheet.xsl"?>
<root>
<title>Page Title</title>
<block name="main">
<article xmlns="http://www.w3.org/1999/xhtml">
<p>Hello world</p>
</article>
</block>
</root>
<?xml version="1.0" encoding="ASCII"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/root">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">
<head>
<title><xsl:value-of select="title" /></title>
</head>
<body>
<h1>My Fancy Blog</h1>
<xsl:copy-of select="block[@name='main']/xhtml:article" />
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Anyhow, if there's one general purpose tool that predates the web and will probably be around when it's replaced by some other content publishing standard, it's Emacs. You could do a lot with a minimal SSG in Emacs and Org Mode, and it would be forward compatible with whatever is in the future, as well as backward compatible to whatever you like.
Maybe not. There's an argument to be made that says you should treat a blog as a series of pages, each modeling something corresponding to what you might call a "publication event" in the real world, e.g. printing a magazine or passing around a physical memo. The consistency angle is probably overvalued (not worth its cost). When a newspaper or magazine changes its masthead, old issues don't get updated. You might say that this reflects a limitation of the physical medium and that you would if you could (as is the case with digital editions), but what does it get you, really? Your links to external sources are already going to lead to wildly different forms of presentation outside your control.
If an internal link leads to a page published in 2014, and it still matches the way it looked in 2014, is that a problem? (And if so, e.g. due to changes in fashion/trends that have led to it being intolerable, it's worth asking, "what makes it so?", "was it ever really tolerable, even in 2014?", and "is the material I'm publishing right now guilty of the same thing—its presentation only squeaking over the threshold of acceptability because of something else that's currently en vogue but soon won't be?")
And, if you're just blogging, and you want to have the permanence you're talking about, you still need to ensure that all your links are properly linked, which requires some tooling.
Github pages is still software, running on a server
- Werner Herzog
Thing is, you don't need some jamstack hellhole of complexity if you're serving simple content pages. Need a common header, just do a find replace as he says or write a php include.
It's always been the same: choosing overcomplex solutions may be fun and groovy - and good to learn and interesting - and this may be enough of a reason to do it, but it's always worth asking what you're trying to achieve and whether the toolset fits. So often that doesn't happen, and almost always the simplest solution is the very best one.
If you're curious with what you can build with plain HTML+CSS, check out my side project[0]. It's a collection of free landing page templates in plain HTML+CSS (no JS). No frameworks, no preprocessors.
[0] Uisual: https://uisual.com
HTML is in no way the best tool for write content. But it is the best tool to serve content in a browser.
Why just HTML you ask? Well all the reasons that they provided plus the fact it's only HTML files.
This whole stack argument is silly, just let people use what ever they want to use. If someone wants to use a giant complex webpack setup, that's perfectly fine. Sure there is obvious downfalls and longer term maintenance can be a hassle, but it's what they enjoy.
If you want to use just HTML and CSS, go for it, but why are we bragging?
This works for your personal blog with a super minimalistic design. This is completely unfeasible for client projects, or at least it will break your neck in the long run. And chances are your abysmal lighthouse score on WP had more to do with a bloated, mashed together WP setup than with the technology itself.
Also, if you're really committed, you might be surprised how app-like you can make HTML+CSS, using things like checkbox and :target hacks[1]. The UI demoed in the video on this site[2] has no JS. These techniques pretty much require a generator, and there are obviously tradeoffs.
[0]: https://github.com/boringproxy/boringproxy.io/blob/master/ss...
[1]: https://www.mattzeunert.com/2017/10/30/javascript-free-todo-...
It took me about 25-30 minutes to publish my website with Hugo, from scratch. I can't even estimate how long will it take if i try to build something like the current one.
> Angular, React or Next.js to put a web page online. Raw HTML and CSS do the job.
If you see someone who uses Angular for a blog, go straight to the DEA and report him/her.
For a fair comparison, you'd use a premade pure HTML+CSS template or write a Hugo template from scratch.
Now include hardware into the same philosophy, the long term into shelf live, a single programming language worked on by dedicated knowledgeable individuals ideally. You are on our side of things.
A page (web/print) should be written, locally, off-line, in the same editor of always, in open-source code, preferably the blob of compiled code at it's nucleus, if there is any neeeded also. Content should have a seven hundred year lifeline, readable, view-able in minimal software allowances. Then it cannot be said too often, hardware-software is in-extricable.
For all those that think phishing in the public domain for the soul of the crowds, well, that is fine, but nothing the matter. And be prepared for a frustrated life-time of scratching your itches.
Theodore Kackzinski, people who vouch for the "hundred year", robust hardware, for the fashion of the ages, they seem to be on the right side of history. That same observation de-obfuscates the evidenced in what is going on in AI, and statistics, mining data. ...when the data are repeats, high-level, junk, outright meaningless, no amount of AI or tweaking using computer power will assert anything but junk outcomes.
People scale badly, that makes for the most efficient workflow to be a-synchronous, for nuggets of which as an individual we have as a rule none, and few individuals very little, that sort of data merits a long life-line, that data need to be tailored for the above allowances as you point rightfully out.
You might be fake, or limited in your ambitions, but from what I read, I must concede you make sense before any back-ground check is at order.
Markdown is a significant win, and CommonMark made it a lot better.
CommonMark is a Useful, High-Quality Project http://www.oilshell.org/blog/2018/02/14.html
Admittedly I need a Makefile, and Make is pretty impoverished for this use, and I want to replace it with something else. Shell isn't quite good enough because I don't want to rebuild the entire site on every edit, and I don't want to remember which files to rebuild. http://www.oilshell.org/site.html
If you are looking for Make replacement - I cannot sing enough praises for redo: https://github.com/apenwarr/redo
Is your build parallel? That's one of my main requirements. I'd be interested in seeing the redo files if they're public.
My website is probably a lot simpler than yours. All the "do" files are at the root level. But I have to state that there is no "redo" syntax really. You just take the scripts that do things and save them to files with a "do" extension.
But it feels more than a little like I'm essentially adopting a build system, since I have to run this manually each update. The idea was I wanted a stack which I could not touch for 10+ years, and nothing would go out of date and stop working. I don't think I have that safety for anything involving NPM...
- actual post
- teaser on the front page
- RSS feed
- search index
- title in multiple "tag" pages
- title in sitemap
- title in a paged list
etc. pp. Sure, you can maintain all that manually, but it's so much easier using an SSG like Hugo.
What I don't understand is how the linked page is downloading 1 MB of resources which unpack to nearly 2 MB. This page shouldn't need more than 100 KB.
<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "Article", "author": "Steren Giannini", "name": "My stack will outlive yours", "image": "https://blog.steren.fr/2020/my-stack-will-outlive-yours/ligh..." } </script>
is this something created programmatically? I'd like to create a blog but I don't want to have to type all all the necessary schema.org tags myself. Any ideas here?
edit: God, I can't even get this text to format properly. I'm such an idiot.
However, I've chosen to also use Jekyll. Github pages explicitly supports/couples with Jekyll [2], so I view the combination as a single dependency as opposed to an extra. For deployment, I push to a git branch and github builds and updates my site in the 10-60 second time frame.
[1] http://www.growthalytics.com/programming/2015/07/19/setting-...
[2] https://docs.github.com/en/free-pro-team@latest/github/worki...
Oh, but as he said earlier in the post, relying on a static site generator that you can install and run locally is unacceptable. That makes sense.
``` You don’t need Wordpress, or Hugo to put a blog online, or Angular, React or Next.js to put a web page online. Raw HTML and CSS do the job.
That being said, you’ll need to pick up some tooling or framework if you want to build a web app or add more interactivity or customization to your web pages. ```
So often people forget not everything sitting on the web has the same needs. saying 'you don't need a framework' ignores that, maybe i do infact need one, because otherwise i'd have to write it myself.
But I guess there could still be vulnerabilities in HTML that may need to be addressed? Like cross domain or cookie security...
But then again, same for a vanilla stack.
It definitely seems like maximum future-proofness should be more of a thing.
The only plugin that's relevant for that is WP Super Cache.
I don't know what the author did with his Wordpress, but even the awful Twenty Twenty theme with the broken fonts wouldn't give you a 19 score in Performance.
The only downside I have notice is that I can't easily put JS demos _within_ my rendered markdown, but I can work around it by stitching together multiple markdown files. Not pretty, but it works.
It was a University portal for teachers, students and admin staff that handled almost everything in the campus: grades, attendance, class schedule, downloads, renting books in the library, making room reservations, lunch vouchers for staff, a helpdesk system for students and staff, getting a free email account, etc.
The goal was to be simple enough for non-technical students and older teachers. Most things were one click away from the home page, which was just a bunch of colorful icons. You clicked one icon and could see schedule, grades and attendance. The teacher could edit grades and attendance of the whole class in a single screen.
There were no special requirements to drop JS. We just removed JS at some point and never added anything again.
Frankly it worked pretty well. The design was made by a professional rather than using off-the-shelf stuff.
What killed it was a migration to Bootstrap around 2015 after I left. For no reason. The layout ended up looking outdated compared to what we had, and the animations and javascript dropdowns were too heavy for the University's ageing computer fleet. The extra whitespace from default tables made everything too big to fit in a screen. Kind of a pity.
But by this point everyone was moving to phones anyway, so the university spent a couple million in an iOS/Android app.
The only thing I can think of that can be done in pure HTML+CSS that would drive any sort of revenue and could be considered a business is an affiliate marketing site. I suppose you could also run a survey site and collect feedback via mailto link, but that's really old school.
Comments are something I consider pretty vital to even a basic blog now. And so he's kind of missed the mark for me.
Version everything in your Gemfile, use rbenv, and and you're set.
<title>My stack will outlive yours</title>
<meta name="description" content="My stack will outlive yours">
<meta name="twitter:title" content="My stack will outlive yours">
<meta property="og:title" content="My stack will outlive yours">
"name": "My stack will outlive yours",
<h2>My stack will outlive yours</h2>Don't Repeat Yourself? I'm OK repeating myself if that can avoid me taking a dependency on fragile tooling
But all the other complexity that comes along with the web and web development don't exist just because of those use cases.
Nothing wrong here, although the litany of "look i'm just using html and css" gets to be a bit much sometimes and it sort of irks me to see yet another and another posted on HN and up voted with nothing new to say about it.
Is there a library that can give you HTML + CSS low kb site but those client site fast interactions (no page reloads)?
p.s.: hire me pls.
My light house scores are ~95, 100, 100, 100.
It can be done, you just have to be smart about how you do things.
Once you get into forms and submissions you can’t do no-js anymore.
> I didn’t need 99% of its features anyway
Oh, then it was already a terrible fit. So why are you advising people on how to replace Wordpress?
It's a blog, not a full blown app.
You know, HTML is rooted in SGML and digital humanism. The entire point of it is that you use it as a simple means for self-publishing of digital text (and HTML 5 "standards" portray it in that role, in case you've never had a look).
Granted, that isn't quite apparent when looking at the trainwreck that is HTML/CSS/JS. The solution (with SGML at least) is that you use your own custom markup vocabulary, including custom Wiki syntax for markdown and other short form syntax, and then convert that into result markup for delivery. The idea being that nothing can be as lasting for your specific purpose than your own text format.
But the self-proclaimed web heads didn't get it. They made CSS so absurdly powerful and "meta" to cater for the historic shortcomings of HTML, which is just a format for casual academic publishing locked in 1991. Not considering that you can, in fact, define your own elements and meta rules. Or at least, I don't have another explanation for the fact that everything around HTML has to change ad absurdum while HTML has to stay the same while it quite obviously isn't a good fit for the vast majority of content on the web. And that for some reason you absolutely have to send the same HTML to your mobile that you send to your desktop, and that CSS absolutely has to be the place to shift, re-layout and hide content for these different purposes.
The world prefers ad hoc rather than formal and verified. Worse-is-better strikes again.
Which is ironic now that we have garbage like GraphQL and TypeScript moving us back to formalism, but built on top of dynamic ad hoc structures. Guys... this... this is bloody fucking ridiculous. It's like trying to build a house out of wet tissue paper.
I've sometimes wondered whether pg's essays are done with just HTML and CSS — it kinda looks that way, [0] but I'm not expert enough to be able to tell.
This doesn't even touch upon the topic of good developer performance, which is just as important as a set of Lighthouse scores. It's far easier to jump into an app with established build tools and documentation than it is to wade through a block of static HTML. Though if you're the only one working in your zen garden, have at it.
No it doesn't. Are you sure something on your system isn't injecting JavaScript (browser extension?)