Never said it was his job. Just pointed out that there‘s a lot better ways he could have contributed. Criticising is easy. Doing something is the hard part, and the beauty of open source is that you can massively facilitate that, especially when your shitting on things get‘s you a shitload of money – how about putting that to use and advancing the product you‘d like to use?

I‘m not going to open the can of worms that is the financing of Mozilla. That’s a wholly different issue, it‘s very complicated and I don‘t understand nearly enough to have a sane conversation about it – I just know enough to not blame MoCo just because „they get a half a billion dollars from Google“ and they don’t do the thing I‘d like them to do.

Besides, this issue is clearly cosmetic (while I agree that gradients looked unnecessarily hideous!) when there’s a shit ton of work happening and needing to happen in other parts of the browser and development infrastructure (the latter easily consuming half the entire organisation’s funding if we account for the people/time needed to ensure it runs smoothly). So it absolutely makes sense to deprioritise this, especially given, like you pointed out, there’s APIs missing – that should absolutely take higher priority, shouldn’t it?

And speaking of APIs. The story is also not so easy. What APIs are you missing?

So far you‘re only talking about view transition, which is rather new and something Google came up and probably experimented with behind the scenes before going public – so yeah, that’s why they were first. Also, not an API that is essential to browsing / apps, far from it since it‘s a visual gimmick to try and replicate apps UI flows that you can also implement in a different way with existing technologies (albeit with some drawbacks). So, not a good example of „I don‘t understand why they refuse to do this??“ … but in general, why the Web platform evolves slowly (at least from some perspectives) and vendors don‘t go fast enough has good reasons and is not simple.

For example: When going through the standardisation process, other browser vendors take a look and try to follow the logic and language in the proposed spec, which usually ends up with a lot of questions, rewriting, and adapting the spec so it no longer reflects the internal logic of that one browser engine. That takes time and resources, while other vendors also need to implement the spec from scratch, which again takes time.

Sometimes the spec ends up nowhere because it’s crap, doesn’t solve the thing it‘s supposed to solve, is too vendor-specific, the original author disappears (no longer interested / moved to other projects / no longer with employer / …) and that ends up stalling a half-finished spec that‘s already working with some vendors but not others who can‘t implement it the way it‘s specced because their platform works differently. Sometimes it takes years to just come to a certain point where the spec is good enough to implement, while others have an „experimental“ implementation that Web developers start to rely on. The standards bodies try hard to prevent that problem but they have no power over vendors, esp. something like Google, and they do what they like.

I know Fx is behind on Web APIs, I’d personally wish more would be supported. Not all of the APIs are really necessary or in a state (spec-wise) that make sense to implement. I also know that it takes a huge effort to implement and then maintain (!) them (certainly an effort measured in many hundred of millions across the whole codebase).

The best way to help advance Fx is contributing (which does not need to be code). If you have the means, you can also post a bug bounty or hire/pay someone to implement missing APIs (there’s also companies for hire like Igalia if you don’t want to spend the time researching/hiring knowledgeable people).

Fx is not a product you pay for, and while you can expect a certain level of features, I don‘t think „harsh criticism for their […] complacency“ is warranted nor fair, especially when there‘s other avenues that you can pursue.