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

51–60 of 263 posts

Re: Progressive Enhancement Is Dead

#51

Post by wycats »

mwcampbell wrote: post #40
austinz wrote: post #32

Earlier quoted context omitted.

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, suc…

Today's reasonably-built JavaScript-based applications are built using HTML as templates. They don't use a as a button, they use a as a button. They don't invent navigation using JavaScript, they use tags and a JavaScript-based router.

Take a look at discuss.emberjs.com, which uses Discourse (which is powered by Ember... INCEPTION):

On the front page, every navigation, including the links on top and the links to individual forum posts, are tags with an href. When you navigate to a forum post, the buttons to reply, flag, favorite, etc. are all elements.

You definitely want to be (1) using a framework that encourages the use of HTML for the view layer, and (2) using a framework that makes URL-based navigation easy. There's nothing about JavaScript-based applications that make semantic markup and URLs impossible, and today's screen readers don't care whether your HTML was rendered using JavaScript or from the server.

I think you're jaded because the previous generation of frameworks (SproutCore, Capuccino, Ext.js) shunned HTML in favor of all-JavaScript UI toolkits, but that framework style has fallen out of favor. HTML is here to stay.

Re: Progressive Enhancement Is Dead

#52

Post by d0m »

mynameisme wrote: post #9

There's no reasons sites like tumblr shouldn't work without javascript. Period. And while there are some things on the web that are genuine applications (trello, dashboards, etc.), the vast majority of things are content driven, which should never require js.

You claim facts without explaining your reasoning.. Let me put it this way using your own vocabulary:

    There's no reasons sites like tumblr *should work without javascript*. Period.
Why why!

Re: Progressive Enhancement Is Dead

#53

Post by TelmoMenezes »

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.

Maybe I'm getting old but sometimes I really really don't want real time updates.

Re: Progressive Enhancement Is Dead

#54

Post by mnutt »

diminish wrote: post #27
glesica wrote: post #6

"And most importantly: 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." This statement needs a huge, HUGE caveat that you should only be building 100% JavaScript apps in situations where doing so makes sense . For example, I find the new Blogger "web app" i…

i m still opening a dozen tabs and reading them whenever i want, unfortunately most newer js only web blogs such as inc mobile, end up having a lot of errors and white pages.. i understand your newly found js excitement with your full ember.js app, but do'nt forget the lessons from java the browser plugin and flash. 1. ok you re real time, but don't assume i m watching your site like a tv 2. dont consume my precious…

I think some browsers already slow down the render loop in non-visible tabs, but the much nicer solution (if people use it) is the Page Visibility API.

Re: Progressive Enhancement Is Dead

#55

Post by slig »

pornel wrote: post #44
mmastrac wrote: post #30

Earlier quoted context omitted.

There have been techniques for dealing with this for a very long time: https://developers.google.com/webmasters/ajax-crawling/docs/... And this is only an issue for pages where you actually want to expose your content to search engines.

Sigh, Google-only websites. _escaped_fragment_ is a stupid hack that requires hardest bit of work needed for progressive enhancement, but provides none of the benefit.

It's not like other search engines can't step up their game and build the same functionality.

Re: Progressive Enhancement Is Dead

#56

Post by huhtenberg »

pornel wrote: post #44
mmastrac wrote: post #30

Earlier quoted context omitted.

There have been techniques for dealing with this for a very long time: https://developers.google.com/webmasters/ajax-crawling/docs/... And this is only an issue for pages where you actually want to expose your content to search engines.

Sigh, Google-only websites. _escaped_fragment_ is a stupid hack that requires hardest bit of work needed for progressive enhancement, but provides none of the benefit.

Google has been crawling AJAX'd websites bypassing the _escaped_fragment_ mechanism for at least a year now.

Re: Progressive Enhancement Is Dead

#57

Post by slig »

sergiotapia wrote: post #48
rwmj wrote: post #7

Earlier quoted context omitted.

And people using NoScript.

And who cares about people using NoScript, no one should. They are in the vast minority, not worth the trouble accommodating for them.

And they know they're using NoScript. If the website doesn't work, they can decide if they want to enable or not. It's their burden, not mine.

Unless, of course, my client wants a 100% working no-script webapp/site. Then I'll happily charge for the extra time building it.

Re: Progressive Enhancement Is Dead

#59

Post by soljin2000 »

Only if you never need any referrals from search engines. I know a site that has this awesome locally sourced food delivery/pickup system. Connecting consumers directly with the growers.

Their site is 100% in JS. And if you google for anything even remotely close to what this site sells you simply cannot find them.

Unless you are a members only app site would I say progressive enhancement is dead. Well that is unless you care about the millions of users on slower mobile connections with crappy smart phones.

Re: Progressive Enhancement Is Dead

#60

Post by padolsey »

tomdale wrote: post #42
padolsey wrote: post #35

Earlier quoted context omitted.

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

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 versioned JSON API is awesome, I am not denying that. I also don't deny that the current state of the HTML markup on most sites is semantically rubbish.

Regardless of this entire PE debate, we would still have a problem, on the web, of data being out of reach due to walled apps that only serve rubbish HTML.

The problem of open + semantic data is very relevant to this discussion but we're pretending that one "side" has all the answers. I want a better web -- more open -- more semantic -- and maybe some shimmer of a truly semantic web[1] will emerge in the next 20 years.

So, yes, a 100% JS App is 100% awesome if, IMHO, it has:

* A publicly documented and consumable REST API

* Semantically enriched data through that API

* Some kind of degraded state NOT just for search-engines but for older devices and restrictive access (e.g. behind national/corporate firewalls)

I am not interested in being one side or another regarding this PE feud, and I am sure you're not either. I am trying to question what is best for the web and humanity as a whole. I don't think we have a silver-bullet answer. I do think it's necessary to dichotomize walled web-apps and open websites, and the latter deserve additional thought regarding usability, accessibility and semantics.

[1] http://en.wikipedia.org/wiki/Semantic_Web

Post reply on HN