3 ms·

"Agreement: Progressive enhancement isn’t for building real apps. All the technologies follow from the view that serious JavaScript applications require proper

"Agreement: Progressive enhancement isn’t for building real apps. All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code. Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s not even a novelty any more)." I really don't understand this. While I get WAI-ARIA for accessability, Google still depends on static content for indexing, last I checked. Are we just stuck doing two separate page flows? If that's the case, why bother with the framework at all if it's just doubling the workload? (Note: I'm looking at a way to allow the initial rendering of the page statically, then using backbone to attach to events after the fact and use as a single page application after the fact. Handlebars and Hogan handle the templating on client and server side, and both client and server models are extending a common model shared with both. It will be great if it all works. ;)

ilaksh 14y ago
See my comment in this thread, I have a link to my github repo (and a video describing the project) where I have a solution to the static content on dynamic websites problem. My solution is to use PhantomJS to render static pages using the same code that the dynamic pages are rendered with.
asolove 14y ago
There are two answers here. If your page is a content page, you should follow the pattern that YUI's MVC uses, which is to hydrate your model objects by scraping the html on the page. So you need templates shared (or similar) on back-end and front-end, you render them on the back-end with initial content, when dom ready happens you create models instances with the data that you grep out of that markup, and then as soon as the user does something you re-render that data with the client-side templates. Needless to say, this is less than fun. (Especially if you do i18n and need templates that can do so on both front- and back-end.) The second answer is: web apps usually aren't for searchable content. Let's say you're a startup with information about local restaurants, and you add a Backbone app for finding things nearby and filtering by type. Google should crawl your external site (home page, marketing pages, etc.) as well as your data pages (one page per restaurant, one per type per city, etc.). And all those pages link to or include your shiny new restaurant-finder Backbone app/widget. But Google doesn't need to crawl that app. For most users of Backbone, where their app sits behind a login wall anyway, worrying about search engines is irrelevant.
nl 14y ago
Google still depends on static content for indexing Actually, no. Google now will run JS in some cases[1]. I don't believe they have made public statements about when they do this, but I would suspect it may to to verify that the ajax-crawlerable version of the site[2] matches the real one. [1] http://swapped.tumblr.com/post/23133779276/google-bot-now-crawls-arbitrary-javascript-sites http://swapped.tumblr.com/post/23133779276/google-bot-now-cr... [2] https://developers.google.com/webmasters/ajax-crawling/ https://developers.google.com/webmasters/ajax-crawling/
andybak 14y ago
Throwing away Progressive Enhancement makes sense for things way at the 'App' end of the spectrum but it's going to spread like a cancer right up to the 'Content' end of things and if we're not careful one day we're going to look back and realise we've broken the web.

ilaksh 14y ago

See my comment in this thread, I have a link to my github repo (and a video describing the project) where I have a solution to the static content on dynamic websites problem. My solution is to use PhantomJS to render static pages using the same code that the dynamic pages are rendered with.

asolove 14y ago

There are two answers here. If your page is a content page, you should follow the pattern that YUI's MVC uses, which is to hydrate your model objects by scraping the html on the page. So you need templates shared (or similar) on back-end and front-end, you render them on the back-end with initial content, when dom ready happens you create models instances with the data that you grep out of that markup, and then as soon as the user does something you re-render that data with the client-side templates. Needless to say, this is less than fun. (Especially if you do i18n and need templates that can do so on both front- and back-end.) The second answer is: web apps usually aren't for searchable content. Let's say you're a startup with information about local restaurants, and you add a Backbone app for finding things nearby and filtering by type. Google should crawl your external site (home page, marketing pages, etc.) as well as your data pages (one page per restaurant, one per type per city, etc.). And all those pages link to or include your shiny new restaurant-finder Backbone app/widget. But Google doesn't need to crawl that app. For most users of Backbone, where their app sits behind a login wall anyway, worrying about search engines is irrelevant.

nl 14y ago

Google still depends on static content for indexing Actually, no. Google now will run JS in some cases[1]. I don't believe they have made public statements about when they do this, but I would suspect it may to to verify that the ajax-crawlerable version of the site[2] matches the real one. [1] http://swapped.tumblr.com/post/23133779276/google-bot-now-crawls-arbitrary-javascript-sites http://swapped.tumblr.com/post/23133779276/google-bot-now-cr... [2] https://developers.google.com/webmasters/ajax-crawling/ https://developers.google.com/webmasters/ajax-crawling/

andybak 14y ago

Throwing away Progressive Enhancement makes sense for things way at the 'App' end of the spectrum but it's going to spread like a cancer right up to the 'Content' end of things and if we're not careful one day we're going to look back and realise we've broken the web.