10 ms·

Go Static or Go Home

123 points by fiber 12y ago

__Joker 12y ago
Interesting. Also if you are interested read http://programmers.stackexchange.com/questions/206558/why-does-the-us-government-disallow-dynamic-languages-for-secure-projects http://programmers.stackexchange.com/questions/206558/why-do...
- danieldk 12y ago
  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.
bikamonki 12y ago
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 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.
- icebraining 12y ago
  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.
  - bikamonki 12y ago
    Yes I agree, that is what I use now, in fact I have an additional layer: the static CMS generates JSON that in turn is fed to an front end MVC to render the pages. Assets are uploaded to AWS so I can use/reuse them. I am also serving sites directly from AWS S3 so there is no server to deal with at all. Everything dynamic can be done with SAAS/PAAS (comments, email, form collection, etc). Any static CMS that you recommend? I am using a (very limited) house blend for now, I call it Statico ;)
  - burke 12y ago
    I think I tried a blog engine once that did this. Maybe it was https://movabletype.org/ https://movabletype.org/ ? In any case, I really wish more people/tools employed this strategy.
    - bikamonki 12y ago
      I think more devs will adopt it when we have plugins and themes that can be installed with a click! So far I have been able to adapt HTML themes to a front-end MVC (Angular or Backbone) but it is a long manual process...
  - jeffreyrogers 12y ago
    I agree, this way seems the best. The reason people like WordPress so much is because it abstracts away everything except writing content. Users don't care how the site is served (and most nontechnical users won't even know).
icanblogshitz 12y ago
There 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.
- chriswarbo 12y ago
  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 :)
MrBuddyCasino 12y ago
Well 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.
buro9 12y ago
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?
- Arcanum-XIII 12y ago
  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.
  - chriswarbo 12y ago
    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).
    - oneeyedpigeon 12y ago
      I work on a statically generated site in which the comment form simply feeds back into the generation workflow. It's certainly not 'battle tested', but it has the advantage that a) we get to own the comments rather than giving them to someone else b) everyone can partake in the discussion c) much less demand on the client when rendering
- chriswarbo 12y ago
  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!).
netaustin 12y ago
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.
- semperfaux 12y ago
  Nice to see your input here, and relevant. Granted, it's no Wonderfile, but then what is? ;)
- jamiesonbecker 12y ago
  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.
  - Retric 12y ago
    Sure we do, it's called caching. There is a minimal difference between a webserver serving static pages and a caching server serving static content. When you get down to it caching is simply a more flexable approach to the classic (autoring tool) -> static webpage approach. In many ways the only difference is the authoring tool is a website not a stand alone program.
andrewstuart2 12y ago
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.
- rimantas 12y ago
  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.
- jkot 12y ago
  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.
  - Diederich 12y ago
    I hear what you're saying, but it doesn't have to be so. All of the web apps I make at work are all javascript in a page apps. But before I start doing any of that, I make a REST API. 100% of the interaction between javascript and the web server is REST. There are many reasons for this, but a key one is that it allows easy command-line or programatic interaction. Much easier than with traditional, server generated web apps.
    - sbilstein 12y ago
      Same here. Increasingly products I work on do almost no server side templating; frontend templates call REST services that I can test with curl, postman, or other tools.
      - tsax 12y ago
