4 ms·

> Don’t be ashamed to build 100% JavaScript applications. You may get some incensed priests vituperating you in their blogs. But there will be an army of users

> Don’t be ashamed to build 100% JavaScript applications. You may get some incensed priests vituperating you in their blogs. But there will be an army of users (like me) who will fall in love with using your app. We all want wonderful experiences as users. The crux is almost a question of "how we want things to be" and "how we want to get there". For me, the 100% JS MV movement is wonderful for a specific genre of app: An app that is: * Behind an intranet * Behind a paywall * Behind a login-wall * Prototypes / Demos / PoCs / etc. But for the open web -- wikipedia, blogs, discussion forums, journalism (etc.) this movement detracts from the web as a whole, in that it excuses developers from having to worry about degraded and/or non-human consumption of their websites' data. We have to ask ourselves what we, as humanity, want from the web. Do we really want a web of 100% bespoke JavaScript MV web-apps with no publicly consumable APIs nor semantic representations? If that is the intent and desire of the developers, designers and otherwise educated-concerned web-goers, then fine, let's do that and hope it works out okay... But there is an alternative that has its roots already planted deep in the web -- the idea and virtue of a web where you can: * Request an HTTP resource and get back a meaningful and semantically enriched representation * Access and mash-up each-others' data, so as to better further understanding & enlightenment * Equally access data and insight via any medium, the latest Chrome or the oldest Nokia So, please, go ahead and create a 100% JS front-end but, if you are creating something for the open web, consider exposing alternative representations for degraded/non-human consumption. It doesn't have to be progressively enhanced. Imagine for a moment if Wikipedia was one massive Ember App... And no, Wikipedia is not an exception from the norm -- it is the embodiment of the open web.

mwcampbell 13y ago
Strongly agree. The day that merely reading Wikipedia requires JavaScript will be the day that the open Web is dead.
tomdale 13y ago
Every Ember.js app, by definition, connects to an API that does all of the things you are asking for. Seriously, open up any Ember.js app and look at the network traffic. You'll see a series of requests, usually using very RESTful URLs, that requests the document. The only difference is that, instead of HTML, where you are conflating the markup and the content, you get a nice, easily-consumable version of the document in JSON form. There is literally no change to the web here, other than the UIs are faster and better, and it's easier for me to consume JSON documents than trying to scrape HTML.
- padolsey 13y ago
  That could work -- if the JSON is intended for public consumption, and if it is documented as so. The problem, I'd argue, with JSON is that it does not intentionally facilitate semantic annotations, unlike HTML(5). I'd argue that a properly marked-up HTML5 representation of a piece of data is more useful than a bespoke JSON structure with crude naming liable to change without notice. The benefit I get with an HTML representation is that it's the exact thing that was intended for the user to read/consume, whereas JSON is awkward to divine meaning from without the crucial app-specific view-logic that turns it into DOM. How would you reconcile the need for an open-semantic-web with arbitrary JSON structures with no governing semantic standard? EDIT: An example of a potential problem: Please take a look at how the Bustle app you referenced brings its article content to the front-end: E.g. http://www.bustle.com/articles/4470-why-we-should-root-for-lamar-odom http://www.bustle.com/articles/4470-why-we-should-root-for-l... View source. It's not a public REST API (not visibly so); it's awkwardly embedded as literal JS in the HTML document itself... That'd be hell to publicly consume through any kind of automation.
  - tomdale 13y ago
    You are building up a strawman against JSON without acknowledging that every problem you outline applies just as much, if not more, to HTML. Is the HTML of any popular website publicly documented? Is there any guarantee that an XPath to a particular value won't change? Is there any guarantee the data I need is marked up with semantically accurate class names? No. HTML is intended for public consumption—by a human, at a particular time. It is not a data interchange format. Contrast that with things like Twitter or GitHub, which provide a versioned JSON API that is guaranteed not to change. Your web site becomes just another consumer of that API. JSON contains all of the data you need, but in a way designed to be consumed by computers, and you don't have to do all of that awful HTML scraping. And as for Bustle not having a public JSON API, well, here you go: curl -H "Accept: application/json" http://www.bustle.com/api/v1/sections/home.json http://www.bustle.com/api/v1/sections/home.json A versioned JSON API that is guaranteed not to change. Can any public site on the internet guarantee that about its HTML?
    - 13y ago

mwcampbell 13y ago

Strongly agree. The day that merely reading Wikipedia requires JavaScript will be the day that the open Web is dead.

tomdale 13y ago

Every Ember.js app, by definition, connects to an API that does all of the things you are asking for. Seriously, open up any Ember.js app and look at the network traffic. You'll see a series of requests, usually using very RESTful URLs, that requests the document. The only difference is that, instead of HTML, where you are conflating the markup and the content, you get a nice, easily-consumable version of the document in JSON form. There is literally no change to the web here, other than the UIs are faster and better, and it's easier for me to consume JSON documents than trying to scrape HTML.

padolsey 13y ago
That could work -- if the JSON is intended for public consumption, and if it is documented as so. The problem, I'd argue, with JSON is that it does not intentionally facilitate semantic annotations, unlike HTML(5). I'd argue that a properly marked-up HTML5 representation of a piece of data is more useful than a bespoke JSON structure with crude naming liable to change without notice. The benefit I get with an HTML representation is that it's the exact thing that was intended for the user to read/consume, whereas JSON is awkward to divine meaning from without the crucial app-specific view-logic that turns it into DOM. How would you reconcile the need for an open-semantic-web with arbitrary JSON structures with no governing semantic standard? EDIT: An example of a potential problem: Please take a look at how the Bustle app you referenced brings its article content to the front-end: E.g. http://www.bustle.com/articles/4470-why-we-should-root-for-lamar-odom http://www.bustle.com/articles/4470-why-we-should-root-for-l... View source. It's not a public REST API (not visibly so); it's awkwardly embedded as literal JS in the HTML document itself... That'd be hell to publicly consume through any kind of automation.
- tomdale 13y ago
  You are building up a strawman against JSON without acknowledging that every problem you outline applies just as much, if not more, to HTML. Is the HTML of any popular website publicly documented? Is there any guarantee that an XPath to a particular value won't change? Is there any guarantee the data I need is marked up with semantically accurate class names? No. HTML is intended for public consumption—by a human, at a particular time. It is not a data interchange format. Contrast that with things like Twitter or GitHub, which provide a versioned JSON API that is guaranteed not to change. Your web site becomes just another consumer of that API. JSON contains all of the data you need, but in a way designed to be consumed by computers, and you don't have to do all of that awful HTML scraping. And as for Bustle not having a public JSON API, well, here you go: curl -H "Accept: application/json" http://www.bustle.com/api/v1/sections/home.json http://www.bustle.com/api/v1/sections/home.json A versioned JSON API that is guaranteed not to change. Can any public site on the internet guarantee that about its HTML?
  - 13y ago