Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static site generators focus on the wrong thing

blog.pankajmore.in

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Static site generators focus on the wrong thing

#71

Post by dreamfactory2 »

jacquesm wrote: post #53
diminish wrote: post #52

Earlier quoted context omitted.

dynamic with caching (e.g. Varnish) is like static from security and response time perspective..but static has the advantage of local distributed fronts (cloudfront)... If we think, 99% of all blogs will be read less than 1000 times per day, the performance consideration does not matter.

I don't agree at all that 'dynamic with caching' is like static from a security perspective. It's very easy to bust the cache (simply affix a random bit of nonsense to the end of the urls) and force dynamic execution of every request you make, opening you up to all the security issues that a direct dynamic front-end would give.

That's just a question of cache config surely.

Re: Static site generators focus on the wrong thing

#72

Post by phloxicon »

geekam wrote: post #3

I use Pelican[1] (Python) SSG and they are adding (have added?) a feature to skip articles that have not been touched. That makes compilation really fast. [1] https://github.com/getpelican/pelican

I'm really interested in that feature. Do you know which issue that is on the tracker?

Re: Static site generators focus on the wrong thing

#73

Post by winter_blue »

smacktoward wrote: post #10

This is an argument that literally goes back to the dawn of the CMS. CMS designs tend to fall somewhere between two extremes: completely static (grinding out HTML files) and completely dynamic (generating new pages for each request). Static is appealing because it scales like crazy, but it's also unappealing because it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger. Dy…

Incremental compilation has been around for decades. I have a couple of scripts that generate static HTML pages for parts of my website, and I use *make -- and when I make a single change, only its corresponding page is updated. SSGs don't ever need to rebuild from scratch. Just leverage existing make/ninja/etc tools for your blog...

Re: Static site generators focus on the wrong thing

#74

Post by winter_blue »

This guy totally misses the point, even as to why Tom Preston-Werner kicked off Jekyll. His goals were:

* Have blog posts be plain-text files, in Markdown or some other such similar human-readable format. Not locked away in a MySQL database that can't be easily versioned with Git.

* Versioning: plain text lends itself really well to versioning. Diffs are meaningful. It's easy and light-weight, and pragmatic to version a bunch of simple markdown files.

* Finally: fine-tuned output control. This is what Liquid lets you accomplish. You can specify your HTML pages in Liquid, and easily give your blog a new look. The simplicity, ease, and freedom that this system gives a person with basic web dev skills, shouldn't be ignored.

Re: Static site generators focus on the wrong thing

#75

Post by syntern »

dreamfactory2 wrote: post #70
syntern wrote: post #39

Earlier quoted context omitted.

While it may be shiny and hip to provide the latest and greatest news with very fast publishing cycles, I am not sure if this is for everyone. Thoughtful articles require time to write and edit, reviewers will spend time on them. Re-running a static site generator to publish them is a fraction of the total time it requires to write a good article. If, on the other hand, you are not in for quality, then yes, time to p…

That's really just the difference between news and articles. News events (big trials, disasters etc) are highly time-sensitive and if your income depends on display ads and Google, instant publishing is crucial and something that comes up on RFPs for such systems. Workflow where content is created by multiple people isn't as well understood but can be a source of incredible friction and productivity killer in publish…

This really hits home for me, because I'd love to use a CMS, but I just haven't found that is: (a) easy to use (b) easy to customize.

Just to single out a shortcomings I've recently found: multiple authors with multiple languages, defining short and long version of bio/tagline. The tagline is displayed at the article, which may be tagged with multiple contributors with different roles (author, translator, reviewer), while the author page displays the long version.

I've spent days to figure out what plugin/theme combination (Wordpress or Drupal) would enable me this single feature, and I couldn't figure it out.

Yesterday evening I gave up, and now I have <200 lines of code in Dart (using markdown and mustache), generating static pages that were annotated with metadata, doing just that. To be honest, I'd trade it any time for a decent CMS, I just can't find any.

Re: Static site generators focus on the wrong thing

#76

Post by jacquesm »

dreamfactory2 wrote: post #71
jacquesm wrote: post #53

Earlier quoted context omitted.

I don't agree at all that 'dynamic with caching' is like static from a security perspective. It's very easy to bust the cache (simply affix a random bit of nonsense to the end of the urls) and force dynamic execution of every request you make, opening you up to all the security issues that a direct dynamic front-end would give.

That's just a question of cache config surely.

