17 ms·

Progressive Enhancement Is Dead

• toddmorey 13y 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 "interactive document" (as he mentions).
  • tomdale 13y ago
    Bustle actually uses PhantomJS to create static versions of the site, for serving to search spiders. The advantage of using Ember.js for Bustle is that it's really, really, ridiculously fast. Seriously, try it. Go to bustle.com and click around. They could make it work without JavaScript, but they're a new company with a long list of technical challenges to solve. They ran the numbers and the percentage of users with JS disabled is so microscopic it just doesn't make sense to spend time on it.
    • deleted 13y ago
      [deleted]
    • Isofarro 13y ago
      "Bustle actually uses PhantomJS to create static versions of the site, for serving to search spiders." What value dose using PhantomJS offer above what progressive enhancement gives you for free? This feels like a contradiction. Avoiding progressive enhancement, and then bolting on a hack for search spiders in a way that is less robust than the technique you're avoiding. "The advantage of using Ember.js for Bustle is that it's really, really, ridiculously fast. Seriously, try it. Go to bustle.com and click around." The initial load is horribly slow. For example: http://www.bustle.com/articles/4549-pew-poll-american-people-dont-support-syrian-strike http://www.bustle.com/articles/4549-pew-poll-american-people... took 10 seconds. That's very slow for a one page article. That's gonna hurt people following links to the page. That's exactly the reason why Twitter walked away from it's JavaScript driven content and went for progressive enhancement. A substantial portion of new visitors will have a cold cache, and have this annoying wait for what is effectively a one page article. (cf. http://statichtml.com/2011/google-ajax-libraries-caching.html http://statichtml.com/2011/google-ajax-libraries-caching.htm... ) "They could make it work without JavaScript, but they're a new company with a long list of technical challenges to solve. They ran the numbers and the percentage of users with JS disabled is so microscopic it just doesn't make sense to spend time on it." Another contradiction. Progressive enhancement isn't a technical challenge, it is so brain dead simple. So they figured out the number of users with JavaScript disabled is too small to warrant supporting. Interesting, except, progressive enhancement isn't solely about people with JavaScript disabled, right? cf: http://isolani.co.uk/blog/javascript/DisablingJavaScriptAskingTheWrongQuestion http://isolani.co.uk/blog/javascript/DisablingJavaScriptAski... Also, so they ran the numbers of these, under the incorrect assertion that progressive enhancement only impacts people with JavaScript disabled. But did they run those same numbers that determined the number of search spiders wasn't microscopic, to justify the PhantomJS bodge you initially mentioned? Are you really implicitly asserting that there are far more search spider visitors to bustle.com than visitors with JavaScript disabled? (I'd love to understand the logic that lead to that determination). So, what justification was there to spend time on building a PhantomJS site scraper to provide static content to search engine spiders, and yet fail to appreciate that progressive enhancement would have served that spider audience, as well as the JavaScript audience, as well as the variety of issues that progressive enhancement helps alleviate? But, if bustle.com were a content site, then progressive enhancement is the way to go, right? But this is an ember app, so it is not a content site (clearly). Except when search spiders visit, then there's a need for a static version of each page. It's very confusion. is bustle.com an app or a website? Also, how does bustle.com / ember, guarantee perfect delivery of assets other than HTML to a visitor's browser? How does it guarantee robustness? For example, when using a CDN, how does it manage when this happens: http://www.theregister.co.uk/2012/01/05/google_opendns_clash/ http://www.theregister.co.uk/2012/01/05/google_opendns_clash... How does bustle.com / ember protect your JavaScript so that when a third-party chunk of JavaScript (like Google Analytics, Disqus, Facebook, ChartBeat, Quantcase, WebTrends) does something funky, or hiccups and causes a JavaScript error?
• Pinckney 13y ago
  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 javascript so it can do some stupid flashy thing that breaks the expected interface behaviour. And frankly, that's most of what I'm seeing in "Sigh, Javascript."
  • leokun 13y ago
    Check out meteor.js for why JavaScript would be needed for "static only content". Real time updates. That's why. Everything is an app.
    • mynameisme 13y ago
      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.
      • kansface 13y ago
        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.
        • icebraining 13y ago
          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.
