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

21–30 of 100 posts

Re: Static site generators focus on the wrong thing

#21

Post by spatten »

Funny, I looked at the same tech stacks and came to exactly the opposite conclusion.

I want to be able to write on my computer, in Markdown, using the tools I want (I blog in either Emacs or iA Writer, depending on whether I want to be in "programmer brain" or "writer brain"). I guess I spend enough time in Markdown that I don't need to preview that much, so I don't find the switch to the browser and reload the page cycle especially frequent or onerous. Definitely less onerous than the click preview and wait for it to load cycle I had on WordPress.

Having to log into a browser and type into a crappy little rich text editor would lower my (already extremely low) blogging frequency to non-existence.

But hey, that's my choice -- you should use whatever works for you. I'm just glad that we have the plethora of options.

Re: Static site generators focus on the wrong thing

#22

Post by dreamfactory2 »

joshcrews wrote: post #12
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…

You can get the best of both by using a dynamic site CMS, and then hooking it up to Amazon Cloudfront to cache your html. The only challenge then is page cache expiration. You can set that by either using the http headers for Cache-Control or setting page rules in Cloudfront's admin. Such a setup will scale like crazy and skip "compilation" steps

The challenge isn't page caching but object caching and rendering.

SSGs are just a rerun of the 90's and don't solve anything that Varnish doesn't already. Pages are an increasingly quaint notion on an increasingly dynamic, personalised, multi-device web. Time to publish is ever more important as Google SEO measures news sources in minutes and publishing workflows often require instant publishing and internal search where there are handoffs (e.g. a subeditor and picture desk).

The two real problems I see is that ESI is our best solution to rendering (and is a clunky 90s-style design), and that object cache refresh has a tendency to combinatorial explosion.

Re: Static site generators focus on the wrong thing

#23

Post by jacquesm »

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 moment of serving up the content in time, does not even have to happen on the same server.

So from an operational security perspective, if you can run a site statically you probably should. And what with blogs outsourcing comments to disqus and the like quite a few of them are candidate for being served up statically.

As for the performance element, if a site has 1000 pages then re-generating that site will be the same load as serving up 1000 pages when the caches are cold. So that's 1000 visitors. If that's slow then it is annoying to the site admins, not to the visitors. It's an off-line process, it doesn't have to be fast to work. All that matters is that the end product can then be served up blazingly fast.

Any website that does not require user generated input or logged in users is a really good candidate for this workflow.

Re: Static site generators focus on the wrong thing

#24

Post by smackfu »

Vaskivo wrote: post #17
dminor wrote: post #7

Sure, but they're not called static blog generators, they're static site generators. They are specifically for people who want static sites, not specifically people who want frictionless blogging.

I believe most static site generators are "blog oriented". And a blog is still a website.

Yeah, Jekyll brags about being "blog-aware" whatever that means.

Re: Static site generators focus on the wrong thing

#25

Post by paulyg »

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…

I agree with your assessment. To me the reason we keep ping-pnging between the two extremes is a lack of standardized and common caching mechanism. In a perfect world every web server would be behind an HTTP reverse proxy and we could just use HTTP headers to control caching. But there are a lot of quirks to that so unless you control the whole stack you don't have a proxy out front. And then you get into all other kinds of caching schemes: filesystem, memcache, redis, s3/cloudfront, etc. Which one you choose is determined by your tech stack, your PaaS, etc. Which the CMS creators have limited control over. If caching was a no brainer CMS creators could just concentrate on making the dynamic part good.

Re: Static site generators focus on the wrong thing

#26

Post by falcolas »

I know the author said automation wasn't what they wanted, but gods below this problem begging to be automated away.

1) Only compile newly updated items.

2) git commit -am 'new post'

3) git push origin master

The first step needs to be built out in the tool itself, but the rest is a simple bash script, really. It's not even something that needs to be monitored. If you did want to monitor it, it's a few simple `curl` commands away from pushing to prowl or NMA. No need to sit at your computer waiting for it to finish.

Seems like a good weekend project - build a set of tools around Jekyll (and/or any number of other static site generation tools), and let the laurels rain down.

Re: Static site generators focus on the wrong thing

#27

Post by smackfu »

leephillips wrote: post #13
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…

> "live pages" equals "lots of hits to the database" Is it common for people to set up a database backed website without caching? The framework I'm most familiar with, Django, will cache the results of database queries, so if, say, an article on the site becomes popular the database is hit once, and thousands of views are served from the cache. Edit: Jweb_Guru, thanks for that clarification.

Wordpress uses plugins for caching, last I checked.

Re: Static site generators focus on the wrong thing

#28

Post by marban »

rmorabia wrote: post #5

Medium is NOT a blogging platform, contrary to popular belief. Blogging is owning your content, and when you write for Mediium, make no mistake, it belongs to Medium. Although, I just switched over from Wordpress to Jekyll, and I find it there to be a lot less friction for publishing. I talked more about the new and exciting workflow of Jekyll at http://rmorabia.com/redesign I really don't agree with the author here.…

If you're looking for a mix between svblte and Medium you might give http://www.postagon.com a shot.

Re: Static site generators focus on the wrong thing

#29

Post by 0xdeadbeefbabe »

smutticus wrote: post #9

I recently upgraded my Jekyll install, and I must say this beast is becoming bloated. One of the many gem packages it now requires is a JS interpreter. Why? I use an SSG because they're simple, don't require dynamic page loads and are more secure. However, the 'simple' part of this is wearing thin. Like so much of modern web software the developers only add things to it. They never remove or refactor. So you end up w…

Wait, were there days when software bloat didn't happen? I think feature creep and accompanying bloat is human nature for all time.

Re: Static site generators focus on the wrong thing

#30

Post by dreamfactory2 »

I think there's an interesting phenomenon at play here - the swing from interpretation to compilation across the board. It's not just happening in SSGs but also CSS (SASS etc), frameworks (PHP composer, NPM), languages (Go, Rust). Seems weird to be adding such layers of indirection when we are already suffering from overcomplexity and when processing is cheaper and faster.
Post reply on HN