old, yes. good, no.
* Browsers never implemented a way to "log out", so creds end up cached in memory until the browser is restarted.
* There is no concept of a session so the credentials need to be included in each request and verified every time. If you use something like bcrypt or pbkdf2 on the backend that means every request will take hundreds of milliseconds.
* Since every request needs to be verified you can't easily use 2FA, without ugly hacks that 'remember' that the earlier creds were valid.
Hopefully things like WebAuthn will result in a resurgence of browser native autentication.
Yes! It was great! People would just transmit username and password in plaintext!
Wait. That's actually the opposite of great. That's why nobody uses it any more.
And no, handycapped people aren't excluded just because something doesn't degrade gracefully into a no-JS environment. You can (and many people do) make perfectly accessible web sites that still require JS.
As for offloading captchas to the client? That suffers a similar problem to basic auth - it's extremely vulnerable because attackers can obtain access to information that makes their job trivial. That's why we cannot "come up with a standard" - the client has to be treated as hostile, because there's no way to verify their integrity.
> Wait. That's actually the opposite of great. That's why nobody uses it any more.
Unless of course, if you're using HTTPS, in which case HTTP basic auth is fine and very simple to configure for many use cases.
My guess on the reason why is two-fold. First, we've been telling people that Basic Auth is a terrible thing only stupid people would use for more than two decades now, and once a lesson like that gets hammered deep enough into the mass consciousness it tends to stay there even long after the underlying facts have changed. And second, using Basic Auth means giving up any possibility of styling/designing your login experience and relying instead on the browser's built-in dialogs, which tend to be clunky and ugly in the extreme.
For further risks, see e.g. https://security.stackexchange.com/questions/988/is-basic-au...
Yes, it's simple. And you're trading off security for simplicity. Make that choice, maybe, for your Intranet or your small blog. Commercial sites that have stored PII really, REALLY shouldn't.
Then it's more or less as broken as alternative authentication methods
I’m a web developer who has never done significant forms without JavaScript.
So I’m curious: how would you handle reactive form fields without client side scripting? For example (perhaps a bad example): the user is entering data in “rows”. The user clicks “add row” and then a new row of fields appears. The user can also delete rows on a whim. Their changes should only be persisted once submit is clicked.
Would the “right” way be a full page reload with the row added/deleted, and caching all the values?
Not to mention, if fields require cross validation, is it customary to have to submit the form to get the validation error messages to occur? On some of the forms I’ve worked on, this would be very complex.
I find it mind-boggling there’s a generation of developers after me that doesn’t know the basics of server side state. No offence intended to yourself, and good on you for putting yourself out there to ask :)
There is a reason single-page apps became a thing, so I'm not clear why you think a page refresh for every user interaction is somehow a good thing. The dismissive attitude that "Regarding form fields appearing and all your fancy front end logic: none of this would fly in user testing" flies in the face of how 90% of heavy consumer front ends out there work today.
So the reason I always hear is performance: Less HTTP-requests, less latency, therefore better user experience. While that might be the case for flaky mobile connections (although executing lots of Javascript on resource constraint devices might not be the best idea either), with fast wired connections I experience the opposite: The single page apps of today feel a lot slower to me, than the websites with the same functionality did 10 years ago, thanks to all the computation which has to be done on client side. Just take Youtube for example: What a bad experience nowadays, especially with Firefox. That was way better back in a time when they didn't try to avoid page refreshes. And it's not just Youtube, it's all over the web. A welcome change to all of that is HN, because it still feels as fast as websites did, before frontend development was even a thing.
Straw man. We don’t want to go 15 years back, only 10 :-)
Seriously, the web was at a local maximum around 2009. Google worked, GMail was OK, Ajax was expected for r new stuff but was still written with graceful degradation in mind.
The problem is that many people, for various reason (accessibility, poor network connection, low-end hardware, etc.) are stuck "in the past" with regards to the web. This doesn't mean you have to make this the experience for everyone using your website: just make sure it degrades gracefully for those who can't use the new shiny stuff.
I hate to say it, but you're essentially saying "we can't afford to support people who are disabled, cannot afford the newest hardware, or are simply driving through a place with poor reception".
You have to do that cost-benefit analysis based on how important those things are to your business—for instance, screen reader support is an absolute necessity for the public sector and certain information-heavy apps, but probably not as important for visual tools.
I was talking to someone once about how ridiculously bloated Imgur is and that I had to use Imgoat because of the slow internet I was experiencing then. Of course they were trying to make all kinds of excuses like imgur not having servers nearby etc. But of course the really simple fact couldn't get to their heads that Imgur downloads like what 2-3 MB maybe even more of crap minus the actual image whereas Imgoat is something like 500 KB. No amount of network optimizations and caches etc are going to get over this fact. And also, such optimizations are over and above the page download size improvements anyways. If Imgoat used such techniques it'd be even faster. Most importantly: both sites have the exact same and simple core function, yet one site is so many times more bloated than the other. I will let you derive your own conclusions as to what this means.
And imgur also has the typical horrendous js misuses such as scrollbar hijacking that makes absolutely no sense etc.
Okay, example: client pays me to make an somewhat interactive website. Client wants it to be done using React as that is easy to get other devs for in the future, if the need arises. Client doesn't want to pay double (random estimate) to make everything behave in e.g. Lynx. Do I do it out of pocket, or just say no to the client?
And the absolute number of HN people like you shaming folks for not supporting text-mode browsers like lynx is a rounding error for most websites.
This is absolutely not true. Think about any kind of dynamic dashboard or data management platform. Having full page reloads for any minor change to filters, etc, is simply an unacceptable UX. But it has to be web-based because you need to be able to access it from any device, anywhere, without installing an app.
Plus, on a personal level, there are many services for which I will never install a native app—because I don't use it often, or because the native app provides no added benefit, or for one of a hundred other reasons. Those services don't get my business if they don't have a web app.
Theere's no reason a static contnt page must require JS Simply to render text, with a blank page as fallback.
Better ways of addressing the dashboaard example might be worth considering.
Too: bullshit dashboards with JS-based fakery;
https://www.theverge.com/2016/11/8/13571216/new-york-times-e...
In all seriousness, there is a big difference between static content pages and full-blown applications; the cost to make the latter work properly without JS enabled is almost never worth it. But the same is true even for some static pages; for instance, I would never expect that NY times election forecast page to work without JavaScript, and don't see any reason that it should. (The "JS-based fakery" is pretty irrelevant to the discussion, IMO.)
And: Sampling bias. A simple static page shouldn't require development. Hence, anyone doing web dev will have experience skewed strongly to more complex designs.
How would you describe the basic underlying structure and mechanics of a typical app you've built?
I strongly prefer single-page web apps over native apps. Web apps are constrained by my browser. Native apps get a lot more trust.
Native apps have a performance benefit at the expense of everything we take for granted on the web, like being able to open up a developer console and inspect it.
For example, I noticed that the top language translation app on the Mac App Store incurs a Google Analytics request for every keystroke. And since there's no easy network tab I can open on any app, I only found it out because I was curious how it worked and mitm'd it with a proxy. And I couldn't just toss uBlock Origin at it to de-trackify it like I can any web app.
Doesn't seem like a 100% epic win for users to me. In fact, the only upside I can even think of is that it probably uses less RAM than a Chrome tab opened to Google Translate. Let's slow down and acknowledge the trade-offs before we go all-in on HN memes like native app superiority.
Nothing in software engineering is absolute. And even if something were to be 100% the correct solution one day, the next it could change.
I wonder if there's a market for an alternative "browser" that loads "native" code (or as close as practically possible) and runs it in a sandbox.
This is probably not what you had in mind, and I'm not sure how good it would be at sandboxing, but REBOL Reblets imho come close to this <http://www.rebol.com/reblets.html>
Electron comes close, but many don’t like it at all. (I have somewhat mixed experiences, I love VS Code but I’m not too fond of Slack.)
Mike Acton once said something about having created a browser plugin his team used that loaded and ran binary exe tools on demand, but that it was also wildly insecure. At least I think he said something like that. My memory could be wrong about that.
Citation?
No.
And no, moving client-side logic to the back-end isn't self-evidently superior. Not for your implementation nor for user UX. So you'd have to use more than condescension to make your point. Full page reloads for an "Add Row" button died for more reasons than just "web developers are idiots and don't realize how everyone actually loved that."
I find it mind-boggling that people forget the hell of flash scope and the back button and broken history and POST-redirect-GET. Session state was miserable and the best thing about SPAs is avoiding that.
Usually, such things are in abundance and take priority over supporting browsers without JS. For the vast majority of apps and businesses, JS as a minimum entry requirement is a perfectly acceptable tradeoff of lost users vs additional development cost.
I think just insisting on JS is, for most applications, the best thing for the most people. If the app is such that it has maximum availability as one of its top goals (government public service, public infrastructure, bill paying etc) I completely get it, but otherwise I'm just not convinced that not requiring JS is somehow inherently good.
If you'll allow a pretty weak analogy, it's almost like refusing to use a car and insisting upon using a horse and cart. You may have your own good reasons for doing that, and that's completely fine, you are free to make that choice, but you absolutely should expect the modern roads not to cater to you, and to be very often inconvenienced. Indeed, you shouldn't really expect society to spend lots of tax money catering to your choice and designing all roads, junctions, etc with it in mind, beyond the very minimum level so you can at least use the most important roads.
But rather than any analogy, think about how many times more powerful a modern computer is than a computer from 2000. Now think about how many times more "things" you can do on that computer simultaneously. The latter is much smaller than the former.
A US college or university site can be sued for lack of Section 508 compliace.
So, it goes beyond development costs to legal risk of lack of compliance.
OTOH, a site selling cars probably does not need to worry about potential car-buyers using screen-readers.
I'm absolutely all for accessibility and would never argue against making things accessible as part of some cost-based tradeoff. Frankly this shouldn't even be an issue that comes up if you 'just do things right' from the get go - but even if it does, the imperative is always on you to just fix it.
There might be a correlation where apps that happen to use JS are more likely to be written in a way which is less accessible by default, but that's another conversation.
With that out the way - totally agree with you, for certain apps with regulatory requirements insisting that JS not be required for use, that's what you do - and for good reason - max availability to anyone for public services etc - that makes complete sense.
The point I may have misunderstood is putting development effort into a SPA that only uses JS and works well with a screenreader versus the non-JS alternative that also works well with a screenreader.
Of course, it depends on where in the development process the developer becomes ‘aware’ of making the site compliant.
As you said, ‘do the right thing from the get go’.
Perhaps you should give it a try and learn how to do it. That way you'll know when building non-js fallbacks is feasible and how do it easily.
> is it customary to have to submit the form to get the validation error messages to occur?
You trust the client to perform validation? Client-side validation should only be used to improve UX, not as a substitute for server-side validation.
Something like 90% of sites I run in to deliver static content, yet almost all use Javascript (again, for tracking and ad delivery).
Fortunately, the overwhelming majority of these sites still work great or at least good enough without Javascript.
Most sites out there really have no legitimate need for Javascript, with the exception of truly interactive sites like ones that let you play games in the browser, let you use some sort of application (like a spreadsheet, word processor, graphics program, or, arguably, web mail) in the browser, or do something like let you see live updates of things like stock tickers. But most sites are not like this. They just serve static content that could be served up just as well or even better without JS.
I don't know if this is the "right" way, but it sure sounds like a more reasonable fallback for clients without JS than serving them a blank page.
If the user didn't have Javascript enabled, then yes.
You'll have to do the validation server side anyway, client side scripting is just a "nice to have" it shouldn't be mandatory.
There are also probably too many people using the web to build applications that should be native.
I hear this a lot, but I'm personally glad I don't need to download an app to my phone/computer to order pizza or find directions.
Obviously this is a balance, but of the two extremes that could exist, having too many web-apps seems to be better than having too few. The quickest, simplest step you can take ATM to improve your device security is to install fewer apps -- particularly if you use an OS like Android.
It's not clear to me that situation would get any better if half of the web disappeared.
Yes! I recently used an e-shop that uses HTTP auth for user accounts. It was a bit unsettling, when the browser asked me for login credentials. :)
PS: I am using Ubuntu so I can't use 1Password as a standalone application; but how does it happen that a website is perfectly capable of blocking my interaction with the browser? Why doesn't Firefox ask for the password as part of the actual webpage instead?
Hadn't tried it in other browsers - does it work at all?
The cross-browser modal dialog is entirely anti-Ux.
I do wish Mozilla would finally do away with the modal auth dialog and use in-tab content that extensions can interact with.
https://github.com/h2o/h2o/wiki/Hosting-private-and-public-r...
This is one of those things that's technically true, but misleading.
Without scripting, you can't do any client-side validation, so you have to submit the form.
Without scripting, it's then harder to repop the form for the user when it fails.
I'm not saying things aren't excessive today -- they clearly are. But tossing client-side scripting entirely seems like a baby/bathwater situation.
Even more, html validation has by far a much better UX than most custom made JS solutions. For example if there is an error in the validation, your cursor is immediately transported to the offending field where you can do the correction, with the appropriate css classes available to highlight the field properly.
And for the stuff that html validation is not powerful enough, well then you most probably want to check that on the server as well anyway.
+ client-side validation is not validation.
Since you're doing the server-side validation you have to do anyway, it's child's play to return the HTML form with the values the client submitted pre-filled.
Client-side validation is a user convenience; it's awesome, but not sufficient in itself, because it can only protect the client, not the server, from invalid values.
Repopulating the form on the server side after validation failure is trivial and even more so when there are libraries that abstract that away (eg. wtforms).
On a similar note I somehow fail to see the benefit of writing (and often duplicating) large parts of business logic in client-side javascript and replacing perfectly good HTML form-submission mechanism with random JSON "REST" APIs.
> Repopulating the form on the server side
> after validation failure is trivial
True. But I'm glad to use Javascript on forms where fields are depending on input from other fields.
Or when you want to give the user the option to submit multiple entries of the same field type. For example when you ask for a job history.
Yes you can sumbit the form on every step but this is much harder to develop and has a lot of negative interactions for the user. For example the scrollposition is gone on each submit. And the user has to wait for a reply from the server on each submit.
Javascript is not the problem, bloated and spammy websites are.
Could this be fixed by dynamically-created anchors, so for instance when one is adding a new row to the "job experience" section of an application form, the reload to add the new row could also direct the user to "somesite.com/jobapp#JobExp2"?
It is part of the problem. Because of what Javascript allows and makes possible, bloat can thrive and endure in the modern web.
Because then Google would lose a large free pool of labor for training its machine learning.
Also, for a while they used it to determine street numbers for Google Maps.
That’s not how accessibility works. Requiring JavaScript does not change how accessible your site is to persons with disabilities.
What does hurt is making sites that are difficult to navigate by keyboard, without proper accessibility hints, and actually it’s quite easy to do that without JavaScript.
Using Chrome with all tracking enabled is basically that. You just don't see CAPTCHAs. Blocking bot is a hard problem to solve.
Basic authentication is fine if all you need is to control access to documents, but it can not be used for access delegation or any scope control.
Why not? It's just a header with a username and password. Your app can do whatever you want with that info. It also doesn't strictly have to be a username and password, you allow app tokens or whatever you want in there, that's just what the browser UI calls it.
You can make your application code check the authorization header, get the username from there and do authorization based on that.
Yes, I use it on some of my sites. For some reason chrome password manager won't work with it. Not sure why.
What would prevent the client from not rendering anything and always replying "yes this is a human"?
The client would take care of displaying the challenge, and taking and sending the repsonse.
If you write even mildly complex business applications with business rules and want a professional and non shitty user experience you absolutely need Javascript, there's no substitute.
If you make simple sign up forms then by all means don't use Javascript.
JavaScript doesn't deserve all the hate it gets, but the flip side of that is that it gets most of that hate because of the way developers keep using it.
Also, no JavaScript means no Google Maps.
plus what's in this comment https://security.stackexchange.com/questions/988/is-basic-au...
1. can be done by humans most of the time
2. cannot be done by machines most of the time
3. fit into the workflow of a web form
Point 3 is the interesting bit: You cannot build a captcha that tests dexterity, emotional intelligence or creative problem solving but is still accessible to a large internet audience.
I also wish more people valued clear language over these battles of ever more contrived euphemisms. George Carlin has a brilliant sketch on this very issue [1], which is both thoughtful and inoffensive (specifically references "handicapped" around the 5:30 mark).
I suggested no such thing. I just pointed out that it felt odd to me to read that. From the rest of the discussion below it's pretty clear that there isn't much of a global consensus. However, it's also clear that, whatever term is preferred, 'handicapped' isn't it.
I'd guess this is the case here, since the word is spelled incorrectly, too.
Speaking as an American.
I think the phrasing itself is problematic because it describes some people as broken or less than whole. That puts the emphasis on something wrong with a person rather than something wrong with the system.
Better to talk about the system: “this makes the site less accessible.” Because really, that’s the issue. It’s what you have control over and where the problem lies. Software engineers can change a websites but not the people using them. People should expect websites to accommodate their needs, not the other way around.
Respect is the core principle here. Respect your users and enable them to come as they are. Don’t place the focus on their weaknesses, regardless of what those are or why they have appeared. Focus on how you can build a system that’s accessible to everyone.
you can't build something that is accessible to "everyone". It's a myth. Because some people will stray so far away from the "median capabilities you can expect", you can't even imagine their problems or use cases. It's a very, very hard problem and well known in numerous areas of product design.
They problem is that when someone then ask - "to whom", you are left being unable to answer.
Practically, there is no way to identify all the potential issues a user of your site might face.
Like most large communities, there is less consensus on this than that kind of statement suggests. The terminology doesn't change because everyone in the community flips over night in their preferences, but because the ebb and flow of how many people do each term preferable (or intolerable) ends up changing what is on balance the best (or least bad) term.
It also describes people who might have limited sight now, but will have full sight later (recovering from surgery, etc). And that is something that could happen to any of us, so we should be building all our tech to cover at least common edge cases, if resources don't permit covering all of them.
The group of people with disabilities is not one hive mind with a collective opinion of which nouns they prefer: some will like some terms and some won't. Handicapped seems to be generally accepted as inoffensive to most people, so I don't see any reason to not use it.
though i suppose context and use of any term could be used to degrade especially something like this which does point to capabilities but because of a condition and specific to the disability.
http://news.bbc.co.uk/1/hi/magazine/3708576.stm
I wouldn't describe it as neutral at all.
how would you describe the term handicap in the form of a lack in capability specific to the disability?
https://www.youtube.com/watch?v=vuEQixrBKCc&feature=youtu.be...
Lost? It is just ignored for the sake of cool SPAs and hottest new js stuff.
It's an interesting alternative, though. Pay 5 bucks with the credit card to validate your identity if you don't want to subject yourself to captcha...
Really, there is no reason why a form should require JavaScript. When jQuery was hip, the js community celebrated "Graceful degradation". I frequently have the feeling this attitude is lost. That's super sad because it also excludes all the handycapped people.
Does even anybody remember the good old HTTP basic acess authentification? This is one of the most accessible ways of protecting ressources, it can be consumed by any HTTP client (!), and it is just reduced to the basic.
One of the worst things are these terrible captchas everywhere. I wonder why we cannot come up with a web standard interface in a way the captchas could be offloaded to customizable and adaptable GUIS rendered by the browsing client. This way, clients (users) could even declare what kind of captcha they can solve (blind people obviously cannot read images).