Hacker News Reader

Comment by seanwilson | Hacker News Reader

How much is the speed issue related to the language used? I know Hugo is an order of magnitude faster than most static site generators for example - it's written in Go with e.g. 2 seconds to generate about 10K pages https://forestry.io/blog/hugo-vs-jekyll-benchmark/.

I would have thought the generation process could be massively parallelised and a typical blog page would only need a modest amount of computation e.g. concat header, footer, pull in body text, resolve a few URLs. I can't help but think about how much work a typical computer game is doing in comparison 60 times per second even without a GPU.

View on HN

I don’t think it’s a language issue. Even for JavaScript bundlers you have the slow extensible bundle and the “new super fast bundler” that dies in a month because it only fits one use case.

How flexible is Hugo? And how many plugins does someone generally use?

> How flexible is Hugo? And how many plugins does someone generally use?

It processes Markdown, JSON, YAML and SASS, can pull in data files from URLs, and has custom templates/themes, custom macros/shortcuts, image processing and live reload. It doesn't have a plugin system as far as I know but nothing stops you combining Hugo with other tools e.g. run a JS script to pull in and transform a JSON file before Hugo runs.

I think that’s the point. No plugin system. Compare Babel to Bublé or even Sucrase for example: https://github.com/alangpierce/sucrase

Preparing data for external use always takes extra effort.

You can build an efficient self-contained tool in JavaScript too.

A counterpoint: Babel's extensibility doesn't matter in practice at all, other than helping the Babel team organize their code.

Pretty much every new ES6 feature required parser and babel-core changes just to be able to be used.

Example: a lot of changes that only worked in Babel 7 (that was on Beta for months) were not possible in Babel 6, and so on for previous versions. A plugin was not enough: you also needed parser/core changes.

Other than for novel non-standard features (like code substitution), plugins are not exactly that powerful, and even things like that are frowned upon in most environments, as 99.9% of people just want ES6 features.

> Preparing data for external use always takes extra effort.

How much effort are you really talking about for a static site though? Can you be specific?

Most sites I've worked on are processing a modest number of Markdown + JSON files, where sometimes these are pulled in from an external URL. Why does any of this require anything particularly complicated or anything that could justify a big performance hit?

> You can build an efficient self-contained tool in JavaScript too.

Does one exist for static site generators though?

I use Hugo to run a site for a small news organization. It’s flexible enough. I’ve never run into something I couldn’t make it do with some creative thinking. It doesn’t have any plugins because why would it need a plugin? I guess there is a basic build and an extended build for including image resizing, but they would only have one build if they didn’t need to use C for the image stuff. Plugins mean the system doesn’t solve the problems of its users…

It does have themes, but I just write my own.

Some of it is due to the language and the general JS tooling being bloated and slow.

However, in many cases build time is slow because you're doing something that's slow, like calling a REST API. You are not going to generate 10k pages in 2sec if you need to make 10k REST requests, each taking 100ms, to a remote API to fetch the data for your pages. This kind of "data integration" from various sources is a standard use cases for site generators like gatsby and next.js. It seems like what this is targeting is smarter caching to avoid such expensive calls when possible.

Hugo is different in that it basically just transforms local HTML/Templates/Markdown. That's always fast. Even JS can handle that.

> Hugo is different in that it basically just transforms local HTML/Templates/Markdown. That's always fast. Even JS can handle that.

Do you know of any benchmarks that show that? As far as I know, most static site generators can take minutes to process a few thousand Markdown files with Hugo being the exception.

Reply on news.ycombinator.com