normloman 12y ago
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?
- andrewstuart2 12y ago
  One word: caching. The more resources you can cache fully (like the template) the fewer round trips you need to make and/or the shorter those round trips become. It's always the latency that slows us down (by definition), which is why even modern processors have sophisticated cache layers and branch prediction. The further from the CPU the resource is, the slower the interaction will be. This debate is interesting and a bit funny to me because it's very similar to the old dumb terminal vs personal computer debate. We've swung back to the mainframe, except now it's distributed and we call it the cloud. My prediction (take it or leave it) is that we'll soon be swung all the way back to dynamic client-side sites. And then eventually back to the quantum cloud (heh, "Electron Cloud"). Or something new and more powerful than whatever sits in our pocket or on our desk.
  - normloman 12y ago
    Thanks for answering my question. Would you mind clarifying it for me? If your blog has a reusable template, wouldn't the images, fonts, and stylesheets that are part of the template get cached on the user's computer, regardless of whether it was dynamic or static? Or are you talking about caching things serverside?
    - Xorlev 12y ago
      I think he means that you can cache the majority of the page (including the HTML template) and then substitute in just the data (usually coming from JSON). I don't buy that it's more efficient personally. I'd rather resend a lightweight page on every time then force the browser to download it all, load the JS, then build a page and have the browser draw that. It seems to me that single-page apps are great when you aren't leaving the page and have a lot of navigation, but overkill for a blog. I am rather interested in react+react-router though. That seems like the best of both worlds -- render serverside, then render deltas clientside.
k__ 12y ago
Also, in times of SPAs, LocalStorage, WebRTC, Parse and FireBase you can sprinkle your static web-sites with some dynamic functionality, when needed...
gizzlon 12y ago
Ok, I understand that there's reasons for using static pages, but I don't get the feeling this guy really understands what he's talking about. > Even if [..] and there's nothing like bash installed on the same computer as the web server Bash installed? Huh? Why Bash exactly? I feel mentioning jails or containers here would be more on point.. > This is because every DCMS page view involves running a few tiny bits of software on your web server, rather than just returning the contents of some files that were generated earlier. Sure, but guess how those pages are returned? By running code on the server.. It seems like hes real beef is with "dynamic" (vs staic) sites, but he keeps mentioning CMS's for some reasons (ike you can't can have "dynamic" sites witjout a cms) > The web server executes no code on behalf of a viewer until that viewer has logged in.. 1) Of course it does, 2) How do the site check your info without executing code? :) etc etc.. There's a case for static sites, but this post just confuses things.
- anth1y 12y ago
  > Ok, I understand that there's reasons for using static pages, but I don't get the feeling this guy really understands what he's talking about. I think he might know a little bit: http://en.wikipedia.org/wiki/Paul_Vixie http://en.wikipedia.org/wiki/Paul_Vixie
  - mordocai 12y ago
    None of the things on that wikipedia page makes me think he actually knows anything about web servers. Sure, he obviously should know about some of the things that make the internet work (BIND, cron, etc) but nothing on there has anything to do with making web sites. All of it is about the infrastructure. Either this article is filled with intentional hyperbole, or this guy doesn't know what he's talking about when it comes to serving web pages.
    - tptacek 12y ago
      Ordinarily I'd be bristling at a comment like this, but you are articulating some stuff --- a little rudely, but still --- that I believe about Vixie as well. I won't pretend not to have noticed and let you take all the heat. Paul Vixie's reputation among software security people is a little bit fraught.
StefanKarpinski 12y ago
"Little Johnny Tables". Um, yes, that was "Little Bobby Tables" [1]. Obviously not a big deal, but it seems emblematic of how sloppy this piece is. The article confuses – seemingly willfully, since Paul Vixie should know better – the concepts of dynamic language, dynamic page generation, lack of proper input hygiene, and various other orthogonal issues. The argument that dynamic languages are less secure depends an awful lot on the language – I don't think anyone is going to buy that C is more secure than Python. Haskell vs Python? Now that's a debate to be had. Certainly, websites that do no dynamic content generation are probably more secure – but then you're stuck with the Internet circa 1993. And of course, nobody is in favor not sanitizing inputs properly. [1] http://xkcd.com/327/ http://xkcd.com/327/
- yk 12y ago
  Calling any Turing complete language "more secure" is probably nonsense. It is possible to write secure applications in C, and it is possible to directly pipe attacker controlled input to a shell in Haskell.
  - StefanKarpinski 12y ago
    Sure, you can do dangerous stuff in any language, but it's much harder to write a secure C program than a secure Python or Haskell program.
  - tptacek 12y ago
    I know a total of zero working security researchers who think C is just as safe as Scala. The obvious flaw in your example: you can exec a program unsafely in both C and in Scala, but only in C can you do it accidentally simply by idiomatically copying a string from one place to another.
    - thegeomaster 12y ago
      FWIW, idiomatically copying a string in C is done using strncpy, and that doesn't introduce any RCE bugs. I would not in my right mind defend the premise that C is just as safe as Scala, but the truth is that sloppy programming can do harm in every language imaginable. It just becomes about damage control.
