Bugs I’ve filed on browsers
https://nolanlawson.com/2024/03/03/bugs-ive-filed-on-browsers/ [nolanlawson.com]
2024-03-04 05:28
tags:
browser
bugfix
development
web
As such, I’ve filed a lot of bugs on browsers over the years. For whatever reason – stubbornness, frustration, some highfalutin sense of serving the web at large – I’ve made a habit of nagging browser vendors about whatever roadblock I’m hitting that day. And they often fix it! So I thought it might be interesting to do an analysis of the bugs I’ve filed on the major browser engines – Chromium, Firefox, and WebKit – over my roughly 10-year web development career.
source: HN
Fixing memory leaks in web applications
https://nolanlawson.com/2020/02/19/fixing-memory-leaks-in-web-applications/ [nolanlawson.com]
2020-02-21 15:33
tags:
garbage-collection
javascript
programming
web
Part of the bargain we struck when we switched from building server-rendered websites to client-rendered SPAs is that we suddenly had to take a lot more care with the resources on the user’s device. Don’t block the UI thread, don’t make the laptop’s fan spin, don’t drain the phone’s battery, etc. We traded better interactivity and “app-like” behavior for a new class of problems that don’t really exist in the server-rendered world.
One of these problems is memory leaks. A poorly-coded SPA can easily eat up megabytes or even gigabytes of memory, continuing to gobble up more and more resources, even as it’s sitting innocently in a background tab. At this point, the page might start to slow to a crawl, or the browser may just terminate the tab and you’ll see Chrome’s familiar “Aw, snap!” page.
High-performance input handling on the web
https://nolanlawson.com/2019/08/11/high-performance-input-handling-on-the-web/ [nolanlawson.com]
2019-08-11 18:00
tags:
browser
html
javascript
perf
programming
ux
web
There is a class of UI performance problems that arise from the following situation: An input event is firing faster than the browser can paint frames.
In a previous post, I discussed Lodash’s debounce and throttle functions, which I find very useful for these kinds of situations. Recently however, I found a pattern I like even better, so I want to discuss that here.
Follow up: https://nolanlawson.com/2019/08/14/browsers-input-events-and-frame-throttling/
source: L
Scrolling the main document is better for performance, accessibility, and usability
https://nolanlawson.com/2018/11/18/scrolling-the-main-document-is-better-for-performance-accessibility-and-usability/ [nolanlawson.com]
2019-07-05 15:34
tags:
browser
html
perf
ux
web
This subscroller fix may be obvious to more experienced web devs, but to me it was a bit surprising. From a design standpoint, the two options seemed roughly equivalent, and it didn’t occur to me that one or the other would have such a big impact, especially on mobile browsers. Given the difference in performance, accessibility, and usability though, I’ll definitely think harder in the future about exactly which element I want to be the scrollable one.