30 ms·

Regarding the topic of browser mono-cultures, I was web developer in the post browser war era in the early 2000s where we had a dominant IE6 and a stagnant brow

by sime2009 7y ago

Regarding the topic of browser mono-cultures, I was web developer in the post browser war era in the early 2000s where we had a dominant IE6 and a stagnant browser landscape. 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.

duxup 7y ago
I'm a noob web dev working in a small shop that sells a niche SaaS product. 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).
- darekkay 7y ago
  To be fair, Edge has a good feature support (check caniuse.com). It would be interesting to know what the exact issues your app has with the browser. Otherwise it sounds more like your devs like to use some vendor-specific hacks and blame Edge for it. I know there are some Flexbox things to consider, but nothing a small team can't handle. IE11 is another story, though.
  - ewgoforth 7y ago
    I'd also be curious to know what features that Edge doesn't support. I know it doesn't do everything Chrome does, but I haven't run into any scenarios that Edge didn't support in a long time. 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.
    - tracker1 7y ago
      IE6 was closed source and only ran on Windows... Chromium/Blink run cross platform, open source and already 2 forks in. There's some stark contrast, even if it's more of a mono-culture, it's nothing like the IE6 days, even if google does have more power/control than other stakeholders.
      - tomc1985 7y ago
        IE had a mac version, but it died due to lack of interest/support
        kalleboo 7y ago
        The Mac version had a completely different, incompatible, renderer (which was actually better than the Windows one from a standards perspective) https://en.wikipedia.org/wiki/Tasman_(layout_engine) https://en.wikipedia.org/wiki/Tasman_(layout_engine)
        tracker1 7y ago
        IIRC, the mac version never got an IE6 release, it was 5.x...
    - emayljames 7y ago
      Has issue in not printing PDFs correctly. Namely changing text, swapping out fonts and other issues.
    - xp84 7y ago
  - emayljames 7y ago
    Yeah, IE needs odd custom CSS designed for accessibility, to make up for the mountains of missing CSS spec in it. And forget it if you use flex.
- dan1234 7y ago
  What are you using that Edge doesn't support? 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).
  - chrismorgan 7y ago
    A few things I’ve been using without EdgeHTML support: #rgba and #rrggbbaa in CSS, <details>, Custom Elements v1. On my personal website, I have deliberately chosen to no longer polyfill these or change my process to avoid #rgba in the final CSS, so various background colours are missing, the light/dark theme switcher doesn’t collapse (it should start collapsed), and a terminal recording will be missing in an upcoming blog post. 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 https://bugs.chromium.org/p/chromium/issues/detail?id=992398 which was impossible to work around, simply stopping rendering the page after 8192px!
  - ataylor32 7y ago
    A few issues I have run into with Edge: 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/ https://samherbert.net/svg-loaders/
    - simongray 7y ago
      Damn, lacking :focus-within is a big one. That pseudo-selector is very useful when creating custom widgets.
- adventist 7y ago
  Yeah it would be interesting to hear of the feature that Edge could not support.
  - emayljames 7y ago
    I'm having to fix an issue where a user's workstation uses edge to print PDFs. It is bad at it, it swaps out embedded fonts (random ones) and changes some text. A known issue.
- ken 7y ago
  Last time I was doing web dev (maybe 2 years ago), I worked primarily in Firefox and Safari. Chrome presented more issues for me than Edge ever did. I don't think I ever had anything work in Chrome, and fail in Edge. 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.
  - userbinator 7y ago
    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.
- tracker1 7y ago
  Been tacitly supporting Edge myself, but drew a hard line at IE (even 11) for current projects. Without async functions, promises etc, it's just too much extra boilerplate, a separate build setup and a huge payload just to support IE11, let alone older. I'll be glad if/when Edge (blink) is deployed with a windows update.. the sooner the better, as far as I'm concerned.
  - DaiPlusPlus 7y ago
    > Been tacitly supporting Edge myself, but drew a hard line at IE (even 11) for current projects. Without async functions, promises etc, it's just too much extra boilerplate, a separate build setup and a huge payload just to support IE11, let alone older. 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).
    - depressedpanda 7y ago
      Why force all your users to download transpiled ES5, just to accommodate IE11 dinosaurs? 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-production-today/ https://philipwalton.com/articles/deploying-es2015-code-in-p... https://calendar.perfplanet.com/2018/doing-differential-serving-in-2019/ https://calendar.perfplanet.com/2018/doing-differential-serv...
      - tracker1 7y ago
        Agreed, but I'd just assume avoid dual builds and targets at this point... a project I'm working on started with IE11 support and dual build targets, but broke in IE11 about 3 weeks in, so changed the "legacy" build mode to a page noting the requirement for a modern and secure browser.
    - tracker1 7y ago
      TypeScript does NOT shim async functions[1] for you, or give you fetch-api[2]? AFAIK, if you want that functionality, you still need babel and the fills/transforms to support async in browsers without it are freakishly huge payloads. That doesn't count dynamic imports and a number of other features that TypeScript doesn't support. 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=fetch