deleted 12y ago
[deleted]
erikb 12y ago
And there we have it. Security needs stability, stability decreases on a daily basis. We can't have that traditional kind of security. We need to move on to a more proactive way of thinking.
sre_ops 12y ago
Ah yes, Vixie, the guy who thought it was his customers that had to adapt to his "vision" rather than his vision had to adapt to customer needs.
qeorge 12y ago
Startup idea, free for the taking: create a service that "ossifies" dynamic websites into static HTML. (By ossify, I mean to take something dynamic and make it static). For example, that WordPress site you commissioned for a movie 3 years ago? Its a huge liability, but you don't have to take it offline - just ossify it. No one is updating that blog anymore! Under the hood, it would basically be a crawler, and the deliverable would be a zip file containing a 1-to-1, static copy of their website with all URLs still working. I suspect most folks here could whip up a shitty proof of concept in 48 hours. If someone does this, email me! I have a couple of potential clients for you (I'm a former consultant, with lots of WordPress sites in my history).
- j_baker 12y ago
  That's basically what the wayback machine does: https://archive.org/web/ https://archive.org/web/
  - qeorge 12y ago
    Yes! It would be like the Wayback machine as a service, but with some key differences: 1) The intention is that you replace your dynamic site with the static copy, but your visitors are none the wiser. All URLs are the same, as well as the content returned. Might require some .htaccess trickery. 2) It would have to preserve all the images, css, and other assets, some possibly hotlinked. (The Wayback Machine is not awesome at this, understandably)
- voyou 12y ago
  You can get pretty close to this, I think with: wget --mirror --convert-links http://site.example.com/ From the wget manual: --convert-links After the download is complete, convert the links in the document to make them suitable for local viewing. This affects not only the visible hyperlinks, but any part of the document that links to external content, such as embedded images, links to style sheets, hyperlinks to non-HTML content, etc. The links to files that have been downloaded by Wget will be changed to refer to the file they point to as a relative link. Example: if the downloaded file /foo/doc.html links to /bar/img.gif, also downloaded, then the link in doc.html will be modified to point to ../bar/img.gif. This kind of transformation works reliably for arbitrary combinations of directories.
faraazin 12y ago
Noob qn:how does custom search work on static sites? May not be the best approach, but a simple SQL query would do the trick for dynamic sites.
- juliangregorian 12y ago
  A simple SQL query is not a great solution even for dynamic sites that pull content from SQL databases. You have to protect against SQL injection and you usually will want fulltext indices for all the text fields to be searched. It's also going to be slow in the naive implementation for databases of any significant size. The better solution for both dynamic and static sites is to set up a search appliance like elasticsearch, solr, or algolia. You can use JS to query it and still be static on the server. If you do set up your own, remember to use a reverse proxy like nginx to avoid exposing elasticsearch directly to the internet.
