browser should not even let the page see this action
> Don't roll your own link navigation.
browser should not even let the page see this action
> Don't roll your own text selection.
browser should not even let the page see this action
> Don't roll your own copy and paste.
browser should not even let the page see this action
I'm serious. WHY javascript code is even allowed to see all these actions of the user? We already loaded the page and rendered it - we users must already be free to do with the content as we please
Also: Javascript should not be able to touch the browser history. I know it's useful for some apps. But it's too prone to abuse and that API should be revoked.
> WHY javascript code is even allowed to see all these actions of the user?
Because the alternative is UI/UX Designers and Visionary Managers insisting on keeping Flash and Java Applets and Microsoft Visual Silverlight .Net++ around forever, because you can't do some things in the browser and We Need To Do Them.
Some things have minimal complexity that either lives in the language itself or in libraries. The Web has minimal bells and whistles that are either implemented in the browsers itself or in plugins.
Seriously. Don't. You want a single-select box? Use a combo box or radio button group. Want an edit box? Use an edit box. Want a list that finds things as you type? That's in the standard too. Don't roll your own.
This "roll our own controls for everything" bothers me to no end as a screen reader user, because practically nobody properly follows ARIA best practices, and that leads to a less accessible internet.
I agree with a caveat: Default date pickers on mobile devices are very good. But on desktop browsers they are terrible. They break design continuity in a very ugly way and have quirks between browsers and systems. And personally, the popup calendar they provide just too small. If the system took over the date picker on desktop like it does on mobile devices instead of forcing the browser to handle it, I feel like we could get somewhere better.
I just went and confirmed this because it’s not something I’ve really looked at and I agree. The date picker you get from a straight up <input type=“date”> on iOS webkit is pretty nice.
The one in webkit on macOS isn’t quite as good, but is better than the one in firefox if only because firefox closes the picker when you type a year in to move far through time. Good thing firefox is open source.
Yes, but having worked on the date picker at Airbnb I can assure you almost every custom implementation (probably ours too!) messes up date picking in some region in an important way
Totally agree. What do engineers or designers think they're trying to accomplish when they mess with the scroll bar? Or the password field? "We are so sophisticated, the built in behavior is simply not good enough for us!"
Congratulations, now your website is a shitty experience for your users. Well done.
In my experience, it's never the engineers nor the designers who makes those decisions. Stuff like that always comes from higher up the ladder, some middle management figure who thinks he is smarter than he is, mandates such abominations and refuses to hear reason from the engineers and the designers.
The engineers and designers then proceed to do as they're told because they like that nice fat paycheck at the end of the month more than they like the service they're building. Which is fair enough.
> Among software developers, and especially among those who work on security-sensitive systems, there is a well-known maxim: Don't roll your own crypto. This does not mean that nobody is allowed to write cryptographic code. Someone has to. It means that, for ordinary production software that protects sensitive data of users, we should not rely on a private, unreviewed implementation that has not been vetted by the wider software development community. We should use established, vetted software packages or tools wherever possible.
The great things about all these crypto libraries are:
- Minimal to no dependencies
- Coded by security conscious people
- Often externally audited
I wish more libs/deps are crafted like them. Until then the risk of rolling your own vs using a dep isn’t as different as it could be.
In the age of AI and npm supply chain attacks I feel like there are more reasons than ever to roll your own.
One other possible title of this article could just be, don’t break UI conventions. Which is not the same thing.
Instead of trying to download and configure a date time thing (for something app specific like domain specific date ranges) rather than having to rely on the configuration of a larger library, then having to manage all future major version upgrades (and some of these npm libraries have major versions every year!) why not just create your own smaller surface area component? It’ll be literally zero maintenance compared to managing an npm dependency in your app.
If you don’t “roll your own,” you must choose from what other people have created. And in this space, there are a bewildering array of options, each of which carries some new pile of abstractions that make some things easy and other things hard.
Many eyes are supposed to make bugs shallow. In the webdev space, many eyes on something like React lead to numerous opinionated alternatives, each successful enough to warrant consideration. This doesn’t seem to be slowing down, either.
Meanwhile, vanilla HTML and DOM capabilities have never been stronger.
all providers only document their bloat-spyware-buggy javascript that creates a button and handles all in the client.
then using libraries you are open to attacks in one hundred ways because those implement all the unrealistic things in the spec (including overriding issuer and setting crypto to nothing, via attacker controlled fields). after two days of evaluating i just gave up and wrote my own, server side and handling the singular case everyone uses. 20 lines, which was less then adopting the libraries.
UX standardizes as majorities begin to agree on patterns/interactions/concepts.
Unfortunately, it’s 1) difficult to reach consensus 2) difficult to broadcast and 3) difficult to enforce. For example, even when major browsers achieve 1) and (e.g. implement a standard component) 2) and 3) are still huge gaps.
If one really wanted to ruffle feathers they could make a script that checks out the latest source code for OpenSSL, OpenSSH maybe a few other communication daemons, makes just a few very subtle changes to a few ciphers, shim in some random nonsensical padding, compile and distribute to a private network of systems.
Whatever you do don't teach AI how to do this or there could be a flood of new VPN's speaking new ciphers that code breaking farms won't know what to do with and ciphers that are not known to exist.
What an odd idea. You should always write your own code whenever possible, that's how we get better things. It's not my job to make the standard better or to force a bad standard, it's your job to make the standard the obviously correct choice.
I'm going to go out on a limb and say there is never a valid reason to mess with page scrolling. It's just bad design and a terrible experience for the user.
> Don't roll your own page scrolling, link navigation, text selection, context menu, copy and paste, password field, or date picker.
Javascript in the browser was a mistake. And if we had to have it, the suitable scope of it was what we had around 2004.
Google invested tens of billions in it realizing they had a way of owning the browser space simply by making it insanely complex. Just hire all of the web standards people, tell them to go crazy and then also hire thousands of C++ browser developers for decades to implement everything. Boom, a moat!
I understand the frustration but don’t take it too far. People often post great games here, cool visualisations, useful utilities. Hardly any of those would work at all without JavaScript.
You can do terrible things with JS but you can do great things too.
For those not trying to implement the dark patterns that enshittify the web.
If you don't roll your own back button behavior, you've missed the opportunity to show a few more ads.
If you don't make your window full screen on my shitty old tablet browser (yes, I'm looking at you, BBC), then it's far too easy for me to close your window. (Joke's on you, though -- my old Samsung tablet has a physical back button.)
> Don't roll your own page scrolling.
browser should not even let the page see this action
> Don't roll your own link navigation.
browser should not even let the page see this action
> Don't roll your own text selection.
browser should not even let the page see this action
> Don't roll your own copy and paste.
browser should not even let the page see this action
I'm serious. WHY javascript code is even allowed to see all these actions of the user? We already loaded the page and rendered it - we users must already be free to do with the content as we please
Because the web browser was burdened with the role of application host, and not just presentation of static content. There's no going backwards.
All of these annoyances and more can be blocked by StopTheMadness (available for iOS and macOS):
https://underpassapp.com/StopTheMadness/
I found that most internet pages are greatly enhanced by disabling JavaScript in my web browser.
It should be illegal for a website to hijack text copying, right clicking, or keyboard shortcuts like Ctrl*f.
No. There are already too many batshit insane laws trying to regulate the internet. We need less, not more.
Indeed, people talk about technical solutions to social problems but there is also such a thing as trying a legal solution for a technical problem.
Also: Javascript should not be able to touch the browser history. I know it's useful for some apps. But it's too prone to abuse and that API should be revoked.
> WHY javascript code is even allowed to see all these actions of the user?
Because the alternative is UI/UX Designers and Visionary Managers insisting on keeping Flash and Java Applets and Microsoft Visual Silverlight .Net++ around forever, because you can't do some things in the browser and We Need To Do Them.
Some things have minimal complexity that either lives in the language itself or in libraries. The Web has minimal bells and whistles that are either implemented in the browsers itself or in plugins.
I'd like to add:
* Don't roll your own standard controls
Seriously. Don't. You want a single-select box? Use a combo box or radio button group. Want an edit box? Use an edit box. Want a list that finds things as you type? That's in the standard too. Don't roll your own.
This "roll our own controls for everything" bothers me to no end as a screen reader user, because practically nobody properly follows ARIA best practices, and that leads to a less accessible internet.
Don't worry, they bother everyone else as well since they are usually broken one way or the other.
I'm always an "It Depends" kind of guy.
I have a personal issue with having a 500KB page load, so a button press can be animated.
I find that most datepickers are better than the browser's default. It's a shame that they can't be styled more
I agree with a caveat: Default date pickers on mobile devices are very good. But on desktop browsers they are terrible. They break design continuity in a very ugly way and have quirks between browsers and systems. And personally, the popup calendar they provide just too small. If the system took over the date picker on desktop like it does on mobile devices instead of forcing the browser to handle it, I feel like we could get somewhere better.
I just went and confirmed this because it’s not something I’ve really looked at and I agree. The date picker you get from a straight up <input type=“date”> on iOS webkit is pretty nice.
The one in webkit on macOS isn’t quite as good, but is better than the one in firefox if only because firefox closes the picker when you type a year in to move far through time. Good thing firefox is open source.
Yes, but having worked on the date picker at Airbnb I can assure you almost every custom implementation (probably ours too!) messes up date picking in some region in an important way
Except...?
There’s no except. They all suck in some specific way.
> I find that most datepickers are better than the browser's
You mean your browser's. There is no "the browser".
Totally agree. What do engineers or designers think they're trying to accomplish when they mess with the scroll bar? Or the password field? "We are so sophisticated, the built in behavior is simply not good enough for us!"
Congratulations, now your website is a shitty experience for your users. Well done.
In my experience, it's never the engineers nor the designers who makes those decisions. Stuff like that always comes from higher up the ladder, some middle management figure who thinks he is smarter than he is, mandates such abominations and refuses to hear reason from the engineers and the designers.
The engineers and designers then proceed to do as they're told because they like that nice fat paycheck at the end of the month more than they like the service they're building. Which is fair enough.
I don't know. Someone above mentioned that don't like their browser's date picker. Maybe they are a "middle management figure", but probably not.
In my experience it's always the designers.
Or nowadays managers can use an LLM to take control, sieze the moment, and make the buy button bigger.
> Among software developers, and especially among those who work on security-sensitive systems, there is a well-known maxim: Don't roll your own crypto. This does not mean that nobody is allowed to write cryptographic code. Someone has to. It means that, for ordinary production software that protects sensitive data of users, we should not rely on a private, unreviewed implementation that has not been vetted by the wider software development community. We should use established, vetted software packages or tools wherever possible.
The great things about all these crypto libraries are:
- Minimal to no dependencies
- Coded by security conscious people
- Often externally audited
I wish more libs/deps are crafted like them. Until then the risk of rolling your own vs using a dep isn’t as different as it could be.
In the age of AI and npm supply chain attacks I feel like there are more reasons than ever to roll your own.
One other possible title of this article could just be, don’t break UI conventions. Which is not the same thing.
Instead of trying to download and configure a date time thing (for something app specific like domain specific date ranges) rather than having to rely on the configuration of a larger library, then having to manage all future major version upgrades (and some of these npm libraries have major versions every year!) why not just create your own smaller surface area component? It’ll be literally zero maintenance compared to managing an npm dependency in your app.
If you don’t “roll your own,” you must choose from what other people have created. And in this space, there are a bewildering array of options, each of which carries some new pile of abstractions that make some things easy and other things hard.
Many eyes are supposed to make bugs shallow. In the webdev space, many eyes on something like React lead to numerous opinionated alternatives, each successful enough to warrant consideration. This doesn’t seem to be slowing down, either.
Meanwhile, vanilla HTML and DOM capabilities have never been stronger.
so much this. tried to implement oauth recently.
all providers only document their bloat-spyware-buggy javascript that creates a button and handles all in the client.
then using libraries you are open to attacks in one hundred ways because those implement all the unrealistic things in the spec (including overriding issuer and setting crypto to nothing, via attacker controlled fields). after two days of evaluating i just gave up and wrote my own, server side and handling the singular case everyone uses. 20 lines, which was less then adopting the libraries.
UX standardizes as majorities begin to agree on patterns/interactions/concepts.
Unfortunately, it’s 1) difficult to reach consensus 2) difficult to broadcast and 3) difficult to enforce. For example, even when major browsers achieve 1) and (e.g. implement a standard component) 2) and 3) are still huge gaps.
If one really wanted to ruffle feathers they could make a script that checks out the latest source code for OpenSSL, OpenSSH maybe a few other communication daemons, makes just a few very subtle changes to a few ciphers, shim in some random nonsensical padding, compile and distribute to a private network of systems.
Whatever you do don't teach AI how to do this or there could be a flood of new VPN's speaking new ciphers that code breaking farms won't know what to do with and ciphers that are not known to exist.
https://news.ycombinator.com/item?id=48141474
agreed, that page decided they needed to write their own scrolling logic and it made the page horrible.
What an odd idea. You should always write your own code whenever possible, that's how we get better things. It's not my job to make the standard better or to force a bad standard, it's your job to make the standard the obviously correct choice.
At the same time, ask yourself "do I really need something special for this?" because the browser adds native support for things all the time.
I'm going to go out on a limb and say there is never a valid reason to mess with page scrolling. It's just bad design and a terrible experience for the user.
Don't fuck with the scroll bar should have its own article.
> Don't roll your own page scrolling, link navigation, text selection, context menu, copy and paste, password field, or date picker.
Javascript in the browser was a mistake. And if we had to have it, the suitable scope of it was what we had around 2004.
Google invested tens of billions in it realizing they had a way of owning the browser space simply by making it insanely complex. Just hire all of the web standards people, tell them to go crazy and then also hire thousands of C++ browser developers for decades to implement everything. Boom, a moat!
I understand the frustration but don’t take it too far. People often post great games here, cool visualisations, useful utilities. Hardly any of those would work at all without JavaScript.
You can do terrible things with JS but you can do great things too.
The cost of complexity is generally underestimated. (But hey, we can try out cool demos!)
"Don't roll your own" is perfectly sane advice...
For those not trying to implement the dark patterns that enshittify the web.
If you don't roll your own back button behavior, you've missed the opportunity to show a few more ads.
If you don't make your window full screen on my shitty old tablet browser (yes, I'm looking at you, BBC), then it's far too easy for me to close your window. (Joke's on you, though -- my old Samsung tablet has a physical back button.)