3 ms·

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

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.

badman_ting 13y ago
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.
- jakejohnson 13y ago
  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.
couchand 13y ago
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.
- mbleigh 13y ago
  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.
mbleigh 13y ago
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.

badman_ting 13y ago

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.

jakejohnson 13y ago
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.

couchand 13y ago

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.

mbleigh 13y ago
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.

mbleigh 13y ago

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.