71–80 of 81 posts
Earlier quoted context omitted.
shopflamingo.com, ideo.com, ca.braun.com, and bejamas.io are all blazingly fast for me.
Ideo has a pretty bad insight score (41): https://developers.google.com/speed/pagespeed/insights/?url=... First paint: 4.1 Seconds. Time to interactive: 11.5 Seconds. I wouldn't say that's very fast. Edit: I didn't check the other three.
ca.braun.com gets 77
bejamas.io gets 96
So implementation dependent I guess
Earlier quoted context omitted.
Cheaper to build a site and dunp files to a bucket than running Wordpress code on every request.
Surely there's a CPU/disk trade off at some point. Static pages are much larger (less likely in memory) and would cause disk reads much sooner than the same files being generated dynamically. Of course wordpress isn't known for it's efficiency so the static page preference is probably quite high.
At an extreme case, yes. Disk is SO CHEAP.
Earlier quoted context omitted.
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…
Preparing data for external use always takes extra effort.
You can build an efficient self-contained tool in JavaScript too.
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
Wordpress in particular is not “just fine”. During this crisis, every government site based on WordPress ends up crashing under the load. Yes, you can avoid this with a good cache plugin and a CDN. But you can also avoid it by using a tool that is designed to not crash under load in he first place.
Serving up a HTML file from disk or generating some dynamic HTML are both trivial to do once . After that, a CDN layer is used to cache the HTTP response, regardless of how it was generated. Sure if you just want to serve HTML files on every request with a simple file server than static files will be faster, but it'll eventually get overloaded too. The CDN is where the real scaling happens. And using a CDN is far eas…
Using a static site generator is basically just a way of ensuring that the pages are properly cached by the brute fact that they've been dumped out on disk. It's not strictly necessary for a well designed system, but it raises the floor because even in the worst case, the pages are static files.
For many public facing sites, dynamic applications aren't strictly necessary. If you're just hosting a PDF of an Excel spreadsheet of permitted job categories, you don't need a dynamic application. Again, a well designed app would already be hosting this through S3, but you can't trust things to be well designed when made by a contractor with no technical oversight.
Earlier quoted context omitted.
Serving up a HTML file from disk or generating some dynamic HTML are both trivial to do once . After that, a CDN layer is used to cache the HTTP response, regardless of how it was generated. Sure if you just want to serve HTML files on every request with a simple file server than static files will be faster, but it'll eventually get overloaded too. The CDN is where the real scaling happens. And using a CDN is far eas…
I am specifically complaining about WordPress. Anyone could make a server side dynamic application that applies proper caching headers to work with a CDN. Anyone could, but WordPress specifically did not. It's an uncacheable mess by default and caching plugins just barely make it useable. Using a static site generator is basically just a way of ensuring that the pages are properly cached by the brute fact that they'v…
CDNs handle scaling of static assets. That's their entire purpose, with features like request coalescing and origin shielding to help ensure unique URLs are never requested more than once. Optimizing for static files at the origin is just not worth the trouble when Wordpress and other frameworks are far more productive and provide CMS functionality which is usually needed anyway.
Earlier quoted context omitted.
> 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.
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?
Earlier quoted context omitted.
I am specifically complaining about WordPress. Anyone could make a server side dynamic application that applies proper caching headers to work with a CDN. Anyone could, but WordPress specifically did not. It's an uncacheable mess by default and caching plugins just barely make it useable. Using a static site generator is basically just a way of ensuring that the pages are properly cached by the brute fact that they'v…
Static files don't automatically set any headers either, you still need a webserver to serve those. And you can override those headers in the server or in the CDN so there's no reason to switch out the entire backend for it. CDNs handle scaling of static assets. That's their entire purpose, with features like request coalescing and origin shielding to help ensure unique URLs are never requested more than once. Optimi…
Earlier quoted context omitted.
Cheaper to build a site and dunp files to a bucket than running Wordpress code on every request.
Surely there's a CPU/disk trade off at some point. Static pages are much larger (less likely in memory) and would cause disk reads much sooner than the same files being generated dynamically. Of course wordpress isn't known for it's efficiency so the static page preference is probably quite high.
Earlier quoted context omitted.
Surely there's a CPU/disk trade off at some point. Static pages are much larger (less likely in memory) and would cause disk reads much sooner than the same files being generated dynamically. Of course wordpress isn't known for it's efficiency so the static page preference is probably quite high.
> Surely there's a CPU/disk trade off at some point At an extreme case, yes. Disk is SO CHEAP.