7 ms·

Anything that requires JavaScript to fetch and display content.

by cmg 12y ago

VMG 12y ago
Well somebody tell Google and Facebook, they're probably missing out on a lot of revenue because of their broken websites.
- Piskvorrr 12y ago
  Broken != unprofitable.
- Millennium 12y ago
  Website != API. A cleverly-written API can exist in the same space as a Website (even the same URLs, if you differentiate by things like Accept: headers), but they're not the same thing. It's perfectly acceptable for Websites to include, and even require the use of, JavaScript. It's also perfectly acceptable to offer a JavaScript client for your API. In fact, you pretty much have to do that if you want your Website to work with the API anyway. What's not OK is for an API to require downloading and using additional JavaScript while the API is being used. As a contrived (and somewhat ludicrous) example, let's say that I queried "http://foo.com/bars" http://foo.com/bars" for some kind of collection. It's OK to return the collection. It's even OK to use an HTTP redirect if the collection actually resides elsewhere: HTTP 302, perhaps, with a Location of "http://foo.com.bazes" http://foo.com.bazes". What's not OK is to return a line of JavaScript reading "window.location = 'http://foo.com/bazes';" http://foo.com/bazes';" which might work for the browser, but wouldn't work for most other clients.
twerquie 12y ago
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
- acdha 12y ago
  On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time.
  - ceejayoz 12y ago
    > Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time. No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.
    - hartator 12y ago
      I think he was making reference to the DOM rendering in the twitter website which used to be on client side until recently when they have switched back to server side rendering. But, it's very similar to pre-rendering React components on the server then mounting it so it might not be a total waste, that was a fad that didn't make a lot of sense for the time though.
    - acdha 12y ago
      They did more than just switch to the history API. During that period, if anything went wrong, you saw a blank page and, of course, robots saw only the generic launcher HTML instead of any content. Now, here's what a tweet looks like without JavaScript enabled: https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-03-20%2019.42.30.png?dl=0 https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-... Here's what it looks with JavaScript enabled: https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-03-20%2019.42.38.png?dl=0 https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-... (The main difference would be that things like the search & menus are either interactive controls or simple links to basic HTML forms depending whether JavaScript loads) During the hashbang era you couldn't use a page without a full rendering ending. Now, however, all of the content is available with fairly rich markup: https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2Fstatus%2F578935560187826176 https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2F...
- kenko 12y ago
  Speaking as someone who often uses text-mode browsers on the web, I wish this would actually happen.
- tlrobinson 12y ago
  The two are not necessarily mutually exclusive, especially with JavaScript frameworks you can run on the server to render the initial page, which then gets wired up to the client-side application. i.e. "Isomorphic JavaScript" [1][2] [1] http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ http://nerds.airbnb.com/isomorphic-javascript-future-web-app... [2] http://isomorphic.net/ http://isomorphic.net/
- bane 12y ago
  Your server should just be providing data that's displayed by the JS App. The JS app can handle a bunch of requests, but each request should provide something useful and be accessible from curl. bonus, it makes it easier to write your app in other languages or for other platforms since the web server really is a server and the front-end is just a client.
