7 ms·

I think it's critical here to distinguish between full client-side application (e.g., gmail) and an informational web site (e.g., a news site, a blog, or code d

I think it's critical here to distinguish between full client-side application (e.g., gmail) and an informational web site (e.g., a news site, a blog, or code documentation). It's a bad idea to require Javascript for the latter, but it's equally silly to try to build a fully-responsive client application using no Javascript, or progressive enhancement. In several of my recent sites, there's been a main company site requiring no Javascript, but then a portal to one or more applications or services that requires Javascript. In these cases, Javascript is taking the place of what before might have been Java applets, Flash apps, or Silverlight applications. But it's arguably more secure, fairly standardized, and "installed" by default. And in the cases of full browser applications, I think it's silly to argue against requiring Javascript. You simply can't build a fully responsive client-side application using just HTTP calls and static HTML, no matter how performant the server side. And I will absolutely continue to use <noscript> tags for browser apps that run on Javascript, since it's rather rude to just show a white screen with no indication of what the problem is to users.

scrollaway 12y ago
I'd like people to start more readily differenciating between web apps and documents (dynamic or not). I think we're at the point where it's obvious that there is a difference between the two and it's just as obvious requiring JS for web apps is completely acceptable.
- dllthomas 12y ago
  I think you are getting at an important distinction, but you're confused about what it actually is. The important question is, "What is the goal of this site? What is the best way to still meet that goal without JS?" For documents, the answer is probably "provide the information", and that can trivially be accomplished without JS. For some excruciatingly dynamic web apps, the answer might be "use someone else's product" or even "it can't be done". There is substantial middle ground, though.
  - scrollaway 12y ago
    So look at the middle-ground in terms of functionality, then. If a feature cannot be provided without JS, then don't provide it to those who don't have JS and move on. If the feature is not critical to other parts of the app, don't make those other parts depend on it. This always seems to be a controversial discussion yet all it is about is a few well-understood rules: - Manage your dependencies - Don't break things on purpose because you don't like the user's setup - Don't feel obligated to fully support platforms you have no desire of supporting
    - dllthomas 12y ago
      Well, treat each feature the same way, really. Offering a less comfortable but still functional experience is precisely what "progressive enhancement" is about. I agree that for many projects, at some point, there is functionality that can't be reasonably made accessible without JS, given the constraints of the project. I do think that many people seem to be too quick to go there. I don't think we have any major disagreement.
    - jiggy2011 12y ago
      The problem is keeping your code DRY when you have a mixture of two languages and execution environments. Inevitably you will have to choose which frameworks you want to use , picking two heavyweight frameworks for client and server will inevitably mean that they fight for control of your application if you want to use both to the fullest because each provides their own router and templating etc. So you need to decide which is going to drive your application.
      - eric_bullington 12y ago
        >heavyweight frameworks for client and server will inevitably mean that they fight for control of your application This is completely true, and I've found things to go best if I do one of two things: 1) Do a server side (template driven) app, using a server framework like Flask, ExpressJS, or else just Golang, with very light Javascript on the client, maybe using JQuery and Bootstrap for Javascript or else just pure Javascript. Minimal progressive enhancement. 2) Do a client-side app using a client framework like AngularJS or Backbone, or ReactJS, and build out a RESTful backend on the server side (or use Firebase or Parse.com). I even do authentication logic on the client now, since it's possible to do so securely. Not possible to use without Javascript. In between these two extremes is a no man's land, particularly if you use big client and server frameworks (as you say pointed out). In my experience, such an approach can make it extremely difficult to build a coherent app structure.
