Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Static or Go Home

queue.acm.org

Post reply on HN
Print view View original

11–20 of 106 posts

Re: Go Static or Go Home

#11

Post by chriswarbo »

buro9 wrote: post #6

I'd love to see how different people solve the highly dynamic plus static problem. This usually boils down to the shopping cart and checkout example... you can always attack the checkout process as it is a unique, dynamic part of the process that no web store wishes to ever be unavailable. How does one "go static" with web applications that by necessity involve interactions with datastores?

Many dynamic things can be accomplished client-side these days. I see no problem with that, as long as it degrades gracefully to some default fallback.

In other cases, it's probably best to have each stateful system as an isolated component. For example, having a dynamic checkout doesn't require the news section to be dynamic. In fact, if you can isolate components like your checkout, you may be able to have someone else manage it for you. For example, at a previous job we used FoxyCart to deal with online checkouts; we just embedded specially-crafted URLs into our pages (although those pages were still running in Drupal!).

Re: Go Static or Go Home

#12

Post by chriswarbo »

Arcanum-XIII wrote: post #10
buro9 wrote: post #6

I'd love to see how different people solve the highly dynamic plus static problem. This usually boils down to the shopping cart and checkout example... you can always attack the checkout process as it is a unique, dynamic part of the process that no web store wishes to ever be unavailable. How does one "go static" with web applications that by necessity involve interactions with datastores?

The idea is not that everything need to be static - some contents are by nature updated too fast, or too often, to be static. Still, there's lot of page that could be pre generated since the content of the datastore itself is not evolving a lot. Most blog could use a static blog generator for example, with the comment being the only dynamic part - and a lot of cms page too ! Pre baking stuff is so much easier, faster…

True. My personal site is static (generated with Hakyll), and uses Disqus for comments (only because I haven't yet seen a simple, self-hosted alternative which has been battle-tested).

Re: Go Static or Go Home

#13

Post by netaustin »

High traffic and high volume sites driven by CMSes, like newspapers, tv stations, etc., largely cannot rely on static files to deliver their content. Rather, they use caching layers for speed and security. There are two better ways to improve security for sites like these, which are highly targeted and poor candidates for static sites:

1) Use a headless CMS. WordPress on the backend that provides and API which is consumed by a Node app, for example.

2) Shift any user-facing dynamic feature off the CMS. Commenting, login, subscription management, etc., can be handled by purpose-built apps that tie into the CMS-driven site via Javascript, preserving the security and cacheability of the CMS.

That's not to say that it's impossible to drive a large-scale news site with static files. I believe CNN does exactly that with their in-house CMS. But no open-source CMS that generates static files is powerful enough to use in a newsroom context, or popular enough to gain traction.

Re: Go Static or Go Home

#14

Post by andrewstuart2 »

A castle with no gate is also more secure. And kind of useless for its inhabitants. Like being under siege all the time.

My point being, sure you can get a more secure `something` by making it more and more static, but you'll probably cripple it somehow.

It's simply a balance you have to find for your use case.

Re: Go Static or Go Home

#15

Post by semperfaux »

netaustin wrote: post #13

High traffic and high volume sites driven by CMSes, like newspapers, tv stations, etc., largely cannot rely on static files to deliver their content. Rather, they use caching layers for speed and security. There are two better ways to improve security for sites like these, which are highly targeted and poor candidates for static sites: 1) Use a headless CMS. WordPress on the backend that provides and API which is con…

Nice to see your input here, and relevant. Granted, it's no Wonderfile, but then what is? ;)

Re: Go Static or Go Home

#16

Post by rimantas »

andrewstuart2 wrote: post #14

A castle with no gate is also more secure. And kind of useless for its inhabitants. Like being under siege all the time. My point being, sure you can get a more secure `something` by making it more and more static, but you'll probably cripple it somehow. It's simply a balance you have to find for your use case.

OTOH I'd say currently balance is heavily skewed to needless dynamism. You cannot get some trivial page without JS enabled and god only knows what's going on on the server.

Re: Go Static or Go Home

#17

Post by jamiesonbecker »

netaustin wrote: post #13

High traffic and high volume sites driven by CMSes, like newspapers, tv stations, etc., largely cannot rely on static files to deliver their content. Rather, they use caching layers for speed and security. There are two better ways to improve security for sites like these, which are highly targeted and poor candidates for static sites: 1) Use a headless CMS. WordPress on the backend that provides and API which is con…

It's simply a matter of inversion. Is the page generation and publication performed upon each change (by editors/authors/etc) or upon each access? Obviously, the former is much more efficient, even for frequent changes, and even across millions of data points. (Just ask Twitter).

Just because we don't really have common, enterprise-grade authoring tools for non-technical people that publish static sites anymore doesn't mean that it's not the better way.

Re: Go Static or Go Home

#18

Post by normloman »

I'm not concerned if a web app or a shopping cart is dynamic. But I see dynamic blogs all the time. Blogs with no comment system, or one that's used infrequently. What's the point of making that dynamic?

While I'm on the subject, can anyone tell me the reasoning behind loading blog content with javascript? I hate when I visit a blog with no script turn on, and get greeted by a blank template. Why does it need javascript to grab the page content?

Re: Go Static or Go Home

#19

Post by burke »

icebraining wrote: post #8
bikamonki wrote: post #3

I've been an evangelist of static sites for a while. With over 15 yrs of experience doing sites I started in static and saw the "dynamic movement" born and grow (at some point I even programmed my own DCMS!); in most cases the motivation to install a DCMS was that the client wanted to update content in-house instead of paying a webmaster (a sound business idea?) but the reality is that even when using a dead simple D…

The best mix may be a (hosted) dynamic editor that generates and deploys the static site. Have you considered this solution? It probably won't eliminate the need for a webmaster, but it should help reduce the requests for small changes while keeping the benefits of the static site.

I think I tried a blog engine once that did this. Maybe it was https://movabletype.org/ ? In any case, I really wish more people/tools employed this strategy.

Re: Go Static or Go Home

#20

Post by jkot »

andrewstuart2 wrote: post #14

A castle with no gate is also more secure. And kind of useless for its inhabitants. Like being under siege all the time. My point being, sure you can get a more secure `something` by making it more and more static, but you'll probably cripple it somehow. It's simply a balance you have to find for your use case.

There are castles with no gates.

I think problem is that current dynamic websites are sort of crippled already. Right now even simple shopping app requires UI based on HTML + web. Not a chance to use command line, some automated devices etc... In future we might see radically simplified protocols/webservices for more universal access.

Post reply on HN