6 ms·

Maybe I can fill in the gap? If you are a developer, you shouldn't rely on Javascript. Yes, feel free to use Javascript to make things sexier, but the use case

Maybe I can fill in the gap? If you are a developer, you shouldn't rely on Javascript. Yes, feel free to use Javascript to make things sexier, but the use cases where a web page should require Javascript to render properly has substantial overlap with the "we didn't think things through" slice of the Venn diagram. If your page is unreadable with NoScript and RequestPolicy turned up to maximum paranoia, your webpage is broken. 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.

gfodor 12y ago
I think I gathered this, but my point is why does this matter? If I run a site that is unreadable on NoScript and RequestPolicy turned up to maximum paranoia, but am generating millions of dollars of revenue, is my webpage "broken?" If only 0.01% of my users actually are affected by such a thing, and I don't care about that, is it still "broken?" If a webpage has a missing closing </div> tag, but is never hit by a human being, is it still broken? I guess what I'm getting at is as I've gotten older I've grown less and less empathetic to arguments that seem to appeal to an engineer's sense of purity, correctness, and craftsmanship and not much else. Tie it to user pleasure, effectiveness, business metrics, anything, but citing the idea that somehow since the web was not designed with Javascript everywhere in mind meaning we should use it as the exception not the rule isn't much more than appeal to tradition argument to me. There are definitely areas of software engineering where you can find many examples where a lack of respect for the craft, or a lack of knowledge of history/standards results in failure, but I'm just not buying the idea that if you build a SPA with a fancy new javascript framework instead of making sure NoScript works you're somehow going to be paying for that in spades down the road because it's breaking some set of rules handed down by the high priests. There are about a million other technical decisions that have more of an impact in a serious project. (For example, instead of arguing about SPA vs non-SPA, or what framework, or whatever, ask yourself: "Is anyone on the team an expert in any particular flavor of this?" If the answer is "yes", then going with any one of those is almost certainly the best strategic decision regardless of the supposed merits or flaws of that particular approach.)
- lstamour 12y ago
  The big reason to avoid shipping a white page with JS turned off is performance. It implies that at some point, the JS will load and you can stop using ng-cloak or whatever else is hiding in the blank space. It's better to pre-load actual content, or if you don't have that, fake content, then to show nothing at all. Similarly, it's better to pay attention to back buttons so your users can navigate a website using built-in controls. This is especially important on phones, where it's easy to click a wrong link, and where back is literally a button. Can you do this with JS? Yes. Is it obvious? Not always. The same was true with our use of CSS over images, or web fonts over flash. Eventually the industry will move in the right direction, it just takes time and the occasional rant or two. ;-)
- aikah 12y ago
  > If only 0.01% of my users actually are affected by such a thing All users don't have the same value. And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. You might not care today,but when it's time to care, well your competitor that cared will get the users and the revenue lost because "you didn't care".
  - mklim 12y ago
    > And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. Do you have any data to back that up? In my experience it seems like the number of people who turn JS off by default has declined since SPAs became so common. It looks like the search trend for Noscript has been gradually declining since 2009, while Adblock has risen: http://www.google.com/trends/explore#q=noscript%2C%20adblock&cmpt=q&tz= http://www.google.com/trends/explore#q=noscript%2C%20adblock...
  - gfodor 12y ago
    This should have a huge *citation needed. There are a million decisions you make which affect user adoption and retention of a software product, deciding to support NoScript users is a small grain of sand in that desert. Your claim that this facet of all those decisions will result in a competitor stealing market share completely ignores the concept of engineering tradeoffs. The competitor that "cared" about noscript visitors may spend many man hours (in direct costs or opportunity cost) supporting those visitors, time may be best spent building better competitive differentiators for a larger number of visitors. No design decision lives in a vacuum, and in my own experience designing to support non-JS visitors is almost universally faaaar down the list of priorities if there are good reasons to not do so.
