Go Static or Go Home
queue.acm.org
Go Static or Go Home
1–10 of 106 posts
Re: Go Static or Go Home
#2Interesting. Also if you are interested read http://programmers.stackexchange.com/questions/206558/why-do...
Re: Go Static or Go Home
#3I'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 DCMS clients always find it difficult to run it and still contact the webmaster. Furthermore, the vast majority of sites are seldom or never updated so having the 'kick me' sign in those cases is nosense. I guess a strong selling point of DCMS that made us all buy in even knowing that it was a bad idea where themes and plugins! So many of them, so nice looking, cross-browser tested and so easy to install. Clients where über happy with the end product.
So a couple of years ago I decided to do static sites for ALL my clients (there may be dynamic components that I normally implement with a back-end data service). I still have a few dozen sites and web apps with DCMS but the goal is to migrate them as well.
Re: Go Static or Go Home
#4There was a submission briefly on the front page here where someone was proclaiming security by not using c/c++ for projects, yet, they left their blog comments and site wide open for some idiots who have already tried to post silly comments with JS popups.
I guess maybe we need people to use static sites, like trainer wheels on bikes, until they become more security concious.
Re: Go Static or Go Home
#5Well this certainly looks familiar:
"At work, our public-facing website is completely static. There is a CMS (Content Management System), but it's extremely technical—it requires the use of UNIX text editors, a version control utility called GIT, and knowledge of a language called Markdown. This frustrates our non-technical employees, including some members of our business team, but it means that our web server runs no code to render a web object—it just returns files that were pre-generated using the "ikiwiki" CMS."
To quote Linus out of context:
"Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them. To me, security is important. But it's no less important than everything else that is also important!"
Almost by definition, security people never are the ones to make sensible trade-offs. Something is either secure or it isn't. There may be environments where increasing security up to the point where it is "almost preventing you getting any work done" is justified, but don't be surprised if the other 99% ignore you.
Re: Go Static or Go Home
#6I'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?
Re: Go Static or Go Home
#7Interesting. Also if you are interested read http://programmers.stackexchange.com/questions/206558/why-do...
Did you read the article? It's about static vs. dynamic site generation. It mentions eval() in a passing, but it's not about dynamic vs. static typing.
Re: Go Static or Go Home
#8I'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.
Re: Go Static or Go Home
#9There was a submission briefly on the front page here where someone was proclaiming security by not using c/c++ for projects, yet, they left their blog comments and site wide open for some idiots who have already tried to post silly comments with JS popups. I guess maybe we need people to use static sites, like trainer wheels on bikes, until they become more security concious.
Security is additive: the more precautions you take, the more secure you'll be. Avoiding C/C++ when safer, higher-level languages could be used is one example. Escaping Web site comments is another. Doing both is best, but either on its own is still better than neither.
Becoming "security concious"[sic] doesn't mean outgrowing best practices. If Bruce Schneier used "password" as his password, he wouldn't avoid getting attacked just because he knew it was a bad practice. Likewise, understanding the tradeoffs between static and dynamic Web sites doesn't make someone's dynamic site secure.
As the article points out, even a locked-down, well-tuned dynamic site with CAPTCHA-protected registration forms is orders of magnitude easier to bring down with DDoS attacks, since dynamic sites must perform more work per request, eg. to render "Hello CaptchaFarmUser99999" at the top of the page. If they don't need to perform more work per request, since all pages are always fully cached, then you've just re-invented static sites :)
Re: Go Static or Go Home
#10I'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, and cleaner.