• __alexs 13y ago
  "Friendly reminder that "people with JS disabled" includes those on high-latency networks, bad firewalls, and browsers you don't support." - @jcoglan https://twitter.com/jcoglan/status/370173041193406464 https://twitter.com/jcoglan/status/370173041193406464
  • rwmj 13y ago
    And people using NoScript.
    • sergiotapia 13y ago
      And who cares about people using NoScript, no one should. They are in the vast minority, not worth the trouble accommodating for them.
      • slig 13y ago
        And they know they're using NoScript. If the website doesn't work, they can decide if they want to enable or not. It's their burden, not mine. Unless, of course, my client wants a 100% working no-script webapp/site. Then I'll happily charge for the extra time building it.
        • prodigal_erik 13y ago
          You may want to use a pseudonym for work where you cut corners and failed to do work you're actually prepared to do properly. I browse without javascript enabled to judge the quality of the tools I'm considering; I wouldn't hire anyone with a portfolio full of broken non-semantic documents.
          • slig 13y ago
            It's not "cutting corners". It does take more time to build an webapp that works without any JS. If it takes more time, the final product costs more. The client should be aware of that and make the decision. Why should he/she always pay for something that will only be useful for a very small % of his/hers clients?
• leokun 13y 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's a runtime now. The web has evolved, and aren't you glad it did because flash is dying.
  • gergles 13y ago
    I'd rather have Flash + HTML that I can parse and view on any application rather than JS that works on the list of Approved Browsers that were all released within the past week. Nobody would've made a Flash-only site but for some reason JS-only sites that shut out anyone with slow computers, old computers, mobile browsers that aren't Safari, etc. are totally okay.
    • kreper 13y ago
      All kinds of wrong here.
  • dictum 13y ago
    I'm not glad Flash is dying. If we're considering requiring JS for static pages, we didn't learn anything from the horrors of Flash's heyday. Most of the time when I'm browsing the web—does "browsing the web" sound too 1995?—I want a request to return hypertext. A text file with hyperlinks, sections, titles, embedded pictures, forms. I don't want any computation done, I don't want a runtime, I want a trillion linked augmented text files.
• glesica 13y ago
  "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" infuriating. I shouldn't have to stare at a loading screen to read a half-dozen paragraphs of text, that's just stupid. Just serve the HTML. No one is going to "fall in love" with your app if your app shouldn't exist in the first place because the old-school solution provided a superior experience.
  • austinz 13y ago
    Not to mention stuff like accessibility that ends up being an afterthought for a lot of people.
    • tomdale 13y ago
      Accessibility is a red herring. JavaScript apps work just fine with screen readers, especially if you support WAI-ARIA. http://words.steveklabnik.com/emberjs-and-accessibility http://words.steveklabnik.com/emberjs-and-accessibility
      • zenojevski 13y ago
        Absolutely, but the context "afterthought" narrows the situation to a very specific case, that in which you have given no consideration at all about accessibility. My belief is that if you were able to produce good markup, it would have been accessible from the very beginning, because accessible markup tends to be well-formed and semantically correct. This would probably rule knowledge of WAI-ARIA out from everyone who fit parent's case.
      • austinz 13y ago
        No, I totally agree that accessibility is possible if your app is JavaScript based. But if you're unaware of or you forget to add in accessibility features, you run the risk of failing much less gracefully for people who need those features than if there were more static content. (This is, of course, a generalization; specific use cases may vary.)
