4 ms·

One of the testimonials: "From now on, I think I'm going to strive to build all my apps as fully static sites." What? I can understand the idea of not overcom

One of the testimonials: "From now on, I think I'm going to strive to build all my apps as fully static sites." What? I can understand the idea of not overcomplicating an app when you don't need to, but how does this goal make sense for anyone who wants to build anything non-trivial?

savanaly 10y ago
Did he perhaps mean build all his apps as single page apps? A react or angular site that uses ajax to load all data is, in some sense, fully static. This only applies if you consider the term "app" as applying only to the frontend part of your app. But that might make sense if your backend is all firebase or some other api.
ccallebs 10y ago
Fully static sites don't necessarily mean static content in a user interaction sense. A lot of blogging platforms are database driven, but generate static documents instead of rendering the pages on the fly. I agree it's a hyperbolic claim but it can work depending on the domain.
igorgue 10y ago
Done this many times, in fact currently I deploy to S3 (look for "static website") and the static site interacts with an API. This is the whole point of JavaScript frameworks to me. And definitely not trivial stuff.
- debaserab2 10y ago
  > This is the whole point of JavaScript frameworks to me. What does it matter if your front endpoint is on S3 or being served by your own web server? Delivering static assets isn't that hard and you don't solve a lot by hosting the front end point of your app on S3. Your bottleneck is way more likely to be your API long before static asset serving is a problem.
- pyrophane 10y ago
  I understand the architecture you are describing, and I don't think that it is trivial. My confusion is over what really constitutes a "fully static" app.
  - jqueryin 10y ago
    IMO, static doesn't have to have a correlation to being simpler. HTML, CSS, JS, and media are all static assets but you're welcome to request whatever datatypes you want behind the scenes via AJAX and/or CORs. The benefits are entirely in the rendering speeds of an optimized web server and cache layer. Also, this approach plays extremely nicely with CDNs. Difficulties can arise if you have to begin dealing with versioning of your assets to avoid cache invalidation, but that's what a proper build process can add to the static site.
    - aeosynth 10y ago
      Is the performance/simplicity that much better than setting up Cloudflare yourself?
  - igorgue 10y ago
    In this particular case, my understanding is, the fully static code is just the frontend, in other words to not render HTML from your Web Server to the Browsers.
- sorenbs 10y ago
  Indeed this is how I have build all my projects for the last two years. Currently I am building a platform to easily deploy a graphql api called https://graph.cool https://graph.cool
thinkloop 10y ago
Static generally means the assets and code are created and cached at deploy time, without any changes or code generation after deploy. Static sites use the same base code for every user, and interact with APIs to customize the experience. Loading new context-specific code, even if cached along the way, is not generally considered static. This is part 1 of "the dream", the next step is being completely serverless - that is, not managing your own servers and using hosted services instead. The challenge there is mainly authentication and the security model, but with something like firebase with it's clever security model (or another similar authentication-only service who's name escapes me) you can basically build an app of almost any complexity. CDN > Auth Service > Message Queue > Lamda-type processing > Hosted DB
sintaxi 10y ago
No one is suggesting compiling a giant project like wikipedia into a static site and deploying to surge. its about the web client being a static front-end that can be cached and run offline.

savanaly 10y ago

Did he perhaps mean build all his apps as single page apps? A react or angular site that uses ajax to load all data is, in some sense, fully static. This only applies if you consider the term "app" as applying only to the frontend part of your app. But that might make sense if your backend is all firebase or some other api.

ccallebs 10y ago

Fully static sites don't necessarily mean static content in a user interaction sense. A lot of blogging platforms are database driven, but generate static documents instead of rendering the pages on the fly. I agree it's a hyperbolic claim but it can work depending on the domain.

igorgue 10y ago

Done this many times, in fact currently I deploy to S3 (look for "static website") and the static site interacts with an API. This is the whole point of JavaScript frameworks to me. And definitely not trivial stuff.

debaserab2 10y ago
> This is the whole point of JavaScript frameworks to me. What does it matter if your front endpoint is on S3 or being served by your own web server? Delivering static assets isn't that hard and you don't solve a lot by hosting the front end point of your app on S3. Your bottleneck is way more likely to be your API long before static asset serving is a problem.
pyrophane 10y ago
I understand the architecture you are describing, and I don't think that it is trivial. My confusion is over what really constitutes a "fully static" app.
- jqueryin 10y ago
  IMO, static doesn't have to have a correlation to being simpler. HTML, CSS, JS, and media are all static assets but you're welcome to request whatever datatypes you want behind the scenes via AJAX and/or CORs. The benefits are entirely in the rendering speeds of an optimized web server and cache layer. Also, this approach plays extremely nicely with CDNs. Difficulties can arise if you have to begin dealing with versioning of your assets to avoid cache invalidation, but that's what a proper build process can add to the static site.
  - aeosynth 10y ago
    Is the performance/simplicity that much better than setting up Cloudflare yourself?
- igorgue 10y ago
  In this particular case, my understanding is, the fully static code is just the frontend, in other words to not render HTML from your Web Server to the Browsers.
sorenbs 10y ago
Indeed this is how I have build all my projects for the last two years. Currently I am building a platform to easily deploy a graphql api called https://graph.cool https://graph.cool

thinkloop 10y ago

Static generally means the assets and code are created and cached at deploy time, without any changes or code generation after deploy. Static sites use the same base code for every user, and interact with APIs to customize the experience. Loading new context-specific code, even if cached along the way, is not generally considered static. This is part 1 of "the dream", the next step is being completely serverless - that is, not managing your own servers and using hosted services instead. The challenge there is mainly authentication and the security model, but with something like firebase with it's clever security model (or another similar authentication-only service who's name escapes me) you can basically build an app of almost any complexity. CDN > Auth Service > Message Queue > Lamda-type processing > Hosted DB

sintaxi 10y ago

No one is suggesting compiling a giant project like wikipedia into a static site and deploying to surge. its about the web client being a static front-end that can be cached and run offline.