Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Progressive Enhancement Is Dead

tomdale.net

Post reply on HN
Print view View original

31–40 of 263 posts

Re: Progressive Enhancement Is Dead

#31

Post by tomdale »

padolsey wrote: post #22

> 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 ap…

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.

Re: Progressive Enhancement Is Dead

#32

Post by austinz »

tomdale wrote: post #25
austinz wrote: post #21

Earlier quoted context omitted.

Not to mention stuff like accessibility that ends up being an afterthought for a lot of people.

Accessibility is a red herring. JavaScript apps work just fine with screen readers, especially if you support WAI-ARIA. http://words.steveklabnik.com/emberjs-and-accessibility

No, I totally agree that accessibility is possible if your app is JavaScript based. But if you're unaware of or you forget to add in accessibility features, you run the risk of failing much less gracefully for people who need those features than if there were more static content.

(This is, of course, a generalization; specific use cases may vary.)

Re: Progressive Enhancement Is Dead

#33

Post by jhh »

While I agree that you can assume Javascript being enabled I really think that "conventional" web development has still many advantages over making SPAs.

Business logic on the server, HTML generated on the server, conventional mvc-architecture, use ajax and push state to make it highly interactive.

Fine - you can assume JS being available, but from that it simply does not follow that you have to throw away the traditional (rails style) dev model of the web.

Re: Progressive Enhancement Is Dead

#34

Post by Joeboy »

leokun wrote: post #8
Pinckney wrote: post #3

I think the point that's overlooked here is that the offenders aren't the clever apps that would be impossible to write without javascript. Go ahead and write those. I'm happy for you, really. The problem is pages that require javascript to display static content. There are very few good reasons for an article, or an image gallery, or a homepage that could have been displayed just fine a decade ago to now need javasc…

Check out meteor.js for why JavaScript would be needed for "static only content". Real time updates. That's why. Everything is an app.

So, for static content that changes in real time.

Re: Progressive Enhancement Is Dead

#35

Post by padolsey »

tomdale wrote: post #31
padolsey wrote: post #22

> 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 ap…

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 documen…

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-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.

Re: Progressive Enhancement Is Dead

#36

Post by leokun »

anonymousab wrote: post #19
leokun wrote: post #8

Earlier quoted context omitted.

Check out meteor.js for why JavaScript would be needed for "static only content". Real time updates. That's why. Everything is an app.

Which is silly. If I'm just trying to view a news article from yesterday or a year ago, I shouldn't have to worry about what some silly script is trying to do. If the core of the content is or should be text, then there's no need for countless silly layers around it.

Maybe you want a PDF instead.

Re: Progressive Enhancement Is Dead

#37

Post by bluepnume »

andrenotgiant wrote: post #15

Progressive Enhancement is still important for CONTENT SITES Why? Search Engine accessibility. It used to be that Googlebot wouldn't find content loaded asynchronously, or links that rely on Javascript. Now it's different - You can confirm that Googlebot discovers a lot of Javascript links using Webmaster Tools: https://www.google.com/webmasters/tools/home?hl=en BUT - There's still no way to break from the "Page Para…

Having URLs which point to specific resources is still 100% possible for javascript web apps. Take a look at Ember, as an example, those guys place a load of emphasis on URLs as 1st class citizens in frontend web apps.

Re: Progressive Enhancement Is Dead

#38

Post by [deleted] »

tomdale wrote: post #10
toddmorey wrote: post #2

I pretty much agree with all of the points in this article. I do wonder, though, why Bustle.com (the example used) is an Ember.js app and why it displays nothing but a blank page if Javascript is turned off. Skylight makes perfect sense as a full JS app. But Bustle, a content site, seems to be more of an "interactive document" (as he mentions).

Bustle actually uses PhantomJS to create static versions of the site, for serving to search spiders. The advantage of using Ember.js for Bustle is that it's really, really, ridiculously fast. Seriously, try it. Go to bustle.com and click around. They could make it work without JavaScript, but they're a new company with a long list of technical challenges to solve. They ran the numbers and the percentage of users with…

[deleted]

Re: Progressive Enhancement Is Dead

#39

Post by FooBarWidget »

leokun wrote: post #8
Pinckney wrote: post #3

I think the point that's overlooked here is that the offenders aren't the clever apps that would be impossible to write without javascript. Go ahead and write those. I'm happy for you, really. The problem is pages that require javascript to display static content. There are very few good reasons for an article, or an image gallery, or a homepage that could have been displayed just fine a decade ago to now need javasc…

Check out meteor.js for why JavaScript would be needed for "static only content". Real time updates. That's why. Everything is an app.

When your only tool is a hammer, everything looks like a nail. There are valid use cases that meteor.js is awesome for, but one should avoid cargo culting.

Re: Progressive Enhancement Is Dead

#40

Post by mwcampbell »

austinz wrote: post #32
tomdale wrote: post #25

Earlier quoted context omitted.

Accessibility is a red herring. JavaScript apps work just fine with screen readers, especially if you support WAI-ARIA. http://words.steveklabnik.com/emberjs-and-accessibility

No, I totally agree that accessibility is possible if your app is JavaScript based. But if you're unaware of or you forget to add in accessibility features, you run the risk of failing much less gracefully for people who need those features than if there were more static content. (This is, of course, a generalization; specific use cases may vary.)

I think this is a valid generalization. On a page that doesn't use JavaScript, some links, form fields, and/or buttons may be unlabeled, but a blind user at least knows they're there and might be able to look at some hints to their functionality, such as URLs or element IDs. Moreover, the controls and interactions are standard. What happens if the developer attaches some functionality to a device-dependent event, such as onclick, on an undistinguished element such as a div? The element might be styled such that a sighted user knows it's intended to be clicked, but a blind user doesn't get this same information unless the element has an appropriate WAI-ARIA role. And how many web application developers are going to pay attention to ARIA as they craft their unique JavaScript-powered user experiences? Maybe I'm just cynical, but I'm guessing that outside of companies that have a strong incentive to get accessibility right so they can sell to governments and schools, the answer is "not many".
Post reply on HN