Static Website Generators Are the Next Big Thing • Hacker News Board

Re: Static Website Generators Are the Next Big Thing

#111

Post by davexunit » Tue, Nov 03, 2015, 5:27 PM UTC

Tomte wrote: post #99

davexunit wrote: post #31

The reason I like static site generators so much is because it allows me to treat my website as a program that outputs a website. Take some posts in whichever format you prefer, write a program to parse them as a tree of HTML nodes, insert them into templates for HTML pages, Atom feeds, etc. It's all just plain text code and markup, no stateful database with a dynamic web application in front doing everything.

Have you had a look at Pollen, by Matthew Butterick?

Yes. I like Butterick's "Practical Typography" a lot, and the rationale behind using Racket. That said, I don't actually like Pollen because it's just a string-based templating system. Instead, I want to use something that is based around s-expressions. My static site generator, Haunt, works with SXML trees instead of raw strings which is much nicer to work with.

Re: Static Website Generators Are the Next Big Thing

#112

Post by notacoward » Tue, Nov 03, 2015, 5:27 PM UTC

codingdave wrote: post #103

notacoward wrote: post #17

Earlier quoted context omitted.

"Statically generated JSON resources" implies client-side rendering, and I suspect you'd find some disagreement over whether that's really static. If there's only one such resource per page, then maybe, though you'd still be losing some advantages wrt caching. If the JS running on the client has to fetch many such resources and stitch them together, then it's functionally equivalent to a standard dynamic website and…

How do you figure that loading a static file is the same as a DB query? Even if the actual finding of the bits on the hard drive and sending them across the wire is close to the same, you don't need a database running. You get to shut down an entire process, or depending on your architecture, an entire server. Heck, once CDNs and caching get involved, I wonder how many requests will even hit your HTTP process at all.

