5 ms·

>If you're building a client-side application rather than just a web page, then it's okay if turning JS off breaks your app. I wouldn't even say that this was

>If you're building a client-side application rather than just a web page, then it's okay if turning JS off breaks your app. I wouldn't even say that this was necessarily true. Client side applications that can be made perfectly functional without JS should be made functional with JS. I don't want my online banking website or my tax return web apps to use javascript at all. They do, though. The fact that people make blogs, whose only real function is to serve static text, render with javascript is nuts.

MichaelGG 12y ago
Why should your bank spend more money and effort coding and testing both a JS enabled version plus a non JS version? The idea of no JS gets worse when you start applying the idea of just making an API, then having the client just use those APIs, whether they're browsers, backend systems or mobile clients. Requiring two separate client UIs to accommodate no-JS is unlikely to be a worthwhile cost for many sites/applications.
- crdoconnor 12y ago
  >Why should your bank spend more money and effort coding and testing both a JS enabled version plus a non JS version? My bank should not create a site that requires javascript at all. It increases the attack surface, it increases the likelihood that there will be bugs lurking and it increases the likelihood that the site will fail under circumstances where the user has low bandwidth and lots of dropped packets. Furthermore, it is not necessary for a working site that does everything that I want. At all. So what is the point?? >The idea of no JS gets worse when you start applying the idea of just making an API, then having the client just use those APIs, whether they're browsers, backend systems or mobile clients. Which I would not advise doing under any circumstances. Sharing common REST APIs between browser, backend systems and mobile clients sounds like a great idea until you consider that they all require different modes of authentication, authorization, access policies and security features and the like. Are you going to force your backend systems to authenticate using cookies and use the same CSRF protection? Having separate APIs need not mean that you duplicate a lot of code, so I don't see the need to try to accommodate multiple different use cases using the same APIs. >Requiring two separate client UIs to accommodate no-JS is unlikely to be a worthwhile cost for many sites/applications. Requiring JS for many sites/applications is unlikely to be a worthwhile cost, especially considering the additional testing required to make it work equivalently well to a non-JS enabled site/application.
  - gfodor 12y ago
    In general, the thing that draws people to building a JS-driven site is because it allows faster responsiveness for users, and a more versatile interface that behaves more like a application and less like a document. I think by now this much should be obvious. If the standard HTTP request/response approach resulted in the responsiveness in feedback we see with AJAX, then we wouldn't have been having this discussion for the last 10 years. So in short, if a JS-oriented banking website results in a user being able to do their banking more quickly, this is a real benefit and is "the point." You can argue it is not worth the tradeoff, but it's a bit odd to first admit you don't see the point and then go on to say it's not worth it. If you don't see the point, how can you make claims about if it's a valuable thing to be doing? If a bank has 50k daily active users and it shaves 1-2 minutes off of their individual session times, you're looking at saving approximately 50 days of time for people every day. And most banks probably have way more than 50k daily actives. Combine this with other potential benefits like users being able to get enough done in a single banking session to avoid a second visit later, or the user interface being less confusing since users can fall back on desktop metaphors, the amount of saved effort could become truly staggering, worth the additional risk and engineering time of developing a SPA-based solution.
    - crdoconnor 12y ago
      >In general, the thing that draws people to building a JS-driven site is because it allows faster responsiveness for users The reality, however, when you create sites like banking websites is that it is more often slower. Google maps is the exception, not the norm. >a more versatile interface that behaves more like a application and less like a document. I think by now this much should be obvious. If the standard HTTP request/response approach resulted in the responsiveness in feedback we see with AJAX, then we wouldn't have been having this discussion for the last 10 years. We've had the NoSQL discussion for an equivalent duration. Ironically, the source of this discussion was the same in both cases - that because it worked well for Google's specific requirements, it should be used everywhere. That proved to be an unfounded assumption. >So in short, if a JS-oriented banking website results in a user being able to do their banking more quickly, this is a real benefit Unfortunately, it doesn't usually result in a faster website. The banking website I use that makes heavy use of javascript is actually slower than those that do not. >You can argue it is not worth the tradeoff, but it's a bit odd to first admit you don't see the point and then go on to say it's not worth it. The point was fairly clear: unless you can make a significant speed gain (and more than you think can not), then there is no trade off. It is universally a bad idea. >If a bank has 50k daily active users and it shaves 1-2 minutes off of their individual session times, you're looking at saving approximately 50 days of time for people every day. That's the second time on this thread that you've pulled a number right out of your ass. >Combine this with other potential benefits like users being able to get enough done in a single banking session to avoid a second visit later, or the user interface being less confusing since users can fall back on desktop metaphors Then there are those AJAX websites that break the back button. Users LOVE that.

