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

31–40 of 100 posts

Re: Static site generators focus on the wrong thing

#31

Post by VeejayRampay »

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…

Not necessarily so. More and more, we're seeing rich-content in-browser website builders which allow customers to have their lunch and eat it. You get to customize and modify your page (optionally with WYSIWYG) online, publish it on the fly and have it generated and stored in cache somewhere in the blink of an eye. Just today, two web applications doing just that have hit the home page of HN.

It doesn't have to be either/or and I don't think the market really "oscillates" in that regard, in my opinion it will eventually provide users the best of both worlds (and maybe already does), at least for more or less static websites.

Re: Static site generators focus on the wrong thing

#32

Post by callahad »

podman wrote: post #6

I think the usefulness of a SSG really depends on your goals. If your goal is simply to publish a blog, perhaps a SSG is not the right solution for you. SSGs are interesting because they have zero external dependences. I can just deploy my blog to Amazon S3, use CloudFront if I so choose, and never have to worry about scalability or how much traffic my blog can handle. To me, that is more important than the perceived…

> SSGs are interesting because they have zero external dependences.

Not necessarily. In most cases, they simply move the external dependencies from the server side to the client side.

Re: Static site generators focus on the wrong thing

#33

Post by resu_nimda »

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

What definition of "blogging" deals with ownership? Seems more like a personal issue with Medium on your end (which may even be unfounded?).

Re: Static site generators focus on the wrong thing

#34

Post by jacquesm »

spatten wrote: post #19

If your jekyll generation time is getting too large, you can limit the number of posts it generates like this: jekyll --limit_posts 3 It makes your site feel like new again :) I made this into a rake task which I blogged about here: http://scottpatten.ca/2011/11/speeding-up-jekyll-generation....

I looked at your blog post but it leaves some questions.

Does this also update 'latest posts' boxes and tag clouds on all the other pages?

What about the homepage?

(I used OctoPress, not Jekyll but I suspect there is a way in there to use this same trick)

Re: Static site generators focus on the wrong thing

#35

Post by andybak »

paulyg wrote: post #25
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 k…

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 centralized server - but that's not what is being discussed here.

Re: Static site generators focus on the wrong thing

#36

Post by rschuetzler »

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 blog regularly." Then a month later I still haven't posted anything. I enjoy blogging with Jekyll. I like writing my posts in Markdown, and I have no problem with the "git commit, push cycle." I just don't blog that often, and so far no platform I have found has changed that fact.

Re: Static site generators focus on the wrong thing

#37

Post by fideloper »

I'm not even sure about the analytics part being important, both because (to me, personally) the only interesting metrics on my blog are really "who shares my content where" and "are people reading my content". So, Google Analytics and done for me.

My blog isn't my business, although I certainly use content (blogs, newsletters, eBooks) as part of my "personal brand".

Re: Static site generators focus on the wrong thing

#38

Post by 0xdeadbeefbabe »

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…

Speaking of swinging pendulums in content management systems and wrong things, don't you ever get sick of http(s)? Http gets it wrong in many ways too, but I don't hear much about alternatives.

Re: Static site generators focus on the wrong thing

#39

Post by syntern »

dreamfactory2 wrote: post #22
joshcrews wrote: post #12

Earlier quoted context omitted.

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…

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 publish may be important for you.

Re: Static site generators focus on the wrong thing

#40

Post by Jweb_Guru »

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.

That isn't true by default. Django will cache queries the first time they're executed for a particular request, but not in general for all requests. You can opt-in to caching pages thereafter in something like memcached, but that would be extremely questionable default behavior and a great way to cause consistency bugs.
Post reply on HN