Hacker News Reader

Comment by nicbou | Hacker News Reader

I run a content website for a living. This year I switched from Craft CMS to my own static site generator.

I no longer think about the server or the CMS. I no longer need to keep it updated. I got rid of the heavy database and the elaborate caching setup. Now it's just a static file server. If it was just the blog it would be even easier to host. The website is more reliable and requires virtually no maintenance.

The best part for me is that I can work offline. It's just me and my text editor, so even my tiny Macbook 12" feels blazing fast.

Version control is also incredibly valuable. I can review my changes or roll them back. I can also find/replace across the entire content with regex. Text files are easy to work with.

I wrote about how it feels and why it works here: https://nicolasbouliane.com/projects/ursus

View on HN

Static makes so much sense for sole-author sites with technical owners.

Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach.

(Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your migration; it's great to see it's still useful.)

Products like [decap CMS](https://github.com/decaporg/decap-cms) try to bridge that gap, but I agree that this space needs to be further developed. In fact I think there needs to be a bunch more work to allow mere mortals to use version control and branch workflows in day to day work.

Tina does a good job of making branching workflows more accessible with its recent editorial workflow features (backed by a GitHub repo and PR reviews):

https://tina.io/blog/Introducing-Editorial-Workflow-Features...

We need more like this that doesn't require a SaaS-backed "business or enterprise plan", though.

> Static makes so much sense for sole-author sites with technical owners.

Totally agree for this narrow use case. But you're also correct that if you're a startup with a marketing site--going the Gatsby/Hugo/etc. route is a total disaster. Have seen so many technical founders make this mistake.

What happens is you realize, crap, my team needs to publish content for SEO and build new landing pages...and they aren't able to do my esoteric Git + Hand coding + Markdown/Front Matter + build process steps. So then you get sold some convoluted "HEADLESS CMS," which claims to solve your problems, but is actually a total freaking nightmare to setup and maintain (god forbid you ever want to change anything).

Have witnessed this charade more times than I can count. Seriously, just use Webflow. I know HN is highly disgusted by the idea of something being marketed as a "no-code" tool. But Webflow basically is a static site generator + headless CMS, just with a UI layer for non-technical folks. When you click publish on updates to a Webflow site you're basically automating the recompile and deploy steps.

99% of ppl pushing headless CMS are ppl who get paid for building *and more importantly, maintaining* headless CMS sites.

Yes, they have their place but it's far morw niche than the hype wants you to believe.

To offer the other side of this, at $dayjob we just got done getting out of Webflow and into hand-coded HTML. That stack comes with a number of severe headaches.

* The UI layer is complete and total garbage. It is unbelievably slow and clunky and it makes doing anything with it a chore.

* The UI is complicated enough that it would be easier to teach the non-technical folks to use markdown.

* Uncomfortable amounts of lock-in. You can export your entire site of course but retrieving your "CMS" records is not so straightforward.

* If you need to do anything interesting, the UI benefit is gone, because now you get to write code AND use their awful platform.

* Expensive, with a recent price hike with no increase in the functionality or quality.

The recompile and deploy steps can be automated in ways that don't require hitching yourself to this behemoth.

I agree and made that mistake myself... Framer is another good alternative to consider.

I’ve been down this path enough times that I built https://sitepress.cc/, which lets you embed content in a rails app with features that are present in Jekyll, Middleman, etc. like Frontmatter, site hierarchy traversal, etc. It keeps content as files in the app/content directory, but when it’s time to pull data in from the Rails app for SEO, it’s all right there in the Rails app. There’s no “Headless CMS” crap to jump through.

For me, this is another way of keeping everything in a monolith, and which requires a lot less context switching. If I’m building a feature and I want to create marketing or support content for it, it’s all right there in the same repo. I just create the markdown files I need, commit them to the repo, and I’m don.

The thought of switching between a static content site or something like Webflow just seems silly for a small team or project.

They need Cloud Cannon!

I’ve been running a news site with Hugo for the last four years. You setup a CMS that lets the non-technical people make content changes without you. For design changes, you always are going to need someone who knows how to code, so it’s not a big deal to use Hugo.

Of all the problems we’ve had running a website, Hugo has not been one of them.

Webflow has some huge constraints when you’re trying to actually build a good marketing page. Try framer instead, the fact that you can rely on React for anything that’s not possible to do in the visual editor is a life saver and actually enables you to build sites that are on-par with traditional headless CMS plus meta framework stacks while still being just as easy (if not easier) to maintain by non-technical users. The only problem is the price-tag which means you’ll be outpriced for small personal projects but it’s still a good deal for startups and bigger companies.

I'm surprised you'd say Webflow has the constraints vs. Framer. Framer definitely seems promising but is way too limited and basic at the moment. They don't even have an API, and the CMS just feels super sandboxed. Good luck doing any of the programmatic SEO stuff you can do with Webflow. I'm confident they'll get there in a few years though.

Or you can have a look at React Bricks, too. Devs create content blocks as React components with inline visual editing and sidebar props, with constraints so that the design system cannot be broken. Content editors can use these Lego bricks of content with freedom, without breaking the design.

I haven't used it, but Publii[0] might be along the lines of what you're thinking of. I ran across it in a previous HN discussion, and it seems to be static site generator with a pretty user-friendly graphical interface.

[0]: https://getpublii.com/

I've been thrilled with Publii. So happy to be rid of WP. I use it to run https://legendstudio.com/

There are a couple of companies/hosts - the names escape me, sorry - that do WordPress to static. That's at least fairly accessible to all/most.

> Would be great to make the tech more accessible to those without the skills to recompile and deploy

Originally, hand-writing HTML was a supposed-to-be-accessible-to-non-technical-users way to make a website.

Until the late 1990's, HTML was used sort of like Markdown is used today.

And people could not resist the urge to add styling and heterogeneous layouts all over. Weird typography, layouts, alignments and extra padding here and there.

A secret reason why I like to push markdown workflows is that you can't deviate from the site's overall look and feel. Focus on your content, hit publish and it will look good. Even if we change the site's look down the road, the content is still going to be fine.

I miss all that weird styling :(

It gave the internet character and flaws. Now it feels like everyone limits themselves to publishing nothing but perfect images of themselves.

<marquee> tag is awesome and noone can tell me otherwise.

Thanks for the warning, I won't try to tell you otherwise hahaha! Besides, if you like marquees who am I to say you're wrong!? I have exactly 0 design or taste bones in my body and think lime green text on a blue background is the pinnacle of human beauty.

I agree!

Hit Count: 3,404

Site creation tools that encourage freeform styling are great, especially if they make it easier than rolling your own HTML/CSS.

For example:

https://build.mmm.page/

And then there was Wikitext.

Wikipedia only recently perfected their Visual Editor in a way that made me feel comfortable using it, but it's still a situational decision whether I use VE or edit the source directly.

And at $dayjob I am accustomed to poring over raw MarkDown, due to lack of a viable WYSIWYG application.

I agree completely with this thought. So many people jump right to a wordpress because it can be "easy" (and as an EE, even figuring out the details of Hugo was pretty confusing for what basically amounts to an evening hobby). When I first started putting together my website [0] I considered the tradeoff between static and "dynamic", but constrained myself to the former because I didn't want to pay extra for hosting costs. The Fastmail file/website hosting has been absolutely incredible for this purpose.

All-in-all, doing a static site has allowed me to learn so much more about html and other basic web technology than I think I would have ever gotten from a Wordpress or similar site. The biggest downside thus far is that I wanted to start a sort of Wiki-style knowledge base for users to contribute in my particular niche, but of course the static aspect precludes any user editing. I use that area of my site as my own knowledge-base still, putting info there that I reference all the time at my day job. For fun the other night, I got sucked down the rabbit hole of adding Disqus comments too. I don't expect anyone to ever use them, but instead was just learning about how to do it.

[0] The site is at https://ShieldDigitalDesign.com if anyone is curious to see what a dumb EE can do with a Hugo-generated site hosted with Fastmail.

Hugo’s documentation site is poor. WordPress installation is a beast and involves getting PHP, Apache, and MySQL installed, which are each nontrivial. Hugo only seems more intimidating than WordPress because of the size of the documentation gap.

Yeah, I'd agree with that. Even when just setting up the Disqus comments the other day I found the docs lacking. This would probably be less of an issue making Hugo config changes was something I did more than a couple of times per year.

I was just thinking about how much trouble it would be to onboard an employee. Markdown is not rocket science, but getting the SSG to run? Committing files? Oh boy.

On the other hand, it's great for me, because I don't need to babysit a database or maintain hosted software. I can go on vacation and not worry about anything.

Adobe actually had a product like that about 20 years ago that the agency I worked with then used with their clients. Clients could just directly edit their content in a wysiwyg format, hit a publish button and it would upload. Can’t remember what it was called!

Perhaps it was Contribute? https://en.wikipedia.org/wiki/Adobe_Contribute

All About Berlin is a great little site - good work.

https://allaboutberlin.com/

Fast, complete in what it does, to the point.

[ IMHO <cough> it could use a section on TV Series and Movies set in Berlin past and present with a quick rating on how realisticly they portray actual Berlin ... but that's just me :-) ]

I have something about movies set in Berlin, but I dread updating it. It's out of scope for me.

This really should have been the case once we moved to SSD on server. For 95+% of all website, we likely have enough RAM to store 70% of the Hot Content in Cache and 30% of the content served from SSD at 10,000 IOPS Random Read.

Unless you constantly fiddle with the site design, the site and HTML generation should really be on devices and the whole thing should take less than a second to generate.

Unfortunately as other comments have said the current way of Github / Version Control / Text Editor are very much tech / Programmer focus. We need something like a hosted version of Wordpress, back to the old days of Dreamweaver / Frontpage.

Lektor CMS is sort of a prototype-ish thing doing this: https://www.getlektor.com/

It has (used to have? Can't find them on the site now) pre-packaged binaries that you would drop into a folder structure generated by the technically-minded person, and the content editor can simply click on that binary, which opens the backend of the CMS in the web browser, make changes and click deploy.

I suppose you could build this on top of Django as well, with django-distill, putting the distill-deploy step into the Django admin and then compiling that to a binary.

It's such a tragedy Intel completely dropped the ball on Optane drives. With them having an order of magnitude higher random IOPS, it would have been incredible for servers!

Samsung claims to deliver half a million IOPS on 980 NVMe drives. Is that not enough for you?

Previous generation 970 claims to deliver 50k IOPS

They claim that but it's not true. It will deliver significantly less than that in 4k random read.

I don't have the link to benchmarks at hand right now, but there was a review running CrystalDiskMark on these drives and the 4k random performance of the Optane drive was more than 10x the 980 pro. For servers delivering tons of small-ish files, that's exactly the use case.

Those numbers are quoted with high Queue Depth. So not always applicable depending on circumstances. But even in the worst case scenario of QD1 it is still plenty for 95%+ of sites.

> Now it's just a static file server. If it was just the blog it would be even easier to host. The website is more reliable and requires virtually no maintenance.

Same here, I'm using Sphinx and loving it !

I very much appreciate the ability to get all nitty gritty whenever I want to implement something "special" like the Favorite Git Aliases post which when edited gets turned into a .bash_aliases file and pushed to Gitlab and mirrored to GitHub! :D

For those curious it's over at https://jdsalaro.com , I don't have much details on my stack or why but I will be documenting bits here and there. I did start with my Markdown and Myst Cheatsheet for Sphinx (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) and how to load the environment.pickle (https://jdsalaro.com/howto/sphinx-load-environment-pickle/)

This is the fun part with simple text files. I built a linter for my content that runs like unit tests.

I love your idea. It's very clever!

This is very interesting. Impressive how much efficiency and performance is gained. This also means that fewer resources (electricity) are consumed, that less bulky hardware is used and, most importantly, that security is improved. A static website is more difficult to attack and the only possible flaw is in the web server and not in the code of the website. I usually use Hugo. It is very complete and rich in features. I have also created a multilingual website using it. Have you considered integrating Turbo Hotwired into your static website? You could have an improvement in the responsiveness of the navigation and a reduction in the load on both the server and the client side. If necessary, Turbo can also be integrated with Mercure for live page streaming.

> This also means that fewer resources (electricity) are consumed

Most servers in the world use a constant amount of electricity, regardless of load. Generally the way to make DCs more green is to build them around a renewable plan with batteries (that they already need). Save for the fact that the whole thing is made of rare earth metals and lead, and you've got yourself something pretty green.

> Most servers in the world use a constant amount of electricity, regardless of load.

That seems unlikely. Even if you disable frequency scaling, hlt uses less energy than a full pipeline of avx. Disks use more energy when reading or writing than idle (although for spinning disks, if they're not idle enough to spin down, the difference isn't that much)

Datacenters do tend to have a lot of batteries, but the runtime expectation is pretty small, 5ish minutes takes a lot of batteries and is enough for the onsite backup generator to start amd warm up. It's been a while; maybe those aren't lead acid anymore, but they used to be. Stationary, weight doesn't matter, volume isn't super important, cost is important, leads towards lead acid, IMHO.

I have a robot vacuum cleaner that runs linux, and it CAN run a Caddy server. I managed to get a website running on it last time. Now that my websites are static I'm tempted to host my personal blog on it.

I try to keep things simple. Simple websites are fast and reliable. Turbo seems to be a departure from that. Since the heaviest part of my pages is the text, it would not help much.

Please do this and write a blogpost about it!

In its simplest and most basic form, Turbo does it all for you. All you have to do is add the javascript files and when the user visits a page, Turbo will intercept the request, pass it to the server, retrieve the HTML response, extract the content of the body tag and surgically insert the content into the client browser. I'm using it on a couple of sites (including mine, a static one built with Hugo) and web applications and the difference in speed and responsiveness is remarkable. Of course you can go further. I'm now building a PWA using CodeIgniter and Turbo. The big advantage of this approach is that you can use "classic" technologies (HTML5 + backend) and achieve similar responsiveness to the modern Javascript frameworks, reusing all the existing backend code and logic.

I did the same thing for my site. Custom generator in a few lines of ruby. It’s so much easier and it loads so much faster.

https://www.networksfromscratch.com/

I read your Ursus page with high interest. Do you plan on sharing the source/scripts/github? Do you plan on monetizing it? Personally, it sounds like something that would be great to check out.

Same question here! Cheers from Pberg.

It's on https://github.com/nicbou/ursus. A slightly older version is on pypi. It's been running for a few months now, but only for two websites.

I love your Berlin site! It’s so clean, useful, and informative.

May I ask how the revenue works? I just like that it’s not polluted with ads.

Affiliate marketing. I am just bery careful about which products I mention and how. People need a bank account, health insurance, liability insurance, etc. I get a cut when I refer them to a business. I work with pretty much every business though, so I don't need to sell anything.

I did the same with my blog. It was custom written in PHP and was fairly stable, no reddit/hn hug ever killed it but I wrote a wrapper to make it static and now I can host it on a Raspberry Pi with nginx. Even thought about making it solar powered because of the low energy needed.

An edited site could also (mostly) be static if edits pushed / queued a job to publish the updated static content. Ideally a casual visitor would never see non-static content, other than possibly dynamic addins that mix the data client side if they have an active account.

CMV: if you're running code on the server anyway, there's no advantage to having all the precomputed header+content+footer combinations. You may as well run a script that combines the generic header + specific content + generic footer at request time. The advantage of static sites is that you don't have to worry about any server scripting at all.

You might be reading too much into the infrastructure. I was speaking generally.

E.G. The workflow might be updating a database on the local system and a set of affected pages published. Or it could be modifying comments within source code files and a Makefile like regeneration of document files that are then rsynced to a host elsewhere.

If there are user specific portions for some reason those would act more as a real application in sideband to the data, rather than a synchronous (and render blocking / load slowing) detraction from the experience.

One benefit is that python scripts are easier to run on a dev machine than nginx. These days I rarely run the whole website with docker, just the Python static file server with `ursus -s`. It made a huge difference on my slow machine. I could listen to music and work at the same time without bringing the machine to a crawl.

I found my way to this page on your site:

https://allaboutberlin.com/guides/movies-set-in-berlin

There's a typo in the TOC. … is being rendered literally I'm guessing because the ampersand is escaped accidentally.

Also a few you might add to the list: Berlin Alexanderplatz (1980), Possession (1981), Gotcha! (1985), Suspiria (2018), Undine (2020)

This is probably a remnant from the content migration. I have a few of those before. Thanks for the heads up!

And yes, that page is woefully outdated. It's also missing One Two Three, Babylon Berlin, Dark (kind of) and many more.

Wow, that website loads so fast.

It's very small, the CSS is inlined before the content, everything loads in a single request, and I use fonts and images sparsely. CloudFlare makes it fast everywhere.

I keep thinking one of the things we should look for in a nextgen version control system is a useful API.

Many apps need VCS, not a database, and CMS is one of the clearest.

but then formatting is awful in markdown, especially with all the template and tag syntax you add there which sometimes take more space than the actual words they mark up, and also due to all the tags you can't search/find/replace across the entire content, how do you find a "__bold__ in a phrase" or "bold in a __phrase__" reliably?

> how do you find a "__bold__ in a phrase" or "bold in a __phrase__" reliably?

Can't you use regex?

_[^_\n\r]+_

edit: I think double underscores are easier, you should be able to use __.+__ and there's no reason to have to avoid matching single_underscore words.

I meant searching for a "bold in a phrase" phrase when it can have various markup in arbitrary places (also, it's not just __, you might have some other valid marker) But anyway, you can't really use regex here as it's too complicated and error prone for such a frequently needed operation, you need a better mechanism line index or a built in functionality to ignore all markup

So look for **? This has been working well for me.

look where? it can be any other marker, and it can be nested, and it can be in any position, you can't craft a regex on the fly to capture that, your regex will be longer than the phrase.

I spend most of my time editing markdown, and this was never an issue.

On the other hand, now I can use any search and editing utility I want, not just whatever my CMS provides. A good example is adding a space after the § character, which I use a lot. It would take five seconds to fix it across the website.

A good text editor theme makes a big difference. I fine-tuned an existing Markdown theme for Sublime Text to better highlight the markup, especially headings.

> and this was never an issue

weird that broken search basics are not an issue, you extol the virtues of site search in your blog, that engine is capable of matching "shcfua" to "Schufa". Markdown, on the other hand, fails in search long before getting to fuzziness

> § character, which I use a lot. It would take five seconds to fix it across the website

True, and then forever to hunt down those few instances where § was used in a quote or something and should not have been fixed

> I fine-tuned an existing Markdown theme for Sublime Text to better highlight the markup, especially headings.

I "highlighted" most of text markup to make it invisible, a bold text is already visualy bold even in Sublime, why woud I need an extra __indicator__? And heading size is also the best highlighter, which plain text editors don't do

But yeah, I wish there were Sublime-level tool for rich text so you wouldn't have to compromize like that...

Search can be anything you want. It's just text. You are free to use the tools that work for you.

I see the diff in Sublime Merge before committing, so I'm far less likely to break something. I used to make so many errors because the WYSIWYG editor caught a random keypress.

Personally, I want those indicators to be there. I'm editing the text and the formatting. I want both to be on the screen.

Frankly I don't need to convince you that this is better. I work with this 40 hours a week and it's better for me. Feel free to take a different approach, but also accept that this approach is tested and true for me.

But it's not "just text", that's the whole point of "markup", and that's also the reason why the diffs would fail outside of simplistic changes. To search properly you'd need to strip that markup, so it can't be anything I want, which text editors offer that???

Also, formatting is there on the screen - in the form of formatting!

The markup is part of the text. Making text bold is a change to the text. It's part of the diff. The text without the markup has no value. I'm not sure I understand what you're getting at.

> The markup is part of the text

So do you change text font size in CSS separate from the content or within markdown since it's part of text and has no value when separated?

> It's part of the diff

it doesn't have to be part of the same diff. In your current workflow you can't separate it by design

> I'm not sure I understand what you're getting at.

It's pretty simple - content diffs are very valuable, markdown pollutes it

Did you name your SSG Ursus after the bear on Berlin’s flag?

What do you think would benefit other than content systems?

Reply on news.ycombinator.com