> Reload this page with JavaScript disabled and see how the content was "prerendered" at compile time.
To their credit, the page is not blank, unlike a lot of "web" authors out there. Unfortunately there are several links that point to invalid and nonexistent fragments like #/home/ instead of actual elements of that or some other document, which really means the framework is happy to make a siloed javascript app and does not ensure you are responsibly making all your content available as part of the world-wide web at some stable URL where third parties can reference it.
tl,dr: this encourages single-page apps which will be the death of the web.
> tl,dr: this encourages single-page apps which will be the death of the web.
The first sentence of the "Web Apps" section is Web applications are not documents. This is a motto that I believe a lot of people who think the way you do should take pause and reflect upon.
After years producing web apps, I came to the conclusion that non-js web apps are some of the craziest ideas ever. The browser without js is a tool to consume and, to some very minimal extent, produce documents. I consider most non-js apps on the browser to be huge hacks at best, that do what they can to circumvent the shortcomings of that technology. And heaven knows that shortcomings are a dime a dozen (lack of http method on anchors, limited to GET and POST, to only name a few).
If you do embrace building apps with js, then you need to stop thinking in the document-oriented paradigm, otherwise you'll be making some unnecessary compromises at the expense of your end users, and you'll be making your life harder as a developer. For instance, some actions that the standalone or native version of your application does with a single click might require 3 or 4 user interventions on the browser version, simply because you wish to remain true to some dogma.
A while back I've embraced the idea that web apps aren't documents. It freed me as an app developer to make choices that were otherwise unthinkable in a previous mindset. My APIs make more sense, my interfaces are more intuitive and my users are the happier for it.
"Web app" is usually a misnomer. The world-wide web is the linked universe of addressable documents (resources). An app which is not just some behavior added to that core architecture is not capable of becoming a part of the web. It's a ghetto of single-purpose data, exactly like the client/server apps from the 1980s, only this time with a deployment model that gets it past gatekeepers in IT. It shouldn't be called a "web app" simply because its installer is delivered via HTTP, and people working on such projects ought to be aware that the network they're building is competing with the web for content while being far more hostile to hacking and mashups.
>is not capable of becoming a part of the web. It's a ghetto of single-purpose data
Sorry, but with the exception of screen-scrapping, 99.9% of the web IS single-purpose data.
Some people imagine a magical unicorn world where webpages inter-operate etc, but that never was the case. And I don't want my Gmail data messing with my Adobe Kuler data, my Amazon data, or my eBay data anyway.
For inter-operation, we have RSS, REST, AJAX, JSON and co. Web pages themselves, as served to the end user, are not were it should be expected to be (and never was there in the first place).
I think the "web" in "web app" is for web browser app, not world wide web app. Whether it should or shouldn't be called differently is by now besides the point. It's certainly not the first concept to be allegedly ill named and it won't be the last. The most important thing is to understand the nuances when creating resources to be consumed or produced over http.
> people working on such projects ought to be aware that the network they're building is competing with the web for content while being far more hostile to hacking and mashups.
On the contrary, case in point APIs: they're often distributed using formats such as JSON or XML, which weren't designed to be particularly web friendly the way HTML is. They're still much more suitable to hacking and mashups, because they go beyond the conceptual limitations of the web to fully embrace the potential of HTTP.
The only thing required for any app, even js intensive ones, to be part of the web is to provide some urls that resolve to web friendly versions of their resources and that really isn't that complicated.
What en earth makes you think that? Yeah, the current way of doing SPAs without fallback for non-js clients is horrible and the alternative of a two-way site too much work.
But the solution is obvious: if what you serve is of any meaning to anyone else, you also have some sort of content consumption API. Sooner or later we'll standardize some RESTy way of doing it for apps, and for blogs and magazines RSS/Atom feeds are already good enough content-consumption pseudo-APIs.
The API will be the Javascript-less version of all sites, and all sites will have an API. Then people will make UIs for the content consumption parts of these (pseudo-)APIs, and these UIs, even if they run themselves in browsers will become the new "browsers" and gain their own scripting level features, while "old browser apps" will become today's equivalent of desktop apps.
It's not "death" of the web, just "endless, infinite pain" for us developers working in its perpetual shifting front-end... it's way worse than death! :)
Nobody used "semantic HTML" to do anything serious with cross-webpage interoperability (where nobody means less than 1% of web developers/pages). As for TBL's "semantic web" that was dead on arrival.
And that will be exactly what we end up getting back in the end; single page applications that treat a click as functionally equivalent to following a link.
> doing SPAs without fallback for non-js clients is horrible
Why? The number of customers that a) don't use javascript and b) would pay for a service only if they have a non-javascript version is incredibly small in my experience. If the service has value, non-javascript users will enable javascript to use it.
I'm ok with a SPA as long as long you also have an API. I'm also ok with a SPA as long as your app is just a content consumption app, e.g. you don't publish original content that is not accessible through other sources. But since even aggregating or re-mixing content or comments can actually be seen as creating "new content", the distinction is blurry.
My point is that we should be able to consume data on the web without having the full-browser+javascript to be the lowest level interface we have to this data.
And about the clients' interests: well, I think it is our duty as professionals to be able to see past our clients' interest too, to try and shape the future of the field we work in to the right shape, at least after we provide the clients with with good enough solutions (and yes, we should remember to stop at "good enough", because there's no point polishing a short-sighted solution, instead of working more to reshape it into a more future oriented one) and ensure short term profitability. Now, we don't all have a common notion of this "right shape" of the future of the web, but I do my best to shape it as much as I can towards "my kind of people's right shape" and push our vision up as many people's throats as we can, hopefully helping us all escape from this hell of short-sighted short-term clients' interests based decisions that brought us the current overcomplicated mess that the web is right now.
> I'm ok with a SPA as long as long you also have an API
That would be great, but I have no faith that the same developers who are today shirking responsibility for shipping their content as HTML with transcluded resources at stable URLs, will someday start shipping their content in a stable schema and API. They think nothing of turning their data and URLs upside down and changing their client to match, because they have a blind spot around the very idea that theirs is not the only client.
The "prerendering" function isn't for human consumption. It's meant to make the page spiderable by search engines. Since it's a single-page app all content is on the page so the #/home/ links aren't really something a search engine would care about.
I think the days when you'd put HTML documents on the web like emails with no dynamic behavior in them are over, and have been for quite some time now. If you have content you want people to read and act on, you're going to want to develop the user experience.
I don't think SPA's will be "the death of the web" exactly, but there is a big problem with this muddling of concerns... browsers get more and more confused with each passing year - is it for browsing hypermedia content, or is it a poor man's X server? Is the browser good at navigating, following links and rendering HTML, or is it good at becoming an application delivery platform? Or is it both? Why should it be both? Separation of concerns anybody?
Having content and apps on the web makes perfect sense to me, but I can't help but think we need to do something different in terms of delivering apps over the web. The problem is, the browser itself is the only "runtime" that's guaranteed to be available in all browsers on all platforms. Something like Java had tons of promise at one time for handling the "app" side, but Sun screwed the pooch by not shipping a JVM with reasonable startup times until years too late, and missing the boat on security. Now Java has a such a bad rep as a consumer-facing tech, that it would be just-short-of-impossible to revive it, even though it's probably still the best solution for "apps over the web" in many ways.
Maybe Google's NaCl / PNaCl will eventually help, but I'm not holding my breath.
I like to think that as web apps take off, we might see the emergence of one or more frameworks that specialize in rendering pure documents for the person who doesn't want to use javascript or wants minimal loading of assets.
The reason I suggest this might happen is that for years we've been trying to get away with munging the visual design while still preserving the notion of the document. Web apps take it to the extreme where documents are most often deliver as pure data (i.e. JSON). This move towards having all content as pure data is a great first step towards supplying the content for a pure text only framework.
I like this possible direction the world can take much more. Progressive enhancement was flawed from the start. Let interfaces be super rich, but supplied by content in pure data form that can also be delivered via the simplest interface ever, like basic semantic HTML.
To their credit, the page is not blank, unlike a lot of "web" authors out there. Unfortunately there are several links that point to invalid and nonexistent fragments like #/home/ instead of actual elements of that or some other document, which really means the framework is happy to make a siloed javascript app and does not ensure you are responsibly making all your content available as part of the world-wide web at some stable URL where third parties can reference it.
tl,dr: this encourages single-page apps which will be the death of the web.