crdoconnor 12y ago
>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.
lambeosaurus 12y ago
> If you are a developer, you shouldn't rely on Javascript. I'm sorry but I think he's saying something a little to the left of that. His overarching point about javascript seems to be that it adds complexity to any application - suddenly, page loading indicators and all application states must be handled intelligently by us, developers. His point here is that we already have an issue with developers working on code they don't have the experience, ability or time to understand. SPAs and anything else lead to a serious requirement for developer discipline. I think some important points were, in my own words: - Choosing a technology stack doesn't matter - Choosing a framework doesn't matter - What the application does and how it behaves is all that matters. Choose any tech stack that will do the job. - No matter what tech stack you choose, your app will run into issues. It will need maintaining. Like he says: > What a good app needs is a team of dedicated people behind it. Good apps are good because talented people cared about them and pooled their skills. - No amount of abstraction will help. If the abstraction is not understood, it will also hurt. But please feel free to agree or disagree with me. I'd love to know what you all thought.
- gitah 12y ago
  Choosing a tech stack and framework DOES matter greatly. Some technologies make development a lot easier and maintainable. Otherwise everyone will still be using PHP to write their websites. Abstractions does help greatly and frameworks are a good way to get your entire team to think about things using the same abstraction. The platitude about needing a "talented", "passionate" team is vacuous and meaningless. You might as well write the key aspect of a good app is very little bugs. Absolutely meaningless statement. It's very obvious a bad developer with a good framework will lead to bad output; no need for a 5000 word article on it.
  - melvinmt 12y ago
    I've worked on projects that have generated hundreds of millions of dollars, all written in shitty PHP code. Was it a big pain for us developers to maintain it? Yes. Did our struggle matter? No.
    - 12y ago
MichaelGG 12y ago
What's missing is the why. Just asserting that all JS-driven sites are broken and should use progressive enhancement doesn't really translate into real benefits. Using a system that spits out JS and saves me time and effort is a win. Why should I trade that out? I agree for some users, a properly gracefully degrading system is nice. I like when sites I use are properly URL-based, when I can share links and they just work. But that's rarely a reason I'll switch sites. So until there's some solid evidence that relying on JS translates into lost money or other serious damage, it's simply not worthwhile and declaring such things broken by fiat accomplishes nothing.
ledzep2 12y ago
I disagree. Backward compatibility is sometimes necessary to keep and sometimes necessary to break. And the standard of browsing is evolving, with or without such efforts.
onion2k 12y ago
If your page is unreadable with NoScript and RequestPolicy turned up to maximum paranoia, your webpage is broken. Building a broken web page is fine if you choose to build it that way. If 1% of people can't see your site, or 10%, or even 99%, then that's your choice as a developer. If I want my business website built with WebGL, asm.js, HTML5 audio and WebRTC then that's ok. I'm allowed to do that even if you can't render it. As a user you have no implicit right to use a given website if your choice to turn something off or to use a browser that doesn't support something means it won't work for you. To draw an offline analogy, I have no right to build an application if I choose to remove make from my computer. There are exceptions - users who need special access technology like screen readers should be protected from developers who build in ways that mean they're put at a disadvantage for example - but ordinary people who choose not to use something like js have no such protections. Using a screen reader is usually not a choice.

gfodor 12y ago

I think I gathered this, but my point is why does this matter? If I run a site that is unreadable on NoScript and RequestPolicy turned up to maximum paranoia, but am generating millions of dollars of revenue, is my webpage "broken?" If only 0.01% of my users actually are affected by such a thing, and I don't care about that, is it still "broken?" If a webpage has a missing closing </div> tag, but is never hit by a human being, is it still broken? I guess what I'm getting at is as I've gotten older I've grown less and less empathetic to arguments that seem to appeal to an engineer's sense of purity, correctness, and craftsmanship and not much else. Tie it to user pleasure, effectiveness, business metrics, anything, but citing the idea that somehow since the web was not designed with Javascript everywhere in mind meaning we should use it as the exception not the rule isn't much more than appeal to tradition argument to me. There are definitely areas of software engineering where you can find many examples where a lack of respect for the craft, or a lack of knowledge of history/standards results in failure, but I'm just not buying the idea that if you build a SPA with a fancy new javascript framework instead of making sure NoScript works you're somehow going to be paying for that in spades down the road because it's breaking some set of rules handed down by the high priests. There are about a million other technical decisions that have more of an impact in a serious project. (For example, instead of arguing about SPA vs non-SPA, or what framework, or whatever, ask yourself: "Is anyone on the team an expert in any particular flavor of this?" If the answer is "yes", then going with any one of those is almost certainly the best strategic decision regardless of the supposed merits or flaws of that particular approach.)