Only if you have prior knowledge of what URLs are possible.

If you don't then the front-end cache will have to play it safe and will have to pass the request to the backend if it does not know the URL.

Any kind of variability in the request that causes a conversation between the front-end and the back-end and the cache can be busted, or is a potential DOS vector.

Please show me a caching front-end with a dynamic back-end that you control and that you think is protected against cache busting and we'll discuss that off-line. I'd hate to expose you to some joker taking you down just to make the point.

A cache can even become it's own enemy, for instance, if it passes requests on to the backend server if the GET contains url parameters and these make the request unique in the eyes of the cache but not unique in the eyes of the back-end then the cache could easily eat up a ton of memory even though from the back-ends perspective the same page got hit over and over again.

Caching is tricky.

Re: Static site generators focus on the wrong thing

#77

Post by reinhardt »

jacquesm wrote: post #23
smacktoward wrote: post #10

This is an argument that literally goes back to the dawn of the CMS. CMS designs tend to fall somewhere between two extremes: completely static (grinding out HTML files) and completely dynamic (generating new pages for each request). Static is appealing because it scales like crazy, but it's also unappealing because it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger. Dy…

There is one argument against dynamic sites where a static one will do: a static website is reliant only for security on the http server and the underlying OS. Dynamic sites run so much code during page generation that there are a lot of ways in which you could try to use all that code to do something unintended. And some of those ways pay off. A static site cleanly separates the moment of code execution and the mome…

> All that matters is that the end product can then be served up blazingly fast.

TFA argues exactly against this point. All that matter (or rather, what matters more) is minimizing the friction for the blog author in order to stay motivated, not if it takes a fraction of a second more for a page to load.

Re: Static site generators focus on the wrong thing

#78

Post by joshvm »

pdonis wrote: post #56
smacktoward wrote: post #10

This is an argument that literally goes back to the dawn of the CMS. CMS designs tend to fall somewhere between two extremes: completely static (grinding out HTML files) and completely dynamic (generating new pages for each request). Static is appealing because it scales like crazy, but it's also unappealing because it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger. Dy…

> it requires a "compilation"/"rebuilding" step that gets longer and longer as your site gets bigger Unless the generator can keep track of what has and hasn't changed and only rebuild the changed stuff.

Obvious gotcha to that is if you have a link on every blog post to jump to the most recent entry. If you were going dynamic, that info would be inserted on page generation, if you're going static then you need to update everything.

Easy solution would be to make a duplicate page like /latest.html which updates as necessary.

Re: Static site generators focus on the wrong thing

#79

Post by h4ckth3pl4n3t »

I agree with many of the points made in this article however I believe the conclusion is flawed. Many SSGs focus on the wrong thing, but not all of them. Fed up with Jekyll (which I used after being fed up with Wordpress) I wanted something with even less friction.

I came across Hugo (http://hugo.spf13.com) and have been super happy ever since. Here's some of the reasons why:

1. Really easy to install. One binary, no dependencies or package managers

2. Really fast. Renders my entire site with hundreds of posts in less than half a second. Even changes to templates or themes (which affect every page in the site) render in milliseconds. Wordpress couldn't even render a single page that quickly.

3. Because it is so fast the live reload feature Hugo has works really well. Keep a browser window open and see a nearly instant preview every time I save a file.

4. Deploying is as simple as running a 3 line shell script I wrote in a couple minutes. Since I'm already in the terminal running the script is trivial. I can even run it from within Vim. Thanks to Rsync it takes around 3 seconds to deploy my content. Again, less time that it takes to hit preview and then save in Wordpress.

And all of these are the default.

Re: Static site generators focus on the wrong thing

#80

Post by jacquesm »

reinhardt wrote: post #77
jacquesm wrote: post #23

Earlier quoted context omitted.

There is one argument against dynamic sites where a static one will do: a static website is reliant only for security on the http server and the underlying OS. Dynamic sites run so much code during page generation that there are a lot of ways in which you could try to use all that code to do something unintended. And some of those ways pay off. A static site cleanly separates the moment of code execution and the mome…

> All that matters is that the end product can then be served up blazingly fast. TFA argues exactly against this point. All that matter (or rather, what matters more) is minimizing the friction for the blog author in order to stay motivated, not if it takes a fraction of a second more for a page to load.

That's strongly dependent on how many people visit a particular blog. For smaller blogs, sure the page generation time is not relevant.
Post reply on HN