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

151–160 of 263 posts

Re: Progressive Enhancement Is Dead

#151

Post by dreamfactory »

oneeyedpigeon wrote: post #130
mmastrac wrote: post #13

Earlier quoted context omitted.

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?

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

Re: Progressive Enhancement Is Dead

#152

Post by eru »

dllthomas wrote: post #141
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…

Entirely an aside, and not meant as criticism but merely an interesting (hopefully) point noted in passing: If you are doing something that requires Turing-completeness, you're doing something that can't be done on real computers, because any collection of digital hardware can be represented as a (flippin' ginormous) finite state machine.

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

Re: Progressive Enhancement Is Dead

#153

Post by sergiosgc »

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

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.

Re: Progressive Enhancement Is Dead

#154

Post by EGreg »

camus wrote: post #82
EGreg wrote: post #12

Javascript is great for making more efficient sites. Here's why: 1) Static resources can be cached on a CDN and composited on the client instead of an overloaded app server 2) You can load data instead of heavy and repetitive HTML over the wire 3) You can cache the data in the client and re-use it later, making for snappier interfaces That said, you have to watch out for URLs. Just because you can write everything wi…

1/ Because you cant cache static resources on a CDN without javascript ? 2/ Because you cant load light html over the wire ? 3/ Because you cant cache html pages client side ?

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 much less on the wire.

3. If you are rendering stuff on the client and only fetching data for it (which is what modern Javascript MVC frameworks let you do) then you can cache that data and re-use it. Caching entire HTML pages is at a much lower level of granularity that caching each piece of data you get from the server, and reassembling it in different ways.

Re: Progressive Enhancement Is Dead

#155

Post by EGreg »

mariusz79 wrote: post #134
EGreg wrote: post #12

Javascript is great for making more efficient sites. Here's why: 1) Static resources can be cached on a CDN and composited on the client instead of an overloaded app server 2) You can load data instead of heavy and repetitive HTML over the wire 3) You can cache the data in the client and re-use it later, making for snappier interfaces That said, you have to watch out for URLs. Just because you can write everything wi…

1 has been possible since the beginning of time. Every modern browser as cache built-in.

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.

Re: Progressive Enhancement Is Dead

#156

Post by sergiosgc »

tomdale wrote: post #24
shawnz wrote: post #20

This author is making an assumption that progressive enhancement exists only so that people who are browsing without Javascript can have a better experience. Of course, this isn't true. Progressive enhancement is a good thing because it encourages you to be as descriptive as possible at every layer of your technology stack. Why does it matter in practice? Well, there's more than one reason, but consider that not ever…

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.

Re: Progressive Enhancement Is Dead

#157

Post by dllthomas »

eru wrote: post #152
dllthomas wrote: post #141

Earlier quoted context omitted.

Entirely an aside, and not meant as criticism but merely an interesting (hopefully) point noted in passing: If you are doing something that requires Turing-completeness, you're doing something that can't be done on real computers, because any collection of digital hardware can be represented as a (flippin' ginormous) finite state machine.

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.

Re: Progressive Enhancement Is Dead

#158

Post by sergiosgc »

EGreg wrote: post #154
camus wrote: post #82

Earlier quoted context omitted.

1/ Because you cant cache static resources on a CDN without javascript ? 2/ Because you cant load light html over the wire ? 3/ Because you cant cache html pages client side ?

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.

Re: Progressive Enhancement Is Dead

#159

Post by elliotanderson »

tambourine_man wrote: post #70

Not a single mention of SEO on the article. I guess Google is dead too.

Try viewing meta.discourse.org without Javascript on then look under the hood - it's a pretty easy problem to solve with some tags. Other approaches use PhantomJS to create a "rendered" copy that is accessible to primitive clients/scrapers.

Re: Progressive Enhancement Is Dead

#160

Post by ef4 »

tambourine_man wrote: post #70

Not a single mention of SEO on the article. I guess Google is dead too.

It wasn't mentioned because that particular fallacy has already been beat to death.

Take a look at Discourse or Bustle. They're pure Javascript apps that are still SEO-friendly.

Post reply on HN