Comments on Let Links Be Links

21 Reader Comments

Back to the Article
  1. Yes, Ember is working on this. But so long as you don’t require a monolithic framework, you can do this today with React. Here is an example:

    Copy & paste the code below to embed this comment.
  2. For Angular, the prefered linking syntax for that login button would be a regular link like so:

    <a href=”/login”>Log In</a>

    You would only need to use ng-href if the value was dynamically rendered in javascript.  And even if you did use ng-href, you could technically use both and have a fallback for non JS browsers:

    <a ng-href=”/{{pathVariable}}” href=”/login”>Log In</a>

    Copy & paste the code below to embed this comment.
  3. Server-rendering isn’t enough because SPAs usually don’t have a dedicated page for every component. Don’t believe me? Just disable JS, visit and try to send a tweet (send it to @Meekostuff)

    What is needed is for web-sites to be developed as a HTML-payload WebAPI. Look at (but not on Firefox). Why didn’t someone think to progressively-enhance that?

    The site will be fully-functional without JS and pages will be just primary content (and some meta-content). Pages may as well be single-column with simple styling so that it can display on older browsers, tiny devices, everywhere. Everything about a richer UI - multi-column-layout, fancy decor, auxiliary-content - can be installed as progressive-enhancement.

    What sort of JS Framework can work with this kind of web-site?

    Framesets were the original single-page-app and - in spite of all their faults - imposed a good structure on web-sites and the use of links.

    There is the opportunity now - with 20 years of hindsight - to design a successor to framesets which features:

    - content-first + progressive-enhancement
    - light-weight, seamless frames
    - responsive layout
    - multiple-views, conditional-content, etc

    This will allow (compell even) the server representation of a site (which is what browsers without JS will render) to be basically a fully-functional, HTML-payload WebAPI.

    Copy & paste the code below to embed this comment.
  4. Derby.js and Meteor are both js frameworks that are working on running the same code on the client and the server.

    Copy & paste the code below to embed this comment.
  5. Thanks for the article Ross!

    While it’s true that Meteor also runs on the server, along with its example apps display no content with JavaScript disabled. Learning Meteor at the moment, this worries me a bit.

    Copy & paste the code below to embed this comment.
  6. I agree with you. I tend to use JS to enhance web forms but not to depend on it. I understand that the approach is different now but it doesn’t have to overcome the primary web purpose: get information in any kind of device.
    I’m going to test Haxe. It’s supposed to build both server & client scripts from a single project & basecode. I want to know how it does such magic.

    Copy & paste the code below to embed this comment.
  7. Nice article. I agree it’s better to use true html links when possible, especially links to content (more so than login buttons.)

    My rule of thumb is that public search-indexable web content should be readable without JavaScript, but it’s fine to require JavaScript for app-like actions like login and any content behind login.

    Most single page apps I’ve seen are behind login and therefore not instapaper-able.

    Copy & paste the code below to embed this comment.
  8. This is a great read and related to something I have been working on so I thought I’d share. I’ve recently been exploring HTML 1st design over at My thoughts on HTML 1st design are here:

    On the site asynchronous components such as the main navigation are powered with React.js yet fully support .no-js because there is semantic HTML powered by MODX Revolution underneath anything JavaScript enhances.

    Copy & paste the code below to embed this comment.
  9. In practice, it’s important to make sure that we don’t sacrifice the experiences of a small number of users just so we can slightly improve the experiences of the rest, damaging the universal nature of the web in the process.

    While I appreciate the idealism of this statement (I genuinely do), it really isn’t this simple. Every site has limited amounts of time and resources at it’s disposal. Many sites are run by individuals or groups of individuals who want to see a return on their investment. Spending extra hours to support a small percentage of users (using archaic browsers or disabling browser functionality no less) just doesn’t make financial sense to them.

    Four out of every 500 people who visit a website built with Angular or Ember will encounter a completely blank page.

    4/500 = 0.8%. Less than the 0.9% of IE7 users ( who will also not be able to view the Angular/Ember site anyway (because they don’t support IE8-). In fact, if you combine IE 6/7/8 users, you have a far more meaningful statistical number (to a business) than the number of users who don’t support JS.

    I’m not trying to demonize your article or the idea that the web should be universal. But the web evolved far beyond what it’s founders created it to be. We have a need for powerful web tools and services that rely on JS. There’s nothing wrong with a site trying to maximize the experience for it’s largest market shares instead of the web as a whole.

    Whether you like it or not, that’s just smart business.

    Copy & paste the code below to embed this comment.
  10. Ross, I’m one of the 1% you discuss who disable Javascript - using NoScript. Allowing untrusted sites to run code on your browser indiscriminately is the dumbest of ideas in my opinion.

    When I encounter a site that doesn’t work properly I then have a choice - go somewhere else, or accept the security risk of allowing the site to run scripts on my browser. Often the latter results in multiple other sites wanting to run scripts too and involves playing a game of “what is the minimum set of sites I can allow temporarily to make this sucker work”. And so very often I just browse elsewhere.

    Copy & paste the code below to embed this comment.
  11. I’m very interested in the potential of web app approach, but this is a great reflections of @PenmanRoss.

    Copy & paste the code below to embed this comment.
  12. Great article! Thanks Ross

    Copy & paste the code below to embed this comment.
  13. This is an area, like the Flash-based websites of the past, where I’m a bit conflicted. I really like some of the new web design styles, but implementing them often leaves you with this sort of problem, where the basic elements of the site break in many cases - or you need to spend tons of effort working the proper elements into the functionality you want.

    So far, my way of dealing with these items has been to hang back until standards catch up, or the trend passes. I’m proud to say I have never let a client use even a little flash outside of non-critical video.

    Copy & paste the code below to embed this comment.
  14. @William Morris - what scripts are you worried about websites running? You describe it as though JavaScript can run arbitrary code on your machine, I hope you know this isn’t true? The worst a site could do with JavaScript is annoy you - in which case you can leave. There hasn’t been a security risk with JavaScript since… decades ago? JS is used to write cookies, but if you’re worried about cookies then that can be dealt with in isolation, but you’re far better off using something like a third-party script blocker in such cases - no need to cut off the nose to spite the face.

    Intentionally turning off JavaScript hinders your internet experience with no tangible benefit.  It’s your prerogative but it’s a drastic and often misguided decision.

    The above does assume that you spend your time on websites that aren’t actively trying to rip you off in some way - but even then JS is only going to make that slightly easier, in the same way that CSS will.

    Catering for those that *can’t* run JavaScript, now that’s something else entirely.

    Copy & paste the code below to embed this comment.
  15. I see how this is an issue for a lot of teams but the guys I’m working with at the moment have budget for non JS versions and we test everything in non JS so I hope we’re accounting for browsers if all capabilities.

    I am a hobby coder too so from that perspective I’ll have to do some extra reading to make sure I’m catering for as many people as possible but from within my own abilities and resources.

    Thanks for this.

    UI Designer
    Blockety HTML Templates

    Copy & paste the code below to embed this comment.
  16. Nice Article Ross. Awesome work!

    Copy & paste the code below to embed this comment.
  17. Hi there, I read your blogs on a regular basis. Your humoristic style is witty, keep it up!

    Copy & paste the code below to embed this comment.
  18. Sorry, commenting is closed on this article.