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

61–70 of 100 posts

Re: Static site generators focus on the wrong thing

#61

Post by pdonis »

prezjordan wrote: post #14
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.…

I invite you to glance over the Medium Terms of Service. "You own the rights to the content you post on Medium." https://medium.com/policy/9db0094a1e0f#0fae

But you don't control how it's published:

"However, by posting or transferring content to Medium, you give us permission to use your content solely to do the things we need to do to provide Medium Services, including, without limitation, storing, displaying, reproducing, and distributing your content. This may include promoting your content with partner companies or services for broader broadcast, distribution, or publication."

(They do say they won't sell your content to third parties without your consent, which is good.)

And you don't control if and when the terms of service change.

Re: Static site generators focus on the wrong thing

#62

Post by ojilles »

krat0sprakhar wrote: post #45
falcolas wrote: post #26

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`…

Can't agree with this more. All you need is a simple rakefile[0] that does it for you. I have something like this for myself - prakhar1989.github.com git/master* $ rake rake default # List tasks rake draft # Create a new draft in ./_drafts rake post # Create a new post in ./_posts rake preview # Live Preview (use mode=drafts for drafts) rake publish # Push to github [0] - https://github.com/prakhar1989/prakhar1989.gi…

I have the same, with one addition (that would be running at the end of your 'publish' step): a 47-line bash script that will spider the whole site to find any internal 404 links.

https://github.com/ojilles/jilles.net/blob/master/_bin/wget-...

(Poorly implemented but works for me)

Re: Static site generators focus on the wrong thing

#63

Post by city41 »

I feel SSGs solved exactly the correct problem: enabling storing posts in version control, using whatever editor you prefer to write them, and a very quick feedback loop through a live preview. This enables much more elaborate posts to be written. I recently wrote a long article on JavaScript promises[1] that I can't even imagine trying to tackle in say WordPress. I use Wintersmith[2] for my blog and it was a key factor in creating such a long post

[1]http://mattgreer.org/articles/promises-in-wicked-detail/

[2]http://wintersmith.io/

Re: Static site generators focus on the wrong thing

#64

Post by jostylr »

zzzeek wrote: post #41

you can build a software service that allows one to maintain a static site in a git repo, which is then published to a host somewhere. the service can go as far as having you input the location of your git repo anywhere in the world, and the location of your hosting, whether it be an S3 bucket, rsync or FTP host, and it can then provide ordinary blog edit / workflow tools which use the git repo as persistence and the…

I have this idea too. I call it WriteWeb and I am focusing on git to s3.

My thought is to write a book and sell that. It would be aimed at those who want to create content-rich websites (less blogs, more lasting and organized). So the middle man server is just a bit of quick glue and easily replaced/localized.

The goal is to help people get their stories out there without a lot of irrelevant technical choices. Just start writing content and the system gets it out there.

I also like the idea of version control, issues, and wiki planning the github gives. And with prose.io, editing markdown files directly in a github repo is very pleasant.

Re: Static site generators focus on the wrong thing

#65

Post by fdik »

I wrote my own one, and am blogging with it. And no, it's not “focusing on the wrong thing” – it's focusing on the totally right thing, which is doing exactly what I need.

And it's 822 LOC, so it's easy to write, easy to handle. No big issues, no PHP security hole, no Wordpress monsters to administrate. Another 508 LOC give users comments with Markdown using Djangoproject.

And, last but not least: I prefer writing my blog articles partly automated using vim. YMMV.

http://blog.fdik.org

But hey, if you don't like it: just write your own one.

Re: Static site generators focus on the wrong thing

#66

Post by scott_karana »

pdonis wrote: post #60
scott_karana wrote: post #49

Earlier quoted context omitted.

I appreciate that they have that feature, but haven't makefiles had the same feature since the late 1970s? I love the idea of a static site generator, but they're really, really reinventing the wheel...

> haven't makefiles had the same feature since the late 1970s? Sure, if you're willing to use make as your SSG. :-)

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

Re: Static site generators focus on the wrong thing

#67

Post by pdonis »

scott_karana wrote: post #66
pdonis wrote: post #60

Earlier quoted context omitted.

> haven't makefiles had the same feature since the late 1970s? Sure, if you're willing to use make as your SSG. :-)

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 those. In other words, suppose I make a change on machine A, re-generate the site, then push; then I pull from machine B. Make on machine B may not be able to tell that the site was re-generated, because the file timestamps are not preserved by the push/pull, so machine B is seeing different ones than machine A did.

Re: Static site generators focus on the wrong thing

#68

Post by marcosdumay »

sitkack wrote: post #55
rschuetzler wrote: post #36

I think this post missed the mark by claiming that Hakyll blogs aren't updated because it's Hakyll, and therefore hard. I think the type of person who will set up a Hakyll blog just may not be the kind of person who will blog frequently. I have set up a Jekyll blog, Wordpress, Ghost, and now I'm using Octopress. Each time I set up a new blog I think "Ya, this new platform is great. It will be exactly what I need to b…

I think doing some sociology studies around computer languages would be really interesting. Do people that use Haskell self select for doing new things?

People that like to try new things are certainly more likely than others to try a language created as late as the 90's that never had a marketing budget.

Re: Static site generators focus on the wrong thing

#69

Post by drzaiusapelord »

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 to 20 different vendors and whatever hackey scripting to keep everything talking to everything else. Even end users could see how rickety the whole production was. There's something to be said about a central monolithic structure with plugins vs a collection of scripts and html.

Deployment was usually frustrating and broke in non-obvious ways. Deploying a non-trivial Collage site was like gambling.

The experience of switching to Drupal was like night and day. Any bullshit concerns about performance were taken care of with just Varnish or a caching plugin. I can't imagine going back to an SSG and an ecosystem of disparate webapps to make it a usable website. Heck, even my side projects with Wordpress are like switching from a Model T to a Tesla compared to dealing with an SSG. Maybe SSG's are fun for sites with low requirements, but once you have a non-trivial set of features to support, then you're doing extra work and experiencing extra pain that a CMS wouldn't give you.

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.

Re: Static site generators focus on the wrong thing

#70

Post by dreamfactory2 »

syntern wrote: post #39
dreamfactory2 wrote: post #22

Earlier quoted context omitted.

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…

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

The argument is sometimes made that this doesn't apply to simple blogging and that SSGs of course aren't aimed at pros, but I can say with some certainty that the segment of bloggers who can and want to publish with Git etc is infinitesimally small and quite possibly 100% represented on HN :) That's fine and great if it works for your use case but it pains me a bit to see people re-discovering the very old and disproven model that SSG represents. It's a) highly niche and b) counter to many current and new requirements in content publishing.

The main argument for it is performance but I don't see how it improves on Varnish - albeit w cache warming - and tellingly edge cases of cache warming are getting replayed in SSG increasing complexity. In fact dynamic systems often forgo cache warming as not worth the result much of the time (and can do it selectively), but you don't get that control at all in an SSG system.

Post reply on HN