7 ms·

"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

• 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.)
      • mwcampbell 13y ago
        I think this is a valid generalization. On a page that doesn't use JavaScript, some links, form fields, and/or buttons may be unlabeled, but a blind user at least knows they're there and might be able to look at some hints to their functionality, such as URLs or element IDs. Moreover, the controls and interactions are standard. What happens if the developer attaches some functionality to a device-dependent event, such as onclick, on an undistinguished element such as a div? The element might be styled such that a sighted user knows it's intended to be clicked, but a blind user doesn't get this same information unless the element has an appropriate WAI-ARIA role. And how many web application developers are going to pay attention to ARIA as they craft their unique JavaScript-powered user experiences? Maybe I'm just cynical, but I'm guessing that outside of companies that have a strong incentive to get accessibility right so they can sell to governments and schools, the answer is "not many".
        • wycats 13y ago
          Today's reasonably-built JavaScript-based applications are built using HTML as templates. They don't use a <div> as a button, they use a <button> as a button. They don't invent navigation using JavaScript, they use <a> tags and a JavaScript-based router. Take a look at discuss.emberjs.com, which uses Discourse (which is powered by Ember... INCEPTION): On the front page, every navigation, including the links on top and the links to individual forum posts, are <a> tags with an href. When you navigate to a forum post, the buttons to reply, flag, favorite, etc. are all <button> elements. You definitely want to be (1) using a framework that encourages the use of HTML for the view layer, and (2) using a framework that makes URL-based navigation easy. There's nothing about JavaScript-based applications that make semantic markup and URLs impossible, and today's screen readers don't care whether your HTML was rendered using JavaScript or from the server. I think you're jaded because the previous generation of frameworks (SproutCore, Capuccino, Ext.js) shunned HTML in favor of all-JavaScript UI toolkits, but that framework style has fallen out of favor. HTML is here to stay.
          • mwcampbell 13y ago
            You're right to point out that the current best practice is to use HTML as intended, including semantic markup for links and buttons. Still, some developers attach mouse and/or touch events to semantically undistinguished elements without providing appropriate markup. For instance, the TodoMVC examples do this (including the Ember.js one). I guess it's time for me to start submitting pull requests.
• diminish 13y ago
  i m still opening a dozen tabs and reading them whenever i want, unfortunately most newer js only web blogs such as inc mobile, end up having a lot of errors and white pages.. i understand your newly found js excitement with your full ember.js app, but do'nt forget the lessons from java the browser plugin and flash. 1. ok you re real time, but don't assume i m watching your site like a tv 2. dont consume my precious cpu power.. otherwise app throttling will come to browser tabs.. 3. dont end up in lots of clientside errors due to various problems, including local storage.. twitter mobile client is an abysmal example where tweets are lost on screen and inc mobile is another with empty ehite pages
  • dasil003 13y ago
    JavaScript architecture skills evolved much more slowly than traditional back-end web development and of course it's more difficult to monitor errors that happen on the client side, so yes, it's still a reality that there is a correlation between heavy javascript and broken pages. However I don't think citing the problems with Flash and Java Applets is applicable. JavaScript maturity is explicitly the long-awaited remedy to the problems of those bolted-on runtimes. It's true that bloated over-the-top CPU-hogging monstrosities will be done with JS as with prior technologies, but there's no technology that is immune to that. FWIW, Ember is pretty performance-oriented and lets you get a lot done with a very low code / performance / byte overhead.
    • TheZenPsycho 13y ago
      Javascript is no cure-all. Just like flash and java, avoiding the subjugation of built-in browser features (back button, bookmarking, hyperlinks, context menus, copy and paste) requires explicit effort many developers simply don't give either out of laziness or ignorance. Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature.
      • radq 13y ago
        > Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature. But the vast majority of my users don't even know what cURL is, so why should I worry about this? And in any case, I believe that if I wanted to extract content programmatically, consuming the same API that the Javascript uses to fetch content would be much easier than extracting it from HTML.
• ebiester 13y ago
  You know, check out bustle.com -- I used to agree with you, but that's really fast for both the first load and subsequent loads.
  • jenius 13y ago
    Idn, I'm not impressed with the initial load time. If that site was served as a static page that was recompiled when a new article was added, it would be significantly faster. But at the same time, subsequent loads would probably be a little slower. Which one is more worth it?
    • graue 13y ago
      You can do both! Prerender the front page server side, then switch to super-fast PJAX once the JavaScript is loaded. This nifty technique is called... wait for it... "progressive enhancement". Airbnb's recently released Rendr library (https://github.com/airbnb/rendr https://github.com/airbnb/rendr) is a great attempt to make this easy for complex web apps to do.
      • ebiester 13y ago
        Oh wow! I get to write two code paths! I'm so excited to do double the work for a small subset of users! Oh, and I get to test two code paths, and all of the wonderful ways they might interact!
        • graue 13y ago
          The whole point of Rendr is you don't have to write two code paths. That's why I linked to it.