• mynameisme 13y ago
  There's no reasons sites like tumblr shouldn'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.
  • d0m 13y ago
    You claim facts without explaining your reasoning.. Let me put it this way using your own vocabulary: There's no reasons sites like tumblr *should work without javascript*. Period. Why why!
    • ris 13y ago
      I rather think the onus is on people like you to come up with a reason that they _shouldn't_.
      • d0m 13y ago
        Well, philosophically, I think having static content served in a backward compatible way is perfect. Pragmatically, I haven't found a good solution to do it without duplicating all the code. That by itself might be a very good reason as to why one would focus the development efforts on the 95% of users. You say people like me. I'm more agnostic here.. just interested to understand the arguments of both side. I just think that a post saying "This is black. Period" doesn't add much to the discussion.
        • mynameisme 13y ago
          What duplication? Why do you need to use js to render text? I'm not saying that a user without js should expect all, or any of the bells and whistles. But to use client side js rendering to show a user a paragraph or two (like blogger), or literally a sentence (when twitter did client side rendering) is just insane. It breaks stuff, and is MORE work than just doing it the right way.
          • 13y ago
• thezilch 13y ago
  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. 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's not even any research into The Boston Globe'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. I'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't make sense; our intuitions are right; it doesn't take [much] more JS to progressively enhance a site.
• EGreg 13y ago
  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 with javascript doesn't mean you should break URLs. And of course, crawlers other than google's crawler will probably not be able to execute your JS.
  • camus 13y ago
    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 ?
    • EGreg 13y ago
      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.
      • sergiosgc 13y ago
        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.
• andrenotgiant 13y ago
  Progressive Enhancement is still important for CONTENT SITES Why? Search Engine accessibility. It used to be that Googlebot wouldn't find content loaded asynchronously, or links that rely on Javascript. Now it's different - You can confirm that Googlebot discovers a lot of Javascript links using Webmaster Tools: https://www.google.com/webmasters/tools/home?hl=en https://www.google.com/webmasters/tools/home?hl=en BUT - There's still no way to break from the "Page Paradigm" - Google needs URLs to send searchers to. They don't yet send people to specific states of a page. That's why I still use Progressive Enhancement, it forces me to ensure each piece of content has a URL that points to it.
  • bluepnume 13y ago
    Having URLs which point to specific resources is still 100% possible for javascript web apps. Take a look at Ember, as an example, those guys place a load of emphasis on URLs as 1st class citizens in frontend web apps.
• Xcelerate 13y ago
  I agree with all of his points. I think a lot of the counter-arguments are centered around "Yeah, but I see websites that unnecessarily use Javascript when a simple text-based solution will work". That's not a Javascript problem; that's a site-design problem. I'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'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's a design problem.
• thecoffman 13y ago
  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 seems like a mistake.
  • robbyking 13y ago
    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 sized company that version tests almost every change we make, and in the end the version that wins is the feature with the higher conversion rate. [1] http://developer.yahoo.com/blogs/ydn/many-users-javascript-disabled-14121.html http://developer.yahoo.com/blogs/ydn/many-users-javascript-d...
    • kintamanimatt 13y ago
      1% is a small percentage but can make up quite a large number of people.
      • robbyking 13y ago
        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.
        • kintamanimatt 13y ago
          I honestly doubt you'd be saying that if you were part of that 1%!
• shawnz 13y 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'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 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. Some services don'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' experiences are bettered by it.
  • tomdale 13y ago
    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 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 really solid JSON API, because your web site is now a true client that consumes an API. This makes it really easy to integrate with third-party services that consume your content. I agree that putting content behind JavaScript sucks; I'm just advocating that the content be JSON (or some other normalized format), not HTML.
    • ris 13y ago
      "I agree that putting content behind JavaScript sucks; I'm just advocating that the content be JSON (or some other normalized format), not HTML." Ah, so don't put it "behind JavaScript", but put it in a format that a browser can't natively handle in a sane way. And use a grab-bag general object format instead of one that has built-in semantic definitions that are be useful in a document context, like, idunno, <strong> <em> <p> <a> ?
    • 13y ago