- kstrauser 12y ago
  I used Google Site Search (https://www.google.com/work/search/products/gss.html https://www.google.com/work/search/products/gss.html), which starts at $100 per year. Outsource all that infrastructure to a company who's good at it, park your static HTML on a CDN, and enjoy fast worldwide access with searchable content. That's not the only option, but it's a boss-friendly company to name drop. Most organizations wouldn't blink at the price, especially if it means you can move off dynamic hosting to far cheaper static hosting.
ivanhoe 12y ago
Static site is more secure only if the server is also up-to-date and setup properly to trim down all unnecessary options. Putting static site on a general purpose apache installation that will happily serve PHP and CGIs from user home dirs is not such a big security improvement.
programminggeek 12y ago
I'm going to say that the bigger problem in dynamic languages isn't that they are dynamic. It's that they have weak, nonexistant, or very undeveloped mechanisms for creating strong communication protocols that you can depend on as safe or reliable. Take the classic case of SQL injection. You have string input into your system that turns into string input into a SQL query that turns into string input to a database. That is dangerous because if you don't check on what the input string contains, it might contain nothing, or a semicolon, or it might not be a string at all! We understand that putting a string direct into a SQL statement is dangerous at this point, but we have yet to fix its root cause - nonexistant protocols or boundaries in most code we write. What a static language changes in that regard is compiler checked type signatures on your code. That generally stops you from say passing an Integer into something that needs a String. That solves a certain class of problems for sure, and the complier does it for you every time you change your code, so there is a convenience there. What static typing doesn't give you is actual data correctness. Things like buffer overflows or SQL injection can still happen with static typing. You could use a language like Scala or Haskell to have stronger/more complex types that would have more distinct notion of value correctness and at that point the complier would be doing most of the work to ensure your program is correct. Leaning on a type system in that regard is basically turning your types into the protocols that determine correctness in your system. It is also possible to lean on stronger protocols that check messages in a dynamic languages to achieve largely the same thing. In the end, to write safe, high quality software, you need to define the communication protocols between methods/functions/routines/services and enforce them much as you would with an externally facing REST api. The difference between a dynamic system with dynamic protocol checking vs a static system with compiler type checking is the mechanism you are using to enforce the protocol and how easy it is to interact with it. Dynamic systems might be easier to interface with externally because you don't have to understand a complex type, just pass a Hash/Dictionary sort of like a JSON API, vs a static system where you need to use the right types and so on, similar to a SOAP/WSDL API. Performance is also a consideration, but really when you compare static vs dynamic, it is important to understand that at the end of the day you can write Ruby/Python/PHP that is functionally equivalent to C/C++/Java. They are all ultimately going to be able to do the same kinds of things. The tradeoff is in how they solve the problem and how well that fits with the team writing the software.

123 points by fiber 12y ago

Interesting. Also if you are interested read http://programmers.stackexchange.com/questions/206558/why-does-the-us-government-disallow-dynamic-languages-for-secure-projects http://programmers.stackexchange.com/questions/206558/why-do...

danieldk 12y ago
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.

bikamonki 12y ago

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

icebraining 12y ago
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.
- bikamonki 12y ago
  Yes I agree, that is what I use now, in fact I have an additional layer: the static CMS generates JSON that in turn is fed to an front end MVC to render the pages. Assets are uploaded to AWS so I can use/reuse them. I am also serving sites directly from AWS S3 so there is no server to deal with at all. Everything dynamic can be done with SAAS/PAAS (comments, email, form collection, etc). Any static CMS that you recommend? I am using a (very limited) house blend for now, I call it Statico ;)
- burke 12y ago
  I think I tried a blog engine once that did this. Maybe it was https://movabletype.org/ https://movabletype.org/ ? In any case, I really wish more people/tools employed this strategy.
  - bikamonki 12y ago
    I think more devs will adopt it when we have plugins and themes that can be installed with a click! So far I have been able to adapt HTML themes to a front-end MVC (Angular or Backbone) but it is a long manual process...
- jeffreyrogers 12y ago
  I agree, this way seems the best. The reason people like WordPress so much is because it abstracts away everything except writing content. Users don't care how the site is served (and most nontechnical users won't even know).

icanblogshitz 12y ago

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

chriswarbo 12y ago
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 :)

MrBuddyCasino 12y ago

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

buro9 12y ago

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?

Arcanum-XIII 12y ago
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.
- chriswarbo 12y ago
  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).
  - oneeyedpigeon 12y ago
    I work on a statically generated site in which the comment form simply feeds back into the generation workflow. It's certainly not 'battle tested', but it has the advantage that a) we get to own the comments rather than giving them to someone else b) everyone can partake in the discussion c) much less demand on the client when rendering