- steve1977 7y ago
  > We had a customer push us to support Edge. Why though?
  - moooo99 7y ago
    Because in many large companies, it's IE or Edge. If the company has upgraded to Win10, you're probably required to support Edge.
  - astura 7y ago
    Many company's IT departments don't find it worth downloading, supporting, and updating external applications just to access the web when the OS provides that functionality out of the box. You could argue that's "wrong," but that doesn't change reality. I even had a government customer remove IE, clicking on the IE icon launched Edge.
- onion2k 7y ago
  I'm glad we probabbly can direct them to the new Edge now (after some testing). I would be surprised if they still want to be a customer.
- astura 7y ago
  >Edge, just not worth it for a small team. 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.
  - duxup 7y ago
    I don't want to get into technical details except to say some of what we support are/is some legacy stuff customer's use ... that we did not create. It's weird, and faced with the choice of fixing some old products with a lot of unknowns ... and moving customers to something more modern that is more compatible with Edge... we chose the latter. 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.
    - astura 7y ago
      Yeah, I worked around technical debt and legacy support too, it goes with the field. 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.
      - duxup 7y ago
        This is a pretty niche area, "enterprise" would be generous to call these customers that even if it technically fits. It's a surprisingly small ask to have them install a browser. Lots of customers still on Windows 7... that's bad, but we can't change that.
300bps 7y ago
I agree that this is a good thing. I also called for it to happen over 5.5 years ago: https://news.ycombinator.com/item?id=7909383 https://news.ycombinator.com/item?id=7909383
microcolonel 7y ago
Chromium is open source, Microsoft has published most of their interesting work on Chromium itself. A monoculture is a big problem if the alternative is to write a new browser to compete, less so if you can just fork and have the same start line.
- duhi88 7y ago
  Well they could have picked up one of the other less-dominate browser engines. WebKit and Firefox are good starting points, and both could use the extra help maintaining their open-source core. I get that they wanted to use the same browser as Electron, now that they own it...it just sucks.
  - microcolonel 7y ago
    The general quality of Firefox is worse, the tooling is more fiddly, some of it is written in languages which are not as familiar to Microsoft, it is considerably less straightforward to customize; and on top of this, performance is similar at best. Chromium has an architecture which lends itself to deep integration, and the default UI is much closer to Microsoft's own designs. > 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.
    - millstone 7y ago
      What is Microsoft hoping to achieve? "Starting point" for what? 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.