• padolsey 13y ago
  > 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. We all want wonderful experiences as users. The crux is almost a question of "how we want things to be" and "how we want to get there". For me, the 100% JS MV movement is wonderful for a specific genre of app: An app that is: * Behind an intranet * Behind a paywall * Behind a login-wall * Prototypes / Demos / PoCs / etc. 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/or non-human consumption of their websites' data. We have to ask ourselves what we, as humanity, want from the web. Do we really want a web of 100% bespoke JavaScript MV 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's do that and hope it works out okay... 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: * Request an HTTP resource and get back a meaningful and semantically enriched representation * Access and mash-up each-others' data, so as to better further understanding & enlightenment * Equally access data and insight via any medium, the latest Chrome or the oldest Nokia 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/non-human consumption. It doesn't have to be progressively enhanced. 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.
  • mwcampbell 13y ago
    Strongly agree. The day that merely reading Wikipedia requires JavaScript will be the day that the open Web is dead.
  • tomdale 13y ago
    Every Ember.js app, by definition, connects to an API that does all of the things you are asking for. Seriously, open up any Ember.js app and look at the network traffic. You'll see a series of requests, usually using very RESTful URLs, that requests the document. The only difference is that, instead of HTML, where you are conflating the markup and the content, you get a nice, easily-consumable version of the document in JSON form. There is literally no change to the web here, other than the UIs are faster and better, and it's easier for me to consume JSON documents than trying to scrape HTML.
• cpursley 13y ago
  Wow, the size of the Ember app vs. Typical webapp + JavaScript is impressive. Inspecting the Bustle app with the new Chrome Ember Inspector is very cool. Has Bustle open sourced any of their components or written on how they developed the app?
  • bti 13y ago
    One of the engineers wrote a little bit about it on Reddit[1] awhile ago. [1] http://www.reddit.com/r/webdev/comments/1kf84d/bustlecoms_speed/ http://www.reddit.com/r/webdev/comments/1kf84d/bustlecoms_sp...
• jhh 13y ago
  While I agree that you can assume Javascript being enabled I really think that "conventional" web development has still many advantages over making SPAs. Business logic on the server, HTML generated on the server, conventional mvc-architecture, use ajax and push state to make it highly interactive. 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.
• mkilling 13y ago
  Lots of absolute views in this thread. How about: If it's profitable for your site to offer a non-JS fallback, do it. If it isn't, don't.
  • drdaeman 13y ago
    There are other things besides personal financial profits. Think of them as taxes to maintain Internet working and flexible. If you don't pay that tax, you're personally contributing to a future when simple documents become full-fledged programs, and everyone lose abilities to easily manipulate and interact with them in any but author-defined ways. There are cases where you can be exempt from that tax - if your site is not about documents, but their transformations, i.e. it's more of a process, not data. (Then you should call it app, not site). But vast majority of sites isn't.
• brokenparser 13y ago
  It ain't dead until Netcraft confirms it.
• deleted 13y ago
  [deleted]
• Joeboy 13y ago
  Great, I'm going to be debugging other people's websites in my spare time as well as at work.
  • qu4z-2 13y ago
    I experienced this recently. I had to look through the source of a site because their image gallery javascript was broken. I was already looking at a gallery of thumbnails... how hard can it be to make each thumbnail a link to the image in question, and at runtime attach a javascript handler to open the image in a pop-up or whatever?
• soljin2000 13y ago
  Only if you never need any referrals from search engines. I know a site that has this awesome locally sourced food delivery/pickup system. Connecting consumers directly with the growers. 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. 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.
  • kmfrk 13y ago
    It’s a myth that if you use a client side MVC framework that your application’s content cannot be indexed by search engines. In fact, Discourse forums were indexable by Google the day we launched. http://eviltrout.com/2013/06/19/adding-support-for-search-engines-to-your-javascript-applications.html http://eviltrout.com/2013/06/19/adding-support-for-search-en... They are probably a good case to follow, if you want to see what people's experiences with SEO for JS-based services are.
    • asdasf 13y ago
      Why do people who are against server side templates always provide "well, just use server side templates and client side rendering both!" as a solution? Hooray, I can write my app twice for no reason! Way to sell me on pure javascript for delivering content.
  • pablasso 13y ago
    That's a developer problem, not a Javascript problem.
    • camus 13y ago
      No that's a javascript problem which makes things more complicated for little gain. With progressive enhancement you dont need all these phantomjs stupid tricks.