Loading the set of files needed to satisfy a request is equivalent to a database query. Databases and file systems have to deal with similar issues when looking up a single item, so there's a clear correspondence there. The difference is that a database can do a JOIN but a file system can't (directory traversals really aren't equivalent). In that case any such logic would have to be in the client-side JS, fetching objects and quite likely imposing even more load than an SQL query would have. Being able to shut down that database process is good in a lot of ways (especially security) but reduced total load isn't necessarily one of them. You might just be shifting load to the the web server and file system. That's why I said the generator part is as important as the static part. That solves the result-aggregation problem at edit/compile time instead of request/run time, which is good regardless of whether the back end is a database or a file system.

Re: Static Website Generators Are the Next Big Thing

#113

Post by vlunkr » Tue, Nov 03, 2015, 5:31 PM UTC

ts330 wrote: post #7

I'm not entirely sure they're the next big thing. More likely, is that 15 years ago, it was people who were used to static sites began moving to dynamically generated ones as sites became more complex. They were the new thing then. Now we have a load of people who have grown up with dynamically generated sites and are suddenly discovering the benefits of static sites - thanks in part to the proliferation of tools tha…

You're totally right. I think there's a rediscovery of static sites going on, and an improvement in the tools, but it can't possibly solve every use case, or even the majority of them.

Re: Static Website Generators Are the Next Big Thing

#114

Post by masswerk » Tue, Nov 03, 2015, 5:38 PM UTC

ts330 wrote: post #7

I'm not entirely sure they're the next big thing. More likely, is that 15 years ago, it was people who were used to static sites began moving to dynamically generated ones as sites became more complex. They were the new thing then. Now we have a load of people who have grown up with dynamically generated sites and are suddenly discovering the benefits of static sites - thanks in part to the proliferation of tools tha…

15 years ago this even made much more sense. I did a static site generator in good ol' Perl 5 in the 90s – and I'm sure, I wasn't the only one to do this. (Everything was based on file hierarchies, but there wasn't much structure or setup required else. Directories were mangled to intermediate data files in pseudo-XML, only to be reassembled, when there was an update local to that hierarchy. XML wasn't the big thing then, but as this had to mangle HTML anyway, it was somewhat obvious to embed data structures in tags.)

Back then, this really had some advantages: Updates were rare, but views comparably frequent, while databases were either not that performant or quite expensive. This way, you could serve everything from cache (remember Squid?), and, compared to a dynamic site, it was really quick, even in admin-mode. Given the modern machines and the lots of memory they come with, it's quite ironic to see this come back, while we saw the triumph of the LAMP stack on comparably modest machines. Nevertheless, if you've only a few updates and lots of views, it's a good idea towards green computing. (Save some mountaintops! [1])

On the other hand, there is some "magical" limit regarding flexibility and complexity, where things tend soon towards unmaintainable code. So, the judgement is left to you, respective to the purpose.

Edit: [1] "Mountaintop mining" at Google-images: https://www.google.com/search?tbm=isch&hl=en&q=mountaintop+m...

Re: Static Website Generators Are the Next Big Thing

#115

Post by DamnInteresting » Tue, Nov 03, 2015, 5:41 PM UTC

PuffinBlue wrote: post #75

TheOtherHobbes wrote: post #36

Earlier quoted context omitted.

Do you - or anyone - have stats about the possible traffic demands of Slashdot/Reddit/HN front page stardom? I'm very much in the Nginx/static camp, but it would be useful to know how bad the spikes can get.

I spoke with Alan Bellows from 'Damn Interesting'[0] on Reddit after his site hit the front page via a TIL post and he revealed a little about the traffic load.[1] It was very interesting to see and was quite a lot of traffic for sure. Bear in mind that the screenshot he posted is for concurrent visitors too. [0] http://www.damninteresting.com/ [1] https://www.reddit.com/r/todayilearned/comments/3d3vct/til_a...

I had no expectation of encountering my own name in this context. If there is a German word to describe the thing my neurons just did, I'll bet it has a lot of umlauts.

Re: Static Website Generators Are the Next Big Thing

#116

Post by ak39 » Tue, Nov 03, 2015, 5:46 PM UTC

notacoward wrote: post #112

codingdave wrote: post #103

Earlier quoted context omitted.

How do you figure that loading a static file is the same as a DB query? Even if the actual finding of the bits on the hard drive and sending them across the wire is close to the same, you don't need a database running. You get to shut down an entire process, or depending on your architecture, an entire server. Heck, once CDNs and caching get involved, I wonder how many requests will even hit your HTTP process at all.

Loading the set of files needed to satisfy a request is equivalent to a database query. Databases and file systems have to deal with similar issues when looking up a single item, so there's a clear correspondence there. The difference is that a database can do a JOIN but a file system can't (directory traversals really aren't equivalent). In that case any such logic would have to be in the client-side JS, fetching ob…

The loading of static files for HTTP is significantly different from accessing the same data via databases. The biggest difference is the need for a CLI (call level interface) connection object in db access. And those things are resource hungry operations (authentication, prototocol management etc). Most times you have to pool connection objects which in itself is a resource cost.

The DB is truly the scalability bottleneck.

Re: Static Website Generators Are the Next Big Thing

#117

Post by applecore » Tue, Nov 03, 2015, 5:47 PM UTC

jedberg wrote: post #108

When I was heading up reliability at Netflix, we considered, and even began evaluating, turing the whole thing into one big static site. Each user had a custom listing, but generating 60+ million static sites is a very parallelizeable problem. At the time, the recommendations only updated once a day, but an active user would have to dynamically load that content repeatedly, and at the same time, the recs were getting…

This sounds crazy enough to work.

Re: Static Website Generators Are the Next Big Thing

#118

Post by kzhahou » Tue, Nov 03, 2015, 5:56 PM UTC

TheOtherHobbes wrote: post #36

thenomad wrote: post #2

I've been a fan of static websites for a long while now. In addition to page load issues, they also more or less completely solve the Slashdot effect (aka the Reddit Hug Of Death, these days). A competently-configured Nginx server on a 512mb VPS, serving static-only content, will handle ridiculous amounts of traffic without flinching. Ever since a front-page mention on BoingBoing took down my feature film BloodSpell'…

Do you - or anyone - have stats about the possible traffic demands of Slashdot/Reddit/HN front page stardom? I'm very much in the Nginx/static camp, but it would be useful to know how bad the spikes can get.

A TechCrunch article used to get you about 15-20K in a day. Might be less these days.

Re: Static Website Generators Are the Next Big Thing

#119

Post by ics » Tue, Nov 03, 2015, 6:14 PM UTC

AnkhMorporkian wrote: post #16

You know what I've always wanted, but my searches have led me to believe that it (inexplicably) doesn't exist? I want a simple site generator. I don't want markdown, I don't want a fancy templating engine. I want some simple templating system that takes in normal HTML and generates pages from simple templates I define. I want to shove in some arbitrary HTML and have it spit out a site using some base templates. To th…

Jekyll and Middleman have already been mentioned but another is nanoc [http://nanoc.ws/] which I like because it is not so blog-centric. You can get a good overview of how it works relative to what you want just by reading the Rules doc page [http://nanoc.ws/docs/reference/rules/], but essentially it does nothing by default except dump your HTML input into the body of the default layout. I use it for moderately complex as well as dumb I-just-want-a-few-variables-to-stay-updated things, the only downside being multisecond compilation times with many pages.

Re: Static Website Generators Are the Next Big Thing

#120

Post by tootie » Tue, Nov 03, 2015, 6:19 PM UTC

ts330 wrote: post #7

I'm not entirely sure they're the next big thing. More likely, is that 15 years ago, it was people who were used to static sites began moving to dynamically generated ones as sites became more complex. They were the new thing then. Now we have a load of people who have grown up with dynamically generated sites and are suddenly discovering the benefits of static sites - thanks in part to the proliferation of tools tha…

15 years ago we spent $250K for an off-the-shelf CMS that was a static site generator with workflow. Worked perfectly fine even if it was way overengineered.