4 ms·

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 beca

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?

seanwilson 6y ago
> 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.
- turnipla 6y ago
  I think that’s the point. No plugin system. Compare Babel to Bublé or even Sucrase for example: https://github.com/alangpierce/sucrase 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.
  - ratww 6y ago
    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.
  - seanwilson 6y ago
    > 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?
earthboundkid 6y ago
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.

seanwilson 6y ago

> 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.

turnipla 6y ago
I think that’s the point. No plugin system. Compare Babel to Bublé or even Sucrase for example: https://github.com/alangpierce/sucrase 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.
- ratww 6y ago
  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.
- seanwilson 6y ago
  > 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?

earthboundkid 6y ago

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.