• kenster07 13y ago
  I doubt devs are "ashamed" 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't want to take the time to learn, when the current standard is perfectly acceptable for most use cases.
• ritchiea 13y ago
  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" and I said no because the web is the best environment for writing apps today. I don'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'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's only getting better. And we should be excited about leveraging everything modern browsers can do to make great software.
  • rimantas 13y ago
    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.
    • ritchiea 13y ago
      Maybe we're reading that sentence differently? I read it as "the most widely distributed runtime that is also relatively advanced." I took it as a given that Tom Dale does not believe the web is the most advanced programming environment.
• integraton 13y 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't. The vast majority of JavaScript-based "show HN" submissions I've seen don't work on mobile browsers well or at all, to the point where I'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: https://news.ycombinator.com/item?id=6270451 https://news.ycombinator.com/item?id=6270451 Edit: Here is another example from the past few days that's unusable on mobile: https://news.ycombinator.com/item?id=6302825 https://news.ycombinator.com/item?id=6302825 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's often a multi-second delay where where the user has to sit and watch elements fly around as the page is built. 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 "native app." My comment's intended audience is developers with a deep, working understanding of these technologies.
  • leif 13y ago
    I think you just invented an internet forum with a proof-of-technical-proficiency requirement for each post. Well done, sir.
  • asdasf 13y ago
    >since every thick-client media site is intermittently a bad citizen on mobile browsers Not just mobile browsers. They are horrible everywhere that isn't chrome or firefox.
• crazygringo 13y ago
  > 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. This is the key bit. It'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'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's fundamentally a different conversation.)
  • hollerith 13y ago
    It's not just the people with JavaScript turned off: it's people who, for example, rely on the Readability or Readable bookmarklets or Safari's Reader functionality. In general turning documents into programs deprives users of those documents of a kind flexibility that they enjoyed when documents were just data. And does it not bother you that web-browser development has gotten so complicated and labor-intensive that there are exactly five organizations with the resources to maintain a web browser? What hope do operating systems with very small userbases like Plan 9 have of ever running a web browser capable of displaying correctly the majority of web site? Browser complexity closes off certain opportunities: e.g., about 15 years ago, a blind programmer named Karl Dahlke wrote a "command-line web browser" called "edbrowse" that has a command language similar to the line editor ed. Is it OK with you that the fraction of web pages browsable with edbrowse keeps going down? Another way that making the web a richer application-delivery platform reduces the options available to users: approximately nobody bothers to maintain a local copy of the web pages they have browsed (which would be among other things a useful insurance against web pages disappearing from the web) because it is so complicated to do. And then there is the loss of consistency useful to readers. For example, when you click on a link, then hit the Back button, the browser used to always put you back at the same place in the web page that you were when you clicked the link. Not anymore: for example, if you click a search result on hnsearch.com, then hit Back, you are taken to the start of the web page containing the search results with the result that you have to scroll through results you've already sifted through just to get back to the state of progress you were in when you clicked the link. A possible reply to that is that the maintainer of hnsearch.com should fix his web site. But the number and variety of "losses" or "regressions" like that one is so large -- and increasing so fast -- as to make me doubt that webmasters will ever get around to fixing most of them, particularly since webmasters on average are less technically knowledgeable than, e.g., programmers are. Selecting an extent of text in preparation for copying it is another thing that has become less consistent and controllable over time: sometimes when I just want to select a few words, slight movement of the cursor while dragging will cause an entire adjacent column of text to be selected or de-selected according to rules that are essentially unknowable to the reader. In the past, for about 15 years, the space key consistently meant "scroll down a screenful" (provided the page as a whole has the focus -- as opposed to, e.g., a TEXTAREA in the page). The desire to turn the web into an applications-delivery platform caused the web site to gain the discretion to map the space key to something else, which is a gain for authors of web apps, but a loss for readers who used to be able to depend on consistent behavior from the space key. In summary, although I am happy that many thousands of applications developers are now able to make good livings without becoming a "tenant" or a "captive" of a platform owned by a single corporation, I am sad about how complicated, tedious and mystifying it has become to use the web to consume static content -- and how expensive (in programmer time and effort) it has become to put static web content to uses not foreseen and provided for by the author of the content.