deleted 12y ago
[deleted]
dllthomas 12y ago
I mostly agree, but would add that there seems to be a tendency to try and build a "full client-side application" out of things that needn't be one, which I think is a subtly different mistake than the one you were describing - which I would describe as "building a regular website as if it were a full client-side application".
- themartorana 12y ago
  But isn't that just artificially limiting yourself for no real reason? The no-JavaScript argument seems like IE6 repeating itself - intentionally dumbing down the capabilities at hand for a select few - except in this case (vs IE 6 in the aughts) it really is significantly "the few." It might seem technically silly for me to have tons of parallax scrolling and DOM manipulation on my blog, but who cares? I agree that decisions like this have the capacity to disrupt business in certain cases, but I don't see it being something that important in most businesses. Edit: I'm taking a strong view here for certain, but I wonder who, outside an audience this technically literate, actually disables JS? True, the CDN argument is a good one, but in that case I assume most of my other static assets would be blocked as well.
  - agwa 12y ago
    Sites with minimal or no JavaScript are faster than sites with lots of JavaScript. The volume of JS is often so large, especially with frameworks, that it can take a long time both to transfer and to execute. I've noticed the difference to be significant on older computers or slower Internet connections, but it's even perceptible on new systems with fast Internet connections. Studies repeatedly show that ordinary users care about the speed of websites. I think this is a very good reason to shy away from making a "full client-side application" unless the benefits from that approach are significant.
    - Benjamin_Dobell 12y ago
      Studies don't show that users care about the speed of websites - they show that users care about the ease, and therefore "perceived speed", by which they can achieve a goal. A website with a quality interactive UX that adapts to user's needs, ideally with minimal interruption, is going to be substantially more efficient for the user. This is especially true since the very nature of web requires communicating with remote servers in order to update and persist the user's state. Loading an entire webpage every time state changes is not just slower, it's also quite disruptive for the user. Javascript's power comes down to the fact it offers AJAX and a way to manipulate the DOM on the fly. In addition to avoiding full-page reloads, it has the advantage that you can present the user with meaningful UI i.e. progress indicators and what-not.
pdkl95 12y ago
> it's rather rude to just show a white screen Exactly. In the case of something like gmail, while many of the features cannot [practically] be implemented without Javascript, it is always important to have some fallback. Even a dumb, read-only, paginated-<ul> of your inbox is useful. I could be on a strange browser, or behind a restrictive or badly implemented firewall. Even just a message saying what should have been on the page can serve as a reason to come back when a proper browser is available. Put another way: given the noscript extension exists, you should probably give at least <i>some</i> reason for people to click the whitelist button. Just have something there; the Meteor style of not caring and sending an empty <body> tag just makes your site look like a broken webserver.
MrMember 12y ago
Nothing frustrates me more than opening a link to a news article or some other text-based medium, seeing all of the text render normally, and then getting redirected to a page telling me to enable Javascript.

scrollaway 12y ago

I'd like people to start more readily differenciating between web apps and documents (dynamic or not). I think we're at the point where it's obvious that there is a difference between the two and it's just as obvious requiring JS for web apps is completely acceptable.

dllthomas 12y ago
I think you are getting at an important distinction, but you're confused about what it actually is. The important question is, "What is the goal of this site? What is the best way to still meet that goal without JS?" For documents, the answer is probably "provide the information", and that can trivially be accomplished without JS. For some excruciatingly dynamic web apps, the answer might be "use someone else's product" or even "it can't be done". There is substantial middle ground, though.
- scrollaway 12y ago
  So look at the middle-ground in terms of functionality, then. If a feature cannot be provided without JS, then don't provide it to those who don't have JS and move on. If the feature is not critical to other parts of the app, don't make those other parts depend on it. This always seems to be a controversial discussion yet all it is about is a few well-understood rules: - Manage your dependencies - Don't break things on purpose because you don't like the user's setup - Don't feel obligated to fully support platforms you have no desire of supporting
  - dllthomas 12y ago
    Well, treat each feature the same way, really. Offering a less comfortable but still functional experience is precisely what "progressive enhancement" is about. I agree that for many projects, at some point, there is functionality that can't be reasonably made accessible without JS, given the constraints of the project. I do think that many people seem to be too quick to go there. I don't think we have any major disagreement.
  - jiggy2011 12y ago
    The problem is keeping your code DRY when you have a mixture of two languages and execution environments. Inevitably you will have to choose which frameworks you want to use , picking two heavyweight frameworks for client and server will inevitably mean that they fight for control of your application if you want to use both to the fullest because each provides their own router and templating etc. So you need to decide which is going to drive your application.
    - eric_bullington 12y ago
      >heavyweight frameworks for client and server will inevitably mean that they fight for control of your application This is completely true, and I've found things to go best if I do one of two things: 1) Do a server side (template driven) app, using a server framework like Flask, ExpressJS, or else just Golang, with very light Javascript on the client, maybe using JQuery and Bootstrap for Javascript or else just pure Javascript. Minimal progressive enhancement. 2) Do a client-side app using a client framework like AngularJS or Backbone, or ReactJS, and build out a RESTful backend on the server side (or use Firebase or Parse.com). I even do authentication logic on the client now, since it's possible to do so securely. Not possible to use without Javascript. In between these two extremes is a no man's land, particularly if you use big client and server frameworks (as you say pointed out). In my experience, such an approach can make it extremely difficult to build a coherent app structure.