lstamour 12y ago
The big reason to avoid shipping a white page with JS turned off is performance. It implies that at some point, the JS will load and you can stop using ng-cloak or whatever else is hiding in the blank space. It's better to pre-load actual content, or if you don't have that, fake content, then to show nothing at all. Similarly, it's better to pay attention to back buttons so your users can navigate a website using built-in controls. This is especially important on phones, where it's easy to click a wrong link, and where back is literally a button. Can you do this with JS? Yes. Is it obvious? Not always. The same was true with our use of CSS over images, or web fonts over flash. Eventually the industry will move in the right direction, it just takes time and the occasional rant or two. ;-)
aikah 12y ago
> If only 0.01% of my users actually are affected by such a thing All users don't have the same value. And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. You might not care today,but when it's time to care, well your competitor that cared will get the users and the revenue lost because "you didn't care".
- mklim 12y ago
  > And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. Do you have any data to back that up? In my experience it seems like the number of people who turn JS off by default has declined since SPAs became so common. It looks like the search trend for Noscript has been gradually declining since 2009, while Adblock has risen: http://www.google.com/trends/explore#q=noscript%2C%20adblock&cmpt=q&tz= http://www.google.com/trends/explore#q=noscript%2C%20adblock...
- gfodor 12y ago
  This should have a huge *citation needed. There are a million decisions you make which affect user adoption and retention of a software product, deciding to support NoScript users is a small grain of sand in that desert. Your claim that this facet of all those decisions will result in a competitor stealing market share completely ignores the concept of engineering tradeoffs. The competitor that "cared" about noscript visitors may spend many man hours (in direct costs or opportunity cost) supporting those visitors, time may be best spent building better competitive differentiators for a larger number of visitors. No design decision lives in a vacuum, and in my own experience designing to support non-JS visitors is almost universally faaaar down the list of priorities if there are good reasons to not do so.

crdoconnor 12y ago

>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.

lambeosaurus 12y ago

> If you are a developer, you shouldn't rely on Javascript. I'm sorry but I think he's saying something a little to the left of that. His overarching point about javascript seems to be that it adds complexity to any application - suddenly, page loading indicators and all application states must be handled intelligently by us, developers. His point here is that we already have an issue with developers working on code they don't have the experience, ability or time to understand. SPAs and anything else lead to a serious requirement for developer discipline. I think some important points were, in my own words: - Choosing a technology stack doesn't matter - Choosing a framework doesn't matter - What the application does and how it behaves is all that matters. Choose any tech stack that will do the job. - No matter what tech stack you choose, your app will run into issues. It will need maintaining. Like he says: > What a good app needs is a team of dedicated people behind it. Good apps are good because talented people cared about them and pooled their skills. - No amount of abstraction will help. If the abstraction is not understood, it will also hurt. But please feel free to agree or disagree with me. I'd love to know what you all thought.

gitah 12y ago
Choosing a tech stack and framework DOES matter greatly. Some technologies make development a lot easier and maintainable. Otherwise everyone will still be using PHP to write their websites. Abstractions does help greatly and frameworks are a good way to get your entire team to think about things using the same abstraction. The platitude about needing a "talented", "passionate" team is vacuous and meaningless. You might as well write the key aspect of a good app is very little bugs. Absolutely meaningless statement. It's very obvious a bad developer with a good framework will lead to bad output; no need for a 5000 word article on it.
- melvinmt 12y ago
  I've worked on projects that have generated hundreds of millions of dollars, all written in shitty PHP code. Was it a big pain for us developers to maintain it? Yes. Did our struggle matter? No.
  - 12y ago

MichaelGG 12y ago

What's missing is the why. Just asserting that all JS-driven sites are broken and should use progressive enhancement doesn't really translate into real benefits. Using a system that spits out JS and saves me time and effort is a win. Why should I trade that out? I agree for some users, a properly gracefully degrading system is nice. I like when sites I use are properly URL-based, when I can share links and they just work. But that's rarely a reason I'll switch sites. So until there's some solid evidence that relying on JS translates into lost money or other serious damage, it's simply not worthwhile and declaring such things broken by fiat accomplishes nothing.

ledzep2 12y ago

I disagree. Backward compatibility is sometimes necessary to keep and sometimes necessary to break. And the standard of browsing is evolving, with or without such efforts.

onion2k 12y ago

If your page is unreadable with NoScript and RequestPolicy turned up to maximum paranoia, your webpage is broken. Building a broken web page is fine if you choose to build it that way. If 1% of people can't see your site, or 10%, or even 99%, then that's your choice as a developer. If I want my business website built with WebGL, asm.js, HTML5 audio and WebRTC then that's ok. I'm allowed to do that even if you can't render it. As a user you have no implicit right to use a given website if your choice to turn something off or to use a browser that doesn't support something means it won't work for you. To draw an offline analogy, I have no right to build an application if I choose to remove make from my computer. There are exceptions - users who need special access technology like screen readers should be protected from developers who build in ways that mean they're put at a disadvantage for example - but ordinary people who choose not to use something like js have no such protections. Using a screen reader is usually not a choice.