• tambourine_man 13y ago
  Not a single mention of SEO on the article. I guess Google is dead too.
  • elliotanderson 13y ago
    Try viewing meta.discourse.org without Javascript on then look under the hood - it's a pretty easy problem to solve with some <noscript> tags. Other approaches use PhantomJS to create a "rendered" copy that is accessible to primitive clients/scrapers.
    • drdaeman 13y ago
      > Other approaches use PhantomJS to create a "rendered" copy that is accessible to primitive clients/scrapers. Then your site does not require client-side JS support. The point is not about what technologies you use to produce documents, the point is what data you [can] serve.
  • ef4 13y ago
    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.
    • tambourine_man 13y ago
      No one said it can't be done, but it's far from trivial, hence my surprise in its omission. And the Phantom.js approach mentioned below seems more like a workaround to me than a solution
• kleiba 13y ago
  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 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 "Readability" bookmarklet if I can get to it fast enough, i.e., before the JavaScript has frozen my browser completely. Of course I understand that I am part of a tiny minority. And probably I'm not part of your target group anyway. And the web is so much more in 2013 than pages with text on them. If you do, however, want someone like me to come to your site, you better remember to keep it dinosaur-friendly.
  • trafficlight 13y ago
    In all honesty, why should I care about you, the tiny minority? Why should I waste any time at all worrying about you?
    • ris 13y ago
      Nobody's saying you should. But designing things in a progressive-enhancement-type way will mean that you have no need to worry about all these "minorities" as most things will generally more or less work. Besides we're all minorities in one way or another. I'm sure I could find some dimension by which you're a minority and you'd be pretty cheesed off if you weren't catered for for some trivial reason.
      • trafficlight 13y ago
        Not everything in this world has to cater to me. I'd prefer it if everyone stopped trying to be all things.
        • 13y ago
• AdrianRossouw 13y ago
  the one thing that i think is still kind of uncovered ground for javascript frameworks is proper i18n and l10n support.
• dep_b 13y ago
  Well I guess you wouldn'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 https://developers.google.com/webmasters/ajax-crawling/ https://developers.google.com/webmasters/ajax-crawling/ but the situation still is not satisfactory. For my clients it'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.
• ronaldx 13y ago
  I disagree strongly. Concisely: JS has many potential UI/UX benefits which should be used for the users' benefit: although they can also be used to users' disadvantage. If your (static?) website shows blank with no-JS, I find it unlikely that you've considered UI/UX at all. I therefore assume that you are more likely to fall on the disadvantageous side.
• josephscott 13y 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. 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. 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.
• KaoruAoiShiho 13y ago
  Has been dead for a while. The people who complain on HN about "I get a white page" are treated like trolls.
  • camus 13y ago
    you are the troll obviously, calling people that disagree with you trolls.
• wmt 13y 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 "BUSTLE"-banner that doesn't go away when I scroll down. Don'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? (http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#StatCounter_.28July_2008_to_present.29 http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Sta...)
• goatslacker 13y ago
  Just for fun I made http://sighinternet.tumblr.com/ http://sighinternet.tumblr.com/
• mistercow 13y 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). I ask because I'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'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 "dictation box", 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't be usable by you or any of your collaborators. I can't imagine how frustrating it must be to try to use modern web apps as someone who can'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.
• andybak 13y ago
  A great javascript app is wonderful thing but if you fail, you tend to fail hard. A HTML/CSS page + progressive enhancement tends to involve much less shooting-oneself-in-the-foot. If you've got the talent, time and budget to do it well (note that is 'AND' not 'OR'. Gawker being a case of 2 out of 3 not being enough) then please go ahead. 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.
