> Wordpress is a mess that keeps on chugging through inertia
This is a weirdly reductionist position.
WordPress is an auto-updating, security-patched, open source CMS with a stable API, an advanced WYSIWYG editor and now layout tool, a reliable REST interface, good hosting support from stable vendors, a highly functional foundation and a profitable owner, etc.
It's really no messier than any other open source CMS (less messy than several), and it has better community and foundation support than almost any open source product I can think of.
It's fine not to like it, but let's not just casually write it off in a blog post about a static site generator that is limited in scope and a single third party behemoth hosting operation; that's disingenuous.
I agree that WordPress shouldn't be written off, but we have to consider its plugin architecture, and the ecosystem and culture whereby plugins and themes get installed and used.
WordPress core is kept up to date by a responsive team. However, while some WordPress users may be content with a vanilla installation, there are many who are not.
A traditional way to add functionality and style to a WordPress installation is to add plugins and themes. These plugins and themes are not sandboxed, and operate with full privileges.
Unfortunately, there are many plugins and themes which do not uphold the standards of core WordPress with regards to security. And the people who determine which plugins get added to a WordPress install are often non-technical users who are not in a position to evaluate the security implications.
The outcome is that while the WordPress core is hardened, typical WordPress installations which use themes and plugins are still a security shitshow.
The only way I can see to solve this architectural/ecosystem problem would be to somehow nerf plugins, or at least themes, analogous to how browsers discontinued support for the old-style fully-privileged browser extensions. For example, themes could be restricted to inert HTML and CSS. But considering how WordPress gets used, this would be so disruptive that I can't ever see it happening.
And therefore, static site generators like Hugo will continue to enjoy a huge comparative advantage over WordPress in terms of security, even if WordPress core has all the positive traits that you lay out.
> However, while some WordPress users may be content with a vanilla installation, there are many who are not.
Very true. But it is clear that WP's broad trajectory is towards GUI-configurable, block layout themes that do satisfy more users. They are doing more on this than any other CMS project.
> A traditional way to add functionality and style to a WordPress installation is to add plugins and themes. These plugins and themes are not sandboxed, and operate with full privileges.
This is true, as is the risk with third party plugins. (Though ultimately end users will just install some other bodgy CMS if they can't get what they want from plugins. The tradeoff with WP is that those plugins receive some scrutiny through vulnerability databases, better educated WP developers etc.)
Sandboxing themes is always going to be a little tricky, but it is plausible (and indeed it's not out of the question to project WP moving in that direction, given the way its internals are being reconsidered around the REST API).
But do you know of any widely-installable, user-friendly CMS that sandboxes its plugins? That is a huge undertaking. It's something I've thought of many times before, but I can't think of a way to make that practical on the sheer range of hosting options that WP makes possible.
Besides all that, WordPress is doing something that scales [1], unlike all of us techies using static site generators that only people like us can use. If we want the open web to succeed, we should be getting behind things like WordPress.
> Besides all that, WordPress is doing something that scales [1], unlike all of us techies using static site generators that only people like us can use. If we want the open web to succeed, we should be getting behind things like WordPress.
This is a great point - I built a website for a club I go to on Hugo and S3, and it is updated by users going to Forestry.io which then posts changes to Github, which then runs a Github Action which compiles it with Hugo and uploads to S3.
I thought users would be able to get their head around it... nope! I'm the only one that can make changes to the website.
It's still been worth it because of how cheap it is to run, and better for the environment than having a server idling to support our static site, but still a pain that I'm stuck being the one person that can update it.
yah, i'd like to know as well, since i was thinking of recommending the static site generator (but not hugo) + github + forestry.io route for a couple orgs.
* The ability to upload an image and resize it (i.e. someone takes a picture with their iPhone, then uploads it directly, and then cannot resize it within Forestry.io to make it sensible for the page).
* Inserting something like a table becomes an exercise in writing HTML or markdown rather than a GUI action.
* We had a requirement to embed some html in which eventbrite provides every time we have a new event (which gives a 'buy ticket' link embedded to the site for our events, but attributes in the html change for every new event we add to the website). You can embed html directly into the forestry.io editor, however it doesn't work when the html is sufficiently complex, so then they need to edit this particular page in GitHub to add the html in. (Note: using pre-built html blocks in forestry.io does not work for this as far as I can see, as the html changes for each new event). I think this happens when a file contains a combination of both markdown and HTML.
* When creating links, you have to find the relative URL path and then type this in, rather than just clicking on another page in a hierarchy as you would in Wordpress. I know this is a tiny thing - but again it makes users find it more difficult to move when they are used to Wordpress.
Despite these things listed, I do think that forestry.io is fantastic and similar CMS programs are the future - It's just that Wordpress has the edge at the moment. I have seen that the team at forestry.io seems to be building a new product at Tina.io and the forestry.io product does not seem to have changed much recently, so maybe this will start to fill some of the shortfalls.
thanks much for the detailed response. these are good issues to be on the look out for as we explore this route for the two small non-profits i'm thinking about. it's always so frustrating to run into significant usability issues after-the-fact for things meant to be used by less tech-savvy folks. the forestry.io combo still looks promising, so i'll dig into it more with those caveats in mind.
One thing that caused confusion for my person trying to use Forestry was that it "takes a long time" for "saving changes"
After each save, they thought something was wrong so would end up breaking/conflicting the process of git commits etc as they tried clicking different things because something was taking too long.
This was a couple of years ago so things may have changed by now.
> I use and am in favor of Wordpress. However, I’m also in favor of making static site generators easier to use for more people.
Amen, and I think this is the thread creator's point — WordPress doesn't have to "lose" for Hugo to "win", and it's pointless to pick a fight with a wildly different solution that solves a different set of use cases.
The thing that bugs me about more or less any article about why static sites are better/easier/simpler is that they all depend on writing off WP as sort of a straw man.
I have been playing with Publii again after being nudged towards it by a HN comment, and I think it might be a useful middle ground:
I think Wordpress does have some criticism-worthy parts, but criticizing a CMS from the context of a static site generator doesn't make sense. That's a much smaller problem space.
For us technical folk, Wordpress is a beast that needs to be slayed. For John, the non-technical, world-travelling coffee shop owner, that wants to maintain a simple blog describing his adventures, it's perfect.
(I say this as someone who used Wordpress and now uses Hugo)
Totally. There is a stigma against Wordpress for $reasons but compared to all the other platforms listed in this article WP is one of the most aligned with the open web.
WordPress has many problems with the way it's usually used that you don't get with static site generators though:
- WordPress can be auto-updating but when you update the core files, theme, and plugins, and want to upgrade PHP, there's lots of incompatibilities that can take your site down and cause other problems so it's not set and forget.
- Most sites also require a combo of plugins because core is missing essentials (e.g. page caching, SEO tags, contact forms, image optimisation), where each can give page speed, security, and maintenance issues.
- Dynamic PHP code is inherently less secure than static HTML files e.g. there's been remote code execution exploits via WordPress contact form and caching plugins in the past which isn't something you have to worry about with static sites.
- Versioning, deploys and updates via Git and CI/CD isn't standard practice with the WordPress community either. Plugins that update themselves and write files to the server is the norm which is another source of stability and security problems.
- Configuration being split across the filesystem and the database gets in the way of predictable staging/production deploys and QA.
- When writing PHP theme templates, there's minimal default escaping when you output fields so you have to be extra careful to not introduce exploits.
Static sites are fundamentally more secure, more performant and easier to test by default. There's bandaids to some of the above but you'll be fighting against WordPress standard practices all the time.
I'm still trying to find a good open source WYSIWYG page builder experience here that can compete with WordPress though. Using WordPress as a CMS and a static site generator to deploy it is an option though.
> Static sites are fundamentally more secure and more performant by default.
I'm afraid to say I consider "performant" to be a term almost without meaning, but especially here where you just mean "faster".
Any true comparison of performance would have to address the functional things that WP can do that a static generated site cannot do without third party services or serverless functions etc.
I mean page speed, like what Google Lighthouse gives you a rating for. Optimising WordPress for this is much more challenging than static pages in my experience.
What functionality are you thinking about here? I find most business websites don't need much beyond static HTML contact forms, nothing that would need serverless functions. A themed search page is a bit more challenging but you can embed Google Search or something like Algolia. Messaging widgets, analytics are usually JavaScript snippets, same with a lot of buy-button
functionality.
How does your contact form work without backend code?
For me the primary benefit of a contact form is obscuring its destination (or piping it into a CRM or ticket system).
Search is important. But other functionality includes things like content embargo/scheduled publication. Or multi-author systems, where not everyone who is writing the content should be doing any damn thing with CLI tools or Git or any such thing), and where there might be editorial approval before it is posted.
Analytics: again, this is something that I personally believe should be achieved in aggregate on the server side, not in JS trackers.
Most simple business brochure sites do not need much, but most simple business users like a control panel they can log in to.
I do not have _any_ customers I'd deploy a static site generator to. It's just not going to happen without an online frontend (or something like Publii, maybe).
I totally agree with you and would like to add another angle. I have a CS degree but have spent my career largely writing SQL. Given time I can figure out most technical things. Therein lies the issue, time!
I got taken by the HN hype over SSGs and moved my site from Drupal (I didn't want to move to Drupal 8) to Hugo. I spent a glorious three weeks porting my site and getting to grips with Hugo hosting my site on Gitlab. As is the case with me I then didn't touch my site for over four months and when I wanted to post a new post I had to learn a few things again. I have a work device and home PC. Posting meant I had to be at home because that's where my pipeline was setup. In the end I just moved to WordPress. I am not a web developer. There are probably smarter ways to setup and post to Hugo but given limited time at my disposal and limited functionality of my site, WordPress just easier for me.
Obviously there's a third party backend somewhere but better than using a WordPress plugin that might have an RCE security exploit or is open to spam at some point. Outsourcing stuff like this can be a good tradeoff.
> But other functionality includes things like content embargo/scheduled publication. Or multi-author systems, where not everyone who is writing the content should be doing any damn thing with CLI tools or Git or any such thing), and where there might be editorial approval before it is posted.
Customers wouldn't use Git directly or a CLI, they would use a headless CMS. I'm not sure which one covers all of the above but there's lots of headless CMS options here:
Aren’t contact forms easily integrated with tools like Netlify functions or AWS Lambdas (which I believe Netlify functions utilize unless they have their own thing now).. ?
But how many developers do you know outside of your own work team who know how to install an AWS Lambda function?
I've been developing a long time and I have Lambda functions in production but the entire process makes me want to bash my head against the wall to the point of unconsciousness.
The idea that we can write off wordpress as bad in one breath and then recommend a "static" site system which is a bunch of HTML pages with a set of specific third party hosting dependencies has always struck me as interesting. JAMstack is a manifesto for dependency on subscription microservice providers.
Sure, it almost makes you wonder when people go through all those hoops, why not just write up a bit of php just for the email/form or whatever minimal dynamic content you need..
Another way to look at it: why would you want to maintain and secure a PHP stack just to receive an email on a simple HTML page? Just use a simple HTML form service for this, upload your page to something like Netlify or GitHub Pages, and outsource the complexity.
I’m not the author of this and have yet to try it (but I’m going to soon), but it really looks cool and I’ve been looking for something like this for awhile.. I like the fact that because he has it hosted on Replit (believe he has CF in front), he can either edit md files within the Replit UI, or from edit mode within his webui. Neat stuff imo.
Unfortunately, there is no real page building functionality in Publii. There is not even the possibility to create pages. So it's not a real WordPress competitor in this regard.
> I'm still trying to find a good open source WYSIWYG page builder experience here that can compete with WordPress though.
I would be interested to see a static CMS that worked more this way -- Publii is interesting for this though.
> Using WordPress as a CMS and a static site generator to deploy it is an option though.
This definitely can be done, and you could use e.g. the Atlas content modeller plugin and GraphQL and then Gatsby/Gridsome. But it is more work in search of a reason to do it.
Wouldn't it be the same for any software? But Wordpress keeps up quite well, considering the amount of efforts that hackers put in finding bugs on it, given that it powers a big chunk of the web
(You did not deserve downvoting on this; it's a reasonable point. Not sure when the last zero-day was exploited in WP itself, but it definitely happens in plugins and themes.)
I usually find out there is an official patch when I get an email from a WP installation telling me it has already been installed.
Core WP copes with zero-day attacks better than most platforms. To the extent that they will even mitigate problems in widely-installed third party plugins and themes if they think it necessary.
Sure, there is a paradox with anything popular like this, that the people who are installing it are the people least likely to be able to deal with security patches. And that is an endless source of tension. But it is also why WP auto-patches, why plugin and theme auto-updates are now possible etc.
This garbage was normal in early-2000s web development but nowadays this problem has been solved - just look at any modern server-side MVC framework (whether PHP or others - PHP isn't to blame in here).
Maybe it's indeed "good" at handling zero-days in terms of raw numbers, but maybe it would be better to just not have as many zero-days in the first place?
wp-login.php is in need of attention, I think, and will get it through REST eventually.
But it's also entangled with the last bastion of one of WP's most underrated/underdiscussed features: pluggable authentication.
If you mean the appearance of the code: it's not to my taste! But it's actually really heavily governed by code standards (including the Yoda conditions stuff).
WP itself will never be an MVC system, but then MVC is really at odds with the hooks-filters-and-actions API approach WP uses, which again you don't have to like but is crucial to its success.
You can make tiny, targeted changes to the way a WP page renders -- with a single hook function -- that would be hard to replicate in MVC without vastly more effort. Magento tries to achieve this, and does it well, but at the cost of needing dependency injection, XML layout files, etc. etc.; it's enormously more complex.
I personally think MVC is the right thing for app development but wholly the wrong thing for the rendering front end of a CMS site, but I acknowledge this is a contentious opinion.
I think the lack of MVC and general "shaghetti-ness" of the code (why is form HTML rendering mixed in with business logic in the aforementioned file?) is a huge part of why WP has a terrible security track record.
> rendering front end of a CMS site
If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
MVC may be more difficult to grasp, yes - I went through that a decade ago when I moved from shitty PHP scripts similar to the code above (but hey I thought I was being smart by hashing passwords with SHA-512 instead of MD5!) to learning a proper framework like Laravel (and eventually moved off PHP altogether). However, I absolutely believe it's necessary otherwise you kill productivity, increase human errors and make code review much more difficult. If it raises the barrier to entry I'd say that's a good thing as it would prevent at least some terrible & vulnerable plugins from being made.
> If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
Right, but can you give me an example of a dynamic content management system that fully sandboxes its _plugins_? I can't think of one.
I tend towards telling people that adding a plugin or theme to their site is the same as adding its developer to their project. You have to decide where your risks are. But the flip side of this is that adding third party services to a static site generally involves significant GDPR exposure at this point. There is a choice to be made.
> MVC may be more difficult to grasp, yes
It's not that MVC is more difficult to grasp; I've been building PHP apps like that for 16 years (and before that Rails and Perl). I've never had any difficulty teaching it to other developers.
It's that MVC isn't actually appropriate for the generation of static CMS content at all. It ultimately locks you into a very specific pattern of layouts (with all sorts of ugly solutions to break out of the box).
It may not be a popular opinion but the hooks-and-actions approach to WP is a much, much more appropriate system for the generation of code for a content management system.
It gives you a "nudging the asteroid" approach to plugins, where hooking into one function at the right point in the page life cycle gets you what you want. That is more difficult with MVC -- you inevitably run into much greater design complexity. As I've said elsewhere, Magento has attempted this, and they have to offer several different methods (involving dependency injection, method rewriting etc.) that WordPress does not need, because its page rendering has a simpler functional flow.
I came here to ask why these instructions didn’t just use GitHub pages. Especially since it seems it is targeted toward a person that this is a stretch for, and GH pages would be easier.
So anyway, downtime is one reason I suppose. Are there others?
Another thing I remembered, was the support for newer Jekyll version and plugins. I had everything running locally and it failed on GitHub Pages without any error anywhere. It turned out to be that I need to step back few versions with Jekyll (and I think some Github approved plugins).
I’m fine with that but the lack of error why that is happening was hard for me to assume.
Last year, I moved my site[1] (a pretty heavy content with lots of text files from two decades), and I really like Hugo. It was fast and can compile my site quick enough. Jekyll still crawls but I was ready to live with it as I can just write in MarkDown and don’t worry about compiling every time. However, the downtime was the reason I stopped using GitHub Pages.
I use GitHub pages with no build step (GitHub handles that). I use my repos root folder for my page content, starting with index.md. I have a custom domain and just point the a record or cname at my GitHub address or IP. Works great for me and I haven’t noticed a lot of downtime, but I don’t really monitor either.
Edit: It is a little slow to build when you make changes. My changes take a minute or two to appear on the site.
I host my Hugo blogs on S3 at the moment because I wrote a deployment engine that targeted S3 initially. I refactored it recently so that it can deploy pages anywhere, so theoretically I could deploy to GH Pages or anywhere, but S3 works well enough for me.
I seem to recall from my experience that if you want to have a custom domain and subdomain, they can't both be on gh-pages but they can be on Cloudflare.
Don't really remember what the hurdle with gh-pages was though.
I LOVE the IDEA of GitHub pages -- keep the hosting with the source. Simplifies workflows and sync issues. But I find their SSL certs maddenning. They go from working to non working back to working and it is never clear what changed or what the problem is.
I also recently discovered that all our corporate machines show:
"MismatchCert (Hostname mismatch) Blocked by SSL_HOST_MISMATCH"
on the Github provided certificate. I can only wonder how many people have seen this and didnt visit my site because of it...
Does anyone have a recommended site/guide to setting up simple static sites without technical heroics? In the meantime, WordPress is a saviour.
I haven't used GitHub Pages. I use Netlify with Hugo and love it. Super easy, never had any SSL issues. I wrote a guide for this -- apologies if this is self-promotion, I can delete this post if necessary -- the link to my blog is in my bio. I don't think this guide requires "technical heroics", but it depends on your perspective, I guess.
A quick-build feature is in beta; with it, the build env init takes 1–2 seconds, and a Hugo build of a 200-or-so-page site is all done in less than a minute. Existing CFP users can ask to be put on the beta:
Dumb question, why build the site on the server? Shouldn’t the site generate on your laptop and then upload the static content to the server? It just seems to me that building on server adds a lot of complexity.
Cloudflare pages, right now, seems to be both the actual hosting, as well as a system for continuous deployment, bundled into one product. You push updates to GitHub, it runs your build (can be any arbitrary script) and then you tell it the folder that contains the built site at the end.
So you could totally build everyting locally and commit the site into a Git repo and use it in that way. It would be nice to have a non-GitHub way to just shove my built website into CF Pages but I don't know if that is on the roadmap.
True but you often want people to make updates that can only either edit markdown files or use some frontend that then calls the build process. (marketing people, copywriters etc).
When you're a hacker who knows how to install dependencies and don't have to use other machines sure.
That’s what we do, more or less: our build step is a no-op and we simply point Cloudflare Pages to the static site directory in the repo where everything is pre-rendered.
Cloudflare Pages is a continuous deployment wrapper on top of Cloudflare Workers. You can choose to use Workers instead, and the workflow will look more like "upload this folder as my site" (local command, no waiting for a cloud builder).
Pages is also missing some Workers features, like being able to see logs, Unbundled Workers for >50ms server-side processes, etc.
I think it is because the container it spins up is a bit heavy. When you select a framework, it just sets a build command. It seems as though every framework and tool is installed in that build container.
Hey, I’m on Cloudflare’s Developer Advocacy team — this is a top priority for the Pages team right now and big improvements to the build time are being actively worked on!
I made the same comment on Twitter and the pm for Workers said that they are aware and are actively working on it. So I am optimistic it will improve significantly over the coming months.
I agree... I run my static generator on my machine, then just publish pure HTML/CSS/JS (so there's no build step on Cloudflar) and it still takes 2 minutes to "build"... on GitHub Pages, the same setup deploys live within a few seconds of pushing my changes.
Last time I did some research on SSGs, I saw lots of complaints about Hugo, including this one by the creator of Zola:
> This tool and the template engine it is using were born from an intense dislike of the (insane) Golang template engine and therefore of Hugo that I was using before for 6+ sites.
Could anyone with experience with this and other solutions weigh in? There are so many of them my head spins when I think about it. I just want something that doesn't make me babysit it (as in, I can write as little code as possible to get a simple static webite) and has the usual things you'd want by default (e.g. image optimization) and is extensible if I do outgrow it and need to add dynamic components.
Each option lists which template language it uses, license and language it's written in... just pick the option that best suits your taste among the hundreds of options there... they're mostly all great, Hugo really is just one option in hundreds.
I didn't like Hugo template syntax at first but how complex is your logic really going to get? It generally doesn't get much more complex than "if this do that", "loop over each post", "do this for the last post only" etc.
There are many options because these are personal choices. Pick a SSG that has a template language you like and has decent documentation and maybe plugins. In addition, make sure the SSG is easy to install - for example, I migrated from Jekyll to Zola because the templating language is similar and Zola is a single binary while Jekyll is a Ruby gem with C dependencies (at least it was when I tried to install it last) and I had a rough time trying to install it. For what it's worth, I like Zola, but it might not be right for you :)
Zola is the best IMHO because it combines a single binary, expressive templates, runtime speed, and batteries included for images, sections, tags, search, links, microformats, and deployments. Zola also has excellent documentation, clarity of design, and a highly motivated leader in Vincent Prouillet. Rust lends itself very well to SSGs.
I'm wondering why Hugo wants you to install homebrew. It's a Go program. Shouldn't downloading a binary be all you need? Or maybe building it from source? The Go SDK doesn't require Homebrew.
You don't need Go, but it enables certain features like Hugo modules, which I find easier to use e.g. for themes than e.g. git submodules: https://gohugo.io/hugo-modules/
Hello, ox-hugo author here. Hugo has the best support of Org Mode as a markup. But Org mode is more than a markup. I ended up facing some limitations with the original Org mode parser used by Hugo and so I developed this exporter. Since then the Org parser used by Hugo got replaced by an even better exporter, but still the points mentioned here apply: https://ox-hugo.scripter.co/doc/why-ox-hugo/
The biggest ones are being able to organize all my posts as subtrees in a single Org file and leverage the Org mode's inbuilt"meta data" inheritance.
I have been thinking about having a blog for a while now but I can't really see what benefits it would give me? Seems like a lot of effort for something not terribly rewarding but maybe that is me being ill informed.
I've been writing blog posts for 10 years and I don't even write with the intention of anyone reading it, it's just nice to get my thoughts into words or document a project I've been working on (e.g. how to get some weird hardware to work, or what some weird error messages really mean). Having it be public is a motivator to make sure it's at least kind of coherent. Sometimes I get an email from someone who found one of my step by step guides useful, that gives me a warm fuzzy feeling which is the closest thing to a benefit I get.
I enjoy sharing posts because I enjoy the process of writing about something that inspires me. If I made progress on a personal project or learned something interesting, it is nice to take a step back and log it. I find that I can recall what I learned more if I wrote about it, and if I forgot, I have a place to look back on!
Publishing writing on a blog just makes this information public. I chose to do that since I benefit from the blogs of others, so I might as well make my learning and insights public, hopefully helping someone else too!
It's nice for stuff you might want to reference later:
1. Opinions you talk about regularly, that would benefit from a well-structured argument you can link people to instead of typing from scratch every time
2. That one StackOverflow post you need every 2 years but you keep losing it because the search keywords are weird
I usually get email like "We found you via github! If you are seeking for job, please apply today blah blah blah". Maybe these recruiters mention his website?
Like others have said, I write for my future self. I’ve been doing so for about 20 years. It’s extremely rewarding, for me, when someone emails me to say thank you. I’ve gotten emails from people saying I helped them lose 200 lbs (yes 200) or save $1000’s of dollars. That’s pretty rewarding.
For the curious, the person who lost weight was using a calorie tracker I built and wrote a blog post about. The person that saved money followed instructions on how to install old software on newer OS’s, saving them from buying a whole new embroidery machine (something I only did because my Mom needed help with her embroidery hobby).
It can be rewarding in a number of ways, most of which can be split into helping yourself and helping others.
To help myself, as another poster said, I record things I've learned, errors I have fixed, processes for e.g. setting up ssh securely or whatever.
To help others, most of the things that help me also help them. Every now and then I get a really weird error that no-one else seems to get and I have to solve it and then blog about it. Hopefully another 10,000 people don't have to go through the same pain.
At one point, I think I had about 200K viewson my blogspot blog but eventually I just came to hate the fact that they never seemed to update the site or fix any of the bugs on it so I went static and lost a tonne of SEO in the process but that will grow again!
I journal offline in a notebook. It's not "rewarding" in a monetary sense, but I still enjoy it and find it to enhance my life. A blog is similar in that it's like a journal except you can send it to people and get input in response.
There is a slightly different motivation when writing for the public. I have to take a bit more time to make things read well and clearly and this can help my general communication skills.
Engineers are often introverts and many can struggle communicating easily the ideas that they understand entirely but which are complicated. Blogging is a good way to challenge that and force you to abstract something well enough to explain it.
It’s critical if you’re an independent contractor or will become one some day. Writing blog posts about interesting projects or topics then submitting them to tech news aggregators (HN, lobste.rs, r/programming) pays dividends for years. Not even from the post itself necessarily, but it ensures you show up in search results. Much easier than writing a textbook, doing conf talks, or building a really good network. Plus it’s also nice on a psychological level, I feel I only get closure on projects once I write about them.
It gives some people good feeling when they can share good things with others. And some do it for self marketing. And some maybe for self esteem, like Instagram but tech stuff.
I had one that I published to every month for about ten years. I got some positive feedback, which was nice, but ultimately the effort of researching and coming up with what I considered quality content got to be more trouble than it was worth.
If you want a reward, then you’re right, it doesn’t make sense. Hobby sites are creative outlets, it’s about the enjoyment of making stuff just because you can.
Hugo is friggin' awesome for developers that want a high-quality blog. I've seen some incredible websites powered by Hugo that you'd never guess were powered by it.
I say "for developers" because you'll usually need to write at least some HTML and CSS overlays over the themes that Hugo makes available to do things like add analytics tags or custom footers. This is a slight hindrance for non-devs who just want to generate content. Medium or Substack work really well for this user persona.
(Git is not easy to teach outside of the big three commands --- clone, commit, push. I teach engineers how to use Git amongst other things, and it gets complicated (i.e. let's talk about trees and some other CS things) to explain once you scratch slightly beneath the surface, like "what does clone/commit actually do?")
OP mentions Medium which is pretty annoying but do know what irks me the most with them and many other premium platforms is that they seem to convert quotes to smart quotes when people upload articles making it impossible to copy-and-paste examples that people use.
I think Medium have even tried to stop people copying and pasting content without an account. That is so anti-internet. Most of the knowledge I have I got for free so the idea that somehow I should charge others for it instead of helping others to go much further than I ever could.
Medium is the worst blogging platform, I’m really sad that it took off. I’d rather people use wordpress.com and other alternatives that provide easy comments, rss feeds
Did it really take off? It’s obviously popular but it doesn’t seem like the business is a runaway success by any means. Just curious if someone knows (with facts) that it is actually a hit.
So with this setup, will Cloudflare intervene in the case of a DMCA request?
If I host my domain with Njal.la, and have Cloudflare setup as in this post, I should be safe from any frivolous take-down requests, right?
I'm a long time user of Cloudflare, however, when Cloudflare forwarded my personal information due to a DMCA take-down request (even though they refused to act on the actual request, forwarding my personal information was a shock); it opened my eyes to the fact that no one is immune from the bullshit that we call "DMCA".
I work with non-technical people who cannot install (or does not want to) or build anything on their regular machines.
The best option would be rather create posts in a browser or iPad.
Is there a way to set up a stand alone blog (which is not on “community-linked” content platforms like Medium) that DOES NOT require installing and compiling or even a personal laptop?
Consider using WordPress. There are many hosting providers who offer a managed WordPress option. They manage the installation, hosting and back-ups. The non-technical users simply sign-in to WordPress via their browser to write posts using a browser-based editor. Local installation on user machines is simply not required.
Static Site Generators (SSGs) like Hugo are supposedly 'simple' compared to the complexity of dynamic blog engines. However, the Hugo setup discussed in this thread is much too complicated and defies the meanings of simplicity or easy. SSGs lack comments and even a simple contact form is impossible without a third-party service or plug-in.
And I hope somebody else will get inspired by these as well! There are a lot of personal blogs still BTW.
And for those who plans to write. Creating a blog is easy. Maintaining it is the hard part. Irrespective of your experience and topics you want to share, just keeping the website and writing is hard. Do keep in mind so that you will prepare well for this. :)
This is a really cool article. I think more people should have a blog or some form of a personal website.
Here's a small but definetly incomplete list of free static site hosting with a custom domain:
- Cloudflare
- Netlify
- Heroku
- Github Pages
- Gitlab Pages
- Google Firebase (360 MB/day traffic, plenty enough for small sites)
This sounds like a fun project tho I'd likely self-host the git repo because I no longer have a personal github account and don't plan to reverse that decision in the foreseeable future
I've been using Cloudflare Pages almost exclusively. It's nice not having to worry about bandwidth limits. That being said, I would probably use Vercel a lot more if they weren't so strict about their hobby plan not being used for "commercial purposes" at all. While I understand they want to make money, seems silly not to offer some sorta leeway when you have so many other options that do.
I'll add why Cloudflare is cheaper: it's subsidised. The fee for their own operations is $0.00, they expect you to use their other services though, which is paid.
Go daddy is definitely scammy. I’m using NameCheap for the domain and hosting of my blog and quite happy with their service and customer support. I’ve also used PorkBun for domain names. Their prices are reasonable as well
No. I've had domains registered with them for years. They have great support via online chat that I have used a couple times. Also a customer of their email hosting and it has been solid.
> Your site isn’t innately tied to Cloudflare. If you want to move from Cloudflare in future (should they turn evil in some way, or you have another provider in mind), you need to facilitate the following: [...]
I liked this part. Honest, and shows it isn't a vendor lock-in.
Been doing a lot of internal documentation with Gilab pages, Sphinx, and Myst (markdown for Sphinx). There are pre-built templates for the Continuous Integration for rebuilding the pages.
Read article / most of it. Way too complicated for not much benefit I think.
Hugo can be used much more simply and I don't see why we have to use Cloudflare for simple blog. You know you can host it on Github if you want to, or anywhere else.
This is a great article and many of the steps can be generalized to other services. It's a good thing you don't need to click anywhere because that's the most annoying cursor ever!
Static site generators still feel like too much work for me. I am currently hosting a blog using Ghost and couldn't be happier. Fast and simple, almost no maintenance.
Their previous CEO killed elephants. This company supported SOPA. They literally use every trick they could come up with to fool people. It’s probably one of the least ethical domain registrars out there.
Just use namecheap, name.com, gandi.net(Amazon domains uses them I think),inwx or anything more ethical.
I appreciate the sentiment behind this but I don't think static site generators are the solution.
What a static website lacks is interaction with visitors.
Interaction with other people is the whole point of going on the internet.
Forums and comment sections on blogs is the reason we go on the internet. It's the reason people visit HN. If you couldn't write comments, would you visit the website? Maybe you would, but a lot less frequently. For example, I don't visit the lobsters website because I can't sign up for an account so I can't participate in discussions.
The problem is that setting up and maintaing a website in 2022 is quite cumbersome and tiring. No one wants to maintain a web server with the correct configuration of which versions of which applications are installed, where their configs files are, and what the contents of these configuration files are. Which is what you have to do with any of the existing solutions like Wordpress or Ghost or similar products.
A website should just be a program. A program you run and it manages itself. You shouldn't have to manage it. Programs are for automating things with computers.
In 2022, it's not difficult at all to write a program that does all of the following:
- Be an http(s) server (listen on the http and https ports and implement the http protocol)
- Manage its own data storage (database as library, not as a separate program that needs to be setup and configured separately).
- Manage the acquisition and updating of certificates for https (thanks to the ACME protocol and Let's Encrypt)
- Handle thousands of concurrent connections on cheap hardware (about $5/mo) without breaking a sweat
- Manage its own installation. For example, the user need only run a program on his own computer, give it the IP of the server he wants to host the website on, along with root username and password, and that program will do everything necessary to setup the website program and install it on the server. It should not take more than a few seconds (less than 10 seconds, and that's being very generous with time).
I'm not sure why no one is working on such a thing. It seems like a very low hanging fruit.
I suspect that people look at the current landscape and see that users prefer managed solutions like Substack over self-hosted solutions like Ghost, and they conclude that no one wants to self-host their own website.
I think they are wrong.
No one wants to self-host using any of the existing solutions because they all suck in that you have to sort of be a sysadmin in order to self host.
People think this is a fundamental properly of self-hosting and don't realize it's just a coincidence that all current solutions are like that but that things don't actually have to be that way.
For what it's worth, with many Hugo themes, it is possible to add a "Disqus" (or other provider) comment section to posts by simply adding a token to the static site's config file. See: https://gohugo.io/content-management/comments/
This is also possible with other static site generators like Hexo and Jekyll.
> Wordpress is a mess that keeps on chugging through inertia
This is a weirdly reductionist position.
WordPress is an auto-updating, security-patched, open source CMS with a stable API, an advanced WYSIWYG editor and now layout tool, a reliable REST interface, good hosting support from stable vendors, a highly functional foundation and a profitable owner, etc.
It's really no messier than any other open source CMS (less messy than several), and it has better community and foundation support than almost any open source product I can think of.
It's fine not to like it, but let's not just casually write it off in a blog post about a static site generator that is limited in scope and a single third party behemoth hosting operation; that's disingenuous.