Yes, but consider the engineering effort to create a general purpose memory safe language vs just a domain specific one in comparison to the work required to write a browser, which also includes another domain specific language (javascript).
Seat of the pants, I would say getting something like rust on par with g++/clang code generation, and 3rd party tools is probably in the same ballpark engineering wise as actually maintaining the browser.
And if you spend a little time looking at firefox, there is/was a lot of low hanging fruit. I've mentioned elsewhere the difficultly building it, but even more than that, is that pretty much every single version of gcc that came out for a while would break firefox in some fundamental ways. And overwhelmingly these breaks were caused by crappy C++ programming where people were doing things that were known not to be syntactically correct but no one bothered to fix them. Then frequently instead of actually fixing them they did things like switch from building with an old GCC to a newer clang because it threw fewer errors. Then they claimed that the result was "faster" than gcc, despite the fact they were comparing an old version of GCC with a newer version clang. When the work was done to actually get it to build with gcc, it turned out to be even faster. (not that gcc is better than clang, only that ideally a project like firefox would compile cleanly with a wide range of compilers). Said compiler warnings are frequently valid, and analyzing them at least to know if its true is a worthwhile code quality exercise.
Yes, you have to ask yourself why everyone is using V8 as their JavaScript runtime and not Mozilla’s equivalent or why every alternative browser is using Chrome as a foundation.
Or XUL wasn’t packaged as cross platform GUI framework.
And then of course the Firefox mobile fiasco.
My guess is that the engineering and management don’t interact. Two different companies within the same company, no coherent vision.
What FF mobile fiasco are you speaking of? I am using FF mobile happily and have been for years. I haven't noticed any issues with it. Was there a business level fiasco or something?
One objective fiasco is the inability of FF on Android to keep multiple tabs in memory. Older versions were capable of it without issue, ever since the tab unloading feature, Firefox has been reloading tabs at the slightest pretense.
Switch apps? Tabs get reloaded when you're back.
Lock & unlock phone with Firefox in focus? Tabs get reloaded
Switch tabs in Firefox? Tabs get reloaded...
I wish I was just ranting, but all of the above happens with a single active tab loaded...
That is interesting to me because that isn't my experience. I just tried the lock screen for example and I couldn't get any of tabs to reload, foreground or not. I'm on Android 10 running on a Moto G7. Maybe it's affected by vendor settings?
Quite a few devices experience this though. For the record, I use an S9, and used to have 50+ tabs with no issues on older versions of Firefox - now I cannot have one tab remain open without a reload if I lock my phone with Firefox focused and turn unlock it a minute later. And that's with Firefox explicitly exempt from each and every kind of battery/memory etc. "optimization" by Android...
Doesn't happen for me. OnePlus 8 with Oxygen OS 11.
The one thing I really miss in FF mobile is the opposite.. Pull to refresh or another gesture that accomplishes that. The current two tap option is too slow.
Seat of the pants, I would say getting something like rust on par with g++/clang code generation, and 3rd party tools is probably in the same ballpark engineering wise as actually maintaining the browser.
And if you spend a little time looking at firefox, there is/was a lot of low hanging fruit. I've mentioned elsewhere the difficultly building it, but even more than that, is that pretty much every single version of gcc that came out for a while would break firefox in some fundamental ways. And overwhelmingly these breaks were caused by crappy C++ programming where people were doing things that were known not to be syntactically correct but no one bothered to fix them. Then frequently instead of actually fixing them they did things like switch from building with an old GCC to a newer clang because it threw fewer errors. Then they claimed that the result was "faster" than gcc, despite the fact they were comparing an old version of GCC with a newer version clang. When the work was done to actually get it to build with gcc, it turned out to be even faster. (not that gcc is better than clang, only that ideally a project like firefox would compile cleanly with a wide range of compilers). Said compiler warnings are frequently valid, and analyzing them at least to know if its true is a worthwhile code quality exercise.