nolan

nolan, 2 months ago

I think you can get an idea of the cultural mindset of those early Node days by comparing the Browserify website to a more modern equivalent:

• https://browserify.org/
• https://turbo.build/pack

Nobody cared if your website was polished, or if it had crude cartoon characters or whatever – everyone just wanted to hack on cool stuff.

Semicolons were thrown away like neckties. Callbacks were cool. Nobody cared what crazy postinstall scripts you ran. It was a different time.

nolan, 3 months ago

@nikitonsky Great post! Unfortunately though I think "disable cache" may be over-reporting. For react.dev for example, it looks like it is continually re-downloading the same resources as you scroll.

My workaround is usually to use a fresh private window rather than "disable cache," FWIW.

nolan, 3 months ago

@matt Yeah I noticed that the spammer problem has been really bad recently. I've been getting like dozens of reports in a few days. I'll look into this.

nolan, 3 months ago

Personally, I got tired of Google's constant breaking changes with every Android version, and all the hoops I had to jump through just to keep my apps listed. Whereas whatever garbage I put on the web 20 years ago still works today.

An investment in learning the web (even dumb stuff like document.all or document.write) still pays dividends decades later. Whereas all my old Android API knowledge is just gone, like tears in the rain.

nolan, 3 months ago

The biggest danger to the web IMO is the emerging Google-Apple duopoloy, and the fact that whatever bugs existed in WebKit at the time of the Blink split will just be "how the web works." This is why projects like Servo, Ladybird, and Flow are so important – they prove you can still build a browser from scratch, just based on the spec. (And thank heavens for the spec writers who made this possible.)

nolan, 4 months ago

@hawkticehurst @DavidDarnes @andrew_chou This makes a pretty similar point to my article! I like the distinction you draw between global and local event listeners.

nolan, 4 months ago

@hawkticehurst @DavidDarnes @andrew_chou Honestly it feels like we need a generic test suite that tests that a web component can be inserted/removed multiple times without blowing up, and that it doesn't leak (ala https://www.npmjs.com/package/fuite or https://www.npmjs.com/package/memlab or similar).

Realistically, I think a lot of devs are not going to grok the subtle difference between global vs local event listeners. Things like Resize/Intersection/Mutation Observer also vary across browsers w.r.t. memory cleanup.

nolan, 4 months ago

@hawkticehurst @DavidDarnes @andrew_chou Actually scratch that last comment, looks like Jake Archibald went on a tear filing Resize/Intersection Observer leak bugs on browsers; seems they are all fixed now. https://bugs.webkit.org/show_bug.cgi?id=227194

So effectively *Observers should clean up memory when the element is removed. So same issue as event listeners.

nolan, 4 months ago

@matt Just checked and everything looks normal… not sure what happened.

nolan, 4 months ago

You see a similar thing on GameFAQs or GameTabs – there was this flourishing community of people passing around lovingly hand-authored text files (my favorite example is this Super Metroid walkthrough where the text is manually justified https://news.ycombinator.com/item?id=28651093), and now everything is locked behind walled gardens or barely clinging to life (speedrun.com seems like one of those lingering vestiges of the old community-run 'net – GameTabs was, but looks like it got bought or something recently).

nolan, 4 months ago

Maybe I'm just an old curmudgeon or maybe there are still flourishing communities I'm unaware of, but as an old 'net citizen it just grosses me out how much of the modern web is mediated by platforms that only care about wringing out every penny they possibly can. This stuff used to be run by hobbyists on a shoestring budget with bubblegum and twine but care and love (Mastodon still has some of this vibe)

nolan, 4 months ago

The whole "virtual DOM is fast, React is fast because of the virtual DOM" idea seems to me downstream of the fact that JS engines got really fast while DOM engines stagnated (especially at MSFT, where Chakra was in a different part of the org chart and raced ahead with an OSS implementation while Trident/EdgeHTML floundered and fell behind). If you were a web dev, this was just the water you swam in, but for browser devs it was a total historical contingency

nolan, 4 months ago

At some point I need to write a blog post about all sorts of weird IE quirks that web devs coded around, like the fact that CSS attribute selectors were crazy slow or that setTimeout blocked user input but setImmediate didn't… I also fondly recall isolating try/catches into their own functions to avoid V8 deoptimizations (this has been pejoratively called "CrankshaftScript").

My point is that browser engines aren't hewn in stone; they have weird quirks. This shapes the web more than you'd think

nolan, 4 months ago

@bkardell I totally missed this post when you published it. I agree that we need more userland ideation before agreeing on standards.

One analogy I thought of recently: it's like we have BASIC with its "modules" that only have global variables and GOTOs. And people spent years getting very comfortable using GOTOs. Now we have encapsulation but… people miss the GOTOs. Which makes me wonder if we have the right encapsulation boundaries.