MichaelGG 12y ago

Why should your bank spend more money and effort coding and testing both a JS enabled version plus a non JS version? The idea of no JS gets worse when you start applying the idea of just making an API, then having the client just use those APIs, whether they're browsers, backend systems or mobile clients. Requiring two separate client UIs to accommodate no-JS is unlikely to be a worthwhile cost for many sites/applications.

crdoconnor 12y ago
>Why should your bank spend more money and effort coding and testing both a JS enabled version plus a non JS version? My bank should not create a site that requires javascript at all. It increases the attack surface, it increases the likelihood that there will be bugs lurking and it increases the likelihood that the site will fail under circumstances where the user has low bandwidth and lots of dropped packets. Furthermore, it is not necessary for a working site that does everything that I want. At all. So what is the point?? >The idea of no JS gets worse when you start applying the idea of just making an API, then having the client just use those APIs, whether they're browsers, backend systems or mobile clients. Which I would not advise doing under any circumstances. Sharing common REST APIs between browser, backend systems and mobile clients sounds like a great idea until you consider that they all require different modes of authentication, authorization, access policies and security features and the like. Are you going to force your backend systems to authenticate using cookies and use the same CSRF protection? Having separate APIs need not mean that you duplicate a lot of code, so I don't see the need to try to accommodate multiple different use cases using the same APIs. >Requiring two separate client UIs to accommodate no-JS is unlikely to be a worthwhile cost for many sites/applications. Requiring JS for many sites/applications is unlikely to be a worthwhile cost, especially considering the additional testing required to make it work equivalently well to a non-JS enabled site/application.
- gfodor 12y ago
  In general, the thing that draws people to building a JS-driven site is because it allows faster responsiveness for users, and a more versatile interface that behaves more like a application and less like a document. I think by now this much should be obvious. If the standard HTTP request/response approach resulted in the responsiveness in feedback we see with AJAX, then we wouldn't have been having this discussion for the last 10 years. So in short, if a JS-oriented banking website results in a user being able to do their banking more quickly, this is a real benefit and is "the point." You can argue it is not worth the tradeoff, but it's a bit odd to first admit you don't see the point and then go on to say it's not worth it. If you don't see the point, how can you make claims about if it's a valuable thing to be doing? If a bank has 50k daily active users and it shaves 1-2 minutes off of their individual session times, you're looking at saving approximately 50 days of time for people every day. And most banks probably have way more than 50k daily actives. Combine this with other potential benefits like users being able to get enough done in a single banking session to avoid a second visit later, or the user interface being less confusing since users can fall back on desktop metaphors, the amount of saved effort could become truly staggering, worth the additional risk and engineering time of developing a SPA-based solution.
  - crdoconnor 12y ago
    >In general, the thing that draws people to building a JS-driven site is because it allows faster responsiveness for users The reality, however, when you create sites like banking websites is that it is more often slower. Google maps is the exception, not the norm. >a more versatile interface that behaves more like a application and less like a document. I think by now this much should be obvious. If the standard HTTP request/response approach resulted in the responsiveness in feedback we see with AJAX, then we wouldn't have been having this discussion for the last 10 years. We've had the NoSQL discussion for an equivalent duration. Ironically, the source of this discussion was the same in both cases - that because it worked well for Google's specific requirements, it should be used everywhere. That proved to be an unfounded assumption. >So in short, if a JS-oriented banking website results in a user being able to do their banking more quickly, this is a real benefit Unfortunately, it doesn't usually result in a faster website. The banking website I use that makes heavy use of javascript is actually slower than those that do not. >You can argue it is not worth the tradeoff, but it's a bit odd to first admit you don't see the point and then go on to say it's not worth it. The point was fairly clear: unless you can make a significant speed gain (and more than you think can not), then there is no trade off. It is universally a bad idea. >If a bank has 50k daily active users and it shaves 1-2 minutes off of their individual session times, you're looking at saving approximately 50 days of time for people every day. That's the second time on this thread that you've pulled a number right out of your ass. >Combine this with other potential benefits like users being able to get enough done in a single banking session to avoid a second visit later, or the user interface being less confusing since users can fall back on desktop metaphors Then there are those AJAX websites that break the back button. Users LOVE that.