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

241–250 of 263 posts

Re: Progressive Enhancement Is Dead

#241

Post by gnaritas »

asdasf wrote: post #237
gnaritas wrote: post #192

Earlier quoted context omitted.

That's the opposite way of putting it. The way of extra work to support edge case users that often aren't worth the effort. Now maybe it's worth it for a big enough site, but for the average site I doubt it ever is. I think it perfectly reasonable to ignore users who disable JavaScript for most websites.

It isn't extra work or an edge case. It is doing the baseline correct thing. I can't count the number of fad obsessed "web developers" who ask us why we serve html instead of javascript crap, while they take 3 times as long to produce a broken version of the same thing.

> It is doing the baseline correct thing.

You don't get to define what the baseline correct thing is for a business, profit does that. Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.

Re: Progressive Enhancement Is Dead

#242

Post by asdasf »

dragonwriter wrote: post #235
ris wrote: post #234

Earlier quoted context omitted.

"Because that is an utterly ridiculous strawman." Of course it is, but it's clearly an admitted strawman. What's wrong with people these days? You can't rhetorically explore someone's views without everyone jumping in and shouting "strawman" as if it's their new favourite word.

> What's wrong with people these days? You can't rhetorically explore someone's views without everyone jumping in and shouting "strawman" as if it's their new favourite word. A strawman -- which, as you admit, this was -- is very different from "rhetorically exploring someone's views". Its "rhetorically exploring something distinct from the views of your opponent, and using it to impugn the views of your opponent." W…

>A strawman -- which, as you admit, this was -- is very different from "rhetorically exploring someone's views"

No, it isn't. You are making the mistake of conflating a strawman with an argument built on a strawman as a logical fallacy.

Re: Progressive Enhancement Is Dead

#243

Post by asdasf »

kmfrk wrote: post #62
soljin2000 wrote: post #59

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…

It’s a myth that if you use a client side MVC framework that your application’s content cannot be indexed by search engines. In fact, Discourse forums were indexable by Google the day we launched. http://eviltrout.com/2013/06/19/adding-support-for-search-en... They are probably a good case to follow, if you want to see what people's experiences with SEO for JS-based services are.

Why do people who are against server side templates always provide "well, just use server side templates and client side rendering both!" as a solution? Hooray, I can write my app twice for no reason! Way to sell me on pure javascript for delivering content.

Re: Progressive Enhancement Is Dead

#244

Post by dragonwriter »

asdasf wrote: post #242
dragonwriter wrote: post #235

Earlier quoted context omitted.

> What's wrong with people these days? You can't rhetorically explore someone's views without everyone jumping in and shouting "strawman" as if it's their new favourite word. A strawman -- which, as you admit, this was -- is very different from "rhetorically exploring someone's views". Its "rhetorically exploring something distinct from the views of your opponent, and using it to impugn the views of your opponent." W…

>A strawman -- which, as you admit, this was -- is very different from "rhetorically exploring someone's views" No, it isn't. You are making the mistake of conflating a strawman with an argument built on a strawman as a logical fallacy.

> > A strawman [...] is very different from "rhetorically exploring someone's views"

> No, it isn't.

Yes, it is.

> You are making the mistake of conflating a strawman with an argument built on a strawman as a logical fallacy.

No, I'm not. If you are exploring their views rather than yourself constructing something new and distinct from their views, you aren't making a strawman, whether or not you also, implicitly or explicitly, are arguing against their position using whatever you are exploring, which would be the strawman fallacy in the case where you were constructing a strawman.

Re: Progressive Enhancement Is Dead

#245

Post by dllthomas »

gnaritas wrote: post #239
dllthomas wrote: post #231

Earlier quoted context omitted.

"Hardly, you have to consider the additional cost of attempting to support that additional 2%" That's certainly not how I calculate revenue...

Revenue isn't the right metric; profit is. My point is that chasing revenue isn't what good businesses do, they chase profit. I don't care about 2% additional revenue if doing so reduces profit due to the extra development and maintenance overhead and neither should any sane business person.

Obviously. This would have been a solid response to dreamfactory's comment.

Re: Progressive Enhancement Is Dead

#246

Post by asdasf »

gnaritas wrote: post #241
asdasf wrote: post #237

Earlier quoted context omitted.

It isn't extra work or an edge case. It is doing the baseline correct thing. I can't count the number of fad obsessed "web developers" who ask us why we serve html instead of javascript crap, while they take 3 times as long to produce a broken version of the same thing.

> It is doing the baseline correct thing. You don't get to define what the baseline correct thing is for a business, profit does that. Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.

>You don't get to define what the baseline correct thing is for a business, profit does that

That's what I am using.

>Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.

I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.

Re: Progressive Enhancement Is Dead

#247

Post by asdasf »

dragonwriter wrote: post #244
asdasf wrote: post #242

Earlier quoted context omitted.