• rcthompson 13y ago
  I feel like this point is sort of implied by the fact that he said just "Don't be ashamed to build 100% JS apps" and not "Build 100% JS apps for everything". But it's still good to spell this out explicitly.
  • veidr 13y ago
    It's more than implied by the OP; he did, in fact spell this out explicitly: "Of course, there will always be cases where server-rendered HTML will be more appropriate."
• jenius 13y ago
  I think that issue, while valid, is entirely different from what OP is talking about. That is the question of client to server side rendering tradeoff, and it looks something like this in my view: - If you have a website that people will come to then spend a bit of time in different views (like gmail, facebook, or an analytics dashboard), it will usually pay off to dock the initial load time a bit in exchange for much faster loads of subsequent views. This is the base tradeoff made by switching to client-side rendering. - If you have a website where most people will come check out one page then bounce (like a news site, a blog, a page with directions or info, anything where an article will be linked to rather than something that's used like an app), you won't want to make that same trade, since the extra blow to load time initially is going to hit most people and they won't see the benefits of the reduced load time for slowly adds up as you hit more views on the page, because they will read the info then leave. Any page can be built as a single page app, and many people will do this automatically since it's the new hotness. But the question we should be asking ourselves is whether what you are building actually will be used as an app or not. I'll close out with an interesting example: If you are building a news site, you should not build as a single page app because it's likely that you'll have a lot of single page views and a high bounce rate. Those single pages should be rendered as quickly as humanly possible. However, if you are building something like a feed reader, the situation would be the opposite. People will likely spend a bit of time in your interface reading a variety of articles, so the additional load time at the beginning will quickly pay itself off in faster renders for each item they read. EDIT: An interesting approach for a news site would be to render single article views straight from the server or have them compiled, but render their homepage as a single page app. Tailor different parts of your website to the way that they are viewed. Has anyone written about this? Maybe I should write about it...
  • lbotos 13y ago
    I think your edit is spot on. Cache a single page render in the event that someone is hitting it from search or a direct link and if they hit the home page, give them the dynamic single page app treatment. Sounds like a happy medium with a little overhead. (JS apps who want to be indexed would want the static pages for crawlers anyway.)
  • cia_plant 13y ago
• npsimons 13y ago
  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 paragraphs of text? Forget you, I'll keep browsing. And so will crawlers, so you'll never get linked. Attention is scarce, information is not - do the math.
  • twistedpair 13y ago
    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. Frankly there are many things wrong with it, but it should not serve as an example of a well designed JS web app.
    • repsilat 13y ago
      On slow connections I can sometimes only get the base html to load. No images, no external CSS or js. Extra requests for content are just asking for trouble. Worse, when I'm halfway around the world my ping is atrocious. It doesn't matter how quickly you generate your content for me, it's going to take twice as long for me to get it if you don't send it the first time I ask for it. If I click on a link on your page and you have a faster way to get me there than a full page refresh then great, let's do that. On the first page load, though, there is no good excuse to make me request the site template and the content sequentially and smoosh them together myself. Do that on your end.
      • twistedpair 13y ago
        In that case, you'd likely prefer a JS based app that used its app manifest to cache the actual moving parts (JS/images) before you headed on vacation and landed on that slow connection. Now it only makes a bare minimum of compressed RPC's to provide the page with the content to render itself. Depending on the content being rendered, you could even get an RPC down to one or two packets, much better than sending you the entire site frame over and over for a minor change (I'm looking at you classic postback driven ASP app).
• _pius 13y ago
  From the article: Of course, there will always be cases where server-rendered HTML will be more appropriate. But that’s for you to decide by analyzing what percentage of your users have JavaScript disabled and what kind of user experience you want to deliver. Seems like a pretty big caveat to me.
• sambeau 13y ago
  Also, spare a thought for those who have to use screen readers. If your 'app' is just a web page — use a web page!
• Pxtl 13y ago
  That. Performance is paramount. On many smartphone browser tabbing out while I wait for your slow-assed page to load and render isn't an option like it would be on the desktop. I feel the pain of every lazy-loaded image, every sluggish layout script, etc. Many "responsive" pages are actually the worst culprits. Yes, I need a new phone. But older smartphone browsers aren't exactly a rare use-case.