3 ms·

After looking over the site it seems to be advocating simply serving static content statically and / or create single-page web applications. I'm not entirely s

After looking over the site it seems to be advocating simply serving static content statically and / or create single-page web applications. I'm not entirely sure 100% static makes sense either. For instance serving debug versus minified versions of a website. Sure you could compile everything and create different outputs but that takes time and testing to setup; I haven't worked on a team that would really have the upfront time to do that. The alternative is loading assets via JavaScript but that's much slower than including the links upfront. The other issue is serving code that requires higher permissions to execute. I would rather leave chunks out if I know if can't be accessed from the server-side to make it a little more difficult for someone to figure out how to exploit my website. It's certainly not foolproof nor secure but I don't want to make it completely easy for someone to understand how all administrative functions and permissions work either. You could probably compile different versions of the website and control which gets served based upon authentication but that's even more upfront cost.

mbleigh 13y ago
The great thing about a static app architecture is that for things like administrative functions you can usually easily build an entirely separate interface and application utilizing the same back-end resources. Security through obscurity is never sufficient, and static architecture makes you think through those concerns more thoroughly before deploy. See http://www.staticapps.org/articles/authentication-and-authorization http://www.staticapps.org/articles/authentication-and-author... for more on that subject. As to development vs production, minifying etc. that's something we're trying to solve with multi-environment hosting at Divshot.
- BinaryIdiot 13y ago
  It's not typically cost effective or realistic to build an entirely separate interface for administrative functionality (in fact, for user experience purposes, it's typically better to be able to administrator changes in place). As I mentioned it's doable but requires additional upfront work that I have never had time to do on any project I get to work on. Obviously security through obscurity isn't sufficient as I said it wasn't security :) but I don't see any reason why a static architecture should make you think about those issues any more or less; you should already be doing so.

mbleigh 13y ago

The great thing about a static app architecture is that for things like administrative functions you can usually easily build an entirely separate interface and application utilizing the same back-end resources. Security through obscurity is never sufficient, and static architecture makes you think through those concerns more thoroughly before deploy. See http://www.staticapps.org/articles/authentication-and-authorization http://www.staticapps.org/articles/authentication-and-author... for more on that subject. As to development vs production, minifying etc. that's something we're trying to solve with multi-environment hosting at Divshot.

BinaryIdiot 13y ago
It's not typically cost effective or realistic to build an entirely separate interface for administrative functionality (in fact, for user experience purposes, it's typically better to be able to administrator changes in place). As I mentioned it's doable but requires additional upfront work that I have never had time to do on any project I get to work on. Obviously security through obscurity isn't sufficient as I said it wasn't security :) but I don't see any reason why a static architecture should make you think about those issues any more or less; you should already be doing so.