deleted 12y ago

[deleted]

dllthomas 12y ago

I mostly agree, but would add that there seems to be a tendency to try and build a "full client-side application" out of things that needn't be one, which I think is a subtly different mistake than the one you were describing - which I would describe as "building a regular website as if it were a full client-side application".

themartorana 12y ago
But isn't that just artificially limiting yourself for no real reason? The no-JavaScript argument seems like IE6 repeating itself - intentionally dumbing down the capabilities at hand for a select few - except in this case (vs IE 6 in the aughts) it really is significantly "the few." It might seem technically silly for me to have tons of parallax scrolling and DOM manipulation on my blog, but who cares? I agree that decisions like this have the capacity to disrupt business in certain cases, but I don't see it being something that important in most businesses. Edit: I'm taking a strong view here for certain, but I wonder who, outside an audience this technically literate, actually disables JS? True, the CDN argument is a good one, but in that case I assume most of my other static assets would be blocked as well.
- agwa 12y ago
  Sites with minimal or no JavaScript are faster than sites with lots of JavaScript. The volume of JS is often so large, especially with frameworks, that it can take a long time both to transfer and to execute. I've noticed the difference to be significant on older computers or slower Internet connections, but it's even perceptible on new systems with fast Internet connections. Studies repeatedly show that ordinary users care about the speed of websites. I think this is a very good reason to shy away from making a "full client-side application" unless the benefits from that approach are significant.
  - Benjamin_Dobell 12y ago
    Studies don't show that users care about the speed of websites - they show that users care about the ease, and therefore "perceived speed", by which they can achieve a goal. A website with a quality interactive UX that adapts to user's needs, ideally with minimal interruption, is going to be substantially more efficient for the user. This is especially true since the very nature of web requires communicating with remote servers in order to update and persist the user's state. Loading an entire webpage every time state changes is not just slower, it's also quite disruptive for the user. Javascript's power comes down to the fact it offers AJAX and a way to manipulate the DOM on the fly. In addition to avoiding full-page reloads, it has the advantage that you can present the user with meaningful UI i.e. progress indicators and what-not.

pdkl95 12y ago

> it's rather rude to just show a white screen Exactly. In the case of something like gmail, while many of the features cannot [practically] be implemented without Javascript, it is always important to have some fallback. Even a dumb, read-only, paginated-<ul> of your inbox is useful. I could be on a strange browser, or behind a restrictive or badly implemented firewall. Even just a message saying what should have been on the page can serve as a reason to come back when a proper browser is available. Put another way: given the noscript extension exists, you should probably give at least <i>some</i> reason for people to click the whitelist button. Just have something there; the Meteor style of not caring and sending an empty <body> tag just makes your site look like a broken webserver.

MrMember 12y ago

Nothing frustrates me more than opening a link to a news article or some other text-based medium, seeing all of the text render normally, and then getting redirected to a page telling me to enable Javascript.