Live data from Hacker News

Static Website Generators Are the Next Big Thing

smashingmagazine.com

41–50 of 187 posts

Re: Static Website Generators Are the Next Big Thing

#41
I can't wait for ghost's API.

I've been following their repo for a while, hopefully by next year they'll be far along for it to be usable.

Ghost has an excellent editor and it would be awesome to have a static site built in any way you like that links straight to your blog posts via API calls.

They have a trello card that mentions it https://trello.com/c/QEdjRlgK/67-open-public-api-via-oauth-a...

and are working on it as we speak :) https://github.com/TryGhost/Ghost/issues/4004

I know there's a wordpress API as well but I find wordpress too bloated IMO.

Re: Static Website Generators Are the Next Big Thing

#42
post #20

... Next Big Thing For Minimally Dynamic Sites If your content doesn't change frequently and/or the costs of regenerating the static content is minimized for you, great. At what point do we see static sites take a fair share of the top-X-trafficked sites? Top 100? 1000? 1,000,000? This is probably great for a small corp's info site... but then the client asks for a contact form or members/admin secured area, and ther…

I tend to think of it in terms of ratio. Of course, very few sites are 100% static, but a site with thousands of static pages and a contact form that posts to a php script is still a 'static site' in my book. You could also define it on a request method basis, since it doesn't make sense to POST to a plain html file.

Re: Static Website Generators Are the Next Big Thing

#45
I think the simplest static site generator is a command that visits all of your routes and saves the response html into a `build/` folder.

That way you can use whichever framework/stack/templating/database you're already familiar and productive with, and in the end you're just deploying a static build folder from localhost.

I started doing this when it came down to hacking Jekyll to implement something that's trivial to do in a microframework, so I went with microframework + page caching. I do the build and deploy with a gulp task that I'd like to generalize into a gulp module.

Re: Static Website Generators Are the Next Big Thing

#46

Every time static generation rears its head, I'm reminded of Yahoo!'s ... unique... take. Back in 2006 when I worked for Yahoo!, and they had a CMS / template management system called Jake that statically generated templates for the PHP-based frontend servers to evaluate at request time. The idea was that you put as much of your logic as possible into the template generation layer, leaving the request-time logic to h…

this is the first story I've heard that explains why Yahoo's navigation is so horrible and why your logged in state on your yahoo account doesn't follow you to different yahoo sites (business, mail, etc.)

Re: Static Website Generators Are the Next Big Thing

#47
To an extent I agree I think we are just getting better at recognizing the security and performance optimizations that are staring us in the face when content doesn't change rather than having complex websites completely static as static site gens do. I think we will see an increase in static elements mixed with dynamic elements in a more comprehensive way.

------

I host 10s of more or less static sites (Contact forms being the most dynamic elements) which are generated on the spot from one PHP (laravel) installation.

Anyone know the best way to cache the html/css statically to serve?

Re: Static Website Generators Are the Next Big Thing

#48

You know what I've always wanted, but my searches have led me to believe that it (inexplicably) doesn't exist? I want a simple site generator. I don't want markdown, I don't want a fancy templating engine. I want some simple templating system that takes in normal HTML and generates pages from simple templates I define. I want to shove in some arbitrary HTML and have it spit out a site using some base templates. To th…

Can you clarify what you mean by "simple templates"?

It may not be along the lines of what you're hoping for (it may not be simple enough), but I've found Stasis[1] to be a powerful tool for static site generation.

You can write plain old HTML pages and/or fragments, with your desired level or genericity, and then run them through a set of transformations[2] to fill in content, set attributes (e.g. classes, styles, whatever), un/wrap elements, and so on.

[1] https://github.com/magnars/stasis

[2] https://github.com/cgrand/enlive

Re: Static Website Generators Are the Next Big Thing

#49
I'd love to use static site generators for my client work but they usually ask for features like e-commerce that completely rule out it's use.

Usability is also an issue. Wordpress is a far more friendly environment for them to make changes or create a new post than creating a text file with specific formatting and running a script.

Re: Static Website Generators Are the Next Big Thing

#50
post #6

Ok, "static" here means no RDBMS-backed website. But you can still use statically generated JSON resources from a db once off. These resources can then be "filtered" and "combined" without the need for databases (not using the words JOIN or WHERE carefully). Sounds like a great idea to overcome the need to obsess about connection multi-plexing.

"Statically generated JSON resources" implies client-side rendering, and I suspect you'd find some disagreement over whether that's really static. If there's only one such resource per page, then maybe, though you'd still be losing some advantages wrt caching. If the JS running on the client has to fetch many such resources and stitch them together, then it's functionally equivalent to a standard dynamic website and…

> "Statically generated JSON resources" implies client-side rendering, and I suspect you'd find some disagreement over whether that's really static.

> If the JS running on the client has to fetch many such resources and stitch them together, then it's functionally equivalent to a standard dynamic website and shares many of its drawbacks.

Whilst you're talking about extremes (e.g. rendering a page using Javascript), it seems to me that the most abundant use for AJAX-style approaches on static sites is when there are a few "value added" parts which rely on a DB. For example, a static blog with Disqus comments.

As other commenters have noted, the ability to push bits and pieces of functionality into JS has tipped the balance in many cases, e.g. from "if you want comments, it'll all have to be done in PHP" to "there's no point rendering this on demand, we can do the dynamic bits in JS".

Post reply on HN