Static Web Apps – A Field Guide(staticapps.org)
staticapps.org
Static Web Apps – A Field Guide
http://www.staticapps.org/?hn
27 comments
I see your point but sorry, its nonsense when talking about "webapps" - as opposed to anything largely text based and with very limited user interaction. You are going to have to rerender the page for every single user action. The feedback the user gets is going to be ridicously slow for marginally complicated apps, creepingly slow on low-bandwith devices.
Just deleting an item in a paginated list will require posting data while maintaining the query parameters in the url, running a possibly very complex query on the server again, recalculating and rerendering the page and then shoving that data all back to the user via expensive TCP cycles - huge waste. A "webapp" on the otherhand makes a post to the server gets a 204, and on the client side simply removes the corresponding dom element.
As an example, think about implementing MS Paint and the corresponding user experience - using what you're talking about.
Just deleting an item in a paginated list will require posting data while maintaining the query parameters in the url, running a possibly very complex query on the server again, recalculating and rerendering the page and then shoving that data all back to the user via expensive TCP cycles - huge waste. A "webapp" on the otherhand makes a post to the server gets a 204, and on the client side simply removes the corresponding dom element.
As an example, think about implementing MS Paint and the corresponding user experience - using what you're talking about.
I agree that you'd be nuts to build an interactive drawing program like this... But the vast majority of what people are calling "web apps" today aren't anything like a drawing program.
I'm also personally a big fan of adding a layer if JavaScript to improve interactivity, but the "static apps" approach advocated in the OP goes way too far for most apps in my opinion.
I'm also personally a big fan of adding a layer if JavaScript to improve interactivity, but the "static apps" approach advocated in the OP goes way too far for most apps in my opinion.
I agree with you but isn't paint program a bit extreme as an example? surely much less interactive webapps can also benefit lots from programming all the logic/UI on the client? (newbie)
Add a thin-layer of javascript for immediate feedback on certain UI operations, and I'm sold.
Static web apps are excellent for things like webmail, Google Docs, etc. that aren't going to be crawled. It's simpler there, and is probably how things should work in a hypothetical non-web-based but still deployed-web-style app ecosystem.
For a blog, or a forum system, or twitter, or anything that should be crawled and linked to and shared, it doesn't really make sense, and "pages and forms" makes much more sense.
For a blog, or a forum system, or twitter, or anything that should be crawled and linked to and shared, it doesn't really make sense, and "pages and forms" makes much more sense.
It won't catch on :)
These people call an app "static" when all content is dynamically generated at runtime on the client-side. Everybody else calls these things "single-page web applications". I really don't see the point of defining a new, confusing term for an existing concept.
I believe the point is to drive traffic to http://www.divshot.com, re-labelling their snake oil as a uniquely cold-blooded essential along the way.
I quote from their features page:
> Fully featured? Yes. Get pushState with custom routes, clean URLs (goodbye, .html), and more. ... Whatever you choose, we support it.
> S'all about you, dev, s'all 'bout you.
I quote from their features page:
> Fully featured? Yes. Get pushState with custom routes, clean URLs (goodbye, .html), and more. ... Whatever you choose, we support it.
> S'all about you, dev, s'all 'bout you.
Actually, we built our static hosting service because we were already developing with a static web architecture and couldn't find an existing acceptable option for hosting.
I'm building the platform because I believe in the technology, not espousing the technology because I built the platform. :)
I'm building the platform because I believe in the technology, not espousing the technology because I built the platform. :)
I also believe in the technology and the general architecture you're espousing. I found the content on http://www.staticapps.org well written and constructive and the links to http://www.divshot.com are unobtrusive.
My reaction to http://www.divshot.com is something else entirely. To solve the "problem" of static file hosting and deployment with a service that is "compatible with Angular and Firebase" and supports "pushState with custom routes" is clearly disingenuous.
Not that there's anything wrong with effective marketing. If your target audience is people who don't know what the words mean, then knock yourself out.
My reaction to http://www.divshot.com is something else entirely. To solve the "problem" of static file hosting and deployment with a service that is "compatible with Angular and Firebase" and supports "pushState with custom routes" is clearly disingenuous.
Not that there's anything wrong with effective marketing. If your target audience is people who don't know what the words mean, then knock yourself out.
We're trying to market to people who want to use static architecture, regardless of experience. It's a bit of an education issue as people are familiar with e.g. Angular and Ember but don't necessarily know what it means to deploy them as a static app.
Can you tell me what you find disingenuous about the claims? What would appeal to you when describing a static web hosting service?
Can you tell me what you find disingenuous about the claims? What would appeal to you when describing a static web hosting service?
Because it's describing two different (but related) things. Jekyll blogs are static sites, but not Single-Page Apps, as an example.
I used to work at a place that switched to only building apps this way. It was architecturally simple, but for random business apps, there was one major difficulty: The tooling felt like going back on a time machine. You have all this tools out there for download, but almost all of them don't do quite what you want, are not easy to extend without just getting tied to an old version forever, and have trouble interacting with each other.
When you get developers that are wishing they were back using Swing because it was easier, you know you have trouble.
When you get developers that are wishing they were back using Swing because it was easier, you know you have trouble.
Swing is/was verbose for simple stuff, but beyond a fairly low complexity bar it is enormously preferable to the web stack, at least from a developer perspective.
While Java got somewhere with the whole deployment thing it was never quite as slick as the web, and that's the killer aspect of the web really.
What is funny about the web these days is how they're very slowly reinventing all the things NeXT were doing in the 80s, only using a lot more memory and CPU in the process. Ironic given it started on a NeXT in the first place.
While Java got somewhere with the whole deployment thing it was never quite as slick as the web, and that's the killer aspect of the web really.
What is funny about the web these days is how they're very slowly reinventing all the things NeXT were doing in the 80s, only using a lot more memory and CPU in the process. Ironic given it started on a NeXT in the first place.
I once did a website exactly like this. Nothing required a web application server to run, and I was building the (quite simple) thing from the ground up.
Once my build environment was set up, the dev cycle and experience was stellar. Fast, on change, builds, lighting fast local page reloads.
Deployment was just pushing static files on the http server, that served only statics files, like the good old days.
Once that was done, a problem remained: since it was a one shot experiment, with something quite simple, I had only one dev environment for that thing, and I did not document how I did it.
My conclusion was : part of apps that serves dynamic page are kind of build environment that can't pre-built the artifact. But the build environment is part of the code, just like a Makefile would.
It's probably possible to build and serve static page with a good experience as a whole, but your tool quality (easy to deploy and reliable) for building must be great.
Once my build environment was set up, the dev cycle and experience was stellar. Fast, on change, builds, lighting fast local page reloads.
Deployment was just pushing static files on the http server, that served only statics files, like the good old days.
Once that was done, a problem remained: since it was a one shot experiment, with something quite simple, I had only one dev environment for that thing, and I did not document how I did it.
My conclusion was : part of apps that serves dynamic page are kind of build environment that can't pre-built the artifact. But the build environment is part of the code, just like a Makefile would.
It's probably possible to build and serve static page with a good experience as a whole, but your tool quality (easy to deploy and reliable) for building must be great.
The tooling is now awesome (imho). I am the furthest thing from a node.js fanboy, but as a build pipeline it is awesome.
Being able to have a gulpfile take care of compiling jade, coffeescript and sass, triggering live reloads, etc., immediately makes me smile. As a former-Flex developer who dealt with some heinous build-times because the tooling was worth it, I now have a better front-end alternative with sub-quarter-second build times.
And if you have a json-serving backend (rails, spray.io, whatever) you can set up easy double tests of your front-end logic, where you mock out the backend, and then run slower "integration" tests where you include it. Might sound wacky but I've found this to be a way to quickly develop robust systems. For me, angular's dependency-injection makes it even easier.
So this static-koolaid took a while for me to drink, but I'm liking it more all the time.
Being able to have a gulpfile take care of compiling jade, coffeescript and sass, triggering live reloads, etc., immediately makes me smile. As a former-Flex developer who dealt with some heinous build-times because the tooling was worth it, I now have a better front-end alternative with sub-quarter-second build times.
And if you have a json-serving backend (rails, spray.io, whatever) you can set up easy double tests of your front-end logic, where you mock out the backend, and then run slower "integration" tests where you include it. Might sound wacky but I've found this to be a way to quickly develop robust systems. For me, angular's dependency-injection makes it even easier.
So this static-koolaid took a while for me to drink, but I'm liking it more all the time.
Got any specific examples?
Disagree with a few things, the title 'static is better', is hyperbole, its a different environment. Also the 'the doesnt mean they are any less capable' is pretty much by definition wrong.
That being said I absolutely love the architecture, pretty much every application I build these days starts with switching my github default branch to gh-pages. I work on http://pouchdb.com and use that for storing and syncing data. not having to worry about how my servers are configured / how they are running, how to move an application makes me feel like I can build what I want then when I come back in 2 years it 'just works', with dynamic applications I always feel there is a maintenance burden that I cant shake.
That being said I absolutely love the architecture, pretty much every application I build these days starts with switching my github default branch to gh-pages. I work on http://pouchdb.com and use that for storing and syncing data. not having to worry about how my servers are configured / how they are running, how to move an application makes me feel like I can build what I want then when I come back in 2 years it 'just works', with dynamic applications I always feel there is a maintenance burden that I cant shake.
> Disagree with a few things, the title 'static is better', is hyperbole, its a different environment.
This.
I feel I might fall under the hn banhammer soon, but I really wish people would actually read Fieldings thesis (introducing REST) -- it's a really good overview of the different architectures one might use for a client-server system. It' not just REST, REST is a natural conclusion drawn from the alternatives when the goal is a highly performing system for hypermedia:
https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...
But it's worth noting that fat-client styles are also in there, and the trade-offs mentioned are worth keeping in mind (no, there is no silver bullet -- you actually should choose an architecture that fits your problem domain. Shocking, isn't it?).
This.
I feel I might fall under the hn banhammer soon, but I really wish people would actually read Fieldings thesis (introducing REST) -- it's a really good overview of the different architectures one might use for a client-server system. It' not just REST, REST is a natural conclusion drawn from the alternatives when the goal is a highly performing system for hypermedia:
https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch...
But it's worth noting that fat-client styles are also in there, and the trade-offs mentioned are worth keeping in mind (no, there is no silver bullet -- you actually should choose an architecture that fits your problem domain. Shocking, isn't it?).
So is this just another way to talk about the now-ubiquitous thick-client app? Or is there something revolutionary I don't see in my cursory look at this site? There is definitely something to be said for building separate services as your API, rather than thinking your static assets have to be married to the data processing backend. But calling that a static app is misleading -- it's still dynamic, and in fact the server is still processing data, it's just distributed.
The assets served to the client are static, they can be served by a simple server, cached through CDNs, etc.
I don't know how it is static either or are you referring that it is 'static' only from the web browser(consumer) point of view? for example, in the backend you could be generating a value from a database.
He clearly explained what he means by static. The HTML/CSS/JS assets are served without any preprocessing on the server. And, yes, once it hits the browser, it becomes dynamic through the use of Javascript. Does that make sense?
yeah thanks, so the html are just base templates that get modified of the client?
It's really not worth sperging out about this. It just means the HTML/JS/CSS assets delivered by the front-end server do not change.
Equating a lack of understanding (through language, unfamiliarity, etc.) with mental disease.
Nice
Sperging out? Are you serious?
I had to look this one up:
Sperging out: When someone goes on a long, in-depth, overly elaborate explanation long after everyone already gets the point, but will not fucking end.
[1] http://www.urbandictionary.com/define.php?term=Sperging%20ou...
Sperging out: When someone goes on a long, in-depth, overly elaborate explanation long after everyone already gets the point, but will not fucking end.
[1] http://www.urbandictionary.com/define.php?term=Sperging%20ou...
Just so the original author doesn't accidentally misinterpret my complete and utter disgust for his statement as ignorance; I pretty much guessed it instantly.
It might be a new term, but as far as I'm concerned it's as bannable an offense as calling someone a faggot or something of that kind.
It might be a new term, but as far as I'm concerned it's as bannable an offense as calling someone a faggot or something of that kind.
Gee, aren't you an outraged little fella.
Ah well; thank you for your contribution. Enjoy it here; I have feeling you'll fit right in by now.
I'll just retreat to my old-man cave to contemplate a time when the internets had this quaint little place where conversation was civil, the news was enlightening and everyone was striving to break free from the status quo by going at it alone, forging our own path.
It was fun while it lasted...
I'll just retreat to my old-man cave to contemplate a time when the internets had this quaint little place where conversation was civil, the news was enlightening and everyone was striving to break free from the status quo by going at it alone, forging our own path.
It was fun while it lasted...
Did those old times include being insulted and outraged at every word your co-debaters said?
It's quite ironic for you to be sad about the lack of civil discourse, when you used the opportunity to hijack the original point of the poster and start discussing a 'bannable offense' on the occasion of a silly colloqual phrase they used.
You think you're taking the high ground? I for one long for a debate where the people talking can stay focused on a topic without being constantly insulted by this or that for the purpose of cheap outrage.
It's quite ironic for you to be sad about the lack of civil discourse, when you used the opportunity to hijack the original point of the poster and start discussing a 'bannable offense' on the occasion of a silly colloqual phrase they used.
You think you're taking the high ground? I for one long for a debate where the people talking can stay focused on a topic without being constantly insulted by this or that for the purpose of cheap outrage.
Never that.
Yeah, part of the application works that way, but then you still have to write an API, it just lives on a different server.
Uh huh.
The elephant in the room is performance. They can't help mentioning "perceived performance" but conveniently haven't gotten around to explaining that in detail. In my experience browser performance is a struggle, and it's always faster to do as much as possible on the server.
This largely depends on application structure. If your application relies heavily on being "linked into" i.e. a user is likely to follow a link to a single resource within the app and is unlikely to continue browsing or accessing other content on the app, doing it on the server is (at least marginally) faster.
If, however, your application use pattern involves users performing numerous actions or navigating around within the application once they land there, a request/response style app only has the overhead of re-sending various bits of layout HTML and re-requesting all of the JS, CSS, and images associated with the site.
If, however, your application use pattern involves users performing numerous actions or navigating around within the application once they land there, a request/response style app only has the overhead of re-sending various bits of layout HTML and re-requesting all of the JS, CSS, and images associated with the site.
Also indexing by search engines or the like. Expecting a web crawler to resolve your JavaScript code to produce a complete page is probably a recipe for pain.
Search friendliness is probably the biggest problem yet to be completely solved for static apps. There are workarounds, but they are admittedly less than perfect.
However, given the general web development trends towards JS-driven interfaces and upcoming standards like Web Components, I don't think it's going to stay unsolved for much longer.
However, given the general web development trends towards JS-driven interfaces and upcoming standards like Web Components, I don't think it's going to stay unsolved for much longer.
I think performance is slightly more complicated than that. For just a document, like a blog post, I totally agree -- and find it irritating that Blogger has a "static app" now just to serve a damn page with a blog post. But for an application, doing it this way can front-load things, so that the startup time for the app is long, but transitioning between states can be faster.
A great example of this in action is Apostle.io. There's a short delay to front-load things and then the app becomes blazing fast when transitioning between states. Internally, it's only making JSON requests to an API that it needs for the view/state. Only parts of the DOM are updated instead of re-rendering the entire page.
I don't think the dichotomy of static vs. dynamic is that useful really. At least not if they are taken to mean pre-compiled vs. generated directly as a response to a http request. The so-called static pages are presumably still assembled by some programmatic pipeline (aka "dynamic").
What does matter, is that pages that are the same for all users, and that change rarely are served with proper caching headers. That way you can drop a http-cache in front of your app and voila, you have all the same benefits that a pre-compiled site would give you, but without the pain of having to use a completely separate process.
The hard part is separating elements that have different frequencies of change from each other. For some reason, this is not something that popular web frameworks (Such as Rails) push very hard, but it's something I find extremely useful when building web apps. A classic trick is putting user-specific information (Such as your name + karma score in the top right corner of this site) in a separate ajax-call, while the main page is served with hard public-cache headers.
What does matter, is that pages that are the same for all users, and that change rarely are served with proper caching headers. That way you can drop a http-cache in front of your app and voila, you have all the same benefits that a pre-compiled site would give you, but without the pain of having to use a completely separate process.
The hard part is separating elements that have different frequencies of change from each other. For some reason, this is not something that popular web frameworks (Such as Rails) push very hard, but it's something I find extremely useful when building web apps. A classic trick is putting user-specific information (Such as your name + karma score in the top right corner of this site) in a separate ajax-call, while the main page is served with hard public-cache headers.
I honestly misunderstood the definition when I first read it. I've built a variety of web apps (old php + mysql, actual static content, nodeJS + angular), and I this terminology escaped me. I've never looked at an Angular app and referred to it as static? In fact, what is defined here is the exact opposite of what I'd assume was a static application.
I wonder if people who advocate this as "better" have ever build anything even remotely complex. It's this kind of simplistic tunnel vision why many engineers look down their noses at "web development".
Also, this is nothing but a marketing site for a "static web hosting service", which explains the superficial buzzword bingo.
Also, this is nothing but a marketing site for a "static web hosting service", which explains the superficial buzzword bingo.
Your derision comes with a dearth of actual reasoning as to why "complex" applications don't work from a static architecture perspective or how you define complexity.
Isn't this really just advocating clear separation/encapsulation between client-side and server-side? IE. create a "static" web app that can get data from server side through REST API or allow you to plug in other sources of data (pouchdb).
It certainly has its advantages. I would even say if you can get to a point where your app is totally static, you should do it. But if there's even a little server-side state things can get complicated pretty quickly.
For example, say your app uses hash/fragment URLs, and users need to be logged in to access the app. A user hits yourapp.com/#/whatever, but isn't logged in, so you bounce them to the login page. Except, oops, the hash/fragment doesn't get sent to the server, so your login page doesn't know where to redirect the client after logging in.
For example, say your app uses hash/fragment URLs, and users need to be logged in to access the app. A user hits yourapp.com/#/whatever, but isn't logged in, so you bounce them to the login page. Except, oops, the hash/fragment doesn't get sent to the server, so your login page doesn't know where to redirect the client after logging in.
There are ways around this. With ember it is possible to use browser history to mask the hash... http://emberjs.com/guides/routing/specifying-the-location-ap...
[deleted]
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.
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.
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-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.
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-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.
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.
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.
In other breaking news:
) Earth still exists ) Human's breathe oxygen *) Cow's fart a lot
Not to be a total arsehole, but I mean... uhh, what's the point of this?
If anything, it sounds like, from the copy, they want you to make websites but instead of calling it a "website" because that's un-cool? I don't get it.
// Start of semi-related rant
I would also like to call this statement in their opening paragraph complete non-sense and almost simple minded:
"Static web architecture eases common web development headaches without introducing additional complexity"
After many years of doing web development, I can see programming in Java, Obj-C, or .NET is worlds easier for application development. Instead of 27 different platforms (IE, Firefox, Chrome, Safari on different platforms) I have one-- the god damn operating system. Was this always the case? Nope, but it is now.
Is it easier to write a single screen on the web using JS, HTML, and CSS? Sure, but the return is marginally decreasing as the application grows. More screens, more complexity, the more HTML/CSS/JS start to show their age.
Web development becomes actually more complicated than writing a native application.
) Earth still exists ) Human's breathe oxygen *) Cow's fart a lot
Not to be a total arsehole, but I mean... uhh, what's the point of this?
If anything, it sounds like, from the copy, they want you to make websites but instead of calling it a "website" because that's un-cool? I don't get it.
// Start of semi-related rant
I would also like to call this statement in their opening paragraph complete non-sense and almost simple minded:
"Static web architecture eases common web development headaches without introducing additional complexity"
After many years of doing web development, I can see programming in Java, Obj-C, or .NET is worlds easier for application development. Instead of 27 different platforms (IE, Firefox, Chrome, Safari on different platforms) I have one-- the god damn operating system. Was this always the case? Nope, but it is now.
Is it easier to write a single screen on the web using JS, HTML, and CSS? Sure, but the return is marginally decreasing as the application grows. More screens, more complexity, the more HTML/CSS/JS start to show their age.
Web development becomes actually more complicated than writing a native application.
The static thing - I think its a reaction to the obvious inefficiency of dynamic pages, server processing for data that is only changed occasionally.
Consider a blog which gets posted to once a week. Do you really need dynamic processing for every page render 24/7/365? Well, that's the way it works.
But you have to have something additional for changing data/separate API. You can do the static site, but you still gotta have the XHR or JSONP calls to fetch dynamic data. You get a nice separation of UI/data, easier to tweak the UI - independent of the data (hand it off to a designer), and your separate data server can feed multiple apps or you open it up for the world to use.
Consider a blog which gets posted to once a week. Do you really need dynamic processing for every page render 24/7/365? Well, that's the way it works.
But you have to have something additional for changing data/separate API. You can do the static site, but you still gotta have the XHR or JSONP calls to fetch dynamic data. You get a nice separation of UI/data, easier to tweak the UI - independent of the data (hand it off to a designer), and your separate data server can feed multiple apps or you open it up for the world to use.
> Consider a blog which gets posted to once a week. Do you really need dynamic processing for every page render 24/7/365? Well, that's the way it works.
Isn't this the exact problem that a reverse proxy cache solves?
Isn't this the exact problem that a reverse proxy cache solves?
it does if you want to setup the 2nd piece, but I like nginx alot
I try and keep things static unless I have really good reason to do dynamically generated markup. There are still very good reasons for having a backend sometimes.
There is a middle ground if you are primarily replacing a CMS though, which is using a static site generator like jekyll.
This is something I learnt while working at [1] DevelopmentSeed. They also built a wonderful editor for github pages called [2] Prose.
[1] http://developmentseed.org/blog/2012/07/27/build-cms-free-we... [2] http://prose.io
There is a middle ground if you are primarily replacing a CMS though, which is using a static site generator like jekyll.
This is something I learnt while working at [1] DevelopmentSeed. They also built a wonderful editor for github pages called [2] Prose.
[1] http://developmentseed.org/blog/2012/07/27/build-cms-free-we... [2] http://prose.io
Prose is seriously awesome! Thank you :-)
What a coincidence, I have been building a CMS which spits out static HTML which uses the same bolt icon :) http://getsimplesite.com
I think static apps are best suited for very simple apps which don't have a lot of business rules, simple CRUD apps are the best candidates for this kind of a setup. Once you go beyond a simple app doing things on the server is much easier.
I think static apps are best suited for very simple apps which don't have a lot of business rules, simple CRUD apps are the best candidates for this kind of a setup. Once you go beyond a simple app doing things on the server is much easier.
And you also make the same unsubstantiated claims of superiority, without any explanation.
What is this magical hosted CMS that limits my freedom, exactly?
What is this magical hosted CMS that limits my freedom, exactly?
Many CMSes ask you to write your templating code in something which is safe to run on the server, check http://get.harmonyapp.com/ for instance it forces you to use liquid templates. Getsimplesite on the other hand uses plain javascript to write page templates.
So then the solution that comes to mind before I drop my entire stack to use yours, is to simply use the language the CMS itself was written in (Python, PHP, whatever), instead of the CMS. Sorry. Work on your value proposition.
[deleted]
A reverse proxy cache in front of a dynamic application can approach the best of both worlds. If the page requested is static, you get a fully rendered set of HTML etc. from the cache. If the page requested needs to be customized somehow, the request passes through the cache and hits the application, which custom-renders a new page to send back.
Having skimmed the available articles, I'm still left asking: How does authorization work here? As in, do you use it to 200 or 401 an url (example.com/static/klapinat0r/feed).
Or are they simply advocating serving HTML as templates and updating with js? If so, that's hardly news is it?
By their definition that'd be Hybrid though, right?
Or are they simply advocating serving HTML as templates and updating with js? If so, that's hardly news is it?
By their definition that'd be Hybrid though, right?
Authentication and Authorization are handled via JS calls to back-end services that know. Did you read http://www.staticapps.org/articles/authentication-and-author... -- if so, what doesn't make sense from that perspective?
Whether or not this was a new take on static + auth, as it sounded like it was the standard client-js apps (which you confirmed it is). Not that it's not a valid approach, I just assumed it was something new.
Web development newbie here. Is there a starter template available on these lines that has the guts built-in, including both client and server code, user authentication, server-side database access, a default theme, etc., where the developer can start by defining the application-specific data models and business logic?
I recommend checking out some of the examples provided by Firebase. In particular, something like angularFire-seed (https://github.com/firebase/angularFire-seed) is a great way to get started. Firebase can handle user authentication and data storage. AngularJS + Firebase is an amazingly productive combo. Set up Bower and use Bootstrap for the user interface, you’re all set.
It would be a great idea to set up some boilerplates for StaticApps.org showing how easy it is to get started.
It would be a great idea to set up some boilerplates for StaticApps.org showing how easy it is to get started.
What's their plan for dealing with CSRF?
For this type of app, the usual solution is to embed a token in the first response, shared between the page and the server, and use it for authenticated communication through the data channel (be it AJAX or a WebSocket).
Consequently, the first page can't be static.
For this type of app, the usual solution is to embed a token in the first response, shared between the page and the server, and use it for authenticated communication through the data channel (be it AJAX or a WebSocket).
Consequently, the first page can't be static.
The token is returned by the auth service when the user logs in. The initial page bootstraps in unauthenticated mode and always has to query the auth service first to figure out if the user is logged in. That's how I've done it in the past.
How do you tell apart the app loaded in several tabs and and an attacker?
CSRF is more or less impossible in a static site architecture. Since everything is just static HTML there are generally no form submission endpoints to attack.
XSS can be very dangerous, as can session hijacking, but CSRF is pretty much moot on static apps.
XSS can be very dangerous, as can session hijacking, but CSRF is pretty much moot on static apps.
Everything is _not_ static: there's a data channel.
If you need to support browsers that do not support localStorage, indexedDB or another kind of local, private storage, you must either restrict authentication to a single tab or provide a token on page load, and not later (one token per page load).
This is less of a concern now, but it used to be the case.
If you need to support browsers that do not support localStorage, indexedDB or another kind of local, private storage, you must either restrict authentication to a single tab or provide a token on page load, and not later (one token per page load).
This is less of a concern now, but it used to be the case.
You can use CORS and withCredentials to use simple cookie-based browser sessions for authentication. It's still hard against CSRF because as long as you properly origin-check the request you don't have to worry about form forgery.
Wrote about this some at http://www.divshot.com/blog/static-apps/cookies-and-cors
Wrote about this some at http://www.divshot.com/blog/static-apps/cookies-and-cors
[deleted]
So we're back to Powerbuilder again.
Why take a step back in technology?
I think you're misunderstanding what they mean by "static." The served pages are static html and javascript, and the javascript loads other resources from the server. The "static" part just means there is no page rendering occurring on the server.
Out of all the processes that must occur to render a dynamic server-side response (database queries, computations, etc.), assembling HTML ("page rendering") is probably one of the least expensive. This seems like a premature optimization to me.
It's not just a performance optimization. It's a cleaner architecture that's easier to test.
Congratulations. With this arbitrary limitation you just eliminated the cheapest, most scalable and most simple part of the entire web application - HTML template rendering, to replace it with fragile and invisible to search engines JavaScript logic.
I believe people in firm grasp of their common sense would take the practical hybrid approach and do what makes sense for each specific scenario, rather than rely on ideology to architect their app for them.
I believe people in firm grasp of their common sense would take the practical hybrid approach and do what makes sense for each specific scenario, rather than rely on ideology to architect their app for them.
If you're running a mostly-public content site that depends largely on search engine traffic, static is probably not the way to go (yet).
If your application lives mostly inside of a login, there's little reason to force yourself to render HTML from the server rather than building reusable APIs that can be shared across web, mobile, etc.
If your application lives mostly inside of a login, there's little reason to force yourself to render HTML from the server rather than building reusable APIs that can be shared across web, mobile, etc.
False dichotomy.
Building reusable APIs has nothing to do with forcing yourself to consume them with client-side JS. Maybe that approach works as a training wheels type of guide for developers who can't stay focused, but a service layer is pretty much the norm for any competently written web app, whether a particular API call is materialized with client-side or server-side view rendering.
Few additional points about thinking intranet apps get a pass for being intranet:
1. Even on the intranet, it's good for people to be able to bookmark specific point of their navigation and query type (i.e. page, sorting order, filtering criteria, via URL query); it matches how they use the web, and improves their workflows and performance. People don't react well when the web app you developed just decided to pick up all the limitation of native apps, with none of the benefits of a native app (native UI, performance, OS integration etc.). Don't make it a crappy wanna-be-real-app web app, just make it a good web app, acting like a web app.
Now, sure, if you try really heard, you can emulate it with a big number of static pages (so it works when you refresh) and manually synching everything with the browser History API, but whoops, you just blew your budget, deadline and doubled the number of tests your app needs to pass QA checks since your app now has complicated history management where it didn't need any (aside form ideology), instead of letting the browser and server work it out using the good old school ways of handling page state.
2. It's pointless waste to develop two set of practices, tools and processes for creating & maintaining public apps, vs. internal apps. What for? Feeling good inside that you saved 3% CPU on the server in view rendering? Please. I've gotten people fired over insisting on using their own pet practices like these (with no provable real-world benefit) over common sense, and wasting the business time and money.
3. In my practical the line between an intranet app and Internet apps is thing. So if an internal app becomes public (in a limited or full-blown capacity), it's a good idea you don't have to drop all the UI code and start over, mkay.
I write intranet apps for a living (they mix server-side and client-side rendering).
Building reusable APIs has nothing to do with forcing yourself to consume them with client-side JS. Maybe that approach works as a training wheels type of guide for developers who can't stay focused, but a service layer is pretty much the norm for any competently written web app, whether a particular API call is materialized with client-side or server-side view rendering.
Few additional points about thinking intranet apps get a pass for being intranet:
1. Even on the intranet, it's good for people to be able to bookmark specific point of their navigation and query type (i.e. page, sorting order, filtering criteria, via URL query); it matches how they use the web, and improves their workflows and performance. People don't react well when the web app you developed just decided to pick up all the limitation of native apps, with none of the benefits of a native app (native UI, performance, OS integration etc.). Don't make it a crappy wanna-be-real-app web app, just make it a good web app, acting like a web app.
Now, sure, if you try really heard, you can emulate it with a big number of static pages (so it works when you refresh) and manually synching everything with the browser History API, but whoops, you just blew your budget, deadline and doubled the number of tests your app needs to pass QA checks since your app now has complicated history management where it didn't need any (aside form ideology), instead of letting the browser and server work it out using the good old school ways of handling page state.
2. It's pointless waste to develop two set of practices, tools and processes for creating & maintaining public apps, vs. internal apps. What for? Feeling good inside that you saved 3% CPU on the server in view rendering? Please. I've gotten people fired over insisting on using their own pet practices like these (with no provable real-world benefit) over common sense, and wasting the business time and money.
3. In my practical the line between an intranet app and Internet apps is thing. So if an internal app becomes public (in a limited or full-blown capacity), it's a good idea you don't have to drop all the UI code and start over, mkay.
I write intranet apps for a living (they mix server-side and client-side rendering).
I wasn't referring to intranet vs. internet apps, but rather apps that generate public content that can be viewed without authentication (e.g. Twitter) vs. apps whose information is entirely restricted to authenticated users (e.g. GMail). Basically: does the app generate stuff that needs to be crawled by a search engine?
While client-side routing and state preservation used to be a very difficult thing, these days it's actually pretty straightforward (ngRoute, Backbone router, Ember router, etc).
While client-side routing and state preservation used to be a very difficult thing, these days it's actually pretty straightforward (ngRoute, Backbone router, Ember router, etc).
The most scalable way of rendering templates is doing it on the client, since that means users get a dedicated machine for rendering the templates.
You're confusing server CPU usage with scalability and performance.
HTML template rendering on either the server or client is embarassingly parallel, as it just takes a viewmodel (basically) and populates a template of HTML with its variables, with zero other calls and dependencies.
You can scale this particular step to infinite number of servers, without any bottleneck appearing (hence, it's horizontally scalable).
And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach.
Request/response lag is critical in the way an app is perceived.
Also when it comes to CPU, as I already said in my previous response, view rendering is the cheapest step computationally you have in an app. Any other service takes more time and resources than that. So view rendering is never the bottleneck, and "optimizing" it away with complicated client-side shenanigans is the very definition of premature optimization.
HTML template rendering on either the server or client is embarassingly parallel, as it just takes a viewmodel (basically) and populates a template of HTML with its variables, with zero other calls and dependencies.
You can scale this particular step to infinite number of servers, without any bottleneck appearing (hence, it's horizontally scalable).
And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach.
Request/response lag is critical in the way an app is perceived.
Also when it comes to CPU, as I already said in my previous response, view rendering is the cheapest step computationally you have in an app. Any other service takes more time and resources than that. So view rendering is never the bottleneck, and "optimizing" it away with complicated client-side shenanigans is the very definition of premature optimization.
"And HTML template rendering on the server can be faster, because for client-side rendering you need at least two roundtrips to the server (fetch template, one; fetch content via JS, two), and for complex apps this becomes tens of HTTP requests (side panels, user context, footers, menus etc.), versus just one roundtrip for a server-based approach."
Nope.
The template fetch is only the first time.
Because the template/HTML is either cached on the browser or is compiled/inlined with the Javascript with the build pipelines.
"Request/response lag is critical in the way an app is perceived."
Yes it is and it is worse with server rendered pages. A typical size of a page fully dynamically generated on the server side could be a few times larger than that fetching of data/content.
Nope.
The template fetch is only the first time.
Because the template/HTML is either cached on the browser or is compiled/inlined with the Javascript with the build pipelines.
"Request/response lag is critical in the way an app is perceived."
Yes it is and it is worse with server rendered pages. A typical size of a page fully dynamically generated on the server side could be a few times larger than that fetching of data/content.
If you need to display some information, you use an abstraction called a "page" - a full HTML document served from a URL. You can generate the HTML using a variety well understood, easily tested server-side frameworks. You can even just serve static HTML saved in a file.
Pages are easy to scale, easy to link to and work on every device, platform and browser released since IE and Netscape 3 back in 1996 (or earlier if you don't need to rely on the Host header).
How about adding interactivity? That's where "forms" come in. Forms allow your application to request information from users and submit it back to your server using a simple and widely understood key/value mechanism.
By combining pages and forms you can build applications that work everywhere, are easy to link to, easy to maintain and can be scaled to handle anything you can throw at them.