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

161–170 of 263 posts

Re: Progressive Enhancement Is Dead

#161

Post by dham »

First of all you still get html in the end. So whether you get the slightly reduced json payload size and use the users cpu to generate html or just get cached html from the server you still end up with the same thing, and arguably, similar response times.

I find the answer is not one or the other it's both. If a certain page requires interactivity then embrace Javascript and do the interactivity with Angular or Ember. You end up writing less Javascript. If you do it as decorating html using jQuery then you will end up with more javascript. Most pages in web apps don't require this much interactivity on every page though. There may be a few pages here and there. Most of it is just document viewing. In that case just send down cached html. Sure Bustle.com is fast, but so is Basecamp, both take entirely different approaches to display pages.

When I first got into Knockout a few years ago, I was a kid in a candy store. I wanted to do everything with Javascript and Knockout. Soon I grew up and realized you just don't need all that crap to display an f'in table. It's just a table for God's sake. We have been displaying tables since the dawn of web browser. In fact you will pay client CPU cost trying to display a table in Angular when you could just send it over in HTML.

Now if that table requires heavy editing(not filtering, or sorting, that stuff is easy as decoration), then sure bring in Angular.

On the other hand if I need drag and drop, validation, on complex forms, I'll definitely bring in Angular.

Choose the right tool.

Re: Progressive Enhancement Is Dead

#162

Post by eru »

dllthomas wrote: post #157
eru wrote: post #152

Earlier quoted context omitted.

Turing machines are not infinite. There are merely big enough for everything you want to do. (I.e. actual infinity vs potential infinity.)

Turing defined the machines with reference to an infinite tape. Obviously any given machine (that halts) isn't going to use all of it. If you give any specific hard bound, you have a system which can be implemented on a sufficiently large FSM. There is, therefore, a sense in which you can never "need" a Turing complete system to solve any given problem that you can solve with finite resources.

No hard bound, but the tape is only potential infinite. (Compare https://en.wikipedia.org/wiki/Actual_infinity)

Re: Progressive Enhancement Is Dead

#163

Post by TheZenPsycho »

dasil003 wrote: post #43
diminish wrote: post #27

Earlier quoted context omitted.

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…

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.

Re: Progressive Enhancement Is Dead

#164

Post by dllthomas »

eru wrote: post #162
dllthomas wrote: post #157

Earlier quoted context omitted.

Turing defined the machines with reference to an infinite tape. Obviously any given machine (that halts) isn't going to use all of it. If you give any specific hard bound, you have a system which can be implemented on a sufficiently large FSM. There is, therefore, a sense in which you can never "need" a Turing complete system to solve any given problem that you can solve with finite resources.

No hard bound, but the tape is only potential infinite. (Compare https://en.wikipedia.org/wiki/Actual_infinity )

I don't see that that actually has any bearing on what I said, though. Reality will always give some hard bound, on any practical problem.

Re: Progressive Enhancement Is Dead

#165

Post by robbyking »

kintamanimatt wrote: post #87
robbyking wrote: post #50

Earlier quoted context omitted.

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…

1% is a small percentage but can make up quite a large number of people.

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.

Re: Progressive Enhancement Is Dead

#167

Post by EGreg »

sergiosgc wrote: post #158
EGreg wrote: post #154

Earlier quoted context omitted.

Are you serious? 1. The browser requests CDN resources directly and Javascript is used to combine those static files into something that the user sees. Since the code is executing on the client, the app server is not overloaded. 2. Suppose you have a list of 20 items. You could either output HTML with all the tags already rendered for each of the 20 items, or you could output a JSON array with 20 objects, which is mu…

1. Use a CDN that supports ESI, like CloudFront. 2. It's not that much of a difference, after gzipping, which you surely already do. 3. See number 1. Moreover, in the end, you'll get a less heavy document to be processed by the browser. I swear my all bells and whistles i7 X1 Carbon still struggles on some javascript-heavy sites.

Please do elaborate on 1 :)

Re: Progressive Enhancement Is Dead

#168

Post by steveklabnik »

sergiosgc wrote: post #156
tomdale wrote: post #24

Earlier quoted context omitted.

First, the accessibility argument is a red herring that I'm getting frustrated people continue to try to throw around. Screen readers support JS, okay? Let's put this argument to bed. http://words.steveklabnik.com/emberjs-and-accessibility Okay, thank you for letting me get that off my chest. Second, one nice thing about "embracing 100% JavaScript" that I talk about in the post is that it requires you to implement a…

Can you give an example of one of your sites with a "really solid JSON API"? I'm afraid there's a gap in this definition, as good APIs are rare and good JSON APIs with a single client are virtually non-existant.

Here's Bustle's: http://www.bustle.com/api/v1/sections/home.json

It needs run through a pretty-iffier, of course, but seems straightforward to me.

Re: Progressive Enhancement Is Dead

#169

Post by steveklabnik »

EGreg wrote: post #167
sergiosgc wrote: post #158

Earlier quoted context omitted.

1. Use a CDN that supports ESI, like CloudFront. 2. It's not that much of a difference, after gzipping, which you surely already do. 3. See number 1. Moreover, in the end, you'll get a less heavy document to be processed by the browser. I swear my all bells and whistles i7 X1 Carbon still struggles on some javascript-heavy sites.

Please do elaborate on 1 :)

http://en.wikipedia.org/wiki/Edge_Side_Includes

Re: Progressive Enhancement Is Dead

#170

Post by gnaritas »

dreamfactory wrote: post #151
oneeyedpigeon wrote: post #130

Earlier quoted context omitted.

"99.99% of the people visiting my site have JS enabled" Do you know that for a FACT, or are you just guessing?

...because if it's say 98%, you have just thrown away 2% revenue.

Hardly, you have to consider the additional cost of attempting to support that additional 2%; it could very well cost more than it's worth in development time and long term complexity. Of course that's an app specific decision. Every market you specialize for has a cost, short term and long term, so it has to be worth it financially; businesses aren't in the habit of just being nice for no reason.
Post reply on HN