Seems like they got themselves into a tech debt situation now
Seems like they got themselves into a tech debt situation now
Browsers are complex these days, and it's good that we have options to change behaviour that is problematic for us. I run chrome/firefox as part of a batch job on a virtual linux display, so I really need to turn off all the crap like first-start wizards, bookmarks and the like.
Actually: No. Well, at least not in the ridiculous way that Chrome or Firefox do it. Command line options or config files are both fine - when used in moderation.
The problem here (at least in part) is that it is extremely easy for devs to just add a configuration option. But it is much harder to think about whether a user would actually ever want to change the setting, if it had a good default value.
In fact, I think maybe about 20 command line options would cover 99.9% of all usecases for chrome. - And it would be so much more understandable. - Both for the actual developers and the users.
I absolutely despise it when a software product pushes effort downstream this way.
---
Note: I fully understand that in Chrome these flags at least partially leak out of their "trunk-driven development". - But this is no excuse: In no way should the development environment leak out into a released product this way! - And it would be exceptionally easy to stop this too: Just disable all development flags in the release build.
Counter counter counterpoint: I like command line flags and you can take them from my cold dead hands.
For all sorts of testing reasons, there has to be a way to disable the JIT. There has to be a way to disable sandboxing. There has to be a way to bypass the GPU acceleration blacklist, and there has to be a way to launch without GPU acceleration on non-blacklisted hardware. Thank god the options exist!
I mostly wish the documentation was better. It would be great if I could filter by platform. And, um, the definitive source probably shouldn't be some guy's personal website.
The reality is that 99.5% of users have perhaps 10 or 20 actual usecases/requrements. - You named a few of the most prominent ones. These need to be supported (e.g. with flags) and documented properly. Everything else is excess can be removed.
The problem with this is: You need to find out what users want to do. But many software projects are just too lazy and push all the effort downstream.
I guess it's a tribute to what you can get if you throw enough money and effort at something! They must be running flat-out just keeping the project going and the ever-changing product running.
Just imagine what they could have done with that money & effort, if it was spent on clear, focused projects.
Chrome is clearly the most popular browser out there but, for me, popularity counts for little. Chrome is also extremely heavyweight by most measures (installed size, memory usage, cpu usage, build time!)
Re popularity: Imagine you're at a retail store buying a coffee maker. They tell you "this model is very popular". For something that people purchase/install occasionally, popularity isn't a good indicator of quality, though it might be a good indicator of price, advertising, feature-list, or sales commission!
Personally, I want my coffee maker to make great coffee, and to keep doing that for a long time. And I want my browser to be fast, lightweight, and minimally intrusive.