Live data from Hacker News

Progressive Enhancement Is Dead

tomdale.net

121–130 of 263 posts

Re: Progressive Enhancement Is Dead

#121
post #78
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 think that issue, while valid, is entirely different from what OP is talking about. That is the question of client to server side rendering tradeoff, and it looks something like this in my view: - If you have a website that people will come to then spend a bit of time in different views (like gmail, facebook, or an analytics dashboard), it will usually pay off to dock the initial load time a bit in exchange for muc…

It's no secret that you need to minify your scripts and pass them along in a single request and put them at the bottom where they won't be blocking the UI to render. You should also link to CDN's to avoid that costly lookup or wait for the HTTP request hit (which is just so much larger when you're talking about it coming from the server (hopefully its light JSON and not a beast riddled with server-side templates.

Bustle is an example used by Tom Dale, and their js app is what? Not even 150kb? your headers alone are probably slowing you much more than this.

Locking the UI is bad, but it's not all JS apps that lock up the page as the browser puts it all together. You just need to know how the browser reads your styles and scripts and put them in the right place.

Re: Progressive Enhancement Is Dead

#122
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 feel like this point is sort of implied by the fact that he said just "Don't be ashamed to build 100% JS apps" and not "Build 100% JS apps for everything". But it's still good to spell this out explicitly.

It's more than implied by the OP; he did, in fact spell this out explicitly: "Of course, there will always be cases where server-rendered HTML will be more appropriate."

Re: Progressive Enhancement Is Dead

#123
post #97

Earlier quoted context omitted.

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

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

And whilst a vanishingly small percentage of people were using Mozilla, why not? If Mozilla wanted to get people to use it, it had to be compatible with (most) of the existing web.

Similarly, I won't be testing my websites in Soguo or Yandex until more than a vanishingly low percentage of people are using them on those sites.

Re: Progressive Enhancement Is Dead

#124
post #44

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.

_escaped_fragment_ is a bit of a hack, but it also provide enormous benefit. It allows you to gain all the benefits this article is talking about (which I won't repeat here) and still make you site crawlable without duplicating code.

You are right about one thing, it is a pain to setup. Much harder than it sounds at first. After doing it a few times, I finally got sick of it and built http://www.BromBone.com. It's a service that takes generates the html snapshots for site owners and keeps them up to date. I hope it will let site owner keep all the positives and eliminate most of the new negatives.

Re: Progressive Enhancement Is Dead

#125
post #55
post #44

Earlier quoted context omitted.

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.

The problem is that now everyone who wants to build a decent crawler/scraper has to do it as well. Used to be any kid in his parents' basement could put wget and sed together and explore the internet. Now Timmy has to bolt a whole damn browser runtime onto his script to make sure he's getting the content text from blog posts and twitter feeds.

Asking Timmy to "step up his game" is heartless, and it'd be unnecessary if we were better citizens.

Re: Progressive Enhancement Is Dead

#126
post #93
post #52

Earlier quoted context omitted.

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!

I rather think the onus is on people like you to come up with a reason that they _shouldn't_.

Well, philosophically, I think having static content served in a backward compatible way is perfect. Pragmatically, I haven't found a good solution to do it without duplicating all the code. That by itself might be a very good reason as to why one would focus the development efforts on the 95% of users.

You say people like me. I'm more agnostic here.. just interested to understand the arguments of both side. I just think that a post saying "This is black. Period" doesn't add much to the discussion.

Re: Progressive Enhancement Is Dead

#127

Earlier quoted context omitted.

I have to assume, in Google’s case anyway, that they are indexing according to ‘what the user sees’. Not to do so would means lower-quality search results. Users don’t care how the page ‘happens’. I make this assumption because most of us don’t actually know how Google works, acting as a user’s proxy is in Google’s interest, and it is certainly within their technological capability. (Let me emphasize assume , again.)…

From Google's technical guidlines: "Use a text browser such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. If fancy features such as JavaScript, cookies, session IDs, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site." https://support.google.com/webmasters/answer/35769?hl=e…

Not sure what you are trying to say by merely copying and pasting text about random search engine spiders that may have trouble crawling you. Maybe you could explain?

With regard to Google, however, they are explicit in their support for JavaScript rendered sites:

https://developers.google.com/webmasters/ajax-crawling/docs/...

Amongst many other links.

Re: Progressive Enhancement Is Dead

#129
post #126
post #93

Earlier quoted context omitted.

I rather think the onus is on people like you to come up with a reason that they _shouldn't_.

Well, philosophically, I think having static content served in a backward compatible way is perfect. Pragmatically, I haven't found a good solution to do it without duplicating all the code. That by itself might be a very good reason as to why one would focus the development efforts on the 95% of users. You say people like me . I'm more agnostic here.. just interested to understand the arguments of both side. I just…

What duplication? Why do you need to use js to render text? I'm not saying that a user without js should expect all, or any of the bells and whistles. But to use client side js rendering to show a user a paragraph or two (like blogger), or literally a sentence (when twitter did client side rendering) is just insane. It breaks stuff, and is MORE work than just doing it the right way.

Re: Progressive Enhancement Is Dead

#130
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…

What, exactly, is the issue with writing a simple content site that requires JS? If you aren't pulling in half a MB of JS, but it does require scripting to function, I don't see the problem. Just because I could spend the effort to be progressive doesn't constrain me to have to do it. It doesn't make me a lazy programmer either: just pragmatic. 99.99% of the people visiting my site have JS enabled and I'm happy to su…

"99.99% of the people visiting my site have JS enabled"

Do you know that for a FACT, or are you just guessing?

Post reply on HN