>A strawman -- which, as you admit, this was -- is very different from "rhetorically exploring someone's views" No, it isn't. You are making the mistake of conflating a strawman with an argument built on a strawman as a logical fallacy.

> > A strawman [...] is very different from "rhetorically exploring someone's views" > No, it isn't. Yes, it is. > You are making the mistake of conflating a strawman with an argument built on a strawman as a logical fallacy. No, I'm not. If you are exploring their views rather than yourself constructing something new and distinct from their views, you aren't making a strawman, whether or not you also , implicitly or…

A strawman can be used to explore their views. That is the point. It is only a fallacy if you create a strawman, then argue against it and claim to have argued against the original point. That has nothing to do with anything that occurred in your conversation.

Re: Progressive Enhancement Is Dead

#248

Post by dragonwriter »

asdasf wrote: post #247
dragonwriter wrote: post #244

Earlier quoted context omitted.

> > A strawman [...] is very different from "rhetorically exploring someone's views" > No, it isn't. Yes, it is. > You are making the mistake of conflating a strawman with an argument built on a strawman as a logical fallacy. No, I'm not. If you are exploring their views rather than yourself constructing something new and distinct from their views, you aren't making a strawman, whether or not you also , implicitly or…

A strawman can be used to explore their views. That is the point. It is only a fallacy if you create a strawman, then argue against it and claim to have argued against the original point. That has nothing to do with anything that occurred in your conversation.

> A strawman can be used to explore their views.

No, it really can't. Using something meaningfully distinct to "explore" their views is the exact same logical fallacy as using something meaningfully distinct to "argue against" their views. What you are dealing with is something distinctly different than their views, whether you are "arguing against" it or merely "exploring" it.

And, even if it could, it still wouldn't be equivalent to exploring their views, so being called out for using a strawman when using a strawman -- for whatever purpose -- woudl still not be being called out for using a strawman whenever you rhetorically explore someone's views.

Re: Progressive Enhancement Is Dead

#249

Post by asdasf »

Why on earth is he framing it as though it has something to do with time? Like, there was a time when you couldn't rely on browsers having javascript, so progressive enhancement? Progressive enhancement wasn't because browsers didn't have javascript, it was because people turned it off. They still do. And horrible javascript "apps" that just show some text and pictures are only going to make that number get bigger.

Re: Progressive Enhancement Is Dead

#250

Post by Isofarro »

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…

"Bustle actually uses PhantomJS to create static versions of the site, for serving to search spiders."

What value dose using PhantomJS offer above what progressive enhancement gives you for free?

This feels like a contradiction. Avoiding progressive enhancement, and then bolting on a hack for search spiders in a way that is less robust than the technique you're avoiding.

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

The initial load is horribly slow. For example: http://www.bustle.com/articles/4549-pew-poll-american-people... took 10 seconds. That's very slow for a one page article.

That's gonna hurt people following links to the page. That's exactly the reason why Twitter walked away from it's JavaScript driven content and went for progressive enhancement. A substantial portion of new visitors will have a cold cache, and have this annoying wait for what is effectively a one page article. (cf. http://statichtml.com/2011/google-ajax-libraries-caching.htm... )

"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 JS disabled is so microscopic it just doesn't make sense to spend time on it."

Another contradiction. Progressive enhancement isn't a technical challenge, it is so brain dead simple.

So they figured out the number of users with JavaScript disabled is too small to warrant supporting. Interesting, except, progressive enhancement isn't solely about people with JavaScript disabled, right? cf: http://isolani.co.uk/blog/javascript/DisablingJavaScriptAski...

Also, so they ran the numbers of these, under the incorrect assertion that progressive enhancement only impacts people with JavaScript disabled. But did they run those same numbers that determined the number of search spiders wasn't microscopic, to justify the PhantomJS bodge you initially mentioned? Are you really implicitly asserting that there are far more search spider visitors to bustle.com than visitors with JavaScript disabled? (I'd love to understand the logic that lead to that determination).

So, what justification was there to spend time on building a PhantomJS site scraper to provide static content to search engine spiders, and yet fail to appreciate that progressive enhancement would have served that spider audience, as well as the JavaScript audience, as well as the variety of issues that progressive enhancement helps alleviate?

But, if bustle.com were a content site, then progressive enhancement is the way to go, right? But this is an ember app, so it is not a content site (clearly). Except when search spiders visit, then there's a need for a static version of each page. It's very confusion. is bustle.com an app or a website?

Also, how does bustle.com / ember, guarantee perfect delivery of assets other than HTML to a visitor's browser? How does it guarantee robustness?

For example, when using a CDN, how does it manage when this happens: http://www.theregister.co.uk/2012/01/05/google_opendns_clash...

How does bustle.com / ember protect your JavaScript so that when a third-party chunk of JavaScript (like Google Analytics, Disqus, Facebook, ChartBeat, Quantcase, WebTrends) does something funky, or hiccups and causes a JavaScript error?

Post reply on HN