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.
> 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.
I hate how most "modern" websites have MEGABYTES of JavaScript. CSS? Pack it in a js bundle with JSX and object literals. Images? Throw them in too, just make it load on demand.
Hell, just put a <div id=root/> there and let js do the rest. It's not like we have browsers and networks and edge nodes optimized to render websites in other ways.
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.
> 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.
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.)
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.
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
Not the GP, but to me this case feels like extortion.
I have the same problem with paying for extensions like Dark Reader, DeArrow, and any ad blockers. None of these apps should exist in the first place. They were created because the default state of the web is barbaric. And some developers have the gall to charge for the luxury of making the experience tolerable?
But they’re saying it feels like extortion. The problems of the web aren’t the fault of those extension developers, nor can they do anything about it besides trying to mitigate it. It’s in our best interest that they can do so sustainably, meaning charging for it. It’s not gall, they’re fighting it for themselves and making the solution available for all.
That comment places a lot of blame where it doesn’t lie. It’s like calling surgeons extortionists for having the gall to charge for treating you. Yes, ideally that should be free and available to all, and perhaps if those people had the freedom to choose (e.g. having their own needs met so they didn’t have to work) they would do it. But that’s not how the system is setup, and their skills don’t translate to fixing the problem at the root. Not all of us are cut out to be politicians (and as we all know, being well-intentioned as one still doesn’t mean you have the power to enact policy).
> It’s like calling surgeons extortionists for having the gall to charge for treating you. Yes, ideally that should be free and available to all
What do you mean by "should be"? Surgery is free and available to everyone. So why would one accuse surgeons of being extortionists? So I am not sure how the surgeon comparison works. That example supports the parent commenter's point that these extensions should be free.
Of course, there is still the practical question of who will do the work and how they will make a living. We can do what we do for surgeons. Maybe have a nonprofit consortium that people fund, so that it can support the extension developers. Yes, people would be spending money either way, but at least that money would be going toward a larger cause. Just like we pay taxes so the government can fund surgeons, who can then treat people.
I meant “would be”. Not that I think it makes that much difference here.
> Surgery is free and available to everyone.
That’s definitely not true worldwide. I think if you stop for a minute you can come up with at least one country. And even in those where it is free in public hospitals, it’s not uncommon for some to have a waitlist of years to the point you can die before it even happens. Also, did you know there are places where they don’t even have hospitals, let alone surgeons? The world is a big place, lots of disparity.
> So why would one accuse surgeons of being extortionists?
Even given all that, I think if you engage with the argument in good faith and steel man it instead of nitpicking, you’ll understand the point and can come up with your own example to satisfy you. Just pick a job you can’t do and have to pay for someone to fix something which wasn’t your fault or the fault of the other person. I believe you’re a smart person and could surely come up with something with little effort.
> there is still the practical question of who will do the work and how they will make a living.
That’s… The point. Especially for programmers, how many of us would do this shit for free, full time and beyond, for the sole purpose of benefiting others, if we had the opportunity to because we didn’t have to worry about basic needs? A large number. Way less than the number of programmers in the world right now, and that’s a good thing.
> Maybe have a nonprofit consortium that people fund
Fantastic idea. Are you doing it? Can you? Do you know where to start? And if you can’t, is that your fault? Should you be blamed for it? Are you an extortionist? Do you have gall for not doing it?
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.
this is why the web stack feels like a car held together with duct tape these days. we collectively took the wrong fork in the road and doubled, tripled, and quadrupled down. computing in general is glorious when i feel like im working near computing and then i get to web app stuff and im like.. i dunno. sad. i get why we ended up where we did with web stacks but seriously what a nightmare
It's not a nightmare. It's the most popular gui/document/app platform for a reason. It's complex because it has to cater to many types of usecases. Name one platform that's better. I think people have tried and some might have even succeeded in limited slice of what web can do.
I have strong suspicion that it's exactly because of the “document” history why web is so approachable to creators, why there is “view source” and ultimately why you can hop from simple html blog, to CRUD app, to advanced CAD software.
> 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.
Nobody “needed” the web to do these things. We decided that the effort and cost of making native applications was too great. I’d argue we went the wrong way given that even the same browser will exhibit slightly different behavior depending upon the underlying platform upon which it runs.
It depends. A lot of websites refuse to display some stuff without JavaScript, and of course online payments insist on JavaScript (to the point that trying to push through without it can result in strange errors and potential double-charges as you troubleshoot).
I mean, I'm all for for switching to Lua or smth (which is a slightly different anti-JS camp than yours), but the problem isn't in interactive (or even non-frozen) pages in general - it's in pages reading user actions that user doesn't expect/want to
>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 on the modern web, the user is the content, sold to the highest bidder.
The Web is an ads platform with useful functionality as bait.
That's all there really is to it: Mosaic added image support. Investors got excited and asked if the images could animate, if they could record click data and credit card data, if they could add video and additional presentational elements. Holistic user experiences were secondary.
To move forward we have to accept that most of this wasn't an accident and it needs some breaking changes.
Applications like Google Docs would be impossible without each of the four things you listed being available. We had Google Docs that didn’t roll-your-own for each of the items in that list and it was called Writely and it was absolute dogshit (but super cool for its time) because those limitations were too extreme. And by extension it wouldn’t make sense to have Chromebooks as a category of hardware, because web software could never compete at a feature parity level with native software.
That is indeed how things like copy/paste through the menus already work; you install an extension to get the clipboard permission or the browser limits you to keyboard shortcuts
> Applications like Google Docs would be impossible without each of the four things you listed being available.
I was already in favor of banning it. You don't have to keep trying to convince me.
Okay, snark off. But as someone who dislikes the proliferation of "web apps", I'd be perfectly happy to see Google Docs and others die off if it meant we moved back to real, locally run applications.
Right -- like the famous zinger about democracy, Google Docs is the worst implementation of collaborative word processing except for all the others that have been tried.
> WHY javascript code is even allowed to see all these actions of the user? We already loaded the page and rendered it
Nope we haven’t. At least not in a web application. At least not since the days Infinite Scrolling was invented. IIRC Twitter, for eg, only renders a partial list depending on the scroll position.
I once wrote a NER tagger, where implementing custom text selection allowed users to not stress about selecting the exact word boundaries when manually tagging 1000s of words per day.
I can probably find legitimate use cases for almost of these things in the list. While I agree with the broader theme of the article, this idea that the user agent should be a dumb display is not valid.
Yes, you get to the heart of the problem - we turned what started of as a document viewer into a general purpose application platform.
Features paramount in a document viewer (broadly, "respect the user's local document viewing preferences") aren't desirable in a general purpose application platform.
A large number of companies/web developers don't think of themselves as offering the user a document to view on their own terms, but rather an "experience" that they want full control over (which means, most of the time: show ads and record user behavior).
If you're offering me a game, fair enough.
But if you're showing me my hotel reservation or electric bill, I want a document, not an ""experience"".
And management asked nobody, and then did it anyway.
Your preferences are unusual. Most people either don't care or prefer flashiness over consistency.
It's something I've come to realise about the why the world is the way it is. Yes, to a certain extent it is because of locally maximal power structures and hierarchies propagating - but it is also because, taken as a whole, people are really just like that. A single politician may be corrupt, but that does not mean that most people, if taking their place, would not be as or more corrupt. Management sucks, yes - but that doesn't mean that most engineers who become managers wouldn't act the same way. You and I may prefer consistency over flashiness, but the majority of the world couldn't care less. So flashiness and "experiences" win.
A nerd podcast that I listen to was talking about shells and touched on Spaceship for zshell. One of the hosts talked about how having multi-line prompts became possible in the 90s, how it isn't new, but how packaging it up is new and now it's a trend for some people.
I'd previously found it interesting enough to try out for half a day. I've been back to my regular boring prompt ever since. Humans are attracted to shiny things. I innately understand why stuff like this is popular, even if I don't understand it intellectually / psychologically (I tried it because it looked cool; it didn't stick; what's different? I don't know, but I could talk a lot about it without really having a structured point.)
Yes, we've broken the intent of the browser. I'm sure there are better examples, but for me it was Google Maps. Oh my goodness, have you ever seen such a thing? It had to be impossible, but they did it. And from there, nothing was safe.
I don't think we can put the genie back in the bottle. There are things we can believe shouldn't be allowed in the browser. But breaking them would break things that people rely upon. Only pushing further to native apps (which I actually like on my desktop computer, phone is a walled garden) would make it possible and that's annoying as hell) could make it possible. Rambling. Just woke up. Please forgive.
On the extreme end, a web app can do all of its own rendering in a canvas with WebGL/WebGPU. Some apps do exactly this: Figma, Google Maps, Google Docs. Just to name a few. (edit: Earlier I claimed PDFjs uses canvas, but it does not. I was confusing it with Google Docs [1].)
It's a thing you can do. But it is very bad for extensions and extension developers for the same reasons that Java applets, Flash, and Shockwave were bad for the web. These apps are difficult for end users to customize. It's a real bane to tinkerers. And it's a shame that "view source" has slowly grown completely useless over the decades.
Why are HTML5/JS games so much laggier and buggier than Flash games?
Maybe it's not due to differences in the technologies used. I can imagine it's because less people make these games and spend less time per game to optimize it. Years ago there were thousands of flash games of each genre, a lot of them very well made, likely optimized for speed, pure works of art. Now I see the same 100 HTML5 games on all the sites, maybe reskinned a bit. I don't think we'll ever have in terms of quality as what was available on Kongregate or Armor Games.
I might download an old browser with Flash and some games. Years ago there was a collection of a few TB of Flash games, hope it's still around. Maybe some games that required network will not work, but most didn't.
Why are HTML5/JS games so much laggier and buggier than Flash games?
I’m not sure that’s actually the case.
Steve Jobs argued in his “thoughts on Flash” letter that Flash was too buggy, insecure and resource-hungry for mobile platforms. I worked on Chrome around that time and the Flash plugin was definitely one of the biggest sources of problems.
I think all the stuff you’re complaining about is to do with business models and not really anything to do with the technology. I reckon if Flash were still around we’d probably be in much the same place we are now. People would be complaining about restaurant menus being written in Flash instead of plain old HTML, etc etc.
Out of curiosity, does anyone like the way Google Maps hijacks scrolling? I use a trackpad. When I scroll, I'd want it to pan around on the map, not zoom in and out (which always feels awful as a scroll action and never stops where I want it to).
Click-drag to pan doesn't feel nice.
It doesn't really matter anymore, since 99% of maps use is on mobile now, but this was always a small pain point to me in the past.
If you mean you prefer pinch/spread for zoom-out/in, I prefer the status quo with trackpad 2-finger scroll for zooming.
Pinching/spreading with index and middle finger feels unergonomic. Using my thumb on the trackpad would also feel unnatural, as would putting my 2 index fingers on the trackpad.
2 finger scroll is something you can "fling" such that the zooming motion continues even as your fingers have been lifted off the trackpad. Trying to "fling" a spread-out motion with your index and middle finger is an awkward motion, and of course in a pinching motion, your fingers would just crash into each other, so you'd have to lift before they crash. Pretty awkward.
On the phone, I often prefer tap then drag up/down (i.e. touch, lift, touch, slide) to zoom in/out with a single finger. It allows me to "fling" the zooming motion so it continues after I've lifted my finger. It makes a phone's interface behave like a trackpad's scrolling-zoom.
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.
Counterpoint: all of these things are built right into the user's browser, and browser vendors independently work to avoid attacks across the userbase without any intervention from web designers. In fact, if the browser itself is compromised, we probably have bigger problems anyway. By just letting the browser handle these tools, we do not need to spend any resources at all.
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.
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.
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, static compile or containerize and distribute to a private network of systems in minecraft.
Whatever you do don't teach AI how to do this or there could be a flood of VPN's speaking new but not really new ciphers that code breaking farms won't know what to do with and ciphers that are not known to exist and yet nobody ever really rolled their own.
This concept was conceived whilst interacting with Rubix cube players.
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.
> You should always write your own code whenever possible, that's how we get better things.
No, that's how you end up with a mountain of bad half-assed implementations. You should only roll your own when truly necessary, and only after thoroughly understanding the problem and the existing mature solutions and honestly comparing that against your own ideas to see if you're missing important aspects of the problem.
And even after doing all that, when it comes to implementing custom UI for something that already has a standard approach, you should still usually throw away your custom version because it won't be better by a wide enough margin to justify the effort users will need to invest in re-learning and breaking their existing habits.
Save your UI experimentation for your personal tools, and don't inflict it on innocent users.
I'd like to add "don't roll your own image viewer"
twitter and google and google maps and so many have rolled their own and they completely suck compared to just letting the browser render an img tag. They inevitably fail on some bad multitouch interaction that affects the web page, and the image viewer container. Or they add some slow-as-molasses zooming effect.
Nobody cares that a browser's navigation buttons, address bar, tabs, or window controls
don't match the current website. Probably because these things are obviously outside the extents of the web page.
However, scrollbars, context menus, modal windows, and date pickers are rendered within the extents of the web page, and get replaced all the time.
It is my opinion that these controls don't need to be styled to match the website, because they're not part of the website. They're part of the browser. Non-diegetic. Outside the fourth wall.
I'd go even more basic than this: only use native everything. It's a travesty that web pages are to use use custom controls or have any kind of look and feel different from the native OS ones. The look and feel of everything (every app, every webpage) should be determined by the end user, via their OS settings, not by the author of the app or document. What we have is designers being able to get to "my app/webpage looks the same for everyone"; what we ought to have is users being able to get to "every app/webpage looks the same for me".
That depends entirely on how much needs to be downloaded for each round trip.
A lean website can work just fine on complete trash connections like GPRS or Comcast without incremental loading. Web developers are not incentivized to make lean websites.
SPAs add unnecessary complexity -> increasing page weight -> making finer grained incremental loading more important -> requiring even more code. It's a self-induced problem.
As a corollary, McMaster Carr is often used as an example of a website that didn't fall into the SPA trap, and customers greatly benefit from that [1]. The front page weighs about 14 MB with all of the images, but the loading experience is great even with network throttling simulating a poor connection. There is a good reason the site has this reputation.
Overengineering is the true root of all evil. Web developers cannot learn that fast enough.
The problem with Don't Roll Your Own is that Other People's Code gets more and more grotesque with each passing year. More bloat, more random dependencies, more churn. Other People are a headache in any industry; with Other People's code you have Other People problems by proxy.
> "there is a well-known maxim: Don't roll your own crypto."
Fun fact, this was written shortly after one of the biggest linux vulnerabilities which was caused by a kernel crypto library, presumably to avoid userspaces rewriting their own crypto.
the split between documents and apps explains a lot of the pain here. if a page mostly presents content, hijacking selection, scroll, or copy should be treated as a regression
A strange issue I’ve found is careless use of AI at my job has lead to many people rolling their own incomplete mini parsers. Think YAML parsers of a frontmatter that expects either `key: value` exactly or treats `item1, item2, …` as a list.
It’s a litmus test I use to see if someone actually glanced over what the AI generated.
This feels like a modern version of people writing regex to validate email addresses: employing a complicated, yet incomplete roll-your-own approach as the wrong solution to a problem
giancarlostoro | 19 hours ago
singiamtel | 19 hours ago
paularmstrong | 19 hours ago
king_geedorah | 18 hours ago
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.
pwdisswordfishs | 18 hours ago
You mean your browser's. There is no "the browser".
Shellban | 17 hours ago
julianozen | 18 hours ago
neals | 18 hours ago
ceejayoz | 18 hours ago
joenot443 | 15 hours ago
The date range selector used in Google Flights is a near flawless control. The implementation can be done, it’s just hard.
poisonborz | 12 hours ago
omnimus | 10 hours ago
chihuahua | 19 hours ago
Congratulations, now your website is a shitty experience for your users. Well done.
amarant | 19 hours ago
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.
IcyWindows | 18 hours ago
m0llusk | 18 hours ago
LtWorf | 18 hours ago
cousin_it | 17 hours ago
lysace | 19 hours ago
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!
iainmerrick | 18 hours ago
You can do terrible things with JS but you can do great things too.
lysace | 18 hours ago
TacticalCoder | 16 hours ago
There are too many words in that sentence. Here are the words that can be removed: "browser", "in" and "the".
ChrisMarshallNY | 19 hours ago
I have a personal issue with having a 500KB page load, so a button press can be animated.
not_a_bot_4sho | 16 hours ago
I hate how most "modern" websites have MEGABYTES of JavaScript. CSS? Pack it in a js bundle with JSX and object literals. Images? Throw them in too, just make it load on demand.
Hell, just put a <div id=root/> there and let js do the rest. It's not like we have browsers and networks and edge nodes optimized to render websites in other ways.
wxw | 18 hours ago
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.
yardstick | 18 hours ago
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.
zephen | 18 hours ago
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.)
shermantanktop | 18 hours ago
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.
iririririr | 18 hours ago
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.
analogpixel | 18 hours ago
agreed, that page decided they needed to write their own scrolling logic and it made the page horrible.
NooneAtAll3 | 18 hours ago
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
vitally3643 | 18 hours ago
VladVladikoff | 18 hours ago
equinoxnemesis | 18 hours ago
js2 | 18 hours ago
https://underpassapp.com/StopTheMadness/
orhmeh09 | 17 hours ago
NooneAtAll3 | 17 hours ago
aaaand you lost my interest the moment money got involved
all these things are already fixable by browser extensions - what is lacking is exposing that in browser options and even making it the default
latexr | 16 hours ago
Which is what StopTheMadness is and does.
ladberg | 16 hours ago
jason_oster | 15 hours ago
I have the same problem with paying for extensions like Dark Reader, DeArrow, and any ad blockers. None of these apps should exist in the first place. They were created because the default state of the web is barbaric. And some developers have the gall to charge for the luxury of making the experience tolerable?
And yet, I've paid for every one of these.
iainmerrick | 9 hours ago
paulryanrogers | 5 hours ago
We already have regulations for accessibility and advertising. Yet they're weak in the US and rarely enforced.
latexr | 2 hours ago
That comment places a lot of blame where it doesn’t lie. It’s like calling surgeons extortionists for having the gall to charge for treating you. Yes, ideally that should be free and available to all, and perhaps if those people had the freedom to choose (e.g. having their own needs met so they didn’t have to work) they would do it. But that’s not how the system is setup, and their skills don’t translate to fixing the problem at the root. Not all of us are cut out to be politicians (and as we all know, being well-intentioned as one still doesn’t mean you have the power to enact policy).
throw5 | an hour ago
What do you mean by "should be"? Surgery is free and available to everyone. So why would one accuse surgeons of being extortionists? So I am not sure how the surgeon comparison works. That example supports the parent commenter's point that these extensions should be free.
Of course, there is still the practical question of who will do the work and how they will make a living. We can do what we do for surgeons. Maybe have a nonprofit consortium that people fund, so that it can support the extension developers. Yes, people would be spending money either way, but at least that money would be going toward a larger cause. Just like we pay taxes so the government can fund surgeons, who can then treat people.
latexr | 57 minutes ago
I meant “would be”. Not that I think it makes that much difference here.
> Surgery is free and available to everyone.
That’s definitely not true worldwide. I think if you stop for a minute you can come up with at least one country. And even in those where it is free in public hospitals, it’s not uncommon for some to have a waitlist of years to the point you can die before it even happens. Also, did you know there are places where they don’t even have hospitals, let alone surgeons? The world is a big place, lots of disparity.
> So why would one accuse surgeons of being extortionists?
Even given all that, I think if you engage with the argument in good faith and steel man it instead of nitpicking, you’ll understand the point and can come up with your own example to satisfy you. Just pick a job you can’t do and have to pay for someone to fix something which wasn’t your fault or the fault of the other person. I believe you’re a smart person and could surely come up with something with little effort.
> there is still the practical question of who will do the work and how they will make a living.
That’s… The point. Especially for programmers, how many of us would do this shit for free, full time and beyond, for the sole purpose of benefiting others, if we had the opportunity to because we didn’t have to worry about basic needs? A large number. Way less than the number of programmers in the world right now, and that’s a good thing.
> Maybe have a nonprofit consortium that people fund
Fantastic idea. Are you doing it? Can you? Do you know where to start? And if you can’t, is that your fault? Should you be blamed for it? Are you an extortionist? Do you have gall for not doing it?
bigstrat2003 | 18 hours ago
NooneAtAll3 | 17 hours ago
I don't enjoy needing to "go back" 100 times, once for each page of the book just to return to f.e. search results I opened the book from
incr_me | 18 hours ago
trueno | 17 hours ago
omnimus | 10 hours ago
I have strong suspicion that it's exactly because of the “document” history why web is so approachable to creators, why there is “view source” and ultimately why you can hop from simple html blog, to CRUD app, to advanced CAD software.
jay_kyburz | 16 hours ago
msla | 18 hours ago
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.
king_geedorah | 17 hours ago
andai | 18 hours ago
Shellban | 17 hours ago
NooneAtAll3 | 17 hours ago
I mean, I'm all for for switching to Lua or smth (which is a slightly different anti-JS camp than yours), but the problem isn't in interactive (or even non-frozen) pages in general - it's in pages reading user actions that user doesn't expect/want to
GolfPopper | 17 hours ago
Because on the modern web, the user is the content, sold to the highest bidder.
manoDev | 17 hours ago
crq-yml | 17 hours ago
That's all there really is to it: Mosaic added image support. Investors got excited and asked if the images could animate, if they could record click data and credit card data, if they could add video and additional presentational elements. Holistic user experiences were secondary.
To move forward we have to accept that most of this wasn't an accident and it needs some breaking changes.
jakevoytko | 16 hours ago
BrenBarn | 16 hours ago
at_compile_time | 16 hours ago
jakevoytko | 15 hours ago
tiltowait | 15 hours ago
I was already in favor of banning it. You don't have to keep trying to convince me.
Okay, snark off. But as someone who dislikes the proliferation of "web apps", I'd be perfectly happy to see Google Docs and others die off if it meant we moved back to real, locally run applications.
poisonborz | 12 hours ago
iainmerrick | 9 hours ago
tecoholic | 16 hours ago
Nope we haven’t. At least not in a web application. At least not since the days Infinite Scrolling was invented. IIRC Twitter, for eg, only renders a partial list depending on the scroll position.
I once wrote a NER tagger, where implementing custom text selection allowed users to not stress about selecting the exact word boundaries when manually tagging 1000s of words per day.
I can probably find legitimate use cases for almost of these things in the list. While I agree with the broader theme of the article, this idea that the user agent should be a dumb display is not valid.
wasmperson | 16 hours ago
scrolling: used by games, maps, image viewers
link navigation: used for client-side routing (youtube/twitch, any website with a chat window)
text selection and copy/paste: word processors, spreadsheet editors, forum software, etc.
I'm not sure if your question was sincere or if you were trying to say that the web should not support these use cases.
gyomu | 16 hours ago
Features paramount in a document viewer (broadly, "respect the user's local document viewing preferences") aren't desirable in a general purpose application platform.
A large number of companies/web developers don't think of themselves as offering the user a document to view on their own terms, but rather an "experience" that they want full control over (which means, most of the time: show ads and record user behavior).
If you're offering me a game, fair enough. But if you're showing me my hotel reservation or electric bill, I want a document, not an ""experience"".
kevmo314 | 13 hours ago
worthless-trash | 11 hours ago
dag100 | 9 hours ago
Your preferences are unusual. Most people either don't care or prefer flashiness over consistency.
It's something I've come to realise about the why the world is the way it is. Yes, to a certain extent it is because of locally maximal power structures and hierarchies propagating - but it is also because, taken as a whole, people are really just like that. A single politician may be corrupt, but that does not mean that most people, if taking their place, would not be as or more corrupt. Management sucks, yes - but that doesn't mean that most engineers who become managers wouldn't act the same way. You and I may prefer consistency over flashiness, but the majority of the world couldn't care less. So flashiness and "experiences" win.
alsetmusic | 6 hours ago
I'd previously found it interesting enough to try out for half a day. I've been back to my regular boring prompt ever since. Humans are attracted to shiny things. I innately understand why stuff like this is popular, even if I don't understand it intellectually / psychologically (I tried it because it looked cool; it didn't stick; what's different? I don't know, but I could talk a lot about it without really having a structured point.)
Yes, we've broken the intent of the browser. I'm sure there are better examples, but for me it was Google Maps. Oh my goodness, have you ever seen such a thing? It had to be impossible, but they did it. And from there, nothing was safe.
I don't think we can put the genie back in the bottle. There are things we can believe shouldn't be allowed in the browser. But breaking them would break things that people rely upon. Only pushing further to native apps (which I actually like on my desktop computer, phone is a walled garden) would make it possible and that's annoying as hell) could make it possible. Rambling. Just woke up. Please forgive.
jason_oster | 16 hours ago
It's a thing you can do. But it is very bad for extensions and extension developers for the same reasons that Java applets, Flash, and Shockwave were bad for the web. These apps are difficult for end users to customize. It's a real bane to tinkerers. And it's a shame that "view source" has slowly grown completely useless over the decades.
[1]: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
iainmerrick | 9 hours ago
iamalizard | 6 hours ago
Maybe it's not due to differences in the technologies used. I can imagine it's because less people make these games and spend less time per game to optimize it. Years ago there were thousands of flash games of each genre, a lot of them very well made, likely optimized for speed, pure works of art. Now I see the same 100 HTML5 games on all the sites, maybe reskinned a bit. I don't think we'll ever have in terms of quality as what was available on Kongregate or Armor Games.
I might download an old browser with Flash and some games. Years ago there was a collection of a few TB of Flash games, hope it's still around. Maybe some games that required network will not work, but most didn't.
iainmerrick | 2 hours ago
I’m not sure that’s actually the case.
Steve Jobs argued in his “thoughts on Flash” letter that Flash was too buggy, insecure and resource-hungry for mobile platforms. I worked on Chrome around that time and the Flash plugin was definitely one of the biggest sources of problems.
I think all the stuff you’re complaining about is to do with business models and not really anything to do with the technology. I reckon if Flash were still around we’d probably be in much the same place we are now. People would be complaining about restaurant menus being written in Flash instead of plain old HTML, etc etc.
tiltowait | 15 hours ago
Out of curiosity, does anyone like the way Google Maps hijacks scrolling? I use a trackpad. When I scroll, I'd want it to pan around on the map, not zoom in and out (which always feels awful as a scroll action and never stops where I want it to).
Click-drag to pan doesn't feel nice.
It doesn't really matter anymore, since 99% of maps use is on mobile now, but this was always a small pain point to me in the past.
drfloyd51 | 14 hours ago
Panning by swiping feels so natural. That it breaks on a trackpad feels like a major oversight.
jolmg | 12 hours ago
Pinching/spreading with index and middle finger feels unergonomic. Using my thumb on the trackpad would also feel unnatural, as would putting my 2 index fingers on the trackpad.
2 finger scroll is something you can "fling" such that the zooming motion continues even as your fingers have been lifted off the trackpad. Trying to "fling" a spread-out motion with your index and middle finger is an awkward motion, and of course in a pinching motion, your fingers would just crash into each other, so you'd have to lift before they crash. Pretty awkward.
On the phone, I often prefer tap then drag up/down (i.e. touch, lift, touch, slide) to zoom in/out with a single finger. It allows me to "fling" the zooming motion so it continues after I've lifted my finger. It makes a phone's interface behave like a trackpad's scrolling-zoom.
kazinator | 14 hours ago
awongh | 18 hours ago
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.
Shellban | 17 hours ago
bigstrat2003 | 18 hours ago
ethin | 18 hours ago
* 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.
LtWorf | 18 hours ago
Bender | 18 hours ago
Whatever you do don't teach AI how to do this or there could be a flood of VPN's speaking new but not really new ciphers that code breaking farms won't know what to do with and ciphers that are not known to exist and yet nobody ever really rolled their own.
This concept was conceived whilst interacting with Rubix cube players.
andai | 18 hours ago
nosioptar | 2 hours ago
casey2 | 18 hours ago
wtallis | 17 hours ago
No, that's how you end up with a mountain of bad half-assed implementations. You should only roll your own when truly necessary, and only after thoroughly understanding the problem and the existing mature solutions and honestly comparing that against your own ideas to see if you're missing important aspects of the problem.
And even after doing all that, when it comes to implementing custom UI for something that already has a standard approach, you should still usually throw away your custom version because it won't be better by a wide enough margin to justify the effort users will need to invest in re-learning and breaking their existing habits.
Save your UI experimentation for your personal tools, and don't inflict it on innocent users.
bschwindHN | 17 hours ago
twitter and google and google maps and so many have rolled their own and they completely suck compared to just letting the browser render an img tag. They inevitably fail on some bad multitouch interaction that affects the web page, and the image viewer container. Or they add some slow-as-molasses zooming effect.
pvillano | 17 hours ago
However, scrollbars, context menus, modal windows, and date pickers are rendered within the extents of the web page, and get replaced all the time.
It is my opinion that these controls don't need to be styled to match the website, because they're not part of the website. They're part of the browser. Non-diegetic. Outside the fourth wall.
pancsta | 16 hours ago
BrenBarn | 16 hours ago
rozumem | 16 hours ago
jason_oster | 14 hours ago
A lean website can work just fine on complete trash connections like GPRS or Comcast without incremental loading. Web developers are not incentivized to make lean websites.
SPAs add unnecessary complexity -> increasing page weight -> making finer grained incremental loading more important -> requiring even more code. It's a self-induced problem.
As a corollary, McMaster Carr is often used as an example of a website that didn't fall into the SPA trap, and customers greatly benefit from that [1]. The front page weighs about 14 MB with all of the images, but the loading experience is great even with network throttling simulating a poor connection. There is a good reason the site has this reputation.
Overengineering is the true root of all evil. Web developers cannot learn that fast enough.
[1]: https://hn.algolia.com/?q=mcmaster+carr
kazinator | 14 hours ago
TZubiri | 13 hours ago
Fun fact, this was written shortly after one of the biggest linux vulnerabilities which was caused by a kernel crypto library, presumably to avoid userspaces rewriting their own crypto.
okandship | 9 hours ago
rglover | 2 hours ago
ryanschaefer | an hour ago
It’s a litmus test I use to see if someone actually glanced over what the AI generated.
Minor49er | an hour ago