Wowfunhappy 7y ago
I just wish they'd moved to Gecko instead of Chromium. 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.
- RcouF1uZ4gsC 7y ago
  One huge advantage the Chromium has over Gecko is Google's Security Team (ie Project Zero). 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.
  - sjwright 7y ago
    Google have certainly done a great job of maximizing the PR benefit from their security researchers. And it’s a great thing they’re doing. But regardless of how well individual companies market their respective security teams, Firefox has a comparable reputation for their browser engine. 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.
    - rtpg 7y ago
      I can understand value in multiple browsers for experimenting with new things (see Rust integration into Mozilla's engine), but what are the 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
      - core-questions 7y ago
        > what are the security benefits? Not everyone gets hit with every attack. Biological systems work this way too.
ijidak 7y ago
> If push came to shove, forking chromium wouldn't be an idle threat from MS 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.
- oaiey 7y ago
  I also think this will happen. They have very different interests.
- doctor_eval 7y ago
  Google forked WebKit and it worked out pretty well for them.
mc3 7y ago
I think it will be bad for different reasons. Will Chrome not comply with the spec. Nope because the spec follows what the browsers actually do, and Chrome is the browsers. 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.
- paulryanrogers 7y ago
  As more members of WHATWG fork Chromium I think your right that the standard is more like: whatever the dominant fork (Chrome) does.
- millstone 7y ago
  The spec will comply with Chrome.
_pmf_ 7y ago
> It was bad. > Real bad. 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.
- TimTheTinker 7y ago
  Please don't argue with others about their experiences and feelings. I was there, and it was intensely bad. I think it's easy to forget how bad it was, even for those who went through it. 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 https://en.wikipedia.org/wiki/Acid2
azangru 7y ago
Could you elaborate on what made it bad? 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?
- caspper69 7y ago
  Stagnation was the biggest problem. Stagnation is not the problem with Chromium; in fact, it's the opposite, and that's really what's forced Microsoft's hand. They were simply wasting resources playing catch up to Chromium. Why bother?
- sime2009 7y ago
  In terms of being a platform for applications, the browser landscape today is paradise on earth compared to the hellscape we endured in the early 2000s while trying to develop apps for IE6. 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.

duxup 7y ago

I'm a noob web dev working in a small shop that sells a niche SaaS product. 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).

darekkay 7y ago
To be fair, Edge has a good feature support (check caniuse.com). It would be interesting to know what the exact issues your app has with the browser. Otherwise it sounds more like your devs like to use some vendor-specific hacks and blame Edge for it. I know there are some Flexbox things to consider, but nothing a small team can't handle. IE11 is another story, though.
- ewgoforth 7y ago
  I'd also be curious to know what features that Edge doesn't support. I know it doesn't do everything Chrome does, but I haven't run into any scenarios that Edge didn't support in a long time. 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.
  - tracker1 7y ago
    IE6 was closed source and only ran on Windows... Chromium/Blink run cross platform, open source and already 2 forks in. There's some stark contrast, even if it's more of a mono-culture, it's nothing like the IE6 days, even if google does have more power/control than other stakeholders.
    - tomc1985 7y ago
      IE had a mac version, but it died due to lack of interest/support
      - kalleboo 7y ago
        The Mac version had a completely different, incompatible, renderer (which was actually better than the Windows one from a standards perspective) https://en.wikipedia.org/wiki/Tasman_(layout_engine) https://en.wikipedia.org/wiki/Tasman_(layout_engine)
      - tracker1 7y ago
        IIRC, the mac version never got an IE6 release, it was 5.x...
  - emayljames 7y ago
    Has issue in not printing PDFs correctly. Namely changing text, swapping out fonts and other issues.
  - xp84 7y ago
- emayljames 7y ago
  Yeah, IE needs odd custom CSS designed for accessibility, to make up for the mountains of missing CSS spec in it. And forget it if you use flex.
dan1234 7y ago
What are you using that Edge doesn't support? 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).
- chrismorgan 7y ago
  A few things I’ve been using without EdgeHTML support: #rgba and #rrggbbaa in CSS, <details>, Custom Elements v1. On my personal website, I have deliberately chosen to no longer polyfill these or change my process to avoid #rgba in the final CSS, so various background colours are missing, the light/dark theme switcher doesn’t collapse (it should start collapsed), and a terminal recording will be missing in an upcoming blog post. 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 https://bugs.chromium.org/p/chromium/issues/detail?id=992398 which was impossible to work around, simply stopping rendering the page after 8192px!
- ataylor32 7y ago
  A few issues I have run into with Edge: 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/ https://samherbert.net/svg-loaders/
  - simongray 7y ago
    Damn, lacking :focus-within is a big one. That pseudo-selector is very useful when creating custom widgets.
adventist 7y ago
Yeah it would be interesting to hear of the feature that Edge could not support.
- emayljames 7y ago
  I'm having to fix an issue where a user's workstation uses edge to print PDFs. It is bad at it, it swaps out embedded fonts (random ones) and changes some text. A known issue.
ken 7y ago
Last time I was doing web dev (maybe 2 years ago), I worked primarily in Firefox and Safari. Chrome presented more issues for me than Edge ever did. I don't think I ever had anything work in Chrome, and fail in Edge. 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.
- userbinator 7y ago
  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.
tracker1 7y ago
Been tacitly supporting Edge myself, but drew a hard line at IE (even 11) for current projects. Without async functions, promises etc, it's just too much extra boilerplate, a separate build setup and a huge payload just to support IE11, let alone older. I'll be glad if/when Edge (blink) is deployed with a windows update.. the sooner the better, as far as I'm concerned.
- DaiPlusPlus 7y ago
  > Been tacitly supporting Edge myself, but drew a hard line at IE (even 11) for current projects. Without async functions, promises etc, it's just too much extra boilerplate, a separate build setup and a huge payload just to support IE11, let alone older. 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).
  - depressedpanda 7y ago
    Why force all your users to download transpiled ES5, just to accommodate IE11 dinosaurs? 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-production-today/ https://philipwalton.com/articles/deploying-es2015-code-in-p... https://calendar.perfplanet.com/2018/doing-differential-serving-in-2019/ https://calendar.perfplanet.com/2018/doing-differential-serv...
    - tracker1 7y ago
      Agreed, but I'd just assume avoid dual builds and targets at this point... a project I'm working on started with IE11 support and dual build targets, but broke in IE11 about 3 weeks in, so changed the "legacy" build mode to a page noting the requirement for a modern and secure browser.
  - tracker1 7y ago
    TypeScript does NOT shim async functions[1] for you, or give you fetch-api[2]? AFAIK, if you want that functionality, you still need babel and the fills/transforms to support async in browsers without it are freakishly huge payloads. That doesn't count dynamic imports and a number of other features that TypeScript doesn't support. 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=fetch
steve1977 7y ago
> We had a customer push us to support Edge. Why though?
- moooo99 7y ago
  Because in many large companies, it's IE or Edge. If the company has upgraded to Win10, you're probably required to support Edge.
- astura 7y ago
  Many company's IT departments don't find it worth downloading, supporting, and updating external applications just to access the web when the OS provides that functionality out of the box. You could argue that's "wrong," but that doesn't change reality. I even had a government customer remove IE, clicking on the IE icon launched Edge.
onion2k 7y ago
I'm glad we probabbly can direct them to the new Edge now (after some testing). I would be surprised if they still want to be a customer.
astura 7y ago
>Edge, just not worth it for a small team. 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.
- duxup 7y ago
  I don't want to get into technical details except to say some of what we support are/is some legacy stuff customer's use ... that we did not create. It's weird, and faced with the choice of fixing some old products with a lot of unknowns ... and moving customers to something more modern that is more compatible with Edge... we chose the latter. 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.
  - astura 7y ago
    Yeah, I worked around technical debt and legacy support too, it goes with the field. 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.
    - duxup 7y ago
      This is a pretty niche area, "enterprise" would be generous to call these customers that even if it technically fits. It's a surprisingly small ask to have them install a browser. Lots of customers still on Windows 7... that's bad, but we can't change that.

300bps 7y ago

I agree that this is a good thing. I also called for it to happen over 5.5 years ago: https://news.ycombinator.com/item?id=7909383 https://news.ycombinator.com/item?id=7909383

microcolonel 7y ago

Chromium is open source, Microsoft has published most of their interesting work on Chromium itself. A monoculture is a big problem if the alternative is to write a new browser to compete, less so if you can just fork and have the same start line.

duhi88 7y ago
Well they could have picked up one of the other less-dominate browser engines. WebKit and Firefox are good starting points, and both could use the extra help maintaining their open-source core. I get that they wanted to use the same browser as Electron, now that they own it...it just sucks.
- microcolonel 7y ago
  The general quality of Firefox is worse, the tooling is more fiddly, some of it is written in languages which are not as familiar to Microsoft, it is considerably less straightforward to customize; and on top of this, performance is similar at best. Chromium has an architecture which lends itself to deep integration, and the default UI is much closer to Microsoft's own designs. > 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.
  - millstone 7y ago
    What is Microsoft hoping to achieve? "Starting point" for what? 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.

Wowfunhappy 7y ago

I just wish they'd moved to Gecko instead of Chromium. 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.

RcouF1uZ4gsC 7y ago
One huge advantage the Chromium has over Gecko is Google's Security Team (ie Project Zero). 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.
- sjwright 7y ago
  Google have certainly done a great job of maximizing the PR benefit from their security researchers. And it’s a great thing they’re doing. But regardless of how well individual companies market their respective security teams, Firefox has a comparable reputation for their browser engine. 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.
  - rtpg 7y ago
    I can understand value in multiple browsers for experimenting with new things (see Rust integration into Mozilla's engine), but what are the 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
    - core-questions 7y ago
      > what are the security benefits? Not everyone gets hit with every attack. Biological systems work this way too.

ijidak 7y ago

> If push came to shove, forking chromium wouldn't be an idle threat from MS 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.

oaiey 7y ago
I also think this will happen. They have very different interests.
doctor_eval 7y ago
Google forked WebKit and it worked out pretty well for them.

mc3 7y ago

I think it will be bad for different reasons. Will Chrome not comply with the spec. Nope because the spec follows what the browsers actually do, and Chrome is the browsers. 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.

paulryanrogers 7y ago
As more members of WHATWG fork Chromium I think your right that the standard is more like: whatever the dominant fork (Chrome) does.
millstone 7y ago
The spec will comply with Chrome.

_pmf_ 7y ago

> It was bad. > Real bad. 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.

TimTheTinker 7y ago
Please don't argue with others about their experiences and feelings. I was there, and it was intensely bad. I think it's easy to forget how bad it was, even for those who went through it. 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 https://en.wikipedia.org/wiki/Acid2

azangru 7y ago

Could you elaborate on what made it bad? 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?

caspper69 7y ago
Stagnation was the biggest problem. Stagnation is not the problem with Chromium; in fact, it's the opposite, and that's really what's forced Microsoft's hand. They were simply wasting resources playing catch up to Chromium. Why bother?
sime2009 7y ago
In terms of being a platform for applications, the browser landscape today is paradise on earth compared to the hellscape we endured in the early 2000s while trying to develop apps for IE6. 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.