5 ms·

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

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=6D6idUjkvqk https://www.youtube.com/watch?time_continue=4542&v=6D6idUjkv... [1] https://babeljs.io https://babeljs.io [2] https://romefrontend.dev/blog/2020/08/08/introducing-rome.html https://romefrontend.dev/blog/2020/08/08/introducing-rome.ht...

dayjobpork 6y ago
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.
- dewey 6y ago
  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.
- hapless 6y ago
  That approach is what made XUL and XPCOM un-maintainable -- a giant catalog of APIs in which large fractions were legacy, but non-removeable.
- masklinn 6y ago
  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.
- SkyMarshal 6y ago
  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.
- Lex-2008 6y ago
  Shall we keep compatibility with 16-bit drivers and TSRs when formatting floppy disks? https://devblogs.microsoft.com/oldnewthing/20090102-00/?p=19623 https://devblogs.microsoft.com/oldnewthing/20090102-00/?p=19...
- peterkos 6y ago
  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.
roblabla 6y ago
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".

dayjobpork 6y ago

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.

dewey 6y ago
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.
hapless 6y ago
That approach is what made XUL and XPCOM un-maintainable -- a giant catalog of APIs in which large fractions were legacy, but non-removeable.
masklinn 6y ago
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.
SkyMarshal 6y ago
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.
Lex-2008 6y ago
Shall we keep compatibility with 16-bit drivers and TSRs when formatting floppy disks? https://devblogs.microsoft.com/oldnewthing/20090102-00/?p=19623 https://devblogs.microsoft.com/oldnewthing/20090102-00/?p=19...
peterkos 6y ago
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.

roblabla 6y ago

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".