chriswarbo 12y ago
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!).

netaustin 12y ago

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.

semperfaux 12y ago
Nice to see your input here, and relevant. Granted, it's no Wonderfile, but then what is? ;)
jamiesonbecker 12y ago
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.
- Retric 12y ago
  Sure we do, it's called caching. There is a minimal difference between a webserver serving static pages and a caching server serving static content. When you get down to it caching is simply a more flexable approach to the classic (autoring tool) -> static webpage approach. In many ways the only difference is the authoring tool is a website not a stand alone program.

andrewstuart2 12y ago

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.

rimantas 12y ago
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.
jkot 12y ago
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.
- Diederich 12y ago
  I hear what you're saying, but it doesn't have to be so. All of the web apps I make at work are all javascript in a page apps. But before I start doing any of that, I make a REST API. 100% of the interaction between javascript and the web server is REST. There are many reasons for this, but a key one is that it allows easy command-line or programatic interaction. Much easier than with traditional, server generated web apps.
  - sbilstein 12y ago
    Same here. Increasingly products I work on do almost no server side templating; frontend templates call REST services that I can test with curl, postman, or other tools.
    - tsax 12y ago

normloman 12y ago

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?

andrewstuart2 12y ago
One word: caching. The more resources you can cache fully (like the template) the fewer round trips you need to make and/or the shorter those round trips become. It's always the latency that slows us down (by definition), which is why even modern processors have sophisticated cache layers and branch prediction. The further from the CPU the resource is, the slower the interaction will be. This debate is interesting and a bit funny to me because it's very similar to the old dumb terminal vs personal computer debate. We've swung back to the mainframe, except now it's distributed and we call it the cloud. My prediction (take it or leave it) is that we'll soon be swung all the way back to dynamic client-side sites. And then eventually back to the quantum cloud (heh, "Electron Cloud"). Or something new and more powerful than whatever sits in our pocket or on our desk.
- normloman 12y ago
  Thanks for answering my question. Would you mind clarifying it for me? If your blog has a reusable template, wouldn't the images, fonts, and stylesheets that are part of the template get cached on the user's computer, regardless of whether it was dynamic or static? Or are you talking about caching things serverside?
  - Xorlev 12y ago
    I think he means that you can cache the majority of the page (including the HTML template) and then substitute in just the data (usually coming from JSON). I don't buy that it's more efficient personally. I'd rather resend a lightweight page on every time then force the browser to download it all, load the JS, then build a page and have the browser draw that. It seems to me that single-page apps are great when you aren't leaving the page and have a lot of navigation, but overkill for a blog. I am rather interested in react+react-router though. That seems like the best of both worlds -- render serverside, then render deltas clientside.

k__ 12y ago

Also, in times of SPAs, LocalStorage, WebRTC, Parse and FireBase you can sprinkle your static web-sites with some dynamic functionality, when needed...

gizzlon 12y ago

Ok, I understand that there's reasons for using static pages, but I don't get the feeling this guy really understands what he's talking about. > Even if [..] and there's nothing like bash installed on the same computer as the web server Bash installed? Huh? Why Bash exactly? I feel mentioning jails or containers here would be more on point.. > This is because every DCMS page view involves running a few tiny bits of software on your web server, rather than just returning the contents of some files that were generated earlier. Sure, but guess how those pages are returned? By running code on the server.. It seems like hes real beef is with "dynamic" (vs staic) sites, but he keeps mentioning CMS's for some reasons (ike you can't can have "dynamic" sites witjout a cms) > The web server executes no code on behalf of a viewer until that viewer has logged in.. 1) Of course it does, 2) How do the site check your info without executing code? :) etc etc.. There's a case for static sites, but this post just confuses things.

