Hacker News Reader

Comment by frankjr | Hacker News Reader

An alternative explanation about why XUL extensions needed to go by a Firefox dev Mike Conley [0], drawing pretty much the same conclusions and then some.

The same thing that happened to Firefox happened to Babel [1]. Babel's plugin API exposes the internal structures and APIs to plugins, which means they're unrestricted in what they can do, but it also means that it's very hard to change things in the codebase because you might accidentally break plugins that rely on the previous behavior / APIs. This is one of the primary motivations behind Rome [2].

[0] https://www.youtube.com/watch?time_continue=4542&v=6D6idUjkv...

[1] https://babeljs.io

[2] https://romefrontend.dev/blog/2020/08/08/introducing-rome.ht...

View on HN

So there's an interesting parallel in Rust with clippy, which is a linter that uses internal compiler data structures to parse and find the things to lint. This makes clippy very powerful, but very, very prone to breakage. Eventually, clippy was simply upstreamed into the compiler proper, which meant any refactoring of the compiler had to fix all the clippy lint at the same time.

Linux is similar with drivers. Linux breaks internal kernel ABI all the time, but all the drivers upstreamed into the kernel are automatically fixed when this happens.

According to OP post, Firefox and addons developer would communicate when breaking changes happened, to make sure an upgrade path was doable. I wonder if a Linux-like system where a repo with all addons that developers could land refactors on when landing breaking changes would have changed the dynamic somewhat, by reducing the "addons developer tax".

I'd like to live in a world were instead of developers just breaking an existing api, they leave the existing, in use apis and add new ones. It's ridiculous how often shit just breaks because an api is changed in an update.

Because in 90% of the cases the API isn't removed for fun but because something in the backend changed.

You can't just "leave the existing" as that still means work if you have to write some translation layer from the old format to the new format. It's not like it would be free to keep the existing one around.

That approach is what made XUL and XPCOM un-maintainable -- a giant catalog of APIs in which large fractions were legacy, but non-removeable.

I'm sympathetic, but literally most of the article is about how hard Mozilla tried to do this, and how it slowed them to a standstill and precluded improvements entirely.

I’d rather the main platform keep its internal codebase clean and streamlined, removing/replacing APIs whenever there’s a need, and publishing advanced warning so that plugin devs can update their plugins. Legacy plugins shouldn’t be a reason for spaghetti code in the main platform.

Shall we keep compatibility with 16-bit drivers and TSRs when formatting floppy disks? https://devblogs.microsoft.com/oldnewthing/20090102-00/?p=19...

There's this project called "Microsoft Windows" that's done this for decades. You want to be the one digging through 1998-era C++ to fix a bug? Didn't think so.

Reply on news.ycombinator.com