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

51–60 of 100 posts

Re: Static site generators focus on the wrong thing

#51

Post by sitkack »

spatten wrote: post #21

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…

We are conflating things between the UI we want to add content and how we want it served. I'd love to be able to edit locally in my own markup and push to a server dynamically. Bring back frontpage extensions for Markdown.

Re: Static site generators focus on the wrong thing

#52

Post by diminish »

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…

dynamic with caching (e.g. Varnish) is like static from security and response time perspective..but static has the advantage of local distributed fronts (cloudfront)... If we think, 99% of all blogs will be read less than 1000 times per day, the performance consideration does not matter.

Re: Static site generators focus on the wrong thing

#53

Post by jacquesm »

diminish wrote: post #52
jacquesm wrote: post #23

Earlier quoted context omitted.

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…

dynamic with caching (e.g. Varnish) is like static from security and response time perspective..but static has the advantage of local distributed fronts (cloudfront)... If we think, 99% of all blogs will be read less than 1000 times per day, the performance consideration does not matter.

I don't agree at all that 'dynamic with caching' is like static from a security perspective.

It's very easy to bust the cache (simply affix a random bit of nonsense to the end of the urls) and force dynamic execution of every request you make, opening you up to all the security issues that a direct dynamic front-end would give.

Re: Static site generators focus on the wrong thing

#54

Post by jacquesm »

design-of-homes wrote: post #48
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 moved my blog from Wordpress to a static site but I'm actually thinking of returning to Wordpress. Wordpress gives you comments, RSS feeds, search, categorisation and mailing list subscriptions out of the box. I'm missing those features in my static site. I don't want to outsource comments to Disqus. And there are caching techniques you can use to speed up Wordpress. I'm guessing most of the static site generators…

Static can give you RSS feeds, and most of the other bits & pieces can be outsourced these days to parties that specialize in exactly that.

Re: Static site generators focus on the wrong thing

#55

Post by sitkack »

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?

Re: Static site generators focus on the wrong thing

#56

Post by pdonis »

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…

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

Re: Static site generators focus on the wrong thing

#57

Post by pdonis »

jimktrains2 wrote: post #20
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'm working on a new version of Gus[0] that will be able to figure out only what needs to be rebuilt and rebuild it. Another feature for the (not to distant?) future will be generating a TF-IDF index in javascript so that a client-side search functionality could be introduced. I also find Gus to have a pretty low bar to publishing. I write in markdown/textile/reStructuredText, build, and rsync. Granted I haven't used…

> figure out only what needs to be rebuilt and rebuild it.

I thought a number of SSGs already did this.

Re: Static site generators focus on the wrong thing

#58

Post by pdonis »

andybak wrote: post #35
paulyg wrote: post #25

Earlier quoted context omitted.

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

Re: Static site generators focus on the wrong thing

#59

Post by pdonis »

swanson wrote: post #2

It partially depends on how you choose to deploy. If you are compiling your site locally and then pushing the static HTML to a server, you might experience some delay in generating the site. If you use GitHub pages, you just git push and the changes show up almost instantly. I've never run into the case where I felt like it took too long to go from my git push to seeing the post live in the browser - by the time I sw…

> The main appeal of a SSG to me is that you can focus solely on the content

Can't upvote this enough. I want my blogging tools to just get out of my way. (I ended up writing my own for that reason, because none of the ones I tried did it well enough: https://github.com/pdonis/simpleblog3 .)

Re: Static site generators focus on the wrong thing

#60

Post by pdonis »

scott_karana wrote: post #49
geekam wrote: post #3

I use Pelican[1] (Python) SSG and they are adding (have added?) a feature to skip articles that have not been touched. That makes compilation really fast. [1] https://github.com/getpelican/pelican

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

Post reply on HN