Don't Roll Your Own
Web developers are urged not to “roll their own” core browser behaviors like scrolling, navigation, text selection, copy/paste, password fields, and date pickers, because custom implementations often break usability, accessibility, security expectations, and user habits. Commenters debate where to draw the line: some argue native browser and OS controls should be used wherever possible, while others note that complex web apps (e.g., collaborative editors, games, maps) legitimately need deeper control and richer interaction than defaults allow. Underlying this is a broader tension between the simplicity and safety of standardized components and the complexity, bloat, and privacy risks introduced by JavaScript-heavy, highly customized web experiences.
Native vs custom UI controls
- Many argue against custom implementations of scrolling, link navigation, text selection, context menus, copy/paste, password fields, and date pickers; they usually degrade UX and break user expectations.
- Browser-native date pickers are seen as bad on desktop (ugly, inconsistent, small), but quite good on mobile. Some claim most custom date pickers are better; others note that almost every custom one fails for some region, locale, or calendar system.
- Some want “only native everything”: scrollbars, dialogs, pickers, etc. should be treated as browser/OS chrome, not website design elements, with the user in control of look and feel.
User freedom vs web app capabilities
- Strong sentiment that pages should not see or override scrolling, navigation, selection, clipboard, or history; some want browsers to technically forbid this.
- Counterpoint: complex web apps (e.g., maps, editors, Google Docs–style tools, SPAs with client-side routing) rely on these capabilities. Removing them would make many web apps impossible or much worse.
- Underneath is a “documents vs apps” split: for documents like bills or reservations, users want stable, document-like behavior; for games and rich tools, custom interaction is accepted.
JavaScript, complexity, and the web platform
- Some think “JavaScript in the browser was a mistake” and that complexity has exploded due to corporate investments, ads, tracking, and SPA overengineering.
- Others argue JS also enabled great games, visualizations, and apps, and that the web as an app platform is hugely successful despite its messiness.
- Disabling JS improves many sites, but breaks others (payments, some content).
Rolling your own vs using libraries
- “Don’t roll your own crypto” is broadly endorsed; crypto libs are praised for low dependencies and audits.
- For UI and app logic, opinions split:
- One camp prefers small, custom components over heavy, churn-prone, dependency-laden libraries (with AI and npm supply-chain risk as extra motivation).
- Another warns this produces many incomplete, buggy “mini-implementations” (OAuth, parsers, etc.) and accessibility regressions.
Accessibility and UX conventions
- Custom controls, date pickers, and image viewers often ignore ARIA and assistive tech requirements, harming screen-reader users.
- Some say: don’t roll your own standard controls unless you can beat the native ones by a large margin; otherwise you just force users to relearn for no gain.
Economics, extensions, and regulation
- Some want laws or browser defaults to block scrolljacking, copy/selection hijacking, and hostile keyboard overrides.
- Others oppose more regulation and prefer technical/user tools.
- Extensions that “fix the web” (ad blockers, dark mode, anti-hijack tools) are seen as both necessary and frustrating; paying for them feels to some like paying to mitigate problems that shouldn’t exist, yet many still do so.