- IgorPartola 12y ago
  I really wish building single-page apps was better supported by browsers. The current setup is to try to kludge over the fact that DOM is for documents, not apps, and use the awfulness that is CSS and current layout paradigms (note, no CSS is strictly worse than yes CSS, but that doesn't make CSS good). Breaking away from the DOM but keeping the ability to remotely load code and static assets would be the best of both worlds. Something like Google Maps is an application, not a document. Why are we rendering it with a document renderer? Why are we styling it with CSS, which is again, document-oriented? The good part about single page apps is that they deliver a package of code, then are able to keep local state and communicate with the server over a stateless protocol. Oh, and the current breed runs on a platform (browsers) that is installed on every PC and mobile device. Browsers just need a better format for delivering packages of code and better support for these than "manipulate the DOM".

Anything that requires JavaScript to fetch and display content.

by cmg 12y ago

Anything that requires JavaScript to fetch and display content.

VMG 12y ago

Well somebody tell Google and Facebook, they're probably missing out on a lot of revenue because of their broken websites.

Piskvorrr 12y ago
Broken != unprofitable.
Millennium 12y ago
Website != API. A cleverly-written API can exist in the same space as a Website (even the same URLs, if you differentiate by things like Accept: headers), but they're not the same thing. It's perfectly acceptable for Websites to include, and even require the use of, JavaScript. It's also perfectly acceptable to offer a JavaScript client for your API. In fact, you pretty much have to do that if you want your Website to work with the API anyway. What's not OK is for an API to require downloading and using additional JavaScript while the API is being used. As a contrived (and somewhat ludicrous) example, let's say that I queried "http://foo.com/bars" http://foo.com/bars" for some kind of collection. It's OK to return the collection. It's even OK to use an HTTP redirect if the collection actually resides elsewhere: HTTP 302, perhaps, with a Location of "http://foo.com.bazes" http://foo.com.bazes". What's not OK is to return a line of JavaScript reading "window.location = 'http://foo.com/bazes';" http://foo.com/bazes';" which might work for the browser, but wouldn't work for most other clients.

twerquie 12y ago

Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s

acdha 12y ago
On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time.
- ceejayoz 12y ago
  > Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time. No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.
  - hartator 12y ago
    I think he was making reference to the DOM rendering in the twitter website which used to be on client side until recently when they have switched back to server side rendering. But, it's very similar to pre-rendering React components on the server then mounting it so it might not be a total waste, that was a fad that didn't make a lot of sense for the time though.
  - acdha 12y ago
    They did more than just switch to the history API. During that period, if anything went wrong, you saw a blank page and, of course, robots saw only the generic launcher HTML instead of any content. Now, here's what a tweet looks like without JavaScript enabled: https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-03-20%2019.42.30.png?dl=0 https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-... Here's what it looks with JavaScript enabled: https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-03-20%2019.42.38.png?dl=0 https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-... (The main difference would be that things like the search & menus are either interactive controls or simple links to basic HTML forms depending whether JavaScript loads) During the hashbang era you couldn't use a page without a full rendering ending. Now, however, all of the content is available with fairly rich markup: https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2Fstatus%2F578935560187826176 https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2F...
kenko 12y ago
Speaking as someone who often uses text-mode browsers on the web, I wish this would actually happen.
tlrobinson 12y ago
The two are not necessarily mutually exclusive, especially with JavaScript frameworks you can run on the server to render the initial page, which then gets wired up to the client-side application. i.e. "Isomorphic JavaScript" [1][2] [1] http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ http://nerds.airbnb.com/isomorphic-javascript-future-web-app... [2] http://isomorphic.net/ http://isomorphic.net/
bane 12y ago
Your server should just be providing data that's displayed by the JS App. The JS app can handle a bunch of requests, but each request should provide something useful and be accessible from curl. bonus, it makes it easier to write your app in other languages or for other platforms since the web server really is a server and the front-end is just a client.
IgorPartola 12y ago
I really wish building single-page apps was better supported by browsers. The current setup is to try to kludge over the fact that DOM is for documents, not apps, and use the awfulness that is CSS and current layout paradigms (note, no CSS is strictly worse than yes CSS, but that doesn't make CSS good). Breaking away from the DOM but keeping the ability to remotely load code and static assets would be the best of both worlds. Something like Google Maps is an application, not a document. Why are we rendering it with a document renderer? Why are we styling it with CSS, which is again, document-oriented? The good part about single page apps is that they deliver a package of code, then are able to keep local state and communicate with the server over a stateless protocol. Oh, and the current breed runs on a platform (browsers) that is installed on every PC and mobile device. Browsers just need a better format for delivering packages of code and better support for these than "manipulate the DOM".