anth1y 12y ago
> Ok, I understand that there's reasons for using static pages, but I don't get the feeling this guy really understands what he's talking about. I think he might know a little bit: http://en.wikipedia.org/wiki/Paul_Vixie http://en.wikipedia.org/wiki/Paul_Vixie
- mordocai 12y ago
  None of the things on that wikipedia page makes me think he actually knows anything about web servers. Sure, he obviously should know about some of the things that make the internet work (BIND, cron, etc) but nothing on there has anything to do with making web sites. All of it is about the infrastructure. Either this article is filled with intentional hyperbole, or this guy doesn't know what he's talking about when it comes to serving web pages.
  - tptacek 12y ago
    Ordinarily I'd be bristling at a comment like this, but you are articulating some stuff --- a little rudely, but still --- that I believe about Vixie as well. I won't pretend not to have noticed and let you take all the heat. Paul Vixie's reputation among software security people is a little bit fraught.

StefanKarpinski 12y ago

"Little Johnny Tables". Um, yes, that was "Little Bobby Tables" [1]. Obviously not a big deal, but it seems emblematic of how sloppy this piece is. The article confuses – seemingly willfully, since Paul Vixie should know better – the concepts of dynamic language, dynamic page generation, lack of proper input hygiene, and various other orthogonal issues. The argument that dynamic languages are less secure depends an awful lot on the language – I don't think anyone is going to buy that C is more secure than Python. Haskell vs Python? Now that's a debate to be had. Certainly, websites that do no dynamic content generation are probably more secure – but then you're stuck with the Internet circa 1993. And of course, nobody is in favor not sanitizing inputs properly. [1] http://xkcd.com/327/ http://xkcd.com/327/

yk 12y ago
Calling any Turing complete language "more secure" is probably nonsense. It is possible to write secure applications in C, and it is possible to directly pipe attacker controlled input to a shell in Haskell.
- StefanKarpinski 12y ago
  Sure, you can do dangerous stuff in any language, but it's much harder to write a secure C program than a secure Python or Haskell program.
- tptacek 12y ago
  I know a total of zero working security researchers who think C is just as safe as Scala. The obvious flaw in your example: you can exec a program unsafely in both C and in Scala, but only in C can you do it accidentally simply by idiomatically copying a string from one place to another.
  - thegeomaster 12y ago
    FWIW, idiomatically copying a string in C is done using strncpy, and that doesn't introduce any RCE bugs. I would not in my right mind defend the premise that C is just as safe as Scala, but the truth is that sloppy programming can do harm in every language imaginable. It just becomes about damage control.

deleted 12y ago

[deleted]

erikb 12y ago

And there we have it. Security needs stability, stability decreases on a daily basis. We can't have that traditional kind of security. We need to move on to a more proactive way of thinking.

sre_ops 12y ago

Ah yes, Vixie, the guy who thought it was his customers that had to adapt to his "vision" rather than his vision had to adapt to customer needs.

qeorge 12y ago

Startup idea, free for the taking: create a service that "ossifies" dynamic websites into static HTML. (By ossify, I mean to take something dynamic and make it static). For example, that WordPress site you commissioned for a movie 3 years ago? Its a huge liability, but you don't have to take it offline - just ossify it. No one is updating that blog anymore! Under the hood, it would basically be a crawler, and the deliverable would be a zip file containing a 1-to-1, static copy of their website with all URLs still working. I suspect most folks here could whip up a shitty proof of concept in 48 hours. If someone does this, email me! I have a couple of potential clients for you (I'm a former consultant, with lots of WordPress sites in my history).

j_baker 12y ago
That's basically what the wayback machine does: https://archive.org/web/ https://archive.org/web/
- qeorge 12y ago
  Yes! It would be like the Wayback machine as a service, but with some key differences: 1) The intention is that you replace your dynamic site with the static copy, but your visitors are none the wiser. All URLs are the same, as well as the content returned. Might require some .htaccess trickery. 2) It would have to preserve all the images, css, and other assets, some possibly hotlinked. (The Wayback Machine is not awesome at this, understandably)
