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

81–90 of 100 posts

Re: Static site generators focus on the wrong thing

#81

Post by jcheng »

DigitalJack wrote: post #42
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.

They should be called static blog generators because that's what they all do. You can try to finagle generic sites out of them, but all the ones I have looked at all focus on blogging. I don't want a blog generator and find this immensely irritating. However I just found this site: http://staticsitegenerators.net/ , which is an impressiv elisting, so possibly I'll find something that fits my needs or gives me a start…

I found Middleman extremely nice for generic websites. It doesn't even have blog-specific functionality built in (though there is a plugin if you want it).

http://middlemanapp.com/

Re: Static site generators focus on the wrong thing

#82

Post by elviejo »

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…

I once made a static website with 12,000 articles. The key? * used a RAMDISK to generate the site and rsync to upload only the changed part to the server. * we also used JKL (a clone of jekyll in GoLang) * at some point we were doing 40 second compiles.

Re: Static site generators focus on the wrong thing

#83

Post by kiriappeee »

This is bizzarely coincidental. I've been at a hackathon for the last 14 hours and I'm working on a static blog based cms. All the benefits of having a CMS with the output of a blazingly fast and stable static website. Will be open sourcing it when it gets to version "CRUD ready"

Re: Static site generators focus on the wrong thing

#84

Post by inthewoods »

drzaiusapelord wrote: post #69
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…

CMS's won for a reason. I used to admin a Collage install, inherited from an acquisition. What a piece of shit that experience was for all involved. On top of it, everything dynamic had to be tacked on in a 90's web style with certain pages being dynamic, a bit for discussion, a different bit for login, a different bit for whatever, etc. A CMS is at least one system and these things are treated as plugins as opposed…

"Also your coworkers wont be cursing your name after you leave them a patchwork of barely held together code in your wake to make the SSG based site do dynamic things CMS's find trivial. Especially if they come from a CMS background."

Can you provide an example of something that CMS's find trivial that is difficult to do in an SSG?

Re: Static site generators focus on the wrong thing

#85

Post by inthewoods »

kiyoto wrote: post #46

I write a lot (in Japanese) on the web and have had some meaningful traffic. I think the most I got on a single day is like 150k visitors. And I've tried everything from raw HTML to SSG to Wordpress to a homegrown CMS. The truth of the matter is, for most web writers, any CMS is plenty performant. You probably won't even need a cache, and if you end up needing one, it's usually pretty straightforward to add it. And i…

I agree on security - I'm sick of updating Drupal and Wordpress for different security holes.

Re: Static site generators focus on the wrong thing

#87

Post by pdonis »

joshvm wrote: post #78
pdonis wrote: post #56

Earlier quoted context omitted.

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

There are other gotchas as well; for example, on my blog I have links in my sidebar to pages for categories and tags, but the links have total post counts for the category/tag after them, so every time a new post is added at least one count will change on every page. I don't mind because the SSG I use (my own, https://github.com/pdonis/simpleblog3 ) renders fast enough to suit me; it takes about 5-6 seconds to render my entire blog.

Re: Static site generators focus on the wrong thing

#88

Post by grey-area »

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…

No, the main argument is for security, then cost (software updates cost time), then perhaps performance, though as you point out there isn't much difference with a properly configured cache.

Clearly static doesn't suit all sites but if the site is infrequently changed and not too complex or dynamic it is sometimes the best choice. If you have highly dynamic content with multiple authors static is clearly a terrible choice. This is not a zero sum game, there is room for both approaches.

Re: Static site generators focus on the wrong thing

#89

Post by scott_karana »

pdonis wrote: post #67
scott_karana wrote: post #66

Earlier quoted context omitted.

Nothing prevents you from using make (or rake) to invoke an SSG... :-)

Only if the SSG can operate at the single-file level. Most SSGs operate at the entire-site level; there's no way to invoke them and tell them "just rebuild this one page", which is what you'd have to do to use make or rake as your change-detector. Also, I'm not sure how well make or rake would work with version control, since make/rake, AFAIK, look at file modification times to detect changes, and DVCS pulls clobber…

It's true, yeah.

Anyways, my point wasn't that make is sufficient (it isn't), but that a lot of SSGs have been pretty embarrassingly feature-sparse. Understandable, I suppose. :)

Re: Static site generators focus on the wrong thing

#90

Post by andybak »

pdonis wrote: post #58
andybak wrote: post #35

Earlier quoted context omitted.

Agreed. Essentially SSGs are caching - or rather they are a way of pushing the caching problem down onto a lower level. It's no different to 'clear the whole cache every time I change any content and store it all in memcached' - you're just substituting 'file-system' for 'memcached'. Of course - SSG do solve another problem - that of needing complex software running on your server - you can run SSGs locally or on a c…

> It's no different to 'clear the whole cache every time I change any content and store it all in memcached' - you're just substituting 'file-system' for 'memcached' There's no reason why the SSG needs to rebuild the entire site if you've only changed one thing.

True but my point still stands - some caches are dumb and some are smart. Some SSGs rebuild everything and some can figure out what needs to be rebuilt.
Post reply on HN