I am a crusty old (I mean punch card old) 'programmer', with multitude of languages under my belt. [theoretical proof that I should be able to do a static site with my one good eye closed.]
I love the concept.
That said, I do have a bone to pick with the listed generators. They over complicate or fail to explain the site development and the documentation is often a twisted nightmare.
It is absolutely true, that if I could get the site generated as I want it, it would be less cost for the server, faster, and so on as described.
I really believe that static site generators are lagging in adoption, because unclear documentation.
The documentation problem is because they're trying to be everything for everyone imo. You end up with this bizarre labyrinth of conventions (and extension points) for which the only way to navigate is the documentation (and the documentation is unclear, so...)
I'm of the mind that if you want a static site generator, then... you should just build one yourself! Something completely tailored to you can be built in about the same time that it'd take to figure out how tf to get the features you want working with whatever static generator that's popular right now.
I was tired of having to learn how each SSG worked so I ended up writing my very-specific-for-my-needs one in an afternoon (and polishing in a few days more)[0]
Surprisingly, my SSG is starting to look like those SSG I didn't want to use. Is it the natural evolution or am I being biased after years of reading lots of SSG docs? :-)
One of the most annoying things about computers to me is that they require constant maintenance. I don't want to do maintenance anymore; I want a mechanic to do it for me. I have built my own bed, desk, shelves, serving trays, fixed my own cars, plumbing, electric, screens, hinges, walls, drawers, tended my own garden, and wrote my own software. The garden is the only thing I still enjoy maintaining. So I use a SSG. They fix bugs and add features and patch security holes and do releases, and I just download and run it.
Incidentally, I really would like some kind of free offline WYSIWYG html editor for the body of pages, if anyone has a suggestion? I've looked but all the simple ones seem to require JavaScript knowledge? I just want to make content :(
I previously used jekyll-admin, which gives you a web editor for your local Jekyll installation. I was happy with it:
https://github.com/jekyll/jekyll-admin
> I'm of the mind that if you want a static site generator, then... you should just build one yourself!
If you have any specific needs that you'd rather not compromise on then I agree completely, and do in fact have a plan to make my own. I expect it'll be quicker than trying to panel beat somebody else's into submission.
There is no middle ground - all the existing ones are either simple and/or strongly opinionated (great if you are happy with the fixed style and features) or so flexible and complex that it'll take to many plugins and hours poking it and it's documentation that you are practically programming the whole site anyway.
> Something completely tailored to you can be built in about the same time
And if you have any complex ideas you can develop it piecemeal instead of needing to think about everything in detail from the start to make sure the framework truly supports what you want (without you having to write a custom plugin) and you aren't starting in a way that'll make features difficult to add in later.
I don't really think that what I'm doing is making a static site generator, certainly not a generic one. I'm creating a dynamic but slowly changing site with a very strong caching layer.
> with whatever static generator that's popular right now
A key advantage of using an existing SSG is that you essentially get free upgrades from time-to-time, useful if the new features/options are actually useful or otherwise desirable to you. But that only works if the one you pick is one that survives the churn long term.
"Right now" is also key though. I might use one of the simple opinionated SSGs first with a view to getting some stuff out quickly and convert over later. Or I may just make a fully dynamic setup and convert to static if there is any chance the content is popular enough that the resource saving & response time benefits matter at all.
For programmers this is absolutely true. And because the SSG itself isn't exposed to arbitrary threats, there's not nearly the same need to have someone else do security maintenance on it.
Pick your favourite programming language, load some files, do string.replace(), job done.
I just feel that I often need some feature that is a bit time consuming to build. On the other hand the site generators I've tried had missed some feature or another also and they are usually harder to change.
I mean, we live in an age, where, if Medium says that something is >7min read, no one reads stuff, and everyone uses videos to give, and consume, information.
I wrote a fairly ambitious infrastructure system, and spent months writing detailed, accurate, relevant, documentation.
That no one ever read.
It wasn't until I transferred the system over to a new team, who started posting videos on Facebook, that it started to take off. It's now the de facto world standard. Documentation is important, but so is the medium.
I am a not that old (like pre-php old) programmer. For a personal website, crafting your own static website generator is so easy and fast that I would not even bother reading someone else's documentation.
I also did my own SSG, what it basically does is that it adds header.htm and footer.htm to each file in the folder... I first used server side includes (SSI), but often ended up having to edit all files because I needed to make a change in the SSI code. With the SSG I can just re-generate all files.
This is the way. All I wanted was to be able to write markdown and have it produce an aesthetic that I like. And syntax highlighting of code blocks. Pretty trivial to wire up.
On that page, I clicked on your name (http://dario.im/) for what I suppose was going to get me to a page generated by zas. You may want to take another look at it :-)
Gatsby generates a React app, and it embeds that in a set of pages, and renders the content to a set of JSON files as well. When a page is requested the pre-generated page downloads, using only HTML+CSS to display the content for that page. If the user has JS enabled the React app runs and attaches itself to the links in the page to take over how they work. When the user navigates to different page it downloads the content as JSON, and renders it as any other React app would. I think it can also preload content as well.
So in a sense you're correct, it does generate a React app, but it is also true that a Gatsby site works like any other SSG'ed website when you don't have JS enabled. Arguably it's the best of both worlds. It's classic progressive enhancement.
The downside is that it makes the code more complex.
My experience is that vanilla Gatsby, out of the box, performs horribly on things like PageSpeed compared to “true” SSGs like Hugo or Jekyll.
And progressive enhancement is kind of a solution looking for a problem, there are a lot of low hanging perf fruits you can pick before considering PE.
progressive enhancement is kind of a solution looking for a problem
Progressive enhancement is a solution to the problem of giving users the best experience possible without serving unnecessary code, or breaking the site, for users who don't have the capability to run particular features. It's not a perf thing. It's a features thing. And it's a very real problem (see every site that only works in Chrome for details.)
The ones I've tried or at least looked at had pretty good docs up to a limit. For simple things most of them had pretty good docs. For advanced features it was a hit-or-miss with the docs. It may say how to do the things I wanted or it may not. Or it said it in such a way it was hard for me to find the info. In some cases it might have been impossible without coding a plug-in myself but then it was a bit unclear if it was impossible or just no clearly documented.
I do see many static site generators as something that requires that you are a developer. At least you must understand html and templates (and folders and markdown) but often you end up doing things that are basically just programming.
On top of that, SSGs appear as magic to newcomers to webdev and many have a really hard time debugging a build error when things go wrong. I've seen it multiple times (especially with gatsby)
My ideal static site generator would have a locally run web app for editing files, styling content, etc. and then would just generate the static assets when you're ready to deploy. Not sure if anything like this exists currently or not.
Static sites are nice from a deployment perspective, but CMS's make a lot of things easier than static site generators do. Seems like there's room to have the best of both worlds.
Static sites are nice from a deployment perspective, but CMS's make a lot of things easier than static site generators do. Seems like there's room to have the best of both worlds
thank you, that was my experience too.
as a web developer, my primary concern is the users who provide content for a site (including myself).
i have only actively worked with hugo myself and i was disappointed by its complexity.
there are only a few situations where a static site generator is helpful.
one is a distributed team of teach-savy volunteers. here it means that i can submit occasional changes to a site as a patch.
however, the group of people that will benefit from this is limited. and the benefit does not come from the fact that the site is made with an SSG but that the content is stored in a text based revision control system. the friction in such a situation is access control and not deployment. one could easily imagine a dynamic site that pulls its contents from a text based source and still get the same benefits.
I created https://sitepress.cc/ because you can have both! It can run a dynamic content site from a Rails app or it can compile out pages that can be deployed to any static website host.
It doesn’t have a front end for authoring pages, styles, etc, but that could be built on top of this library.
After creating a site you start a local server by executing "lektor run" in the local folder, then preview the site in your webbrowser. There you get a edit-button whivh opens a backend with which you can edit the website. From that backend you can hit an upload button which allows you to push the static site directly to a remote (e.g. via scp).
A friend of mine used a WordPress plugin that did exactly that. He'd style and develop his WordPress website locally, then generate a static "snapshot" and deploy it. Of course it came with all the usual WP bloat and complications, but for my friend that's a feature, not a bug.
I believe the most popular implementation of this is Leon Stafford's WP2Static (open source). I've heard good things about it for years, but have never personally tried it.
On the surface it seems like a pretty roundabout way to work, but the static generation side of things works well. Not quickly (well, not Hugo-quickly).
Yes such things do exist. You can even have a traditional CMS like WordPress or Drupal, where content writers put content and have the build step of the static site generator pull the content down and include it.
Nobody should ever use Drupal in 2022 - it is horrible.
They tried to convert the base to the mainstream PHP framework called Symphony - but there is still too much "PHP Think" in the code, lessons of modern web development never learned, abyss of bad practices.
Also Symphony is more of a joke copy of frameworks from other languages, e.g. often security problems in auth code after many years of development, like the coders simply do not understand what they are doing - you should not rely on that as a base. People speaking of Symphony as a "quality framework" have not worked in different IT areas or with different languages most often - it is mainly a small group of french developers that depend on the popularity of Symphony and keep up a cult, but it is still a joke.
If you are a customer and somebody is offering you a product based on Drupal, save yourself some horror.
Good people simply have left the PHP world a long time ago and moved on to different languages and frameworks. What you get today as "PHP Developers" is the underdogs, the people, that can not get good jobs with better quality work experience missing, mostly people from the global south or eastern europe that have been misused for many years by companies that wanted to save a lot of money on "cheap coders" to sell bad products.
Wordpress is still no shining example of good PHP, but somehow the company Wordpress managed to establish a not too bad ecosystem, still miles ahead of what Drupal is - so if you are forced into PHP, Wordpress with near to zero plugins plus the great static export plugin will give you best results.
That concept reminds me if Joel Splosky's CityDesk[1] software which ran locally (desktop rather than web) and had a publish button to upload the results.
I quite liked it but development tailed off after a couple of years so I imagine it failed in the marketplace.
I think Publii[0] is the modern equivalent as it also runs on desktop and provides a blog-ish CMS with its own editor. I used it to make a small devlog[1] some time ago (on which i only wrote a single article, proving once and for all that the reason i do not blog more isn't because of the blog tech but because i'm too lazy to and i'd rather be writing endless posts in messageboards :-P). I do prefer the CityDesk style though[2], even if Publii is technically more powerful.
I used Publii for my blog, but it was very constraining in terms of its styling (the templates were mediocre). And I had made changes to its defaults for styling (which ended up not being responsive), so that when upgrades came around, it messed things up enough that I just stayed on prior versions. Now I'm stuck.
The whole template problem, along with customization (or is it configuration?) is the biggest blocker for me. I'm going back to a straightforward Markdown-like to HTML generator for my next blog revision.
Yeah, i wanted to make a simpler template like the one used in CityDesk or the one in the root site (that i haven't updated for ages however i already had made a custom template for consistency: the "Blog" part was generated by Pelican and the rest of the site with a custom generator) instead of the heavy one i ended up using (that IMO is the best -or least bad- among those available, at least according to my taste and needs :-P). But when i tried to figure out how to make a custom theme i just noped away.
Many CMS's have limitations in what they allow you to style. The needs kind of clash, the system wants simple templates that every page should follow but writers may want to be able to put some extra styling here and there. For full freedom you basically end up with a programming language. Otherwise the more advanced things gets really hard to do (iterate over each news-blurb and show it but paginate it to only 5 items per page).
Just allowing the user to add a few images to a page and have them show up nicely is pretty hard if you don't control the layout hard.
> Static sites are nice from a deployment perspective, but CMS's make a lot of things easier than static site generators do. Seems like there's room to have the best of both worlds.
A few years ago I wrote a static generator for Ghost. The workflow was the following:
- A Ghost instance runs on my raspberry pi
- I log into it to write content, and save
- A hook is triggered by the content update (this is a native Ghost feature), that sends an HTTP request to a local ExpressJS instance
- A script downloads the whole dynamic Ghost site as static files, fixes the links, and then publish them somewhere
It was _very_ brittle but it worked for my use case.
That looks like Publii. A no-frills SSG with a UI quite similar to WordPress that works completely off-line and generates static files to deploy anywhere.
Every static site generator can be used like that. You can run them all locally to build a directory of static HTML files that you can rysnc (or FTP, or git, or whatever) to a server.
How you generate the content is a separate question. It's quite common to use WordPress as a CMS (because the content people already know it), and then pull the content in to something like 11ty or Gatsby to bake to files and put on a server.
@jeffreyrogers I was about to suggest Lektor, but @atoav beat me to it. :-)
I currently use pelican since i'm ok drafting my stuff in markdown...but I used to use lektor alot...and every person - techie or non - that i've shown Lektor (back when i used it myself) loved lektor! Since that time i'm sure there are other SSGs that operate like lektor.
The best of both worlds already exist: take a CMS (like Wordpress) and generate static content from that. There are multiple Wordpress plugins that do that.
You have one Wordpress instance completely internal, safely hidden behind a VPN, get all the convenience of Wordpress, and each time you publish a change in an article it will publish the static site.
Yes, that's a nice solution. It's very easy to create a local instance of WP with the Local.app (localwp.com) and use the WP2Static plugin to generate a static version of it (or appi.sh, if you need to do that via terminal).
Many static site generators are so fast that you could use, say, the unix `watch` command to rebuild your website every two seconds while running an `http-server` locally to preview the results. And then just rsync the artifacts when ready to deploy.
I've been using Nikola which can publish Jupyter notebooks - which turns out to provide most of the functionality I actually want (previews, graphs, drag and drop image inclusion).
I love static site generators and I really wish more sites were built with them. There are likely millions of websites that have no login functionality or other functionality that specifically requires a back-end, but use a CMS anyway. Usually a CMS is slower for the users on the site, more expensive for the company running it, less secure, less stable, and more maintenance than a statically generated site.
I do think there's still plenty of room for improvement for static site generators though. Does anyone have any recommendations for an SSG with easy support for multi-lingual websites? Ideally, I'd be able to translate the text and provide alternative images, videos, and links without having to change the HTML structure of a given page for each language. Technically, this can be done easily with JavaScript by using a plugin like jQuery Localize [1], but that has two major downsides: (1) all other languages except the default breaks if JavaScript is disabled and (2) users won't know that the site supports their language from search engine results (the snippet will be in the default language.) So it'd be great if I could write the pseudo HTML of a page once, but generate multiple HTML files for each different language (placed into their respective directory, e.g. en/, es/, fr/ etc.)
Hugo has a multilingual mode[1] which I am using on two websites. It's a bit confusing at first but works pretty well for me.
For content, you basically put blogarticle.en.md and blogarticle.fr.md next to each other it will treat it as the same article in different languages. Per default it puts different language websites into different subdirectories (with a default language at root level) but it also supports multi hosts setups where you can define different domains for each language (e.g. blog.de and blog.fr).
There's support for generating "this article in other languages" type menus, which allows you to crosslink the website across languages.
There's also i18n support for translating stuff in templates etc., where you provide a dictionary file with translated versions of each string, and it'll replace them based on the language of the current article (useful for stuff like navigational menus etc.).
My portfolio website is 4-lingual and the initial setup was pretty confusing (a bit trial and error until I understood how it works). But now it works very conveniently.
Static site generators generally only require tiny amounts of scripts to get going and you just write markdown. You can use pre-made themes so no knowledge of HTML or CSS needed.
Business website providers use CMSes with databases in part because they support full on WYSIWYG editors in the browser, among other things.
> Static site generators are significantly faster than dynamic websites because they run expensive computations beforehand and compile static files. First, let’s dig deeper into the first point. If you run a website with dynamic software like WordPress, there are multiple steps to send your content to the user.
…
> These steps take valuable time, and if they take too long, the user could leave before the content loads.
…
> If you use one of the SSGs that use a JavaScript framework, you are likely sending unnecessary JavaScript to the client. However, partial hydration can solve this. To understand why, let’s first look at what hydration is. Most JavaScript frameworks run code on both the build step and the client. The build step creates the HTML. However, interactivity is still needed. To solve this, they use hydration. Hydration uses client-side JavaScript to make static HTML interactive. Sounds good, right? The problem is that frameworks often send code for parts of the HTML that are not interactive. Doing that slows down page loading without actually changing anything.
> The solution is partial hydration, which allows you to define what you want to hydrate.
So if you started out with performance as a key measure and moved to SSGs (despite the usage being more complex compared to a GUI based CMS), with the JavaScript framework based SSGs (not to be mixed up with simple JavaScript/Node based ones) that use/prefer client side rendering and hydration you now have poorer performance for a lot more complexity in designing the site and building it.
Somehow it feels like the JavaScript framework based SSGs are poorer on many fronts, and seem to give me the impression that they could appear slower to the end user browsing the content (I hate seeing empty placeholders with animations while they wait for the content to be rendered).
Just like how it’s easy to spot Electron based apps, it seems easy to spot JavaScript framework based sites too.
> Just like how it’s easy to spot Electron based apps, it seems easy to spot JavaScript framework based sites too.
It is, even on good connections and using new hardware, they'll load slightly slower than bare HTML pages. The latter will finish rendering before you're even aware that it loaded. I've run into many simple blogs that won't load at all without JavaScript.
It isn't just blogs either. I inherited a static site from a client that ran a real estate development business, and it wouldn't load without JavaScript. If you opened it on a phone or tablet you'd see a loading screen for 5+ seconds. The site just had some images and text.
That isn't a fair assessment. For example Next allows fully static content (no JS at all) all the way to fully dynamic content with a few steps in-between. It's up to the developer to decide which of these they use. This decision is made per page btw.
Hence my snippet “a lot more complexity in designing the site and building it” in the comment above. That developers need to take on the additional complexity of deciding what to do can be a burden (as compared to the ones that do everything at build time).
You can have the best of both worlds at the cost of additional setup / wiring.
Build or use a headless CMS for pure content management, have a preview build (client side rendered) of your site to see the changes instantly. Then trigger releases for optimized, static builds.
For me this is a quality improvement in terms of performance and security and a DX improvement in terms of extensibility and separation of concerns. But again, requires one to make a bunch of decisions and plumbing so everything plays nice and coherent.
It's just a choice the developer needs to make. It's a pretty straightforward choice too, if the page is just static content, make it static. The ones that do everything at build time don't let you build a site that can be interactive or dynamic when it needs to be unless you hack JavaScript into it. It's a lot simpler to just use a tool that supports both use cases.
"allows" as in "you can hack it to support that use case" [1].
Moreover, Nextjs's devs are increasingly ignoring that use case to the point where it is unclear if you'll hit a roadblock where you can't update anymore because the required amount of hacking is just too much to continue using it like that.
Rehydration feels „free“ because the site is rendered before that. So there more might be a danger of excusing „bunch of unnecessary stuff“ with it. I think one still has to be reasonably frugal with client side dependencies regardless.
The ones that build the site server side completely (including the ones that are JavaScript based, but not the ones that are JavaScript framework based that tend to move certain parts to the client).
Static Site Generators (SSG) are not new. The SSG blog software Moveable Type launched in 2001 (written in Perl) and preceded WordPress. It featured a friendly browser-based editing, and a publishing experience suitable for all users.
This article omits an important aspect of popular SSGs and the 'Jamstack': they are not easy-to-install or easy to use by non-technical users.
Some of the most popular SSGs are surprisingly complex despite claims to the contrary. (A simple contact form is impossible in many SSGs without embedding third-party services.)
Also, the love of Markdown is not shared by anyone who isn't a developer. Step outside of basic Markdown and it becomes unpleasant to use and cumbersome. It's even harder for non-technical users - try adding a table using Markdown.
Outside of developer circles, SSGs have had neglible impact on non-technical users.
I would also point out that by means of heavy caching Wordpress can solve all the performance issues indicated by the author as the main advantage of SSGs.
In my opinion opposing Wordpress and dynamic CMSs to SSGs is the wrong way to frame the topic. They have different applications, especially if you’re doing client work.
SSG's feel like the first step towards something. Unless the website has really simple structure it likely that you will get stuck i) with sub-optimal content management (e.g using an IDE) and ii) a complex mess of mixing code and content, poorly documented and incompatible themes (my experience is with hugo)
But those are not arguments to go back to using a database when it is clearly not needed, but rather to evolve tools, documentation, theme design principles etc to eliminate pain points
I have been using Hugo for a new blog I am starting, and I have to say that it would be a lot better if the CMS was something like notion. Using an IDE will definitely have some growing pains past 100 posts.
> Not everyone who writes knows how to program too.
Aren't static generators much harder to grok for nonprogrammers than wordpress?
This is a non-problem. The problem is not wordpress. The problem is that modern browser programming, and modern javascript in particular are way more complicated than they need to be for lay people to build their own websites as they did in the good old days. That's why everyone moves their communities in discord instead of building a self-hosted forum. We need to be talking about how to make the browser an accessible platform for everyone again (including moms and pops, remember Frontpage?). NOT to keep over-complicating even the smallest tasks and build frameworks that only benefit the BigCorps
I'm currently in the process of moving my simple blog away from Ghost (formally WordPress) into a static HTML site. I can write HTML with my eyes closed and it's barely more inconvenient than Markdown, only I don't need some parser in the middle to complicate things. The most painful part of this is rewriting my content and moving the images etc across but it's more mundane than anything. Only dynamic part of the site is some simple includes for the header and footer. This is the way I used to run my site back in 1998 and it's far less troublesome. No security updates to worry about, no plugins, just straight up content.
Static site generation definitely predates Jekyl. If anything I think Jekyl would be better flagged in the timeline as the beginning of a renaissance for static site generation. I can think of two eras when it was in vogue before that
To give an example, my team was doing this in the early 00's on some major brand websites to eek performance out of stacks originally built on either PHP or Perl with MySQL Cluster (as in NDB) as the backend.
We fired crawlers both on article creation and periodically overnight that browsed the dynamic site dumping out to a static "cache". Initially this was html chunks which was bolted together by Apache SSI includes. (eg header, footer, menu, content, and a wrapper). Later that evolved in to storing in Memcached with a simple Memcached implementation frontend wrapper to cache on demand.
If I wind my memory back even further to late 90s early 00s I remember pre-Web2 tools that would give you a local desktop based CMS and site generator that pumped out flat files and pushed over FTP. These were especially commonly used by graphic designers making the transition from print design to web for things like brochure sites.
Yes, I feel like Jekyll was the first to make static sites "cool". Maybe because of github that made it super easy to create a site based on Jekyll, without having to compile it locally then upload to FTP or whatever.
In the early days, it seemed like static sites were for programmers who didn't really understand the web, or only had hosting for static content.
Yeah definitely. I did some work with a really ancient Python SSG called rest2web that was around since ~2004ish, so several years before Jekyll even started
Love SSGs too! Came here to share praise for Hakyll[1], for people with an FP leaning.
Predictably, it's not easy to get started, but once you're into it the power of building your own arbitrary content "compilers" (and template extensions etc etc) is pretty impressive.
My experience with SSGs was a mixed bag. I like the concept, but integrating with a headless CMS requires too much coding and simple things like page preview is a pain to setup and use. The existing headless CMSs leave a lot to desire in terms of usability (although, Strapi is not bad).
Static site generation should be simpler. Currently it's over-engineered.
I've made a simple php solution with markdown and blade templating. Newest post with two images fully loads in 1.88 seconds in Germany without a CDN running on 5$ linode in Tokyo.
No build steps and I just write .md files in the git repo. Static Site Generators are nice, but using fewer parts is also an option.
What would you recommend for a GUI interface to authoring a site based on Hugo
I put together a Hugo site, where the site is automatically deployed to Render (similar to Heroku) whenever a commit is made to the GitLab repo.
While I am "ok" using Obsidian + WorkingCopy (iOS git client) on my phone to update the site - its clunky but works- is not acceptable to less-technical people.
I want the benefits of a site based on plaintext Markdown, but want something that approaches the ease of jamming out a doc on Google Docs, Notion etc, dropping images into the content, etc.
I now use Zola with esbuild + postcss + tailwind, and with the new JIT tailwind, I got cold (not counting npm install) build under 500ms for large sites.
I run multitail with one watcher running zola server and the other one running esbuild.
It is the first time since a long long time that I have a js/css build system that is not impossibly complicated to grasp. I do use a few postcss plugins, but all with default configuration (except tailwind). I did them all, grunt, gulp, bower, webpack... always a nightmare.
I would recommend poking around with 11ty,[0] which I find to be significantly simpler than Hugo.
The Go templating of Hugo is extremely confusing for most non-Go people. After using it for years I still constantly look up how to do simple conditionals.
11ty is a very competent, "good enough" generator. We used it to build this site[1] for CERN back in 2019 from scratch over the course of a few days.
Yes, Go templating is quite hard. There was a feature request[1] to implement the Django/Jinja2-like Pongo2 template engine[2], but got rejected because it would have been a too big change.
Templates are the ugliest part of Django. They are completely unaware of the target syntax, so very often the template itself cannot be validated as HTML, which makes it difficult to lint or reformat.
The only tool I'm aware of that can (mostly) correctly reformat Django templates is the PyCharm/IntelliJ family of IDEs, but their reformatting often introduces subtle breakage (such as adding new lines inside tag attributes) and requires careful review.
Thanks, and nice job on the build :) I came across 11ty today. Looked interesting. But, the moment I see code blocks my brain shuts down. I try to stick it out, but it's difficult. Trying tho!
You don’t need to code to get started with Hugo. You just copy some template files around, write your pages using any text editor in the very simple markdown format, run Hugo in the command line, and get html files ready to upload. None of this is actually “code”.
I'm ridiculously noob with all this. Trying to teach myself. I don't even know what a "command line"is. It's a wonder that I keep up with anything at all on here!(though I'm trying).
That’s exactly the question I would search in google to get started. Then when another question pop up in my mind, I would also google it. Keep doing that until you start building a better mental model & before you know it, You are reading tutorials & getting started.
I was teaching myself about Git today, and it's hilarious the Google threads I develop. "Git is a Distributed Concurrent Versions System." OK what's a "Distributed Concurrent Versions System"? Hmmm OK what's a "Concurrent Versions System?" hmm OK what's a "Version system?" googling is helpful af, but at some point I need a human interaction for real time questions. Slowly but surely.
Command line is the black and white (usually) "hacker view" that you see in movies. All OSs have one easily accessible (even windows).
Think of it as a text-only way of moving around and looking at directories/folders inside your computer - you start off in some directory and can move to other ones. In side each directory you can do really basic things like just list the files there, or rename them or move them etc. Just like you can in the GUI.
Where the command line gets powerful is that as well as manipulating files you can run arbitrary "commands" - i.e. you can run programs like you can by double-clicking an icon - AND you can start to do smart stuff like sending the output of one command as the input to another.
So you can do things like sort all of the lines in a text file in alphabetical order, remove duplicates, then count the number of lines with the command line in a couple of seconds, where as in the GUI you'd probably end up pasting the text file into a spreadsheet or something I guess.
Look for "terminal" or "CMD" in Linux/osx or Windows and have a poke around by moving through directories and listing files etc, checking against the GUI as you go. Eventually you'll get an intuition for using it.
Thanks so much. I've been thinking that Terminal on my Mac was gonna play a role in all this learning somehow. Maybe my next step will be to find some tutorials on how it works and for what purpose. Thanks for the Kickstart.
https://ashleynolan.co.uk/blog/getting-started-with-terminal has some very basic stuff for mac terminal (n.b. these are also largely identical to linux too, so bonus!). No relation to the site, just found it from googling and looks to cover off the essentials.
That will get you started getting comfortable moving around and doing things, but it doesn't go further than the absolute minimum. It will at least get you started and hopefully slightly comfortable if you need to use the terminal for anything else in the future as that is where the real learning comes from. E.g. following a tutorial and they say "type this in the command line" you are now at least a little familiar with it and can google the rest.
The Missing Semester of CS education by MIT ( https://missing.csail.mit.edu/ ) has a lot of great materials and videos to get started with basics of command line, shell, and git.
Follow this extremely simple guide & project for a basic free ssg site. I use plain html & Jekyll, two different ones. I have no experience except simple html, css, js & markdown.
The complexity of of static site generator isn't always needed or useful.
If you just want a simple site with a handful of posts a year then manually making .html files with an WYSIWYG editor or just copying old HTML/CSS templates from site likes "alistapart" is a legitimate, simple option. Installing nginx from your system repos is safe and easy too but if you don't want to self host then https://neocities.org/ is decent.
I write a lot! Have used Wordpress for almost a decade and a half. But, am trying to teach myself other ways of doing it all. It gets confusing for me very quickly. Though, I'm trying to teach myself.
You might try going back to basics. First write some pages in plain HTML using a text editor to get a feel for how tags work. Then add some styling using CSS and play around with that. That’s about all I know how to do, but I’m able to maintain a personal website that meets my needs. Since the site has no dependencies, it will presumably be readable for decades to come. And it is extremely light (not that it gets many visitors!).
Thanks for the advice. I have a bit of html and css experience, but mostly from when I tried to customize WordPress over the years. So, I'm bmhetting better at recognizing what's what in the code (is that code?), but I get really tripped up with the "but where is it?" and "how does it get from my text doc or markdown out there online?"
I’ve taught several non-technical people how to use Hugo and many of them still use it to this day on their own. It’s totally achievable after you understand just a few key concepts and pick a well-formed template to start with. And yes, Hugo is your best bet to keep things easy.
Those key concepts are what I'm after. In every vid or article I'm learning from inevitably there's a point where I can see they pivot and lose me, and it's because I'm missing a key perspective or concept. I've yet to figure out what that actually is, which makes it hard to ask for advice! Cuz I don't have the question.
Yeah it’s hard when you don’t know what you don’t know. Your best bet is to go one on one with someone who understands you’re starting from zero. Catching someone who understands that will make a huge difference. Tech in general is absolutely amazing at continually making assumptions in instructions and documentation and it irritates me to no end. A couple hours one on one with a good teacher will crack the case quickly.
This has been my feeling all along. I think in every post I make I need to add that at the end (I'm starting from zero). Bc, understandably, people assume I know more than I do. And, yes. I need to find someone to give me a couple hours to help crack it open so I can better know what I don't know.
I haven't been able to figure it how to implement my Jekyll use case in Hugo, maybe you or someone else would be able to help me.
I don't want to use a theme at all because I don't really use it for making posts, but just a website with different pages. I have a page template that pulls in my head, nav, page content, and footer.
Yeah, Jekyll and Hugo treat pages differently. It does depend on what your intended URL format is going to be when building out your layouts. I’m on mobile so I can’t get into detail now how they differ, but you can’t drop Jekyll templates into Hugo and get them to work like that. I would actually download and study some free Hugo templates to learn by example how they treat pages.
This tripped me up when I switched too, but for me it was worth it to move away from Jekyll.
[edit] I just want to add - pay attention to the content “type” in relation to creating a template and specifying the type in the frontmatter. https://gohugo.io/content-management/organization/#type may point you in the right direction. You can manifest your own type by creating a template in the correct layouts dir and then specifying that type in your frontmatter.
Do not use Hugo for this kind of setup. It's horrendously complicated and it was probably never meant to be used like this. Hugo might be good for a blog, but even a simple personal static site where you want to have different templates for each page is only achievable by jumping so many hoops.
This is my use-case (very simple, fully static site- not blog), and I'd love a tool to generate it from markdown. Do you happen to have a recommendation of a simpler tool for that?
I worked with middleman[0] before and it was much easier to setup for these kind of sites. It might not be as fast as Hugo but who cares if you change a page every other month.
How do you go about teaching people that are outright hostile to the command line and anything that resembles code?
Currently dealing with a snobbish painter/graphic designer who has used Microsoft Frontpage and Adobe Muse for over 20 years and just wants their GUI WYSIWYG back.
Context. I might try something like “Frontpage is to MS Paint as writing code is to Adobe Illustrator. I’m not trying to teach you a child’s toy so you need to stick it out long enough to gain some perspective on this.” I’ve had success convincing people that the terminal isn’t “for hackers” by showing them the command line is really where everything happens like double clicking an icon is the same as running `open ~/Applications/Adobe/Creative \Cloud/Photoshop.app` and other normal operations performed with commands. It also helps to differentiate between things we’re doing just to operate/navigate vs. steps taken in the actual writing of code/building something. You can tell how much they understand by how literal they follow directions. I usually start with a whole lesson on using the command line so when we get to the actual meat of building they’ve seen many of the common commands before. It also helps if they’re on the clock and getting paid to learn vs. trying to pick a new skill on nights and weekends.
So, in light of this (great feedback), for someone like me who's primary motivation is to increase my computer literacy so I can make better and more informed choices on how I post/interact/hang out on the web, would you recommend that I start with what you're discussing: the command line?
My thinking: if I understood basic concepts and philosophy of coding and how the "the web works," I'd be able to build build myself a simple blog, simple website, but also be less beholden to Zuck and Google platforms. Obvs I'd still be using some of it, but I'd just have more choices.
Knowing how to use the command line will not automatically elevate your command of computers in and of itself. Operating your machine at a lower level by way of the command line will over time help you to gain more computing knowledge more as a side effect. There will come times where you will get stuck trying to use a command or series of commands or scripting something for automation and you will hit a wall - this is where you will discover the secret of all power users; knowing how to solve a problem. (Almost) no one here is a great programmer because they memorized an entire language or framework or OS. We’re great programmers because we know how to find information about our issue and apply that knowledge to come up with a solution. You make a mistake or come across something you’ve never seen before, you research and figure it out, your new knowledge helps you to not make that same mistake again and this just keeps repeating. All of computing knowledge is additive; low-level concepts and tools are the foundations for all layers of abstraction above them. So learning how to use a computer at a lower level will give you a proper base for understanding higher concepts and you’ll learn useful meta information along the way. Certainly everyone learns differently, but I would recommend diving into the command line if you want to do any sort of programming or just be a power user.
Don’t try to make them love the terminal. They mostly won't, ever.
Just give them visual tools like Webflow, Blocs.app, Bootstrap Studio or even WordPress (now a complete visual page builder, from version 5.9 onwards).
2–3 seconds for 75 pages is not at all fast. My own Zola-powered site with unusually complex templates and emitting a bunch of large feeds takes under 200ms for that many pages; and Zola is not really architected to be fast (it’s more just incidentally comparatively fast because of Rust)—a static site generator actually designed for performance could certainly handle a site like that in well under fifty milliseconds with no loss of ergonomics, and I think five milliseconds with potential slight loss of ergonomics is feasible.
(Amusing note: Hexo and Zola both have a heading on their home pages “blazing fast”. I think they’re both wrong.)
Once you get below a couple seconds, you're unlikely to be measuring the speed of the SSG, you're measuring I/O latency. Suggesting it could be faster or slower is pointless unless you have identical hardware. The same disks, CPU, and RAM, the same OS, down to the kernel version. The same running processes.
Hundreds of megabytes per second is decidedly on the high side for such a device to begin with, but it only holds for big sequential writes. For random I/O, which is what this is, you’re more likely to average 0.5–5MB/s plus latency.
I was assuming it would be more CPU- than I/O-bound, because hopefully we’re all using SSDs these days, and because Hexo’s website uses similar time figures in its preposterous “blazing fast” description.
shakna’s gone too far the other way (a couple of seconds for a load like this (~80 file reads, processing, ~80 writes, all of the files under 64KB) is easily enough that if it’s measuring I/O latency there’s either something wrong with your machine or you have a slow HDD and wrote your I/O code the wrong way), but my 200ms certainly already reaches the point where CPU, disk and OS/antivirus solution all matter significantly.
In my opinion there are other things that are probably more important besides speed for medium size sites, like SEO optimization, ADA compliance or multilingual support.
Hey guys, anyone know if there is any server/webserver that can actually serve raw markdown files as html? I think Harp can do it but I was just wondering if there is anything else. Thanks.
This is awesome I’ll be exploring this for sure! I was going to mess around with Harp but don’t think it gets updated much, and also it seemed overly complicated in general even without considering the templating stuff..
So how does Caddy accomplish this sort of processing? Just somehow on-the-fly converts to html? Anyway I’ll check it out— would have to also figure out theming/templating if there is also basic functionality for that..
Also this gives me another idea that is going to sound weird. But given this new info, I’m thinking of hosting Caddy+some_md_content on Replit hosting (as Replit can host any Go application (or virtually any language I believe)). This way I can use the Replit web UI if I want, to create md/posts, and then Caddy-on-top-of-replit will serve the page.
Is this weird? I think it’s feasible right? I could/should also put Cloudflare in front perhaps in case of unexpected traffic as Replit’s free tier doesn’t provide a ton of transfer o don’t believe..
Possibly the reason why you had no idea is that Caddy -- while legitimately amazing -- has documentation that feels something like you're playing a 1980s text adventure, stuck in a maze of twisty tunnels.
You could probably set up some kind of pipe or shell script with your favorite md renderer/compiler in apache or lighttpd. CGI is a surprisingly simple protocol
This is exactly what I wanted to do. This idea has been sitting on my sideproject to do list for a while.
I know the cliché is that there are too many web frameworks. But give it a shot. Don't ask others people to use it, make it opinionated and use it yourself.
I want to build this blog generator using python, markdown, jinja and 'chose a classless css yourself'. Jinja is the templating engine, it is super fast and fun to use. If I weren't procrastinating I could ship it under a week. But I think it would be a fun project to do in Typescript if I ever decided to learn it first!
My ideal is a static site generator that has markdown as the input, a couple of data connectors (to things like Google sheets), and that can be "hosted" in GitHub. On commit, a Github Action would generate the static content.
We're close to that I think. Something like Hugo may already be there.
For the vast majority of WordPress or small business portfolio websites (beauty, building, etc) this would be perfect.
GitHub already does this for Jekyll automatically.
I run a couple of charity's websites on their own custom domains from GitHub. The charity workers use github's web UI to edit the markdown and submit, and it automatically rebuilds the site quickly (O(minutes))
The current crop of SSG's will have no impact on WordPress because they are only available through the command line. Normal people have no interest in learning how to use the terminal nor how markdown works.
I‘m going to make a case for one of the more complicated SSG setups.
My current domain is a full blown Next.js setup hosted at Netlify. I use Next.js because I use React in my day job and frankly, I enjoy it. Out of Next I get: partial hydration, automatic image optimization, a no-bullshit build setup, static pages where I need them and the ability to add complex things like Markdown and LaTeX support or interactive graphs for more involved blog post. The real winner is MDX. Where I had to resolve to cheap tricks like shortcodes before, I can just import and place my graph components.
By using the Netlify free tier, my site gains free SSL and builds automatically when I push to master.
You would think this is insanely heavyweight for a basic homepage, but it’s not. Once setup, I can just write my blog in markdown. My entire site ships at just a bit over 50KB gzipped.
Do you need this setup? No. But I had fun doing it.
I just skimmed the article. Was 11ty ever mentioned?
That looks to me like one of the easiest to start with and it has some pretty advanced features also.
Huge fan of statically generated pages. We statically generate all our pages at Levels.fyi. Another benefit is that static websites are also great for SEO. Cool to see a lot more adoption and progress around the tech here. For example, once you reach tens of thousands of generated pages it can get a bit hard to maintain, but tools such as Next's incremental static regeneration make things a bit easier: https://nextjs.org/docs/basic-features/data-fetching/increme...
I love the concept.
That said, I do have a bone to pick with the listed generators. They over complicate or fail to explain the site development and the documentation is often a twisted nightmare.
It is absolutely true, that if I could get the site generated as I want it, it would be less cost for the server, faster, and so on as described.
I really believe that static site generators are lagging in adoption, because unclear documentation.