TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Progressive Enhancement Is Dead

334 pointsby avolcanoover 11 years ago

50 comments

glesicaover 11 years ago
&quot;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.&quot;<p>This statement needs a huge, HUGE caveat that you should only be building 100% JavaScript apps in situations where doing so <i>makes sense</i>. For example, I find the new Blogger &quot;web app&quot; infuriating. I shouldn&#x27;t have to stare at a loading screen to read a half-dozen paragraphs of text, that&#x27;s just stupid. Just serve the HTML. No one is going to &quot;fall in love&quot; with your app if your app shouldn&#x27;t exist in the first place because the old-school solution provided a superior experience.
评论 #6317287 未加载
评论 #6316893 未加载
评论 #6316760 未加载
评论 #6317196 未加载
评论 #6316731 未加载
评论 #6317451 未加载
评论 #6316762 未加载
评论 #6321231 未加载
评论 #6319613 未加载
integratonover 11 years ago
Sometimes I wonder whether advocates for heavy client-side JavaScript ever bother to test on mobile devices, because it very much seems that in the majority of cases they don&#x27;t. The vast majority of JavaScript-based &quot;show HN&quot; submissions I&#x27;ve seen don&#x27;t work on mobile browsers well or at all, to the point where I&#x27;ve been trained not to click them. This submission from a few days ago is an example, and last I checked it caused browser crashes and, even if you managed to load it, was unusable with an iPad: <a href="https://news.ycombinator.com/item?id=6270451" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6270451</a><p>Edit: Here is another example from the past few days that&#x27;s unusable on mobile: <a href="https://news.ycombinator.com/item?id=6302825" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6302825</a><p>This is a common problem with media sites. I dread trying to load quartz, usa today, gawker, etc since every thick-client media site is intermittently a bad citizen on mobile browsers (for example, gawker in Chrome on iOS currently perpetually reloads the page). Even when these kinds of sites work, there&#x27;s often a multi-second delay where where the user has to sit and watch elements fly around as the page is built.<p>Edit again: just to be clear, if you are a non-technical product manager or CEO type, my comment should not be interpreted in any way as an implication that the web or JavaScript is somehow inherently bad and therefore your developers must build a &quot;native app.&quot; My comment&#x27;s intended audience is developers with a deep, working understanding of these technologies.
评论 #6317806 未加载
评论 #6322269 未加载
Pinckneyover 11 years ago
I think the point that&#x27;s overlooked here is that the offenders aren&#x27;t the clever apps that would be impossible to write without javascript. Go ahead and write those. I&#x27;m happy for you, really.<p>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 javascript so it can do some stupid flashy thing that breaks the expected interface behaviour. And frankly, that&#x27;s most of what I&#x27;m seeing in &quot;Sigh, Javascript.&quot;
评论 #6316706 未加载
评论 #6317902 未加载
评论 #6316683 未加载
padolseyover 11 years ago
&gt; 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.<p>We all want wonderful experiences as users. The crux is almost a question of &quot;how we want things to be&quot; and &quot;how we want to get there&quot;.<p>For me, the 100% JS MV<i></i> movement is wonderful for a specific genre of app: An app that is:<p>* Behind an intranet<p>* Behind a paywall<p>* Behind a login-wall<p>* Prototypes &#x2F; Demos &#x2F; PoCs &#x2F; etc.<p>But for the open web -- wikipedia, blogs, discussion forums, journalism (etc.) this movement detracts from the web as a whole, in that it excuses developers from having to worry about degraded and&#x2F;or non-human consumption of their websites&#x27; data.<p>We have to ask ourselves what we, as humanity, want from the web. Do we really want a web of 100% bespoke JavaScript MV<i></i> web-apps with no publicly consumable APIs nor semantic representations? If that is the intent and desire of the developers, designers and otherwise educated-concerned web-goers, then fine, let&#x27;s do that and hope it works out okay...<p>But there is an alternative that has its roots already planted deep in the web -- the idea and virtue of a web where you can:<p>* Request an HTTP resource and get back a meaningful and semantically enriched representation<p>* Access and mash-up each-others&#x27; data, so as to better further understanding &amp; enlightenment<p>* Equally access data and insight via any medium, the latest Chrome or the oldest Nokia<p>So, please, go ahead and create a 100% JS front-end but, if you are creating something for the open web, consider exposing alternative representations for degraded&#x2F;non-human consumption. It doesn&#x27;t have to be progressively enhanced.<p>Imagine for a moment if Wikipedia was one massive Ember App... And no, Wikipedia is not an exception from the norm -- it is the embodiment of the open web.
评论 #6316774 未加载
评论 #6316758 未加载
kleibaover 11 years ago
There are dinosaurs like me who use the web <i>mostly</i> for reading stuff on websites. I also happen to use an old, quite slow computer as my default machine.<p>It aggrevates me when a site that I try to open because of its textual content takes 30 seconds to render since there&#x27;s too much Javascript going on. Then I&#x27;m typically sitting there thinking: &quot;how hard can it be to display a piece of text?&quot; Because of this, when I see my CPU spike as I try to open a website in a new tab, I very often decide to simply close the tab again and do without the information I originally came there to see. This happens a lot for me with online magazines, such as wired or techcrunch. One trick is to invoke the &quot;Readability&quot; bookmarklet if I can get to it fast enough, i.e., before the JavaScript has frozen my browser completely.<p>Of course I understand that I am part of a tiny minority. And probably I&#x27;m not part of your target group anyway. And the web is so much more in 2013 than pages with text on them.<p>If you <i>do</i>, however, want someone like me to come to your site, you better remember to keep it dinosaur-friendly.
评论 #6318620 未加载
评论 #6317289 未加载
thezilchover 11 years ago
<i>What I’ve found, counter-intuitively, is that apps that embrace JavaScript actually end up having less JavaScript. Yeah, I know, it’s some Zen koan shit. But the numbers speak for themselves.</i><p>The author does very little to support his claims. The Boston Globe page also has lot of scripts to support advertising and the advertising itself. As well, entirely different engineering teams and probably cultures. There&#x27;s not even any research into The Boston Globe&#x27;s use of progressive JS; it makes ZERO sense why the two homepages could not have the same JS footprint, with The Boston Globe continuing to work and Bustle continuing to not work, while JS is disabled.<p>I&#x27;m all for not supporting progressive JS; Bustle is certainly within their right to not work without JS; the author is just caught in a confirmation-bias bubble. His conclusions don&#x27;t make sense; our intuitions are right; it doesn&#x27;t take [much] more JS to progressively enhance a site.
crazygringoover 11 years ago
&gt; <i>Worrying about browsers without JavaScript is like worrying about whether you’re backwards compatible with HTML 3.2 or CSS2. At some point, you have to accept that some things are just part of the platform.</i><p>This is the key bit.<p>It&#x27;s a pretty popular attitude on HN to dismiss supporting IE, or IE7, or even IE8 or IE9 -- despite having significant user bases. But there&#x27;s still a strong vocal contingent which argues for webpages to still work fine with without JavaScript, despite it being a miniscule user base. They both seem to come from philosophical standpoints, rather than anything practical. (Granted, SEO is a valid consideration, but that&#x27;s fundamentally a different conversation.)
评论 #6317262 未加载
shawnzover 11 years ago
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&#x27;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.<p>Why does it matter in practice? Well, there&#x27;s more than one reason, but consider that not every user agent is a browser with a person sitting in front of it. Your website also should be interpretable by content indexers like search engines, accessibility devices like screen readers, and so on.<p>Some services don&#x27;t fit this model and really are better off being designed like desktop applications written in HTML and JS. But in my experience, most services can be modelled more like websites without making the design any more difficult to reason about, and almost all users&#x27; experiences are bettered by it.
评论 #6316750 未加载
__alexsover 11 years ago
&quot;Friendly reminder that &quot;people with JS disabled&quot; includes those on high-latency networks, bad firewalls, and browsers you don&#x27;t support.&quot; - @jcoglan<p><a href="https://twitter.com/jcoglan/status/370173041193406464" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;jcoglan&#x2F;status&#x2F;370173041193406464</a>
评论 #6316682 未加载
评论 #6316743 未加载
评论 #6317071 未加载
ritchieaover 11 years ago
<i>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.</i><p>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 &quot;real programming&quot; and I said no because the web is the best environment for writing apps today. I don&#x27;t have to choose whether I want to write for Mac OS which I use myself, or Windows which most consumers use or Linux which hardcore techies use. I don&#x27;t have to choose if my mobile app is iOS or Android first. Sure there are still tradeoffs, and sometimes a desktop or native mobile app is still going to be a good choice. But the browser today is an amazing environment that everyone on the web has access to and it&#x27;s only getting better. And we should be excited about leveraging everything modern browsers can do to make great software.
评论 #6319657 未加载
andrenotgiantover 11 years ago
Progressive Enhancement is still important for CONTENT SITES<p>Why? Search Engine accessibility.<p>It used to be that Googlebot wouldn&#x27;t find content loaded asynchronously, or links that rely on Javascript. Now it&#x27;s different - You can confirm that Googlebot discovers a lot of Javascript links using Webmaster Tools: <a href="https://www.google.com/webmasters/tools/home?hl=en" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;webmasters&#x2F;tools&#x2F;home?hl=en</a><p>BUT - There&#x27;s still no way to break from the &quot;Page Paradigm&quot; - Google needs URLs to send searchers to. They don&#x27;t yet send people to specific states of a page. That&#x27;s why I still use Progressive Enhancement, it forces me to ensure each piece of content has a URL that points to it.
评论 #6316821 未加载
thecoffmanover 11 years ago
This post does nothing to address the biggest reason people might have Javascript disabled: security. If I&#x27;m browsing through Tor (or whatever), I&#x27;m not going to turn on Javascript to use your site. If your site doesn&#x27;t work without it, you&#x27;ve lost a customer.<p>Granted, people who disable javascript are obviously vastly outnumbered, but just saying &quot;fuck you&quot; to security conscious (and most likely tech-savvy) users seems like a mistake.
评论 #6317393 未加载
评论 #6316903 未加载
评论 #6320290 未加载
wmtover 11 years ago
I tried the Bustle.com, showcased in the article as a good example of a pure Javascript website, on my Android browser, and the Javascript was used to reserve 25 % of my screen to show me a &quot;BUSTLE&quot;-banner that doesn&#x27;t go away when I scroll down.<p>Don&#x27;t expect your users to have a mouse. The share of web users on their mobile phone has grown from 6,5 % to 17,25 % since June 2011. Any bets on what the share will be in a year or two from now? (<a href="http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#StatCounter_.28July_2008_to_present.29" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Usage_share_of_web_browsers#Sta...</a>)
mynameismeover 11 years ago
There&#x27;s no reasons sites like tumblr shouldn&#x27;t work without javascript. Period. And while there are some things on the web that are genuine applications (trello, dashboards, etc.), the vast majority of things are content driven, which should never require js.
评论 #6316927 未加载
acjohnson55over 11 years ago
... <i>the browser transformed from being an awesome interactive document viewer into being the world’s most advanced, widely-distributed application runtime.</i><p>If only that were actually true. In reality, we&#x27;re designing the interfaces for these applications using a presentation language made basically for desktop publishing. For interactivity, we essentially have one more or less shite language (<a href="http://bonsaiden.github.io/JavaScript-Garden/" rel="nofollow">http:&#x2F;&#x2F;bonsaiden.github.io&#x2F;JavaScript-Garden&#x2F;</a>) to choose from. We&#x27;re still arguing over the very basics on whether we should use callbacks, promises, generators, etc. for <i>simple sequential operations</i>. Hell, we&#x27;re still trying to figure out how to get a reasonable call stack record to debug when working with any of these options. And God help you if you want to use a modern language that compiles to Javascript <i>and</i> have your debugger too.<p>But to address the author&#x27;s original point, I think progressive enhancement is alive and well. While the majority of browsing is done on the desktop, I just think it makes way more sense to think first about presenting your basic content and <i>then</i> enhancing it than how you&#x27;re going to strip out all the bells and whistles to get your design across on less capable platforms. In the long run, the former will probably save you more time and QA effort. It&#x27;s just more natural to think about using capabilities when present then working around their absence.<p>And no one says your baseline should to a screen reader for all possible web apps. Just pick a the baseline that makes sense for what your doing, and enhance from there. At some point, it may make more sense to fork your platform and have separate implementations for different pieces of your interface. It doesn&#x27;t have to be one monolithic project that magically enhances from mobile phone screen reader all the way up to VR cave.
ronaldxover 11 years ago
I disagree strongly. Concisely:<p>JS has many potential UI&#x2F;UX benefits which should be used for the users&#x27; benefit: although they can also be used to users&#x27; disadvantage.<p>If your (static?) website shows blank with no-JS, I find it unlikely that you&#x27;ve considered UI&#x2F;UX at all. I therefore assume that you are more likely to fall on the disadvantageous side.
Xcelerateover 11 years ago
I agree with all of his points. I think a lot of the counter-arguments are centered around &quot;Yeah, but I see websites that unnecessarily use Javascript when a simple text-based solution will work&quot;. That&#x27;s not a Javascript problem; that&#x27;s a site-design problem.<p>I&#x27;m sure you could make a dynamic page that has a negligibly different loading time compared to a static page that both display similar (static) content, but it&#x27;s the way that you do it that matters. Loading a page, that loads a library, that pulls in another library once the page is loaded, that then displays spinning gears while pulling in a bunch of static content is of course the wrong way to do it for a lot of things. But that&#x27;s a design problem.
dhamover 11 years ago
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.<p>I find the answer is not one or the other it&#x27;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&#x27;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.<p>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&#x27;t need all that crap to display an f&#x27;in table. It&#x27;s just a table for God&#x27;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.<p>Now if that table requires heavy editing(not filtering, or sorting, that stuff is easy as decoration), then sure bring in Angular.<p>On the other hand if I need drag and drop, validation, on complex forms, I&#x27;ll definitely bring in Angular.<p>Choose the right tool.
josephscottover 11 years ago
Stating that one approach or the other is always the right way is the problem. Figure out which one works best for the type of site you are working on.<p>How your site will be used is often a high level indicator of which approach will provide a better experience for your users. Gmail for example, no public part of the site, not uncommon for users to leave it open in a tab all day. Often great for all Javascript approach.<p>Twitter on the opposite end. Lots of public facing pages, performance was worse when they required Javascript just to render 140 characters on the screen. This style of site is generally better off with a progressive enhancement approach.
Joeboyover 11 years ago
Great, I&#x27;m going to be debugging other people&#x27;s websites in my spare time as well as at work.
评论 #6317879 未加载
andybakover 11 years ago
A great javascript app is wonderful thing but if you fail, you tend to fail hard.<p>A HTML&#x2F;CSS page + progressive enhancement tends to involve much less shooting-oneself-in-the-foot.<p>If you&#x27;ve got the talent, time and budget to do it well (note that is &#x27;AND&#x27; not &#x27;OR&#x27;. Gawker being a case of 2 out of 3 not being enough) then please go ahead.<p>However - if you have any doubts about your ability to see the whole thing through to perfection then a half-assed website is much less awful for your audience than a half-assed app.
tlrobinsonover 11 years ago
If you live somewhere with a decent internet connection and don&#x27;t travel often you may have forgotten that lots of places still have slow or unreliable internet connections. Most of those people probably have JavaScript enabled too, but every extra request required to use the site is a point of failure.<p>I&#x27;ll be the first to advocate requiring JavaScript when doing so significantly increases value, but for content sites please at least include the main content directly in the HTML.
toddmoreyover 11 years ago
I pretty much agree with all of the points in this article. I do wonder, though, why Bustle.com (the example used) is an Ember.js app and why it displays nothing but a blank page if Javascript is turned off. Skylight makes perfect sense as a full JS app. But Bustle, a content site, seems to be more of an &quot;interactive document&quot; (as he mentions).
评论 #6316702 未加载
EGregover 11 years ago
Javascript is great for making more efficient sites. Here&#x27;s why:<p>1) Static resources can be cached on a CDN and composited on the client instead of an overloaded app server<p>2) You can load data instead of heavy and repetitive HTML over the wire<p>3) You can cache the data in the client and re-use it later, making for snappier interfaces<p>That said, you have to watch out for URLs. Just because you can write everything with javascript doesn&#x27;t mean you should break URLs. And of course, crawlers other than google&#x27;s crawler will probably not be able to execute your JS.
评论 #6318801 未加载
评论 #6317736 未加载
评论 #6317222 未加载
asgard1024over 11 years ago
I like to save every document I read online (including discussion, if possible, these often contain insightful posts). Maybe it&#x27;s obsessive, but I do it.<p>Some documents, especially those using Ajax for loading content or multiple pages, make this difficult. I hate them. (Hacker News, oddly, does it too - when a discussion is archived, it becomes paged, which makes it more complicated to store.)<p>I wish there would be a standard way to store page offline, including all the JS changes made to its looks, all the external content etc.
mkillingover 11 years ago
Lots of absolute views in this thread.<p>How about: If it&#x27;s profitable for your site to offer a non-JS fallback, do it. If it isn&#x27;t, don&#x27;t.
评论 #6320357 未加载
mistercowover 11 years ago
Are there good tools out there for helping to ensure that a JavaScript web app without progressive enhancement is accessible to the disabled (e.g. screen readers can parse it, speech recognition software can interact with it).<p>I ask because I&#x27;ve recently discovered that Google has massively failed in this department with some of their products, at least as far as speech recognition is concerned. Google Docs is a great example of what I&#x27;m talking about. If you try to use it with Dragon NaturallySpeaking, buttons and menu items are often not recognized, text entry is only reliable by using the separate (and inconvenient) Dragon &quot;dictation box&quot;, editing is a nightmare, and review comments can only be placed by actually copying from a separate program. Your best bet if you need to collaborate is honestly to just use Microsoft Word, and then either upload and convert, or copy and paste, and then accept the fact that a lot of collaboration tools won&#x27;t be usable by you or any of your collaborators.<p>I can&#x27;t imagine how frustrating it must be to try to use modern web apps as someone who can&#x27;t type effectively or read a screen, and it seems like the problem is only going to get worse as people rely more on canvas without taking accessibility into consideration.
jhhover 11 years ago
While I agree that you can assume Javascript being enabled I really think that &quot;conventional&quot; web development has still many advantages over making SPAs.<p>Business logic on the server, HTML generated on the server, conventional mvc-architecture, use ajax and push state to make it highly interactive.<p>Fine - you can assume JS being available, but from that it simply does not follow that you have to throw away the traditional (rails style) dev model of the web.
hcarvalhoalvesover 11 years ago
You can have your hypermedia on api.&lt;yourdomain&gt; and then your AngularJS or whatever on app.&lt;yourdomain&gt;, consuming your api. Then all you need to do is serve HTML from your api when the User-agent accepts html (bonus points: set a canonical meta tag pointing to your foshizzle app so you don&#x27;t lose SEO).<p>Best of both worlds.<p>PS: All this crazy talk stems from the fact Javascript created an apartheid on the web. We need to make a clear distinction between the HTTP-web and the Javascript-enabled-web. The fact the same software (browser) serves this dual purpose adds to the confusion and allows bad architecture decisions, interwinding content and rich interfaces inside the same hypertext mudball.
dep_bover 11 years ago
Well I guess you wouldn&#x27;t want your monitoring tool indexed by Google anyway, right? As soon as you only have JavaScript as the only way for accessing some data it will be harder to index. There are some solutions provided by Google <a href="https://developers.google.com/webmasters/ajax-crawling/" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;webmasters&#x2F;ajax-crawling&#x2F;</a> but the situation still is not satisfactory.<p>For my clients it&#x27;s usually the case that being found well in Google is a major part of their business case. PE makes sure that a basic crawlable version of your website exists with proper titles and tags.
tambourine_manover 11 years ago
Not a single mention of SEO on the article. I guess Google is dead too.
评论 #6318146 未加载
评论 #6318181 未加载
soljin2000over 11 years ago
Only if you never need any referrals from search engines. I know a site that has this awesome locally sourced food delivery&#x2F;pickup system. Connecting consumers directly with the growers.<p>Their site is 100% in JS. And if you google for anything even remotely close to what this site sells you simply cannot find them.<p>Unless you are a members only app site would I say progressive enhancement is dead. Well that is unless you care about the millions of users on slower mobile connections with crappy smart phones.
评论 #6317051 未加载
评论 #6317136 未加载
pcuniteover 11 years ago
I&#x27;m ready for JavaScript sites ... but notice a very important nugget in the authors post, &quot;web apps need to have good URLs&quot;. This cannot be overstated.<p>1. Stop preventing middle and right clicks on JavaScript enabled links. For left clicks, sure ... control the flow.<p>2. Respect the fact that this is NOT a desktop environment, therefore my view of your program&#x27;s &quot;screens&quot; should be on a per URL basis. I actually might want to view a list you generated in my own separate &quot;window&quot; or &quot;screen&quot; with the URL visible, usable, and savable in the browser.
cpursleyover 11 years ago
Wow, the size of the Ember app vs. Typical webapp + JavaScript is impressive.<p>Inspecting the Bustle app with the new Chrome Ember Inspector is very cool.<p>Has Bustle open sourced any of their components or written on how they developed the app?
评论 #6317179 未加载
kenster07over 11 years ago
I doubt devs are &quot;ashamed&quot; of making js web apps. The main issue is that it takes more effort to do so than a traditional web app. There are browser specific quirks. Frameworks like rails are so well-integrated with the db layer that it will be difficult to match that productivity with pure JS apps. And finally, a lot of devs don&#x27;t want to take the time to learn, when the current standard is perfectly acceptable for most use cases.
pkrollover 11 years ago
140 comments in and no mention of TurboLinks? You hit a URL, you get the content. You click a link, it just gets the body and replaces that: no reloading the CSS, or JavaScript, so content gets rendered faster. Search engines get the actual content from the URLs, users get the speed. Issues having to do with making your scripts idempotent are problematic, but it certainly sounds like a good base.
netmuteover 11 years ago
The problem is not Javascript per se. Personally, I like a good webapp.<p>What annoys me is the tendency of Javascript guys to rebuild every damn application there is as a webapp, and rave about it like it&#x27;s the best thing ever. Javascript has become their hammer, and the whole world looks like it needs a good pounding.<p>Just because you can doesn&#x27;t mean you should.
aufreak3over 11 years ago
For me, the real indicator that progressive enhancement is &quot;dead&quot; was that as I began reading the post, I was left wondering &quot;what the &amp;*%^ is this progressive enhancement that he&#x27;s declaring as dead?&quot; until, pretty much, when I finished the post.
spacecadetover 11 years ago
I still teach both &quot;graceful degradation&quot; and &quot;progressive enhancement&quot; to students in my &quot;Web101 - Introduction to Web Development and Design&quot;...
BobbyBobbyover 11 years ago
This post doesn&#x27;t address the main reasons for PE.<p>- Accessibility - Spiderability by search engines<p>If you want to say PE is dead please explain how these don&#x27;t matter to most websites.
Theriac25over 11 years ago
Javascript is cancer.
nraynaudover 11 years ago
Yeah, i like to split the world in 2: web pages and web apps. For web apps, i don&#x27;t hesitate to assume javascript.
AdrianRossouwover 11 years ago
the one thing that i think is still kind of uncovered ground for javascript frameworks is proper i18n and l10n support.
KaoruAoiShihoover 11 years ago
Has been dead for a while. The people who complain on HN about &quot;I get a white page&quot; are treated like trolls.
评论 #6317683 未加载
oelmekkiover 11 years ago
Edit : actually, I&#x27;ll make an article out of this, because I came late in the discussion (I&#x27;m from european timezone) and the message probably won&#x27;t be heard.<p>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.<p>As author mentioned, the browser is now more an execution environment rather than a document viewer. You know what it means ? It means that developers have no control over the execution environment. With server side, if it works for you, it works for everyone. With client side, you&#x27;ll never know. You don&#x27;t know what extensions your user use. You don&#x27;t know how stable his system is. You don&#x27;t know how stable his connection is. And you can&#x27;t ask your users to have a such carefully crafted environment as your servers.<p>What this should make us concludes is that the most heavily your app rely on javascript, the better it should be at error handling.<p>How do you handle error in javascript ? If an error occurs in a callback function, clicking that &lt;a href=&quot;#&quot;&gt; again and again will simply do nothing, and your user will get frustrated and yell : &quot;it does not work !&quot;.<p>With progressive enhancement and graceful degradation, it suddenly becomes simple. Your link has a real href. You can deactivate all event handlers using the event &quot;window.onerror&quot;. That way, clicking a link after a crash will follow it.<p>You even don&#x27;t have to implement the feature totally on server side. If your client side feature can be emulated on server side, do it (and your user won&#x27;t even realize something went wrong) ; if it can&#x27;t, simply warn your user about it. Anyway, javascript runtime will have been reinitialized.<p>So, for all of this to work and make sense, we just have to use modern definitions :<p>* progressive enhancement is ensuring no link &#x2F; button &#x2F; whatever would &quot;freeze&quot; if javascript crash<p>* graceful degradation is ensuring interface get reversed back to an useful state when an error occurs (like, showing again submit button for what was ajax forms). This can easily be done if your page is composed of objects that respond to some kind of destructor method.<p>If you think client side errors do not happen that much, just put something like that in your code :<p><pre><code> window.onerror = function( error, url, lineno ){ $.post( my_exception_url, error: { error, url: url, lineno: lineno, page_url: window.location.href ); } </code></pre> This will post all exceptions to a server side url, where you can relay it to your exception management system (I simply raise a system exception using the passed parameters) or store them. You&#x27;ll be surprised.
评论 #6319846 未加载
leokunover 11 years ago
The websites as applications is correct. I see grumblings from some old time grumpy folk about why does this site need JavaScript. Because it&#x27;s a runtime now. The web has evolved, and aren&#x27;t you glad it did because flash is dying.
评论 #6317311 未加载
评论 #6317115 未加载
brokenparserover 11 years ago
It ain&#x27;t dead until Netcraft confirms it.
asdasfover 11 years ago
Why on earth is he framing it as though it has something to do with time? Like, there was a time when you couldn&#x27;t rely on browsers having javascript, so progressive enhancement? Progressive enhancement wasn&#x27;t because browsers didn&#x27;t have javascript, it was because people turned it off. They still do. And horrible javascript &quot;apps&quot; that just show some text and pictures are only going to make that number get bigger.
crassusover 11 years ago
What bugs me about web apps is that I need to download a new copy of it every time I go back to it (or at least send all the AJAX requests again). Load times suck.
goatslackerover 11 years ago
Just for fun I made <a href="http://sighinternet.tumblr.com/" rel="nofollow">http:&#x2F;&#x2F;sighinternet.tumblr.com&#x2F;</a>