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

201–210 of 263 posts

Re: Progressive Enhancement Is Dead

#201

Post by rgbrgb »

sergiosgc wrote: post #153
twistedpair wrote: post #116

Earlier quoted context omitted.

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

I hope the 10ms quote is for a localhost connection, otherwise I'll read it like I do huge fish weight on my father's last fishing trip.

No, the 10ms is because you don't have to hit the server on every page load.

Re: Progressive Enhancement Is Dead

#202

Post by Amadou »

robbyking wrote: post #50
thecoffman wrote: post #18

This post does nothing to address the biggest reason people might have Javascript disabled: security. If I'm browsing through Tor (or whatever), I'm not going to turn on Javascript to use your site. If your site doesn't work without it, you've lost a customer. Granted, people who disable javascript are obviously vastly outnumbered, but just saying "fuck you" to security conscious (and most likely tech-savvy) users se…

I think the real question is which group is larger: the customers I'll gain by enabling a feature that requires JavaScript or the customers I'll lose because they're unable to view a feature that requires JavaScript. According to developer.yahoo.com[1], > After crunching the numbers, we found a consistent rate of JavaScript-disabled requests hovering around 1% of the actual visitor traffic[...]. I work for a medium s…

NoScript is the 4th most popular add-on for firefox with 2 million users. ( https://addons.mozilla.org/en-US/firefox/ )

Conversion rate is a limited metric. It misses the entire concept of word-of-mouth. Conversion rate can't measure people who don't show up in the first place.

I expect NoScript users to be more sophisticated "power users" - the kind of users that regular users go to for advice. If they aren't using your site then they will never recommend it to their more naive and more easily converted friends.

Re: Progressive Enhancement Is Dead

#203

Post by sambeau »

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…

Also, spare a thought for those who have to use screen readers.

If your 'app' is just a web page — use a web page!

Re: Progressive Enhancement Is Dead

#204

Post by TheZenPsycho »

radq wrote: post #199
TheZenPsycho wrote: post #163

Earlier quoted context omitted.

Javascript is no cure-all. Just like flash and java, avoiding the subjugation of built-in browser features (back button, bookmarking, hyperlinks, context menus, copy and paste) requires explicit effort many developers simply don't give either out of laziness or ignorance. Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature.

> Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature. But the vast majority of my users don't even know what cURL is, so why should I worry about this? And in any case, I believe that if I wanted to extract content programmatically, consuming the same API that the Javascript uses to fetch content would be much easier than extracting it from HTML.

The vast majority of users don't know what a bookmark, a URL or a back button is. This isn't any kind of argument. We don't do the right thing because people know about it. We do it because it doesn't secretly break so many of the conveniences we're used to. We. Us. Power users. Hackers.

Tell me, why should you be lazy just because you think the vast majority of your audience are fools and won't notice?

Re: Progressive Enhancement Is Dead

#205

Post by rimantas »

ritchiea wrote: post #63

At some point recently, the browser transformed from being an awesome interactive document viewer into being the world’s most advanced, widely-distributed application runtime. This is the key sentence in the article and this is why I was motivated to become a web developer. Recently someone asked me if I felt like I was missing out by doing most of my programming on the web since desktop apps are "real programming" a…

That key sentence is at least half wrong. The „most advanced“ part at least. And web was never the best environment for writing apps. And it never will be. It's like hoping to transform the fork into the spoon. I have spent one and a half decades in it, and it may be becoming bearable environment, but far far from the best. Unless it's the only thing you know, then it is the best by definition.

Re: Progressive Enhancement Is Dead

#206

Post by ewang1 »

kintamanimatt wrote: post #183
robbyking wrote: post #165

Earlier quoted context omitted.

I completely agree, but if a version test wins by more than a few percentage points, it usually makes sense to implement the feature even if it does make the page inaccessible to 1% of users.

I honestly doubt you'd be saying that if you were part of that 1%!

Except here, the 1% chose to be in the 1%.

Re: Progressive Enhancement Is Dead

#207

Post by superluminary »

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.

No reason why you can't provide real time updates on your content driven site. and respect progressive enhancement. I'd submit this would be the easiest way to do it.

Re: Progressive Enhancement Is Dead

#208

Post by oelmekki »

oelmekki wrote: post #198

Edit : actually, I'll make an article out of this, because I came late in the discussion (I'm from european timezone) and the message probably won't be heard. People that consider app should be usable entirely without javascript certainly miss the point. So do people that consider progressive enhancement is only about supporting people that deactivated javascript. As author mentioned, the browser is now more an execu…

Article posted : https://news.ycombinator.com/item?id=6319738

Re: Progressive Enhancement Is Dead

#209

Post by phpnode »

iopq wrote: post #197
phpnode wrote: post #73

Earlier quoted context omitted.

and in fact that particular bustle link you posted is a perfect example of where using HTML5 + microdata would be not only faster to render and crawlable but also allow the underlying data structure to be consumed by javascript. There's no reason why Bustle.pageData.article.title couldn't have been extracted from Why We Should Root for Lamar Odom ...

It's a real bitch to implement when your use case is complicated and nested. From experience, I have no idea how to mark up a document "correctly" because of like recursive definitions of some microdata. Like flingy can contain thingy. A thingy can contain flingy. Should I mark my concrete item as flingy where some elements are thingies or should that be a thingy with some subelements as flingies? I just did my best…

you can mark sub-scopes with their own itemscope property, so you could have this:

    
        My Title

        
            
                John
                Smith
            
        
        
        
            Cumberland
            Mystery Meat
in the example above, we define an article that has a related author property, that author property is its own scope so has firstName and lastName properties of its own. We also define an unrelated itemscope (unrelated because it has no itemprop) that happens to be nested in the same element, so this would parse to:

    [
        {
           "type": "/article",
           "properties": {
               "title": ["My Title"],
               "author": [{
                   "type": "/author",
                   "properties": {
                       "firstName": ["John"],
                       "lastName": ["Smith"]

                   }
               }]
 
           }
        },
        {
            "type": "/sausage",
            "properties": {
                "type": ["Cumberland"],
                "ingredients": ["Mystery Meat"]
            }
        }
    ]

Re: Progressive Enhancement Is Dead

#210

Post by dasil003 »

TheZenPsycho wrote: post #163
dasil003 wrote: post #43

Earlier quoted context omitted.

JavaScript architecture skills evolved much more slowly than traditional back-end web development and of course it's more difficult to monitor errors that happen on the client side, so yes, it's still a reality that there is a correlation between heavy javascript and broken pages. However I don't think citing the problems with Flash and Java Applets is applicable. JavaScript maturity is explicitly the long-awaited re…

Javascript is no cure-all. Just like flash and java, avoiding the subjugation of built-in browser features (back button, bookmarking, hyperlinks, context menus, copy and paste) requires explicit effort many developers simply don't give either out of laziness or ignorance. Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature.

-sigh- why would you take that away from my comment? The point is that javascript makes it possible to build a performant and smoothly integrated web app where with Java and Flash by their plugin nature it is impossible.
Post reply on HN