It's not like Gecko is an inherently inferior engine by any stretch, and it would significantly bolster their marketshare so that developers actually have to test against it.
For most users, the web browser is one of the biggest attack surfaces and having arguably the best security team behind the browser engine is a good thing.
Yes some of that might be thanks to PZ, but that’s beside the point, isn’t it?
Choosing Mozilla’s platform would have been better for code diversity, which has its own distinct security benefits.
Like if you have 3 different crypto imlpementations, you have times more teams that have to get a thing right. It seems way easier to try and get it right just once.
Perhaps there's a holistic idea of "if one browser has an issue, at least it doesn't affect 100% of them" but given what CVEs look like in reality (often variations of the same attack across multiple programs) it seems like the cost/benefit would not be in our favor
This happened with Cisco routers back in the day, Juniper had to add a flag to make a routing protocol compatible with Cisco because Cisco implemented it wrong but had so much dominance that Juniper had no choice if they wanted to get in the game.
Not everyone gets hit with every attack. Biological systems work this way too.
Without serious competition you eventually get IE6.
Is this really true? someone posted somewhere(can't find it) where it shows Firefox has a worst security record compared to Chrome.
Also, in the past, Firefox was left out from hacking browser competitions because it was to easy to hack.
Outside of the security teams, I think it's actually that Chromium is much better fuzzed and scrutinized. They just have so many more resources, including those for security.
Most of what I've read relates to Microsoft products - and I'm not saying that Microsoft is better/worse than the rest when it comes to security.
The web is the safest, most battle-tested sandbox environment to run apps in. It’s so safe that you click random links all day long, running 1000s of apps and never have to worry.
I’ll take web apps over native apps from a security perspective, thank you.
There are better ways to sandbox applications in 2020.
This is true despite the fact that on iOS, sideloading custom apps without a developer account is extraordinarily inconvenient.
What's sad is that Windows 98 fully supported desktop-based HTML+JS apps ("HTA Applications"), with access to native resources (using COM via `new ActiveXObject`) and it works with IE11 still - Microsoft just never pitched it as a serious development platform for some reason. Just imagine what today's world would be like if Microsoft did pitch HTA as a successor to VB6 (instead of the quickly-abandoned WinForms platform, now barely on life-support) (I'm mostly thinking we wouldn't be stuck with excessive memory consumption in Slack, and these apps would be able to use things like native context-menus and accessibility features)
That would have been a security nightmare.
Sadly, that doesn't make it wrong per se, just deeply discouraging. It makes me think we're past the point of no return.
---
> I don't see why it's Microsofts responsibility to do whats worse for their products, users and business just to bring some sort of benefit to Mozilla which has awfully mismanaged over the past 10 years or so. The browser monoculture didn't happen over night it happened thanks to years of neglect from the other browser engines. I don't like this situation and don't even use Chrome myself but this is the reality of the web today.
I would wholeheartedly agree with you if Firefox Quantum wasn't so damn good.
I didn't use Firefox for years except for occasionally testing sites. Quantum blew me away in terms of rendering speed; it reminded me of Chrome in the very early days. I know that benchmarks say Chrome is still ever-so-slightly faster, and I can't explain that, but Quantum legitimately feels quicker when I use it. At worst, it's certainly not a downgrade from Chrome.
I do wish Firefox's interface was cleaner—the pocket integration and similar stuff just feels like icky clutter to me—but I've been able to mostly clean it up via about:config tweaks, and none of that's relevant to the rendering engine.
That Firefox managed to do all of this with much more limited resources than Chrome, and despite how many sites nowadays are built to target Chrome specifically... it's seriously impressive. I'd love to see what the engine could do with Microsoft's additional resources behind it.
So we switched to chromium/Blink in late 2015. Much later, when I visited Apple in early 2017, a devrel friend asked why we couldn't use WebKit. A WebKit founder in the meeting agreed with me that there was no way for Brave to do so on Windows w/o running out of capital. DRM again was an issue too, without WideVine. Don’t blame startup for not carrying a full engine — that needs deep pockets. While MS does have deep enough pockets, it is starting by using chromium/Blink and slow-forking.
The reason you gave here for Brave not choosing Gecko (or WebKit) is interesting – but given Microsoft's deep pockets and tech know-how those reasons don't apply to them.
I think this is a strategic blunder on Microsoft's part and I say this as a Linux user. :)
Microsoft has now warmly embraced Linux – and I think they could have chosen this time to warmly embrace Mozilla. Oh well.
I hear what you're saying – but! – a tech giant has to play the long game. The Web is an open (for now) platform and Microsoft, like Apple, like Google, need to have their own web client/server implementation. Makes no sense to be beholden to Google imho.
I'm stunned at how little desktop browser share Edge has (4.6%): https://gs.statcounter.com/browser-market-share/desktop/worl... – however, changing browser engine is not going to change that, is it? I suppose, if Google and Microsoft end up equally and democratically sharing Chromium development then all's well.
Given the recent layoffs at Mozilla it's a pity (in hindsight – for the benefit of the open web) Microsoft didn't back them :(
Anyhow, thanks for the response.
In 2001, Apple could have picked Gecko but forked KHTML instead to create WebKit/Safari because it was smaller and seemed easier to work with.
It doesn’t change the fact that back in the day, high profile companies picked WebKit—Google, Blackberry, Nokia—for their browsers.
In 2013, Google forked WebKit to make Blink and nowadays, Microsoft, Opera, Brave and others have picked Blink/Chromium for their new browsers.
Even as Mozilla is making great strides with updating its engine (was Gecko; now Quantum), nobody else is going on that trip with them.
"I can code in X so I should be able to jump in to any other language and get to speed instantly." is obviously wrong.
You can nest functions nicely and work with closures when it makes sense, if you like that sort of thing.
The async programming model is also really nice to work with.
You also don't need to create classes for every noun, verb, and adjective in your system either - when all you need is a function, you just write a function, not some weird object to hold it.
You also don't have to write a f after all of your decimal values to tell the silly compiler that you mean for 0.25 to be a float. (this one truly does not matter, but there are a lot of little things like this that add up)
I know you can do a lot of that in C#, but its just so effortless in javascript. You just need to be more disciplined about how you code it
I finally got transferred to the client team one whole month later, in early May. Then I had ten days to demo-day.
Why do you feel compelled to make up a story? Because it sounds nicer to you to denigrate my work, it seems.
Because randos on the internet (especially business types) love to make stuff up in the name of puffery and deifying. Legends are rarely true.
Thank you for clarifying.
So, thank you very much for laying down the foundation for a whole generation of new programmers!
https://www.youtube.com/watch?v=aX3ZABCdC38
Friends from SGI recruited me (second attempt) in March 1995, I joined in early April but in the server group. I thought a lot -- but worked too little due to server commitments -- during the month of April, about "the scripting language" which was suggested to be Scheme when I was being recruited, but which by the time I joined could not be Scheme, due to the impending Java deal between Netscape and Sun.
Java meant either no scripting language, or a kid-brother language, which meant C-like syntax, primitive vs. object types as in Java, and other unfortunate consequences.
When I transferred to the client group in early May, I had to produce a demo very quickly. I chose first class functions and (barefly there at first) prototypes as the building blocks. The rest is history.
The Belgium Post built a whole web app+service architecture on LiveConnect.
Think of LiveConnect as "Active Scripting" on MS's platform, which enabled Java components to be developed and glued together by JS.
Edge still has (had?) so many rendering issues on sites we make. One thing I find really impressive about Firefox, despite the completely different engine I _very_ rarely find FF-specific bugs.
Many (all?) Oslo postcodes start with 0, and their site truncates the 0 when you try to enter your postcode. Their stated solution was to use Chrome, so they don't get any of my business.
[1]: https://www.w3.org/TR/html52/sec-forms.html#number-state-typ...
> User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number. If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user’s selection as a floating-point number.
If Chrome is your only target, the standard ceases to mean anything. The real standard is just whatever Chrome does.
The usual answer to that complaint is that Gecko is harder to embed. MDN pages on the subject even mention it’s deprecated and that the documentation is obsolete.
[1]: https://servo.org/
I think it will be around anyway btw, although I'm perhaps less sure.
We had a customer push us to support Edge.
The dev team (3 dudes) just looked at eachother and laid down the "No, Firefox or Chrome...".
It's just so much pressure to dance around the "this one does this, that one doesn't" and generally we rarely run into any Firefox and Chrome issues. Edge, just not worth it for a small team.
I'm glad we probabbly can direct them to the new Edge now (after some testing).
We treat Chrome/Safari/Edge/FF all as 1st class browsers and haven't had many problems (aside from Safari lacking U2F and exotic CSS props like motion-path).
mix-blend-mode is another thing that EdgeHTML doesn’t support that I was using for a bit, but I stopped using it because I kept finding critical bugs with it in Chromium, most notably https://bugs.chromium.org/p/chromium/issues/detail?id=992398 which was impossible to work around, simply stopping rendering the page after 8192px!
1. The :focus-within CSS pseudo-class doesn't work
2. object-fit only works on images
3. These SVG loaders don't work: https://samherbert.net/svg-loaders/
I'll be glad if/when Edge (blink) is deployed with a windows update.. the sooner the better, as far as I'm concerned.
We've been using TypeScript for all scripts longer than ~20 lines for years - so we got async functions for free (it compiles async/await TypeScript functions to IE11-compatible ES5 just fine).
Not to mention all the issues you'll have if you try to use CSS Flex or Grid.
Support IE11 only if you absolutely must, is my advice, and do that with differential serving: https://philipwalton.com/articles/deploying-es2015-code-in-p...
https://calendar.perfplanet.com/2018/doing-differential-serv...
I'd rather not support a dead browser, that's been dead for years now, that has clear replacements and alternatives. Not to mention security concerns above and beyond development pain..
[1] https://caniuse.com/#feat=async-functions
[2] https://caniuse.com/#feat=fetchThe beauty of the approach is that the big pollyfill payloads are only borne by the users who choose (or likely are forced by employers) to use those browser versions.
IE11 is another story, though.
It's a pet peeve of mine that apps don't support Edge/Trident, Vivaldi, etc. It's easier to write cross-browser code than ever, but it seems like we're in the process of reverting back to the bad old days when IE6 was the only browser people supported, but it's Chrome now instead of IE.
People are literally doing User Agent Sniffing again, and even though these browsers carefully craft their UA string to pass naive checks, the sniffers are hacking around that and urging me to "Download Chrome" to use a website.
Notable Offenders: Google Hangouts, and banks. Not impressed, Google.
I lived through the IE6 years, so I was never thrilled with any version of IE I had to support, but Edge was actually a good browser. Strange UI, solid engine.
...and that's one of the reasons everyone hates Edge. I'm a long-time IE user and that stupid dumbed-down UI is absolutely repulsive. If they'd just put the Chromium engine in the normal IE UI I bet they'd get far more users naturally using it.
I would be surprised if they still want to be a customer.
I just can't get behind this lazy "small team" excuse; it's really unnecessary hubris.
I worked on a "small team" of 1 (just myself - I was the only dev) for several years on an enterprise webapp. The kind that does complicated stuff - not a simple CRUD app. [Sidenote: I would have killed for a team of three!!] Yet I supported Edge since the day it came out and never dropped support of IE. In fact, I even supported old versions of IE (7 and up) until the day Microsoft EOLed older version of IE (that was January 12th, 2016, FWIW). It honestly isn't very hard these days. Annoying sometimes, yes, but not difficult.
I suspect the agility of any team is heavily influenced by not just numbers, but tech debt, and other choices.
All future work we do is compatible with Edge, it's not like NOTHING works with Edge, but to say "We support Edge"... customers expect that to mean everything.
Fortunately I don't think we'll have to have that conversation anymore.
Still not an excuse to alienate your customers who want to use a browser that comes with their OS. Enterprise customers never want to go through the hassle of installing external software company wide just to use your services.
Lots of customers still on Windows 7... that's bad, but we can't change that.
Why though?
I get that they wanted to use the same browser as Electron, now that they own it...it just sucks.
> WebKit and Firefox are good starting points, and both could use the extra help maintaining their open-source core.
If Firefox needs "help" from a big boy like Microsoft, it is probably the worse starting point. If WebKit is a good starting point, why is Blink worse? Chromium is more than Blink, and means that the moment Microsoft started with Chromium, they were already close to done. Whereas with WebKit, they would still have to build and test a shell.
It doesn't suck.
Is MS foolish enough to believe they can have influence on the evolution of the web through github.com/google/chromium pull requests?
Alternatively, has MS has given up? Perhaps they are content to rebrand Chrome and collect the bing.com seignorage from new Windows installs.
Unless they fork, it's either naïveté or negotiated surrender.
I mean, "influencing the web" or otherwise, they accept heaps and heaps of patches that aren't about their core business. The Chromium project is really healthy.
> Unless they fork, it's either naïveté or negotiated surrender.
They can fork, but they probably won't need to. Even if they wanted to maintain an entirely separate shell, it is basically trivial to link such a thing in to Chromium.
Can almost guarantee this will happen in 2-5 years.
Given Microsoft's history, I don't see Microsoft and Google playing nice for too long.
Will it have bugs that make the web unusable? Probably not. What makes it bad? The world's biggest ad company is in charge of it, so privacy is at risk.
I am a web developer too, and for me, the biggest annoyance is feature inconsistency between browsers. Only yesterday, I was cursing under my breath, because webkit-based browsers allow scrollbar styling, but firefox doesn't. In our org, we have embraced CSS grid, but by doing so, made a conscious decision to finally ignore IE11 (rather than to use @supports and write fallback CSS for browsers that are left behind). Even considering the wildly improbable scenario that browser monopoly would lead to feature stagnation - at least you will have a single target with a known set of features to develop against. How can this be worse than what we have now?
Just focussing on the browser itself:
* Today's developers enjoy a large and rich platform of (relatively) bug free functionality and APIs on which to build. The hellscape had very limited APIs and were riddled with bugs. For a long time IE and the other browsers didn't even agree on how to compute the width/height of an element w.r.t. padding and borders. (CSS box-models did not match!). We spent a lot of time just working around bugs and keeping up to date on the latest work-arounds for all the problems.
* Today's browsers have high performance JS JITs with very few user visible bugs. The hellscape had slow buggy JS implementations. I remember having to unregister event handlers on page unload otherwise the browser would leak memory.
* Today's browsers have excellent debugging tools built in. In the hellscape, if you had a trailing comma in a JS list on IE, it would give an error message (pop up) with either no file and line number or a bogus one. Yes, that bad.
Even when supporting just one browser, development was often a miserable experience. MS had won the browser war and was trying to kill the idea of apps on the web by neglect. It wasn't until Firefox got going that things improved.
I completely agree, but the points that you then make simply show how modern browsers are vastly better than the old ones. I love developing for a modern browser, such as Chrome. I just fail to see how the claim that having competing browser engines that do not have complete feature parity can be in any way considered desirable by web developers. I can understand this argument from end users' perspective (and even then not quite, because remember the days when sites would say that they were "best viewed in Netscape Navigator", or when you could watch Apple keynote presentation on Apple's site only in Safari?), but not from web developer's perspective. Wouldn't a single healthily evolving browser engine be better from web developer's point of view than multiple engines, each with its quirks?
The primary reason why the hellscape was bad, and remained bad for so long, was because we had a single "winner" of the browser wars. Microsoft won and they immediately tried to strangle the web for years. There were no alternative browsers for a long time to provide some kind of competition which might improve the matter. Sure, we could just test on IE and only support IE, but it was still an awful browser and MS wanted it that way.
The point is that the bad "technical" level situation was sustained by the browser political mono-culture. I'm somewhat positive now about the current situation with MS getting more involved because it will add more diversity to our current political browser situation. This should translate into better results for everyone on all levels, technical, user, privacy (I hope), etc.
So maybe from a pure browser engine point of view there is the same or less diversity, but this situation is very different from the early 2000s one.
I also called for it to happen over 5.5 years ago:
Apparently it was not so bad that we needed a multitude of JS to JS compilation stages and instead could just, you know, execute the same JS in the browser that we actually wrote.
Also, MS invented DHTML and AJAX single handedly, against backlash from "pure" web developers.
Starting mid-2006, I spent almost a year building a full-stack internal SPA for tracking manual and checklist testing at my company. I made the (then brave) decision to target Firefox instead of IE6, which everyone was using at the time - since FF was more standards-compliant.
It was a very good decision in retrospect. But I had to spend 4-5 weeks just getting the front-end to work in IE6. So many HTML/CSS hacks, trying to wrangle the layout engine to do my bidding. Check out the Wikipedia article on the Acid2 test, and the image at the bottom of IE6's rendering, to get an idea how far IE6's layout was from standards: https://en.wikipedia.org/wiki/Acid2
It was bad.
Real bad.
But I'm actually fairly positive about MS getting into the chromium landscape and back into the game. Let's face it MS had lost all of its influence in the browser world before dropping IE and making this move. It is a Google/Chrome dominated world at the moment. But by adopting Chromium, MS can "catch up" on a technical level and also wield significant power inside the Chromium project itself. They have money and they have an experienced browser engine engineering team. They will be able to provide some balance to Google in this ecosystem. If push came to shove, forking chromium wouldn't be an idle threat from MS. They will have some power.
On a technical level it looks like a move towards a mono-culture, but politically it looks like a chance at more balance and diversity to me.