[orestes910]

I'm still struggling to get on board with this. It seems to just favor speed above all else. I found the linked article at http://www.smashingmagazine.com/2015/11/modern-static-websit... to be a bit more helpful in pitching the case, but even so it seems like just pulling the complexity of dynamic sites into the build stage of the static ones all because writing efficient DB queries is "hard". For a companies front page, I can see the benefit of generating content once instead of for every client, but what happens when you need to present information beyond the generic? What happens when you need to show a user's order history? Let them change their password? Allow them to see the distance of that run?

I feel old and crotchety, but I just find it a bit strange that as we get more and more obsessed with data, this emerges; something that seems less that optimal for dealing with it. They make the comparison themselves, but it seems like reverting from "Web Applications" back to "Web Sites" and just filling it with API calls to actual Web Apps.

[bosdev]

To me the logic is simple: It's more efficient to build the site when its content changes (very infrequently) rather than when its viewed (very frequently). Yes various forms of caching can allow you to scale the dynamic model quite far, but scaling gets so much simpler when you move into the static world.

In answer to your questions, the general idea is you have a static site, and a powerful API. The power of the JavaScript engine in modern browsers allows you to build your entire application to run in the browser, sending asynchronous requests to your API as is required. You're essentially just removing the Python/PHP/etc. middleware layer many sites have traditionally had.

[jlg23]

> It seems to just favor speed above all else.

Yes, it seems to be all about speed. But there is one more thing that really convinced me already some 15 years ago to migrate a high profile site to static site generation: Security. The attack surface is reduced to your httpd.

PS: The site did not see too many changes and not many editors - hacking a solution in pmake and some perl for editor UI was done in half a day and everyone was happy, including the sys-admin (me, again) who only had to apply security fixes every 2 years.

PPS: Also, another important reason for some, though for me it was only an afterthought, if at all: Sending a static byte array is much, much more energy efficient than scheduling a meeting with your database for every request.

[exelius]

The "right" way to do this (edit: this is essentially assumed by the article, so I'm not contradicting it) is to build static sites and use JavaScript to pull in any dynamic information. You run data services that output JSON, then the JS on the page calls those data services and renders the views.

This still allows you to reap the benefits of static content (namely CDN distribution / caching) while still maintaining some dynamic content.

But basically, you do it this way to avoid pulling data that isn't user-specific from the database. It's far more efficient to build a header + page + footer once at build time than to have every client have to do that on access -- even if you have 100+ variations of your site that need to be compiled and updated on any change in the shared content. Storage and compute resource are trivially cheap if they don't scale exponentially with number of users.

Yeah, it's more work for your developers, but it saves your DBAs a LOT of work by reducing the volume of data served from the database. And at the end of the day, it's full-stack effort that counts -- I'd rather have my developers spend 2x the time to build a system than have my DBAs fighting fires because the site went down. With a static site, you can set it to read-only mode if the traffic gets to be too much, and the static content will be handled by the CDN (which can almost certainly handle any load).

[Albright]

Using JS to present data moves the work of generating the display of that data from the build process, as with "pure" static site generation, or from server-side code, as with a standard CMS, to the client, where it is most likely to fail in unpredictable ways due to variances in browser JS or CSS engines, network performance, browser extensions, etc, etc.

But given that the concept of progressive enhancement seems to have been completely lost on the latest generation of web developers, who cares, right?

[exelius]

Well, the key here is that any non-JSON data you pull from a URL should be static. That means it can be cached, and the client should only be pulling a small amount of data that varies based on their account.

I wouldn't write an interactive web application this way, but for sites that are mostly content the approach works fine. You still have to test on multiple browsers, and you still have to write code that handles the differences in browsers/engines/etc. But your servers are doing less work, and the content reaches the customer faster. It's still up to you to optimize your JS (though I guarantee most tracking cookies are taxing JS far more than rendering a few divs will).

[Albright]

> the content reaches the customer faster.

Does it? Is it really slower for your customers to download a server-generated page than for them to download a static page, (probably) download a JavaScript file embedded in the page, execute the JavaScript, then download and process server-generated JSON?

[exelius]

Considering they're likely also downloading JavaScript and executing it when using the server-generated page, yes. Let's not pretend it's possible to do everything on the server side. Just now instead of compiling the page in real time when it's accessed, we compile large parts of it long before the user requests it.

[desp]

> it seems like reverting from "Web Applications" back to "Web Sites"

I want to push back against this idea that "Web Applications" represent uniform forward momentum for the web, while "Web Sites" are somehow archaic. This seems to be a fairly common perception, but it strikes me as a false dichotomy.

Both are distinct and useful things. Static site generation isn't a good solution for interactive applications – conversely, React is a poor choice for building low-interactivity web pages.

EDIT: Improved blockquote formatting.

[tedkimble]

There's definitely a point at which an actual web app makes sense. But I think there's also a large category of websites that have been built as dynamic apps even though they’re updated sparingly and only require changes to a few items of content or data.

I recently launched Static Website Manager (https://www.staticwebsitemanager.com) to help bridge this gap between static and dynamic websites. Relevant to this discussion is our Form Responder tool, which provides an endpoint for your HTTP forms.

The cool thing is you can connect them to your Jekyll data files and then new form submission data will be committed (appended or set to a key) to that data file. New commits also trigger builds/deploys, resulting in a dynamically-updated static website. (They work across your branches, too, if you need to moderate submissions before merging with production.)

[sneak]

It looks awesome, and I've been thinking about building a tool just like this one around Jekyll myself.

The pricing is a bit steep - I would be fine with $15/mo/account but I have a half-dozen sites to manage and more all the time. Some of them are low enough traffic that $180/year isn't really justified.

Thoughts?

[tedkimble]

Thanks, and totally understandable. I'm still considering what to offer in a more affordable plan for these types of low-usage/low-traffic sites. Would you be opposed to a plan that limited based on usage (the number of commits, which our service triggers builds/deploys/etc...)?

[sneak]

Yeah, absolutely. I wouldn't need more than 50-100 all year across all my sites.

[fweespeech]

> For a companies front page, I can see the benefit of generating content once instead of for every client, but what happens when you need to present information beyond the generic? What happens when you need to show a user's order history? Let them change their password? Allow them to see the distance of that run?

Well if you can assume the user has javascript enabled, AJAX is an option.

I'm pretty sure they are talking about generating the majority of the site and filling the details in dynamically as needed.