voyou 12y ago
You can get pretty close to this, I think with: wget --mirror --convert-links http://site.example.com/ From the wget manual: --convert-links After the download is complete, convert the links in the document to make them suitable for local viewing. This affects not only the visible hyperlinks, but any part of the document that links to external content, such as embedded images, links to style sheets, hyperlinks to non-HTML content, etc. The links to files that have been downloaded by Wget will be changed to refer to the file they point to as a relative link. Example: if the downloaded file /foo/doc.html links to /bar/img.gif, also downloaded, then the link in doc.html will be modified to point to ../bar/img.gif. This kind of transformation works reliably for arbitrary combinations of directories.

faraazin 12y ago

Noob qn:how does custom search work on static sites? May not be the best approach, but a simple SQL query would do the trick for dynamic sites.

juliangregorian 12y ago
A simple SQL query is not a great solution even for dynamic sites that pull content from SQL databases. You have to protect against SQL injection and you usually will want fulltext indices for all the text fields to be searched. It's also going to be slow in the naive implementation for databases of any significant size. The better solution for both dynamic and static sites is to set up a search appliance like elasticsearch, solr, or algolia. You can use JS to query it and still be static on the server. If you do set up your own, remember to use a reverse proxy like nginx to avoid exposing elasticsearch directly to the internet.
kstrauser 12y ago
I used Google Site Search (https://www.google.com/work/search/products/gss.html https://www.google.com/work/search/products/gss.html), which starts at $100 per year. Outsource all that infrastructure to a company who's good at it, park your static HTML on a CDN, and enjoy fast worldwide access with searchable content. That's not the only option, but it's a boss-friendly company to name drop. Most organizations wouldn't blink at the price, especially if it means you can move off dynamic hosting to far cheaper static hosting.

ivanhoe 12y ago

Static site is more secure only if the server is also up-to-date and setup properly to trim down all unnecessary options. Putting static site on a general purpose apache installation that will happily serve PHP and CGIs from user home dirs is not such a big security improvement.

programminggeek 12y ago

I'm going to say that the bigger problem in dynamic languages isn't that they are dynamic. It's that they have weak, nonexistant, or very undeveloped mechanisms for creating strong communication protocols that you can depend on as safe or reliable. Take the classic case of SQL injection. You have string input into your system that turns into string input into a SQL query that turns into string input to a database. That is dangerous because if you don't check on what the input string contains, it might contain nothing, or a semicolon, or it might not be a string at all! We understand that putting a string direct into a SQL statement is dangerous at this point, but we have yet to fix its root cause - nonexistant protocols or boundaries in most code we write. What a static language changes in that regard is compiler checked type signatures on your code. That generally stops you from say passing an Integer into something that needs a String. That solves a certain class of problems for sure, and the complier does it for you every time you change your code, so there is a convenience there. What static typing doesn't give you is actual data correctness. Things like buffer overflows or SQL injection can still happen with static typing. You could use a language like Scala or Haskell to have stronger/more complex types that would have more distinct notion of value correctness and at that point the complier would be doing most of the work to ensure your program is correct. Leaning on a type system in that regard is basically turning your types into the protocols that determine correctness in your system. It is also possible to lean on stronger protocols that check messages in a dynamic languages to achieve largely the same thing. In the end, to write safe, high quality software, you need to define the communication protocols between methods/functions/routines/services and enforce them much as you would with an externally facing REST api. The difference between a dynamic system with dynamic protocol checking vs a static system with compiler type checking is the mechanism you are using to enforce the protocol and how easy it is to interact with it. Dynamic systems might be easier to interface with externally because you don't have to understand a complex type, just pass a Hash/Dictionary sort of like a JSON API, vs a static system where you need to use the right types and so on, similar to a SOAP/WSDL API. Performance is also a consideration, but really when you compare static vs dynamic, it is important to understand that at the end of the day you can write Ruby/Python/PHP that is functionally equivalent to C/C++/Java. They are all ultimately going to be able to do the same kinds of things. The tradeoff is in how they solve the problem and how well that fits with the team writing the software.