• pkroll 13y 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.
• crassus 13y 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.
• dham 13y 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. 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.
• nraynaud 13y ago
  Yeah, i like to split the world in 2: web pages and web apps. For web apps, i don't hesitate to assume javascript.
• hcarvalhoalves 13y ago
  You can have your hypermedia on api.<yourdomain> and then your AngularJS or whatever on app.<yourdomain>, 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't lose SEO). Best of both worlds. 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.
• acjohnson55 13y ago
  ... the browser transformed from being an awesome interactive document viewer into being the world’s most advanced, widely-distributed application runtime. If only that were actually true. In reality, we'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 (http://bonsaiden.github.io/JavaScript-Garden/ http://bonsaiden.github.io/JavaScript-Garden/) to choose from. We're still arguing over the very basics on whether we should use callbacks, promises, generators, etc. for simple sequential operations. Hell, we'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 and have your debugger too. But to address the author'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 then enhancing it than how you'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's just more natural to think about using capabilities when present then working around their absence. 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't have to be one monolithic project that magically enhances from mobile phone screen reader all the way up to VR cave.
• tlrobinson 13y ago
  If you live somewhere with a decent internet connection and don'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. I'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.
• Theriac25 13y ago
  Javascript is cancer.
• oelmekki 13y ago
  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 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'll never know. You don't know what extensions your user use. You don't know how stable his system is. You don't know how stable his connection is. And you can't ask your users to have a such carefully crafted environment as your servers. What this should make us concludes is that the most heavily your app rely on javascript, the better it should be at error handling. How do you handle error in javascript ? If an error occurs in a callback function, clicking that <a href="#"> again and again will simply do nothing, and your user will get frustrated and yell : "it does not work !". 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 "window.onerror". That way, clicking a link after a crash will follow it. You even don'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't even realize something went wrong) ; if it can't, simply warn your user about it. Anyway, javascript runtime will have been reinitialized. So, for all of this to work and make sense, we just have to use modern definitions : * progressive enhancement is ensuring no link / button / whatever would "freeze" if javascript crash * 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. If you think client side errors do not happen that much, just put something like that in your code : window.onerror = function( error, url, lineno ){ $.post( my_exception_url, error: { error, url: url, lineno: lineno, page_url: window.location.href ); } 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'll be surprised.
  • oelmekki 13y ago
• BobbyBobby 13y ago
  This post doesn't address the main reasons for PE. - Accessibility - Spiderability by search engines If you want to say PE is dead please explain how these don't matter to most websites.
• aufreak3 13y ago
  For me, the real indicator that progressive enhancement is "dead" was that as I began reading the post, I was left wondering "what the &*%^ is this progressive enhancement that he's declaring as dead?" until, pretty much, when I finished the post.
• pcunite 13y ago
  I'm ready for JavaScript sites ... but notice a very important nugget in the authors post, "web apps need to have good URLs". This cannot be overstated. 1. Stop preventing middle and right clicks on JavaScript enabled links. For left clicks, sure ... control the flow. 2. Respect the fact that this is NOT a desktop environment, therefore my view of your program's "screens" should be on a per URL basis. I actually might want to view a list you generated in my own separate "window" or "screen" with the URL visible, usable, and savable in the browser.
• asgard1024 13y ago
  I like to save every document I read online (including discussion, if possible, these often contain insightful posts). Maybe it's obsessive, but I do it. 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.) 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.
• spacecadet 13y ago
  I still teach both "graceful degradation" and "progressive enhancement" to students in my "Web101 - Introduction to Web Development and Design"...
• asdasf 13y 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't rely on browsers having javascript, so progressive enhancement? Progressive enhancement wasn't because browsers didn't have javascript, it was because people turned it off. They still do. And horrible javascript "apps" that just show some text and pictures are only going to make that number get bigger.
• netmute 13y ago
  The problem is not Javascript per se. Personally, I like a good webapp. 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's the best thing ever. Javascript has become their hammer, and the whole world looks like it needs a good pounding. Just because you can doesn't mean you should.