2 ms·

> Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily. Every time someone makes a si

by jefftk 7y ago

> Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily. Every time someone makes a site they're balancing a bunch of tradeoffs. For example, when I built https://trycontra.com https://trycontra.com I could have implemented the search server-side, with a query and response, but this would have involved writing active server side code. Instead I implemented the search entirely in client-side javascript. People are free to choose not to run the JS, but I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either. > Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky. Downloading and executing binaries from random websites is far more risky than allowing JS. A binary runs as you can can trivially do anything you could do, from keylogging to subverting your browser. If you can do similar harmful things from JS, on the other hand, you're eligible for very large bounties from browser vendors. JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS. > That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page. HTML often fails gracefully, but not always. If someone writes a site that doesn't fail gracefully and so is completely unreadable in IE6, I don't think they've done anything wrong.

dredmorbius 7y ago
JS search is not generally a critical site function. Rendering the goddamned content is. If you can't at a minimum give me a title, byline, dateline, main body text and/or some level of summary or description of non-textual content (as with graphics, audio, video, or interactive elements), then you're failing. (SPAs or web applications should at least provide context for understanding what the application is/does. I'm not calling for all functionality to be rendered in HTML, but sufficient context to determine WTF the site is about. Your "but I cannot implement search" is a strawman, and really doesn't address the core complaint. As it stands, I'm looking at options for SSG-based blog posting, and at how it might be possible to support search. JS-based options, plus an extensive tagging / ontological classification, strike me as a reasonable compromise. The fact that the Web is lacking a usable search-oriented standard which could bypass much of this problem, is one that's seldom noted. If sites could provide a permuted index in accessible format, and a standard mechanism for accessing it via a browser site-search function (or independent third-party search tools) ... well, the present online landscape would look remarkably different. Sadly, we're not there, and the orientation of the leading browser developer is quite likely not going to support such development.
- danShumway 7y ago
  > If sites could provide a permuted index in accessible format I'm not going to dismiss this out of hand, but this is a harder problem than you realize. We did have search keywords at one point. The problem was that sites started stuffing them with irrelevant values. Google removed that and started doing their own analysis, because keywords made it too easy to game SEO. There are certainly ways that keywords could be done better today, I'm not going to say we should give up on the entire concept. But asking websites to self-categorize themselves is a very tricky problem that is very prone to abuse. Remember that the web (currently) monetizes eyeballs, so until that situation changes there is a strong incentive to show up in every search regardless of whether or not you're relevant.
- jefftk 7y ago
  > JS search is not generally a critical site function. Rendering the goddamned content is. My example was a domain specific search engine. The only thing the site does is let you run searches, implemented client-side in JS. Without JS the site completely doesn't work.
JohnFen 7y ago
> I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either. Perhaps you misunderstand what I'm saying. I am not saying that you, or anyone else, is obligated to do anything in particular. All I did was to point out a factor that should be considered -- if your site does not work without JS, then you are excluding some people. If you don't care, fair enough. However, I stand by my assertion that sites that do not fail gracefully are (with certain exceptions) poorly engineered sites. > Downloading and executing binaries from random websites is far more risky than allowing JS That does not mean that allowing JS is safe. > JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS. Yes, I'm well aware of that. And yet, JS is commonly used to do all sorts of nefarious things (such as tracking, for instance) anyway.

by jefftk 7y ago

dredmorbius 7y ago

JS search is not generally a critical site function. Rendering the goddamned content is. If you can't at a minimum give me a title, byline, dateline, main body text and/or some level of summary or description of non-textual content (as with graphics, audio, video, or interactive elements), then you're failing. (SPAs or web applications should at least provide context for understanding what the application is/does. I'm not calling for all functionality to be rendered in HTML, but sufficient context to determine WTF the site is about. Your "but I cannot implement search" is a strawman, and really doesn't address the core complaint. As it stands, I'm looking at options for SSG-based blog posting, and at how it might be possible to support search. JS-based options, plus an extensive tagging / ontological classification, strike me as a reasonable compromise. The fact that the Web is lacking a usable search-oriented standard which could bypass much of this problem, is one that's seldom noted. If sites could provide a permuted index in accessible format, and a standard mechanism for accessing it via a browser site-search function (or independent third-party search tools) ... well, the present online landscape would look remarkably different. Sadly, we're not there, and the orientation of the leading browser developer is quite likely not going to support such development.

danShumway 7y ago
> If sites could provide a permuted index in accessible format I'm not going to dismiss this out of hand, but this is a harder problem than you realize. We did have search keywords at one point. The problem was that sites started stuffing them with irrelevant values. Google removed that and started doing their own analysis, because keywords made it too easy to game SEO. There are certainly ways that keywords could be done better today, I'm not going to say we should give up on the entire concept. But asking websites to self-categorize themselves is a very tricky problem that is very prone to abuse. Remember that the web (currently) monetizes eyeballs, so until that situation changes there is a strong incentive to show up in every search regardless of whether or not you're relevant.
jefftk 7y ago
> JS search is not generally a critical site function. Rendering the goddamned content is. My example was a domain specific search engine. The only thing the site does is let you run searches, implemented client-side in JS. Without JS the site completely doesn't work.

JohnFen 7y ago

> I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either. Perhaps you misunderstand what I'm saying. I am not saying that you, or anyone else, is obligated to do anything in particular. All I did was to point out a factor that should be considered -- if your site does not work without JS, then you are excluding some people. If you don't care, fair enough. However, I stand by my assertion that sites that do not fail gracefully are (with certain exceptions) poorly engineered sites. > Downloading and executing binaries from random websites is far more risky than allowing JS That does not mean that allowing JS is safe. > JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS. Yes, I'm well aware of that. And yet, JS is commonly used to do all sorts of nefarious things (such as tracking, for instance) anyway.