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

111–120 of 263 posts

Re: Progressive Enhancement Is Dead

#111

Post by _pius »

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…

From the article:

Of course, there will always be cases where server-rendered HTML will be more appropriate. But that’s for you to decide by analyzing what percentage of your users have JavaScript disabled and what kind of user experience you want to deliver.

Seems like a pretty big caveat to me.

Re: Progressive Enhancement Is Dead

#112

Post by icebraining »

kansface wrote: post #86
mynameisme wrote: post #14

Earlier quoted context omitted.

Is this something people even want in content driven sites though? Imagine reddit in real time, it would be a mess and impossible to keep track of what you last read.

Why should users have to click refresh for pages to load more comments or to see when someone replies to you? The fact that reddit does not do this is not evidence that it would be confusing.

Because sites that distract me from what I'm reading to tell me that there are new comments are extremely annoying.

Sure, you could add, say, auto-loading for new comments when you reach the bottom of the page, or setting the message icon to orange when you get a reply, but that hardly requires a full-blown web app, it's a simple addon to a static site.

Re: Progressive Enhancement Is Dead

#113

Post by cia_plant »

jenius wrote: post #78
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 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…

Template rendering is rarely a bottleneck. When JS-only pages seem slow, it is often because they are loading large JS libraries or are waiting for after page load to begin fetching AJAX data. By prerendering the initial JSON data for the page in script tags, and keeping javascript to the minimum necessary to render the page, pure javascript can render very quickly.

Re: Progressive Enhancement Is Dead

#114

Post by mwcampbell »

trafficlight wrote: post #92
kleiba wrote: post #74

There are dinosaurs like me who use the web mostly for reading stuff on websites. I also happen to use an old, quite slow computer as my default machine. It aggrevates me when a site that I try to open because of its textual content takes 30 seconds to render since there's too much Javascript going on. Then I'm typically sitting there thinking: "how hard can it be to display a piece of text?" Because of this, when I…

In all honesty, why should I care about you, the tiny minority? Why should I waste any time at all worrying about you?

There are two different kinds of minority to consider:

1. People who are part of a minority by choice. For instance, they choose to use an old computer, old OS, old web browser, etc. even though it is within their means to upgrade. Or they have current software but intentionally restrict it with add-ons like NoScript. You might be justified in not catering to these minorities, because it's just not profitable and you have no moral obligation to do so. Maybe the GP falls in that category; I don't know.

2. People who are in a minority through no choice of their own, and have no power to change their circumstance. One example would be a poor student or job-seeker who's stuck with an old computer and can't do anything about it. People with disabilities also fall in this latter category. I know someone who once lost a job because he is blind and some inaccessible software barred him from doing that job. He described how that felt in this blog post:

http://blindaccessjournal.com/2006/02/torn-from-the-collecti...

All that to say that your comment is quite insensitive. Those are real people in that small minority, and depending on why they're in that minority, we developers might have an obligation to accommodate them.

EDIT: Yes, I know that JavaScript apps can be accessible.

Re: Progressive Enhancement Is Dead

#115

Post by antihero »

ris wrote: post #107
trafficlight wrote: post #101

Earlier quoted context omitted.

Not everything in this world has to cater to me. I'd prefer it if everyone stopped trying to be all things.

You'd be fine if half the web didn't work for you? How about we say it's fine replacing text with images? We could always use alt tags for accessibility. The number of people who ever actually select/copy text from your website will be <1%, so why not just do away with it and get the text in any font we like, with any rendering style & layout we like?

Because that is an utterly ridiculous strawman. Using images for text is firstly almost entirely pointless, and has many many drawbacks that using JavaScript doesn't. For instance, it's a pain in the arse to maintain, it breaks text reflowing, it's huge, you have to deal with image compression, and it likely ruins the ability of search engines to spider your content without OCR.

Not to mention that any decent screen reader should surely be decent enough to extract text from an already rendered page (I mean christ, we have testing frameworks that can basically do this already).

If building apps using purely JavaScript breaks screen-readers, we need to fix screen readers. If our applications aren't working for people who insist on browsing with lynx or whatever, well, for shame.

Honestly though, another factor of "JavaScript only" things is that it means that some sort API is exposed to the client, so if it's really such a massive problem, just pull the JSON and parse that into something readable.

Re: Progressive Enhancement Is Dead

#116

Post by twistedpair »

npsimons wrote: post #91
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…

Exactly; those of us "vituperating priests" who rail against JavaScript abuse are mostly complaining about things like plain text (or even text plus photos) requiring JavaScript. You want to create some whiz bang new thing that needs Turing completeness? Go to town with JavaScript. You want to require enabling a possible malware vector and chew through computer resources like they're candy just to read a few paragrap…

I've been building 100% JS apps for 4 years now. With proper fragment loading, rendering optimization, and CDN usage, the apps appear to load just fast as an asp/php/jsp page (i.e. 200ms). Once the base page is loaded, page loads are instant (i.e. 10ms) smoking a non JS web app.

Blogger is sadly a dog and has been for the longest time. Profiling it just now, some of the blocking JS dependencies take > 800ms to load. Frankly there are many things wrong with it, but it should not serve as an example of a well designed JS web app.

Re: Progressive Enhancement Is Dead

#117

Post by wycats »

mwcampbell wrote: post #65
wycats wrote: post #51

Earlier quoted context omitted.

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

You're right to point out that the current best practice is to use HTML as intended, including semantic markup for links and buttons. Still, some developers attach mouse and/or touch events to semantically undistinguished elements without providing appropriate markup. For instance, the TodoMVC examples do this (including the Ember.js one). I guess it's time for me to start submitting pull requests.

It looks like the Ember one has three {{action}}s:

1) (a button) 2) (a button) 3) {{title}} - not a button, but a requirement of TodoMVC. It would be nice if TodoMVC had a marked edit that achieved the same goal.

There is also a subclass of , which:

1) Automatically focuses on insertion (native focuses are properly handled by screen readers) 2) Clears out the Todo if the text becomes empty and the user hits return (somewhat screen-reader friendly, and a requirement of TodoMVC)

What am I missing?

Re: Progressive Enhancement Is Dead

#118

Post by repsilat »

twistedpair wrote: post #116
npsimons wrote: post #91

Earlier quoted context omitted.

Exactly; those of us "vituperating priests" who rail against JavaScript abuse are mostly complaining about things like plain text (or even text plus photos) requiring JavaScript. You want to create some whiz bang new thing that needs Turing completeness? Go to town with JavaScript. You want to require enabling a possible malware vector and chew through computer resources like they're candy just to read a few paragrap…

I've been building 100% JS apps for 4 years now. With proper fragment loading, rendering optimization, and CDN usage, the apps appear to load just fast as an asp/php/jsp page (i.e. 200ms). Once the base page is loaded, page loads are instant (i.e. 10ms) smoking a non JS web app. Blogger is sadly a dog and has been for the longest time. Profiling it just now, some of the blocking JS dependencies take > 800ms to load.…

On slow connections I can sometimes only get the base html to load. No images, no external CSS or js. Extra requests for content are just asking for trouble. Worse, when I'm halfway around the world my ping is atrocious. It doesn't matter how quickly you generate your content for me, it's going to take twice as long for me to get it if you don't send it the first time I ask for it.

If I click on a link on your page and you have a faster way to get me there than a full page refresh then great, let's do that. On the first page load, though, there is no good excuse to make me request the site template and the content sequentially and smoosh them together myself. Do that on your end.

Re: Progressive Enhancement Is Dead

#119

Post by chaddeshon »

huhtenberg wrote: post #56
pornel wrote: 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.

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

Has it really? Do you have an example?

I've never seen an example where Google crawled a page and included content that was loaded via ajax or an external javascript file. I have seen Google index content that is loaded from a script tag included in the html page.

Re: Progressive Enhancement Is Dead

#120

Post by trafficlight »

mwcampbell wrote: post #114
trafficlight wrote: post #92

Earlier quoted context omitted.

In all honesty, why should I care about you, the tiny minority? Why should I waste any time at all worrying about you?

There are two different kinds of minority to consider: 1. People who are part of a minority by choice. For instance, they choose to use an old computer, old OS, old web browser, etc. even though it is within their means to upgrade. Or they have current software but intentionally restrict it with add-ons like NoScript. You might be justified in not catering to these minorities, because it's just not profitable and you…

I should've phrased it better, but I was asking him as a person of minority by choice.

I fully understand making a site accessible for those who need it, but I don't understand the NoScript people.

Post reply on HN