JavaScript performance, WebAssembly, and Shared Memory in Microsoft Edge(blogs.windows.com)
blogs.windows.com
JavaScript performance, WebAssembly, and Shared Memory in Microsoft Edge
https://blogs.windows.com/msedgedev/2017/04/20/improved-javascript-performance-webassembly-shared-memory/#LhwGh0LB9MRs3RHG.97
164 comments
> I hope more sites test on Edge and not just on Chrome.
"Look for your friends, but trust not to hope. It has forsaken these lands."
Seriously. I use Firefox as my main browser and I'm at the point where I'm surprised if anyone tests anything in anything except Chrome, or if they even realize such test-targets exist at all.
Standard response to bug-reports? "Just use Chrome. Works for me!", "It's just Firefox. Low importance." Etc.
From the glory days of web-standards following IE's demise, this profession has sunk gutter low.
"Look for your friends, but trust not to hope. It has forsaken these lands."
Seriously. I use Firefox as my main browser and I'm at the point where I'm surprised if anyone tests anything in anything except Chrome, or if they even realize such test-targets exist at all.
Standard response to bug-reports? "Just use Chrome. Works for me!", "It's just Firefox. Low importance." Etc.
From the glory days of web-standards following IE's demise, this profession has sunk gutter low.
Yeah. It boggles my mind how quickly and totally the amnesia has set in; where the same crowd who vilified IE and the web monoculture it created is perfectly fine with "Just use Chrome" as a solution. I've seen people seriously claim that every browser should use WebKit and all the other rendering engines should be thrown out, and that this would be "for the good of the web". What?!
> I've seen people seriously claim that every browser should use WebKit and all the other rendering engines should be thrown out, and that this would be "for the good of the web". What?!
This has been a meme for years now. I remember John Resig suggesting this in 2013—ironically, right before the Blink fork that ended mainline WebKit dominance.
This has been a meme for years now. I remember John Resig suggesting this in 2013—ironically, right before the Blink fork that ended mainline WebKit dominance.
Wasn't it Joe Hewitt?
This would leave the browser world with one high-quality, open-source implementation as the de facto standard.
I don't think this is so self-evidently awful. There are a number of big open-source projects in this sort of position, like git, TeX, linux, GHC.
What is special about browsers that we need multiple competing implementations of the standard?
I don't think this is so self-evidently awful. There are a number of big open-source projects in this sort of position, like git, TeX, linux, GHC.
What is special about browsers that we need multiple competing implementations of the standard?
When a market with competition becomes a monoculture, every security problem that used to affect only one product becomes a class break[1] that affects everything. Just like the potato famine, software monocultures can fall to a single attacker, who also benefits from the consistent interface.
> What is special about browsers
Nothing. We need multiple implementations of all software that is relied upon for anything remotely important. It still amazes me that so many businesses critically depend on something that is only available from one source. Without a second source[2], the business lives or dies at the whim of the company they depend on.
[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....
[2] https://en.wikipedia.org/wiki/Second_source
> What is special about browsers
Nothing. We need multiple implementations of all software that is relied upon for anything remotely important. It still amazes me that so many businesses critically depend on something that is only available from one source. Without a second source[2], the business lives or dies at the whim of the company they depend on.
[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....
[2] https://en.wikipedia.org/wiki/Second_source
Most of those aren't interchange formats. You can use Mecurial or Perforce instead of Git; PDF is the interchange format in TeX's space; Linux is an OS, so I don't even know what you're talking about here; for GHC, you can use ML or C or Python or PHP or whatever instead of Haskell.
HTML is supposed to be an actual standard for interchange of hypertext.
HTML is supposed to be an actual standard for interchange of hypertext.
> or GHC, you can use ML or C or Python or PHP or whatever instead of Haskell.
Well there are also other Haskell interpreters and compilers (JHC, UHC, Hugs). Although of course GHC is de facto standard due to it's numerous extensions of the language.
Well there are also other Haskell interpreters and compilers (JHC, UHC, Hugs). Although of course GHC is de facto standard due to it's numerous extensions of the language.
Because defining the Web as a legacy pile of mostly sequential C++ code dating back to the '90s is not a forward-thinking idea.
Is your position that Blink's architecture is well suited for getting performance out of modern hardware? Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?
Is your position that Blink's architecture is well suited for getting performance out of modern hardware? Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?
I don't think it matters what the particular engine everyone gets stuck with is. The argument is more that forcing everyone to use it, means that everyone now has an incentive to refactor it into something nice.
Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape.
When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave.
Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.
Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape.
When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave.
Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.
OpenGL is a standard, not an implementation! Imagine if were all stuck with SGI's implementation of GL instead of having it be a standard that the industry could create unique hardware implementations of. Would SGI have willingly collaborated with 3dfx on the Voodoo? Not likely--instead, 3dfx implemented a subset of the de facto GL standard, called it Glide, and created the entire PC GPU market in one fell swoop.
OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :)
> everyone now has an incentive to refactor it into something nice.
My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward.
Do you honestly think Google would be likely to collaborate on that?
OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :)
> everyone now has an incentive to refactor it into something nice.
My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward.
Do you honestly think Google would be likely to collaborate on that?
I don't see it. My point doesn't change between talking about "a standard", and talking about "a FOSS project with open committee-based maintainership" (like e.g. ASF projects are.) It's stone soup: you'd start off with a worthless project—but if that pile of crap has to "feed the whole town", people are going to turn it into something worthwhile.
Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.
> My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that?
Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
See: the Linux kernel.
Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.
> My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that?
Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
See: the Linux kernel.
> Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.
The Web doesn't need "bootstrapping" and "inspiring contributions". It's 20 years old!
> Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
No, the organization that didn't like the change would fork the project. This already happened with WebKit!
> See: the Linux kernel.
Linux gets forked over and over and over again, every time some organization wants to ship a device running it.
The Web doesn't need "bootstrapping" and "inspiring contributions". It's 20 years old!
> Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.
No, the organization that didn't like the change would fork the project. This already happened with WebKit!
> See: the Linux kernel.
Linux gets forked over and over and over again, every time some organization wants to ship a device running it.
> No, the organization that didn't like the change would fork the project. This already happened with WebKit!
Er, this whole thought exercise is about what would happen if it was literally impossible to fork the project. If everyone was forced to work on one implementation, full-stop, no takesie-backsies. (I'm imagining aliens from the Culture holding guns to our heads.)
It's a very implausible thought-exercise, yes, but if you're playing along, you can't challenge the axioms. (It's like one of those "how would a One World Government work" discussions: saying "there could never be one" is beside the point.)
Er, this whole thought exercise is about what would happen if it was literally impossible to fork the project. If everyone was forced to work on one implementation, full-stop, no takesie-backsies. (I'm imagining aliens from the Culture holding guns to our heads.)
It's a very implausible thought-exercise, yes, but if you're playing along, you can't challenge the axioms. (It's like one of those "how would a One World Government work" discussions: saying "there could never be one" is beside the point.)
No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice.
It gives the incentive to create a black market.
It gives the incentive to create a black market.
A black market is based on circumventing some prohibition. What prohibition is one circumventing to fight the Chrome monoculture? Google's success in creating a monoculture is based on making Chrome attractive and reducing friction with their services compared to alternatives. Independent of whether you think that's something they should do given their prominent position in some related markets, who or what is the black market going to be hiding from?
Not every person thinks the same or have the same moral believes. Only because you think that Chrome monoculture is a good thing with rational arguments, you can't assume that everyone agrees with that.
Just the fact that not everyone uses the Chrome engine today is a good indicator to that. Or that we are having this argument.
What will happen is that people not agreeing on Chrome monoculture will go else where. So even if you have the same engine, others have the possibility to create a total different web system. Now you have two different webs. To what gain?
Also an engine monoculture will eventually be treated as the de facto standard and the real standard will be ignored, i.e. implantation details will trump good design.
Just the fact that not everyone uses the Chrome engine today is a good indicator to that. Or that we are having this argument.
What will happen is that people not agreeing on Chrome monoculture will go else where. So even if you have the same engine, others have the possibility to create a total different web system. Now you have two different webs. To what gain?
Also an engine monoculture will eventually be treated as the de facto standard and the real standard will be ignored, i.e. implantation details will trump good design.
I'm not arguing in favor of a Chrome monoculture, since I don't want one. I just don't see how Chrome monoculture => black market happens. It wouldn't even had made sense as a response to the old IE monoculture.
Also the fact that this is even an issue is a product of HTML5, etc. leaving a lot of room for undefined behavior and being easy to misinterpret/misimplement. You don't even have to purposely bend the standard to try and create a monoculture; hard to predict implementation differences happen organically.
Also the fact that this is even an issue is a product of HTML5, etc. leaving a lot of room for undefined behavior and being easy to misinterpret/misimplement. You don't even have to purposely bend the standard to try and create a monoculture; hard to predict implementation differences happen organically.
Black market is what happens who there is no choice.
For the old IE, Firefox happened (and other as well).
For the old IE, Firefox happened (and other as well).
Okay, but what does Firefox's ascendance have to do with a black market? It wasn't even breaking some hard to enforce Microsoft EULA provision. IE got lazy, and Firefox offered a dramatically better experience. Whenever a new product overtakes a more established competitor because it's better, is there a black market involved?
My purpose isn't (just) pedantic. You claimed "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a black market.", but then your example shows an incentive to make a superior product. It starts making a lot less sense in Blink's case if you change it to the more accurate "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a superior product." Why not a superior product that starts with a Blink fork?
My purpose isn't (just) pedantic. You claimed "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a black market.", but then your example shows an incentive to make a superior product. It starts making a lot less sense in Blink's case if you change it to the more accurate "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a superior product." Why not a superior product that starts with a Blink fork?
There's nothing wrong with modern C++, I think it can give any other language a run for its money in this space. If you are talking about a complete re-write, I don't think you can fairly overlook it. RAII + smart pointers eliminate the most pernicious memory management issues. The STL has grown to parity with other modern platforms. Even without a rewrite, given enough time and effort, that crappy old Konquerer codebase may even turn out to look reasonably good.
I would not, however, wish it to be the only thing available.
I would not, however, wish it to be the only thing available.
> There's nothing wrong with modern C++
The fact that it's a set of practices to avoid the deathtraps within a language which itself has plenty of problems left lying around is, arguably, the problem with modern C++.
The fact that it's a set of practices to avoid the deathtraps within a language which itself has plenty of problems left lying around is, arguably, the problem with modern C++.
Yes, that is the problem. It's also what allows you to drag that 20 year old mess forward into the 21st century. It compiles to virtually any platform with a number of compilers. Trade offs...
What platform needs/wants a web browser that isn't covered by an LLVM target?
> RAII + smart pointers eliminate the most pernicious memory management issues.
No, they don't. Browsers have been using RAII and smart pointers for years and years. The memory management-related vulnerabilities keep happening.
The biggest problem tends to be use-after-free, which smart pointers do absolutely nothing to mitigate.
No, they don't. Browsers have been using RAII and smart pointers for years and years. The memory management-related vulnerabilities keep happening.
The biggest problem tends to be use-after-free, which smart pointers do absolutely nothing to mitigate.
This place hardly seems like an appropriate venue for debating the suitability of C++, given that a large chunk of the audience here seems to have a financial interest in competing technologies.
The FUD is strong...
The FUD is strong...
I assume you're referring to Rust? Who has a financial interest in Rust? I have trouble imagining Mozilla making money off of Rust directly; I don't think there's any Rust developers who wouldn't immediately jump to a fork if Mozilla put ads in Rust's documentation or decided rustc needed a default search engine.
As far as making money off of their own software written in Rust, that advantage is actually stronger if they convince everyone else Rust is stupid and not worth their time.
As far as making money off of their own software written in Rust, that advantage is actually stronger if they convince everyone else Rust is stupid and not worth their time.
How is an argument that C++ is a bad foundation not relevant to the proposal that we should define the Web to be a big pile of C++?
Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature. Further, since people here seem to be very invested in <sarcasm>futuristic</sarcasm> technologies and <sarcasm>disruption</sarcasm> they are naturally inclined to knock C++ just because, and then rationalize it with some technical bullshit.
> Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature.
If that is the case, then every browser engine, as well as every piece of large-scale network-facing software worked on by teams using reasonable development practices in C++ is written by unskilled programmers, since all of that software has vulnerabilities. In particular, you're saying that Google hires programmers unskilled in C++. Is that your argument?
> rationalize it with some technical bullshit.
If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.
If that is the case, then every browser engine, as well as every piece of large-scale network-facing software worked on by teams using reasonable development practices in C++ is written by unskilled programmers, since all of that software has vulnerabilities. In particular, you're saying that Google hires programmers unskilled in C++. Is that your argument?
> rationalize it with some technical bullshit.
If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.
> If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.
Way to generalize there. No C++ project has been free of memory safety problems because they don't have to be. C++ is not optimized for that. Sure you can optimize for memory safety but then real hackers (not on "Hacker" News) will find something else, and then all the internet idiots will crow on about how {LANGUAGE} doesn't sufficiently protect them from {SCARY THING}.
Maybe if we stopped adding every feature under-the-sun to our browsers, memory safety problems wouldn't be so prevalent! (But we can't have that, not if there is less money to be made!)
Way to generalize there. No C++ project has been free of memory safety problems because they don't have to be. C++ is not optimized for that. Sure you can optimize for memory safety but then real hackers (not on "Hacker" News) will find something else, and then all the internet idiots will crow on about how {LANGUAGE} doesn't sufficiently protect them from {SCARY THING}.
Maybe if we stopped adding every feature under-the-sun to our browsers, memory safety problems wouldn't be so prevalent! (But we can't have that, not if there is less money to be made!)
> No C++ project has been free of memory safety problems because they don't have to be.
They don't have to be free of security vulnerabilities either, but it would be very nice. What's your point?
They don't have to be free of security vulnerabilities either, but it would be very nice. What's your point?
> Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?
I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.
I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.
And if the language has a direct impact on the efficiency and safety of the product, then what?
A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.
A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.
And taking the train dramatically reduces the risk of being in an automobile accident.
Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.
I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."
Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.
I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."
> Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.
No, because:
1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains.
2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages.
3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.
No, because:
1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains.
2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages.
3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.
> Errors such as use after free simply don't exist in memory safe languages.
Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.
I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.
I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
> Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.
No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does.
> I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…
No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does.
> I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.
W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…
> I care who is writing it and how well it is tested.
Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)
Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)
I strongly disagree. HTML is used for long-term text archival in science, education, administration, politics, literature, for personal notes and memories, and so on. Do you want to leave all this to a single browser implementation dominated by an ad company?
git really?
there are tons of big projects that don't use git. Java for instance.
Also, there are multiple implementations of the Git API. Original "git" is the only command-line implementation but there are JGit and libgit2 libraries that are used in various projects. In particular, Github, Gitlab, and Bitbucket all use libgit2 for hosting Git.
They use it when multiple people code on the same codebase. It's either in Github, Gitlab or Bitbucket and uses git.
I haven't seen someone use anything other than git in a long time, and those that do are ancient projects.
I haven't seen someone use anything other than git in a long time, and those that do are ancient projects.
This just in: an in-development webapp with WebSockets, Shared Workers, and WebRTC integration turns out to actually be "ancient" because it's being managed with subversion!
> I haven't seen someone use anything other than git in a long time, and those that do are ancient projects.
Then you live in a very small bubble.
Then you live in a very small bubble.
I suppose Firefox is ancient too. They use Mercurial canonically. :-(
So does Facebook... My company also uses mercurial - I know plenty of people that prefer it over git - but there is no github equivalent for it.
There's bitbucket. It also has free private repositories.
Well obviously you should just be using Chrome.
Lots of people use and prefer mercurial.
I learnt git when I started college and then discovered Mercurial when I started contributing to Firefox. It was painful at first but after some really good reading of the Mozilla Version Control Tools docs and the Hg Tutorial by Joel Spolsky and some blogs regarding the Mozilla contribution and coding workflow I started liking Hg better than git.
Mercurial has a more sane way of referring to commits and traversing the history. They now also have different kinds of branching models. You can even maintain multiple checkouts of a repo using a single clone which is great and saves me from having to checkout branches when I want to work on another feature. (Imagine checking out 3.5 mn files each time you wanted to change branches).
In, my opinion, Mercurial scales better but suffers from the unintuitive names and lack of enough people talking about it.
Mercurial has a more sane way of referring to commits and traversing the history. They now also have different kinds of branching models. You can even maintain multiple checkouts of a repo using a single clone which is great and saves me from having to checkout branches when I want to work on another feature. (Imagine checking out 3.5 mn files each time you wanted to change branches).
In, my opinion, Mercurial scales better but suffers from the unintuitive names and lack of enough people talking about it.
mmmmh, delicious delicious high quality open source implementation completely controlled by Google. Because Chrome is definitely not known for implementing stuff on their own and ignoring standards. Same way Google is not known for purposefully worsening performance and experience on their websites to non-Chrome users, and same way Google is not transitioning all important Android capabilities into Google Play Services, which itself is closed source.
What could happen with Chrome if they were the only ones on the market, I wonder.
What could happen with Chrome if they were the only ones on the market, I wonder.
Have any citations for those bold Anti-competitive claims?
- Implementing the newest Google Earth through pNaCl, basically ActiveX by Google
- Play Store website threw you out if you were using Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=1131601
- Gmail delivered an inferior mobile version to Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=668275
- Actually, Google fucks with Firefox on Android all the time https://bugzilla.mozilla.org/show_bug.cgi?id=668288
- Inbox is still Chrome only
- Youtube refused to serve webm to Firefox for a while | https://bugzilla.mozilla.org/show_bug.cgi?id=1233970
Is that enough for now?
Google is no better than old Microsoft/IE team often. But hey, since you get a shiny browser that implements non standard things, it's okay, right?
- Play Store website threw you out if you were using Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=1131601
- Gmail delivered an inferior mobile version to Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=668275
- Actually, Google fucks with Firefox on Android all the time https://bugzilla.mozilla.org/show_bug.cgi?id=668288
- Inbox is still Chrome only
- Youtube refused to serve webm to Firefox for a while | https://bugzilla.mozilla.org/show_bug.cgi?id=1233970
Is that enough for now?
Google is no better than old Microsoft/IE team often. But hey, since you get a shiny browser that implements non standard things, it's okay, right?
That is a list of bugs and one has an apology and a fix from Google. Most are even fixed. Even what you consider anti-competive "Youtube refused to serve webm to Firefox for a while", shows bias because the first comment of the ticket explains that it served videos. It probably worked for a ton of people.
Even with the NaCL thing I was able to find and implementation [1] of it that was under a open source license when I was trying to find a NaCl spec. NaCl existed because webassembly didn't, Google wanted other browsers to implement it.
Bugs happens, Technologies don't get adopted; Google is made of people and mistakes happen. Your disingenuous crying of anti-competitive wolf dilutes real claims of anti-competition.
[1] - https://chromium.googlesource.com/native_client/src/native_c...
Even with the NaCL thing I was able to find and implementation [1] of it that was under a open source license when I was trying to find a NaCl spec. NaCl existed because webassembly didn't, Google wanted other browsers to implement it.
Bugs happens, Technologies don't get adopted; Google is made of people and mistakes happen. Your disingenuous crying of anti-competitive wolf dilutes real claims of anti-competition.
[1] - https://chromium.googlesource.com/native_client/src/native_c...
As I explained elsewhere in this thread, (P)NaCl is only open source in the sense that Chromium is. Because of the dependency on Pepper, Google's implementation is Chrome only.
The problem with this is that Google solicited feedback on Pepper on the plugin-futures mailing list early on. The other browser vendors correctly pointed out that Pepper was unnecessary. Google completely ignored the feedback and did it anyway. Years later, it is obvious that the unanimous consensus of the other browser vendors was right. PNaCl is dead, and Web Assembly uses the Web APIs instead of Pepper, which is precisely what everyone else had advocated early on.
The lack of adoption of PNaCl is Google's problem. As is obvious with Web Assembly, nobody has any problem with adding a portable low-level IR to the browser. The biggest problem was the insistence on Pepper. If they had listened to feedback, maybe we would have had Web Assembly much sooner.
The problem with this is that Google solicited feedback on Pepper on the plugin-futures mailing list early on. The other browser vendors correctly pointed out that Pepper was unnecessary. Google completely ignored the feedback and did it anyway. Years later, it is obvious that the unanimous consensus of the other browser vendors was right. PNaCl is dead, and Web Assembly uses the Web APIs instead of Pepper, which is precisely what everyone else had advocated early on.
The lack of adoption of PNaCl is Google's problem. As is obvious with Web Assembly, nobody has any problem with adding a portable low-level IR to the browser. The biggest problem was the insistence on Pepper. If they had listened to feedback, maybe we would have had Web Assembly much sooner.
I am taking what you say about historical events as you say it, but It still doesn't seem like the move is "anti-competitive". At worst its bad engineering.
Its not like there is some new killer feature in the new google maps that makes it not work on Firefox, I have used it from Firefox in the past week and it worked fine. Even if there were some killer feature, they are free to release it in such a way that it only works with their software.
I hate microsoft but I still don't give them flak for not releasing Linux versions of office and excel. They are allowed to not do that. Where it steps into anti-competitive is when they start breaking other's people things or maliciously manipulating standards. Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
Its not like there is some new killer feature in the new google maps that makes it not work on Firefox, I have used it from Firefox in the past week and it worked fine. Even if there were some killer feature, they are free to release it in such a way that it only works with their software.
I hate microsoft but I still don't give them flak for not releasing Linux versions of office and excel. They are allowed to not do that. Where it steps into anti-competitive is when they start breaking other's people things or maliciously manipulating standards. Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
>Its not like there is some new killer feature in the new google maps that makes it not work on Firefox, I have used it from Firefox in the past week and it worked fine. Even if there were some killer feature, they are free to release it in such a way that it only works with their software.
http://i.imgur.com/FDM5DQ9.png
k
You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
>when they start breaking other's people things
They are! They actually are! These bugs I listed aren't "bad engineering". They're "When UserAgent is detected send shitty version". In what world is that not deliberately breaking people's things? Users access Inbox on Firefox, see that their friends on chrome that sent him the link can actually access it, they're not going to blame Google, they're going to say that Firefox is a piece of crap and dump it.
> maliciously manipulating standards.
chrome.* javascript APIs
Bluetooth API
FileSystem API
-webkit CSS prefixes
not manipulating standards, just implementing half assed things on their side of things and leaving the blame on other browser manufacturers when they don't implement them.
>They didn't force it on anyone else.
"Company with 50% of desktop browser share and 80% of mobile browser share only unilaterally did something non standard and screwed everyone over. But that's not forcing everyone's hand I swear, they're only the biggest players on the market."
k
You know, when pcwalton keeps proving you wrong over and over again, you might want to rethink your opinions. It's not as if he knew what he's talking about or anything, right? :>
http://i.imgur.com/FDM5DQ9.png
k
You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
>when they start breaking other's people things
They are! They actually are! These bugs I listed aren't "bad engineering". They're "When UserAgent is detected send shitty version". In what world is that not deliberately breaking people's things? Users access Inbox on Firefox, see that their friends on chrome that sent him the link can actually access it, they're not going to blame Google, they're going to say that Firefox is a piece of crap and dump it.
> maliciously manipulating standards.
chrome.* javascript APIs
Bluetooth API
FileSystem API
-webkit CSS prefixes
not manipulating standards, just implementing half assed things on their side of things and leaving the blame on other browser manufacturers when they don't implement them.
>They didn't force it on anyone else.
"Company with 50% of desktop browser share and 80% of mobile browser share only unilaterally did something non standard and screwed everyone over. But that's not forcing everyone's hand I swear, they're only the biggest players on the market."
k
You know, when pcwalton keeps proving you wrong over and over again, you might want to rethink your opinions. It's not as if he knew what he's talking about or anything, right? :>
> They're "When UserAgent is detected send shitty version".
If you must pick an example of them breaking stuff, please pick one that they didn't already apologize and fix.
> http://i.imgur.com/FDM5DQ9.png
My mistake on confusing google earth with google maps, that is an important point that issue. It does suck that doesn't work on firefox, but no one is forcing any one to do anything. Its not like you paid for any of this, or there is some law that says companies have to give stuff away for free.
> You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
I am not reversing my stance or saying anything self contradictory. I am attempting to define nuanced boundaries around some who would rather bludgeon things into a simple categories whether or not it fits. So far all I hear are complaints about company giving away huge amounts of value for free, but isn't doing it the way you (or I) want.
I never said Google was paragon of anything and I admitted they could do better (I really do wish they would do better), the only line I am taking is that their behavior is not "anti-competitive", which is not a high bar. Which has not been disproved or this case even rationally approached. I am open to having my mind changed, but I would need well thought out discourse and evidence to change it.
If you respond again so thoughtlessly or with such poor grammar I will not be responding again.
If you must pick an example of them breaking stuff, please pick one that they didn't already apologize and fix.
> http://i.imgur.com/FDM5DQ9.png
My mistake on confusing google earth with google maps, that is an important point that issue. It does suck that doesn't work on firefox, but no one is forcing any one to do anything. Its not like you paid for any of this, or there is some law that says companies have to give stuff away for free.
> You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards
I am not reversing my stance or saying anything self contradictory. I am attempting to define nuanced boundaries around some who would rather bludgeon things into a simple categories whether or not it fits. So far all I hear are complaints about company giving away huge amounts of value for free, but isn't doing it the way you (or I) want.
I never said Google was paragon of anything and I admitted they could do better (I really do wish they would do better), the only line I am taking is that their behavior is not "anti-competitive", which is not a high bar. Which has not been disproved or this case even rationally approached. I am open to having my mind changed, but I would need well thought out discourse and evidence to change it.
If you respond again so thoughtlessly or with such poor grammar I will not be responding again.
> I am taking what you say about historical events as you say it, but It still doesn't seem like the move is "anti-competitive".
It sure is when combined with Google releasing NaCl-based software, such as Google Earth.
> Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Not with Dart, which followed a very similar trajectory (see my other comments). Not with -webkit prefixes. Etc. etc.
> Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
It sure is when combined with Google releasing NaCl-based software, such as Google Earth.
> Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.
Not with Dart, which followed a very similar trajectory (see my other comments). Not with -webkit prefixes. Etc. etc.
> Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.
When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
I had a misunderstanding with Google earth vs maps. I used Google maps in Firefox just fine, and that is what I meant earlier.
I was unaware even of the existence of a web based version of Earth. The last time I used Google earth was as a desktop client. That was back when I worked in the Air Force Weather Wing almost a year ago. Have they done away with the desktop client?
Starting over with whether or not this is anticompetitive; who are they repressing by giving away free software that runs on other free software? Does this software need to be used?
This all seems to hinge around this part of what you are saying:
> When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
The option to lose users here is huge. How is this different than microsoft making excel and only supporting it on windows? I choose not to use excel at least in part because it doesn't run on any platform I care to use. I feel I should clarify here, I don't condone this obnoxious behavior from microsoft or Google. I think it is wrong from the stance that all software should inter-operate smoothly and be open source, but it doesn't seem illegal or even unethical.
The answer for a users to both Earth and excel seems to be to use some other competing software. For mapping software something like openstreetmap or even some other Google software like Google maps (or even a pay for solution). For spreadsheets I use libreoffice.
Even if this is anti-competitive it seems so minor that it dilutes the meaning of the term. Lumping this in with things like the Dr DOS fiasco just doesn't seem right. For reference in the Dr DOS times there was a DOS competitor to microsoft's DOS. Dr DOS was a relatively bug free DOS and it worked fine with windows until the 3.0 release (I think). Until this specific version/patch started intermittently causing windows to not run if Dr DOS was detected even though it was advertised as working. The end result was Dr DOS being run out of business because it looked like a bug in Dr DOS and sometime ms even claimed such. The Dr DOS team was very overtly fucked by ms.
Nothing about most of the things brought up in this thread seems overt. No money is being paid for web browsers or this mapping software. Having users takes significant effort to monetize. It seems detached from web standards in any direct way (I agree it indirectly relates to webassembly, but not in a way that seems legally relevant). Most of it seems like engineers being engineers and fixing their own little slice of the world and hoping everyone works with their stuff because they don't want to change. Shortsighted and imperfect just like most humans.
Thank you for taking the time to explain (and listen) to me in a rational and level headed way. I won't be checking my messages here again until I start another build or boring process tomorrow. Have an upvote.
I was unaware even of the existence of a web based version of Earth. The last time I used Google earth was as a desktop client. That was back when I worked in the Air Force Weather Wing almost a year ago. Have they done away with the desktop client?
Starting over with whether or not this is anticompetitive; who are they repressing by giving away free software that runs on other free software? Does this software need to be used?
This all seems to hinge around this part of what you are saying:
> When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.
The option to lose users here is huge. How is this different than microsoft making excel and only supporting it on windows? I choose not to use excel at least in part because it doesn't run on any platform I care to use. I feel I should clarify here, I don't condone this obnoxious behavior from microsoft or Google. I think it is wrong from the stance that all software should inter-operate smoothly and be open source, but it doesn't seem illegal or even unethical.
The answer for a users to both Earth and excel seems to be to use some other competing software. For mapping software something like openstreetmap or even some other Google software like Google maps (or even a pay for solution). For spreadsheets I use libreoffice.
Even if this is anti-competitive it seems so minor that it dilutes the meaning of the term. Lumping this in with things like the Dr DOS fiasco just doesn't seem right. For reference in the Dr DOS times there was a DOS competitor to microsoft's DOS. Dr DOS was a relatively bug free DOS and it worked fine with windows until the 3.0 release (I think). Until this specific version/patch started intermittently causing windows to not run if Dr DOS was detected even though it was advertised as working. The end result was Dr DOS being run out of business because it looked like a bug in Dr DOS and sometime ms even claimed such. The Dr DOS team was very overtly fucked by ms.
Nothing about most of the things brought up in this thread seems overt. No money is being paid for web browsers or this mapping software. Having users takes significant effort to monetize. It seems detached from web standards in any direct way (I agree it indirectly relates to webassembly, but not in a way that seems legally relevant). Most of it seems like engineers being engineers and fixing their own little slice of the world and hoping everyone works with their stuff because they don't want to change. Shortsighted and imperfect just like most humans.
Thank you for taking the time to explain (and listen) to me in a rational and level headed way. I won't be checking my messages here again until I start another build or boring process tomorrow. Have an upvote.
[deleted]
where the same crowd who vilified IE and the web monoculture it created
While a web monoculture isn't ideal, it's rational that people might have differing comfort levels between an OS-tied, closed-source project actively used to undermine the web, and an OS-agnostic, overwhelmingly open-source project that has been a principal contributor to the web moving forward (and arguably delayed or prevented the wholesale app-ification of the industry).
While a web monoculture isn't ideal, it's rational that people might have differing comfort levels between an OS-tied, closed-source project actively used to undermine the web, and an OS-agnostic, overwhelmingly open-source project that has been a principal contributor to the web moving forward (and arguably delayed or prevented the wholesale app-ification of the industry).
I think you're granting way too much favor to a company that uses changes in Chrome to force other companies to do what they want, or as with yesterday's news, to actively block their market competition. Even as an open source project, the fact that decision making and control comes from Google, and the dominant distribution of it is a proprietary version built around Google's corporate needs, it is no more trustworthy than IE at heart.
One of the fun differences between the Chrome and IE FUD is that the former is based upon "but what if!?!?!" (usually ignoring that there is effectively zero lock-in, everything is standardized and open, etc), while the latter is based upon what actually happened. That you mention the news from yesterday, and report on some cynical, nonsensical comments as if they are fact is a perfect example.
I want to be cynical about Google and Chrome. But thus far I have absolutely nothing to actually criticize them on. They literally have kept the web alive, and their attempts to try to clear up the advertising market is yet another example. Or just be cynical about it while everyone migrates to apps.
I want to be cynical about Google and Chrome. But thus far I have absolutely nothing to actually criticize them on. They literally have kept the web alive, and their attempts to try to clear up the advertising market is yet another example. Or just be cynical about it while everyone migrates to apps.
There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox.
Not everything is standardized, sadly. Even the things that are ... well, https://bugs.chromium.org/p/chromium/issues/detail?id=690195 is an example from just earlier today where Chrome went to implement a spec, decided what the spec said was not convenient, and just implemented something else without bothering to raise a spec issue or anything. See https://github.com/whatwg/html/issues/2568 for the resulting lack of interop that the standards now have to sort out. This doesn't always happen, of course, but it happens often enough.
Anyway, the Chrome team itself is, by and large, pretty good to work with (some exceptions like their "let's force-install this on unwitting users' computers" marketing deals notwithstanding). Other parts of Google are very much less great. Getting Gmail to work with your browser unless you spoof the UA string of some other existing browser is an exercise in futility.
Not everything is standardized, sadly. Even the things that are ... well, https://bugs.chromium.org/p/chromium/issues/detail?id=690195 is an example from just earlier today where Chrome went to implement a spec, decided what the spec said was not convenient, and just implemented something else without bothering to raise a spec issue or anything. See https://github.com/whatwg/html/issues/2568 for the resulting lack of interop that the standards now have to sort out. This doesn't always happen, of course, but it happens often enough.
Anyway, the Chrome team itself is, by and large, pretty good to work with (some exceptions like their "let's force-install this on unwitting users' computers" marketing deals notwithstanding). Other parts of Google are very much less great. Getting Gmail to work with your browser unless you spoof the UA string of some other existing browser is an exercise in futility.
> There's zero lock-in unless you want to use Hangouts. Or Google Earth. Or Inbox.
That's not really Chrome's fault - it's the fault of the respective (Hangouts, Earth, Inbox) product teams. We didn't blame Microsoft for "lock-in" back in the IE-only website days, I think it would be fair to give Google that latitude unless you are ascribing nefarious motives above and beyond what lazy/resource-constrained web devs used to do with IE6-only web sites/apps.
That's not really Chrome's fault - it's the fault of the respective (Hangouts, Earth, Inbox) product teams. We didn't blame Microsoft for "lock-in" back in the IE-only website days, I think it would be fair to give Google that latitude unless you are ascribing nefarious motives above and beyond what lazy/resource-constrained web devs used to do with IE6-only web sites/apps.
> We didn't blame Microsoft for "lock-in" back in the IE-only website days
Yes, we did. Very loudly and very frequently. So loudly and frequently that the company was charged with violating the Sherman Antitrust Act.
The expression "embrace, extend, extinguish"[1] was first used to describe Microsoft's attempt to "lock-in" the WWW. Introducing incompatibilities into IE and proprietary extensions (ActiveX, which Google is copying with NaCL) allowed make a show of embracing open standards as bait for the lock-in. This isn't theoretical - in Bill Gates's own words[2]:
>> "One thing we have got to change in our strategy--allowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform."
[1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
[2] (pdf) http://antitrust.slated.org/www.iowaconsumercase.org/011607/...
Yes, we did. Very loudly and very frequently. So loudly and frequently that the company was charged with violating the Sherman Antitrust Act.
The expression "embrace, extend, extinguish"[1] was first used to describe Microsoft's attempt to "lock-in" the WWW. Introducing incompatibilities into IE and proprietary extensions (ActiveX, which Google is copying with NaCL) allowed make a show of embracing open standards as bait for the lock-in. This isn't theoretical - in Bill Gates's own words[2]:
>> "One thing we have got to change in our strategy--allowing Office documents to be rendered very well by other peoples [sic] browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities. Anything else is suicide for our platform."
[1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
[2] (pdf) http://antitrust.slated.org/www.iowaconsumercase.org/011607/...
>> We didn't blame Microsoft for "lock-in" back in the IE-only website days
>Yes, we did.
My phrasing wasn't as clear as I thought - what I meant to say "We didn't blame Microsoft for 'lock-in' due to 3rd parties creating IE-only websites, we blamed the 3rd parties." Implementing non-standard extensions was par for the course during the browser wars (Netscape did the same), and I doubt there was a real expectation of achieving lock-in via the browser by either party: Windows achieved lock-in via Windows, Office and legal threats. Not IE.
>Yes, we did.
My phrasing wasn't as clear as I thought - what I meant to say "We didn't blame Microsoft for 'lock-in' due to 3rd parties creating IE-only websites, we blamed the 3rd parties." Implementing non-standard extensions was par for the course during the browser wars (Netscape did the same), and I doubt there was a real expectation of achieving lock-in via the browser by either party: Windows achieved lock-in via Windows, Office and legal threats. Not IE.
In South Korea, Windows achieved lock-in via legislation requiring IE (or more precisely ActiveX). See https://www.washingtonpost.com/world/asia_pacific/due-to-sec... for a decent summary.
And yes, there was very much expectation of achieving lock-in via ActiveX. And it worked in some cases.
And yes, there was very much expectation of achieving lock-in via ActiveX. And it worked in some cases.
[deleted]
> That's not really Chrome's fault
It's Chrome's fault that it's shipping non-standard things. Not like any browser is blameless here, but let's not pretend they're innocent either.
It's _Google's_ fault that it's shipping non-standard things in its browser and then using them in its other products to lock out other browsers.
> We didn't blame Microsoft for "lock-in" back in the IE-only website days
We sure did. And it wasn't even Microsoft creating the IE-only websites!
It's Chrome's fault that it's shipping non-standard things. Not like any browser is blameless here, but let's not pretend they're innocent either.
It's _Google's_ fault that it's shipping non-standard things in its browser and then using them in its other products to lock out other browsers.
> We didn't blame Microsoft for "lock-in" back in the IE-only website days
We sure did. And it wasn't even Microsoft creating the IE-only websites!
> It's Chrome's fault that it's shipping non-standard things.
I challenge you to name one non-niche browser that didn't ship "non-standard things"
I challenge you to name one non-niche browser that didn't ship "non-standard things"
I explicitly said other browsers have done it too.
Chrome has done a lot more promotion of its non-standard things and of course Google as a whole has been using Chrome's non-standard things quite a bit, which is a large part of the problem.
Chrome has done a lot more promotion of its non-standard things and of course Google as a whole has been using Chrome's non-standard things quite a bit, which is a large part of the problem.
The norms have been different in the past few years than during the first browser war. All browser manufacturers have effectively pledged to not ship things without consensus.
In the case of NaCl, Google got around their own pledge by declaring NaCl "not part of Blink" and therefore not subject to the Blink rules, which was a cop-out if I've ever seen one.
In the case of NaCl, Google got around their own pledge by declaring NaCl "not part of Blink" and therefore not subject to the Blink rules, which was a cop-out if I've ever seen one.
wat
NaCl and Dart are things that actually happened. They were decidedly not standardized.
Dart - ECMA-408. Open and standard. BSD grant, etc.
NaCL - Completely open, patent grants, open source, etc. Not a standard, but they did everything possible to move there, and abandoned it when it didn't get interest from others.
Anything else?
NaCL - Completely open, patent grants, open source, etc. Not a standard, but they did everything possible to move there, and abandoned it when it didn't get interest from others.
Anything else?
Dart and NaCl actively ignored outside feedback, even when in retrospect the feedback was clearly correct.
Few Web developers wanted Dart, and this was clear at the time Google went to ECMA. They pushed ahead with a standard anyway despite no other browser vendor signing on board. You can call anything a standard, but without a multi-vendor process, and with only a single implementation, the idea of a standard is pretty meaningless.
And, regarding Dart, on the WebKit side, many WebKit contributors were (quite reasonably) opposed to adding support for pluggable languages to the DOM, because of the unavoidable overheads introduced by this. As far as I recall, no solution to the problem of cross-language GC, which is one of the biggest issues here, had been even really proposed at the time. Google continued on ahead, forking WebKit into Blink, introducing Dartium, and then ending the project. Now, with Dartium dead, it has become clear in retrospect that the WebKit community was right all along: you don't want multiple incompatible languages hooked up to the DOM.
NaCl may have been "open" in that Chromium was open source, but the dependency on Pepper meant that Google's implementation was Chrome-only. Google solicited feedback on Pepper back in 2010, but Apple and Mozilla engineers provided compelling arguments as to why Pepper was unnecessary. They ignored the feedback and did it anyway. Now, after seven years, NaCl is obsolete in favor of the multi-vendor Web Assembly, which uses the Web APIs instead of Pepper—exactly the approach that everyone else on the plugin-futures mailing list had advocated in the first place.
A lot of unnecessary work would have been avoided if NaCl and Dart had been more receptive to feedback.
Few Web developers wanted Dart, and this was clear at the time Google went to ECMA. They pushed ahead with a standard anyway despite no other browser vendor signing on board. You can call anything a standard, but without a multi-vendor process, and with only a single implementation, the idea of a standard is pretty meaningless.
And, regarding Dart, on the WebKit side, many WebKit contributors were (quite reasonably) opposed to adding support for pluggable languages to the DOM, because of the unavoidable overheads introduced by this. As far as I recall, no solution to the problem of cross-language GC, which is one of the biggest issues here, had been even really proposed at the time. Google continued on ahead, forking WebKit into Blink, introducing Dartium, and then ending the project. Now, with Dartium dead, it has become clear in retrospect that the WebKit community was right all along: you don't want multiple incompatible languages hooked up to the DOM.
NaCl may have been "open" in that Chromium was open source, but the dependency on Pepper meant that Google's implementation was Chrome-only. Google solicited feedback on Pepper back in 2010, but Apple and Mozilla engineers provided compelling arguments as to why Pepper was unnecessary. They ignored the feedback and did it anyway. Now, after seven years, NaCl is obsolete in favor of the multi-vendor Web Assembly, which uses the Web APIs instead of Pepper—exactly the approach that everyone else on the plugin-futures mailing list had advocated in the first place.
A lot of unnecessary work would have been avoided if NaCl and Dart had been more receptive to feedback.
> Few Web developers wanted Dart
Do you just mean they didn't want the dart vm in browsers? Or the language? If the latter as well, I respectfully disagree.
> Dart actively ignored outside feedback
Again, on the language or just having the vm in browsers?
Do you just mean they didn't want the dart vm in browsers? Or the language? If the latter as well, I respectfully disagree.
> Dart actively ignored outside feedback
Again, on the language or just having the vm in browsers?
Few developers wanted either the language or the native support in browsers. Witness the success of e.g. TypeScript compared to Dart.
There were plenty of issues in the Dart language, too. The way generics variance was deliberately unsound was bizarre, in particular, and they resisted attempts to fix it.
There were plenty of issues in the Dart language, too. The way generics variance was deliberately unsound was bizarre, in particular, and they resisted attempts to fix it.
As I'm sure you're aware, the better language doesn't always win the popularity contest. Typescript, being a superset of js still has a lot of its warts. Dart is more of a clean break.
Uh, the difference is Chrome is usually right. Dealing with Firefox bugs is starting to feel like dealing with IE. Favorite example: a 9 year old bug where a select's option menu will render in the wrong location if there's a transform in the DOM above it (https://bugzilla.mozilla.org/show_bug.cgi?id=455164)
I just tried reproducing that bug. It's fixed in multiprocess Firefox, which is the default configuration for most users. It'll be the only configuration a few months for now, once add-ons that are not multiprocess-compatible are no longer supported.
Also, Chrome is not usually right in my experience. A lot of times they don't even manage to implement the specs they themselves write correctly... Then someone else has to come along and file bugs on them, and maybe they fix them. Sometimes.
All of which is anecdote. Actual data would be much better, of course.
Also, Chrome is not usually right in my experience. A lot of times they don't even manage to implement the specs they themselves write correctly... Then someone else has to come along and file bugs on them, and maybe they fix them. Sometimes.
All of which is anecdote. Actual data would be much better, of course.
It doesn't matter if it's fixed in some configuration of Firefox; point is it shouldn't take nine years to fix an app-breaking bug. Even early 2000's IE had a better track record than that. It's not like this is the only instance either, here's a 17(!) year old issue about Firefox not supporting option's label attribute: https://bugzilla.mozilla.org/show_bug.cgi?id=option-label
Could you specify some issues you ran into on Chrome that affected user space this directly or took anywhere near this long to fix? I've been doing all of my development in Chrome for ~6 years and have done very, very few Chrome-specific workarounds. On the other hand, I ran into both the Firefox bugs mentioned in the last half year.
Could you specify some issues you ran into on Chrome that affected user space this directly or took anywhere near this long to fix? I've been doing all of my development in Chrome for ~6 years and have done very, very few Chrome-specific workarounds. On the other hand, I ran into both the Firefox bugs mentioned in the last half year.
> point is it shouldn't take nine years to fix an app-breaking bug
It depends on priorities, obviously. That bug was fixed in various cases that were most-commonly hit (e.g. translate-only transforms) much earlier than now. Fixing it in the scale case more or less required completely rewriting how <select> is implemented, and there was always other stuff that needed to get done that was a bigger problem in practice.
I'm not saying this is good, obviously; it would be great if there were more people working on Gecko bugs and triage were not so critical. But there weren't and it was. I'm sorry that it's caused you problems; I'll see if I can get some progress to happen on the option label thing.
> Could you specify some issues you ran into on Chrome that affected user space this directly
Off the top of my head, https://bugs.chromium.org/p/chromium/issues/detail?id=352144 is a pretty glaring CSS layout bug. Is that direct enough?
Or how about https://bugs.chromium.org/p/chromium/issues/detail?id=269500 which has been around forever (it existed in WebKit long before Chrome was even announced)?
Or https://bugs.chromium.org/p/chromium/issues/detail?id=353580
Or https://bugs.chromium.org/p/chromium/issues/detail?id=286672
Note that all these bugs were filed in the WebKit bug system for a while before I went and refiled them in the Blink bug system after Blink forked off from WebKit. So they are much older than the dates you see on those reports.
It depends on priorities, obviously. That bug was fixed in various cases that were most-commonly hit (e.g. translate-only transforms) much earlier than now. Fixing it in the scale case more or less required completely rewriting how <select> is implemented, and there was always other stuff that needed to get done that was a bigger problem in practice.
I'm not saying this is good, obviously; it would be great if there were more people working on Gecko bugs and triage were not so critical. But there weren't and it was. I'm sorry that it's caused you problems; I'll see if I can get some progress to happen on the option label thing.
> Could you specify some issues you ran into on Chrome that affected user space this directly
Off the top of my head, https://bugs.chromium.org/p/chromium/issues/detail?id=352144 is a pretty glaring CSS layout bug. Is that direct enough?
Or how about https://bugs.chromium.org/p/chromium/issues/detail?id=269500 which has been around forever (it existed in WebKit long before Chrome was even announced)?
Or https://bugs.chromium.org/p/chromium/issues/detail?id=353580
Or https://bugs.chromium.org/p/chromium/issues/detail?id=286672
Note that all these bugs were filed in the WebKit bug system for a while before I went and refiled them in the Blink bug system after Blink forked off from WebKit. So they are much older than the dates you see on those reports.
Firefox is a lot older so obviously the issues are also a lot older.
You can find the oldest unfixed bugs for Chromium here (https://bugs.chromium.org/p/chromium/issues/list?can=2&q=&so...).
A lot of those issues are from 2008 (that's when Google Chrome launched) and hence means that have been there since the beginning and most of them affect user interaction.
Throwing dirt doesn't help anyone. If you have the skills and time, contribute a browser of your choice.
You can find the oldest unfixed bugs for Chromium here (https://bugs.chromium.org/p/chromium/issues/list?can=2&q=&so...).
A lot of those issues are from 2008 (that's when Google Chrome launched) and hence means that have been there since the beginning and most of them affect user interaction.
Throwing dirt doesn't help anyone. If you have the skills and time, contribute a browser of your choice.
I'm not expecting Firefox to be perfect, nor do I think it's a particularly bad browser. I'm specifically trying to point out why web devs are generally accepting of Chrome's dominance when they previously rebelled so hard against IE. The answer is it's not monoculture that's the problem, it's the quality of the technology the monoculture is based on -- and I think it's clear that Chrome is by far the best modern browser to develop against. I don't think you'll find anything in that bug list that's even close to the severity of a missing feature that's supported in every other browser as far back as IE8.
> I don't think you'll find anything in that bug list that's even close to the severity of a missing feature that's supported in every other browser
You mean like not supporting high-contrast themes on Windows, literally the first thing on the list at https://bugs.chromium.org/p/chromium/issues/detail?id=92 ? Not a problem for web devs obviously, just for users, which I guess is partly your point.
Or https://bugs.chromium.org/p/chromium/issues/detail?id=2016 which is about XHR not providing progress notifications properly and at filing time was working correctly in Firefox 3 and IE 7?
Or the lack of sane text rendering behavior, having to at best opt into ligature support, if you can get them at all, etc? That's something they finally fixed recently, after 8+ years of it being a problem.
Or missing MathML support? Granted, some other browsers are pretty bad on this too.
Seriously, there's lots of stuff Chrome couldn't and can't do that other browsers can do. They're just much better (not least due to spending way more money on it) at steering web devs to never try the things Chrome is bad at and focus on the things the Chrome dev team has been focusing on...
You mean like not supporting high-contrast themes on Windows, literally the first thing on the list at https://bugs.chromium.org/p/chromium/issues/detail?id=92 ? Not a problem for web devs obviously, just for users, which I guess is partly your point.
Or https://bugs.chromium.org/p/chromium/issues/detail?id=2016 which is about XHR not providing progress notifications properly and at filing time was working correctly in Firefox 3 and IE 7?
Or the lack of sane text rendering behavior, having to at best opt into ligature support, if you can get them at all, etc? That's something they finally fixed recently, after 8+ years of it being a problem.
Or missing MathML support? Granted, some other browsers are pretty bad on this too.
Seriously, there's lots of stuff Chrome couldn't and can't do that other browsers can do. They're just much better (not least due to spending way more money on it) at steering web devs to never try the things Chrome is bad at and focus on the things the Chrome dev team has been focusing on...
> I don't think you'll find anything in that bug list that's even close to the severity of a missing feature that's supported in every other browser as far back as IE8.
Yes, you will. Take the border-collapse bug I mentioned: it doesn't affect other engines, to my knowledge. Border-collapse goes back to, like, IE5.
Yes, you will. Take the border-collapse bug I mentioned: it doesn't affect other engines, to my knowledge. Border-collapse goes back to, like, IE5.
That's not even in the same league as either of the Firefox issues I've referenced. The first is actually app-breaking (in our case users couldn't see any of the select options) the second is just plain IE-level of stubbornness. I'm not saying Chrome is perfectly immaculate, just trying to explain why it's so popular among the dev community in a way FF/IE are not.
I find problems in Gecko much less often than I find problems in Blink. For example, WebKit handles border-collapse by drawing borders on top of one another, which is totally bogus when transparent borders are involved. While not a spec violation per se, Blink's behavior when absolute containing blocks are split across multiple lines is really bizarre (objects parented to that containing block just disappear). WebKit violates the HTML spec when the top margin of an element at the top of the document is queried in quirks mode. Etc. etc.
Can you file these bugs at crbug.com?
To be fair, IE was awful and held back the industry. Likely, it was awful and held by the industry by design.
To this day, the versions of IE in use by actual people are awful. MS finally has Edge, which isn't awful, but absolutely no one uses it.
If I tell an end user to get Chrome or Firefox, that's the end of the problem, whatever system they have it will work. If I try to tell someone to update their IE or to get Edge, I'm stepping into a black hole of trying to divine which version of Windows they're on and how recent their updates are. None of my mac loving coworkers can easily test against IE or Edge and headless unit testing against IE isn't a thing.
To this day, the versions of IE in use by actual people are awful. MS finally has Edge, which isn't awful, but absolutely no one uses it.
If I tell an end user to get Chrome or Firefox, that's the end of the problem, whatever system they have it will work. If I try to tell someone to update their IE or to get Edge, I'm stepping into a black hole of trying to divine which version of Windows they're on and how recent their updates are. None of my mac loving coworkers can easily test against IE or Edge and headless unit testing against IE isn't a thing.
IE invented nice things like AJAX (XMLHttpRequest) and the "modern" border-box sizing model that has become almost a CSS boilerplate requirement (* { box-sizing: border-box; }), which was how IE originally interpreted the CSS spec.
IE wasn't awful at the time it was built. It was ahead of its time in some areas. It became awful because of tech debt: people building for it and only it. Companies having key line of business apps built solely for IE that locked everyone into a compatibility nightmare.
It is the same thing with the "Just install Chrome" crowd. If all anyone uses is Chrome, then no one else can move forward without first guaranteeing "Chrome compatibility" rather than spec compatibility. How soon until even Chrome has to maintain compatibility with ancient Chrome bugs because some Fortune 500 company relies on that specific bug for LOB software, willing to throw money at dumb bugs? (That Fortune 500 company could even be Google at this point, because they very much seem to have invested in an internal monoculture.)
(Your Mac coworkers can find free Edge testing VMs from Microsoft. There's also "headless" tools like BrowserStack.)
IE wasn't awful at the time it was built. It was ahead of its time in some areas. It became awful because of tech debt: people building for it and only it. Companies having key line of business apps built solely for IE that locked everyone into a compatibility nightmare.
It is the same thing with the "Just install Chrome" crowd. If all anyone uses is Chrome, then no one else can move forward without first guaranteeing "Chrome compatibility" rather than spec compatibility. How soon until even Chrome has to maintain compatibility with ancient Chrome bugs because some Fortune 500 company relies on that specific bug for LOB software, willing to throw money at dumb bugs? (That Fortune 500 company could even be Google at this point, because they very much seem to have invested in an internal monoculture.)
(Your Mac coworkers can find free Edge testing VMs from Microsoft. There's also "headless" tools like BrowserStack.)
> How soon until even Chrome has to maintain compatibility with ancient Chrome bugs because some Fortune 500 company relies on that specific bug for LOB software, willing to throw money at dumb bugs?
Too late. This has already been happening for years in the mobile space. It's why WebKit refuses to remove -webkit prefixes, and other browsers are now forced to implement them.
Too late. This has already been happening for years in the mobile space. It's why WebKit refuses to remove -webkit prefixes, and other browsers are now forced to implement them.
Thanks, I meant to include that. I was thinking about big bugs on the order of having to preserve NaCl or Chrome Apps the way ActiveX ruled the roost for a while in LOB apps, but yes Firefox and Edge both now pay attention to -webkit prefixed things because how many websites rely only on the prefixed versions in their CSS.
> Too late. This has already been happening for years in the mobile space.
I don't think this has much to do with Chrome - I suspect the iPhone's dominance of the mobile browser share is a big factor.
I don't think this has much to do with Chrome - I suspect the iPhone's dominance of the mobile browser share is a big factor.
If you wish to get pedantic, it has been a combined fault of both WebKit-based browsers: Chrome and Safari (Android and iPhone, plus Chrome on the desktop). If it helps, feel free to replace every reference in the posts here to Chrome with WebKit. (Or WebKit-family if you want to get really pedantic and pretend Blink is that different of a renderer.)
IE invented nice things like AJAX (XMLHttpRequest) as an ActiveX control - let's not forget this is exactly the sort of standards-breaking behaviour that you are accusing Google of doing with Chrome.
The web has a long history of post-facto standardization where implementation comes before standardazation (see browser wars).
The web has a long history of post-facto standardization where implementation comes before standardazation (see browser wars).
Yes, that was exactly my point. Browser monocultures create good, bad, and ugly results. As I pointed out with both of my examples: we standardize the good ones, complain about the bad ones, and try to ignore the ugly ones. I am accusing the Chrome monoculture of creating the same sort of environment. As I posted: then no one else can move forward without first guaranteeing "Chrome compatibility" rather than spec compatibility.
You can get a free copy of windows for testing purpuse. you cant do that for mac.
You have a point, but at least Chrome doesn't need me to install a specific OS at a specific version to make it work.
Installing a new OS to view a webpage was a tall order.
Installing a new OS to view a webpage was a tall order.
It's not the same crowd. We've been pumping and dumping tons of "bootcamp" programmers on the field. With the way things go, experienced professionals who know the old gods and the new will always be an extreme minority, just from attrition.
>where the same crowd who vilified IE
It's a different crowd, I think.
It's a different crowd, I think.
People didn't like primarily because IE was fixed version, tied to operating system version, Windows-only.
Chrome is evergreen, cross platform, open source.
That makes a big difference. Chrome gets bug fixes, implements new standards, etc.
Chrome is evergreen, cross platform, open source.
That makes a big difference. Chrome gets bug fixes, implements new standards, etc.
When IE took over the market, it was implementing new features at a breakneck pace. The browser wars were not "IE sits still and gains market share"--they were "IE develops rapidly, takes over the market, and then stops development".
AJAX, bi-directional text, most conformant CSS 2.0 browser, border-box sizing CSS model are all things where IE was ahead of the times. The reason people hated IE was because it implemented only "just enough" to get ahead and then sat on their asses until someone catched up. That's where the antitrust came from.
I believe, order is reverse. IE team was dismantled after the antitrust suit.
W3C should write machine readable specs and vendors should transform those specs into working browsers, where the transformation is mechanically provably correct.
That ship has sailed a long time ago, though I'm all for a formal semantics for CSS, safe JavaScript subsets, etc. Also it's not W3C who do browser and HTML specs these days but WHATWG (eg. Google).
I've seen things go the other way around. As an example, use Chrome Canary to browse https://motherboard.vice.com/en_us/article/its-like-tweeting... and then use Firefox Nightly. Chrome can barely manage to keep up with scrolling while Firefox chugs along nicely.
The only issues Firefox has are when you get to media handling and non-standard APIs from Chrome. 99.9% of websites "work" on all browsers though and I haven't seen any need to run Chrome for a specific website (Google Docs used to be a case but not anymore).
The only issues Firefox has are when you get to media handling and non-standard APIs from Chrome. 99.9% of websites "work" on all browsers though and I haven't seen any need to run Chrome for a specific website (Google Docs used to be a case but not anymore).
I filed this bug here http://crbug.com/713982
This is a behavioral difference with Firefox. Chrome is currently blocking scrolling on the JS inside the wheel event handler which appears to be very slow on the linked website. Firefox is only blocking on the JS for the first event inside the scroll gesture and asynchronously scrolling after which hides the very slow JS handlers.
This is an interesting case because the Chrome behavior lets sites implement certain effects without lagging behind scrolling while the Firefox behavior favors smoothness of scrolling over JS effects synchronized with wheel handlers. In any case, Chrome is currently working towards switching to the Firefox behavior which will make sites like this scroll much more smoothly.
This is a behavioral difference with Firefox. Chrome is currently blocking scrolling on the JS inside the wheel event handler which appears to be very slow on the linked website. Firefox is only blocking on the JS for the first event inside the scroll gesture and asynchronously scrolling after which hides the very slow JS handlers.
This is an interesting case because the Chrome behavior lets sites implement certain effects without lagging behind scrolling while the Firefox behavior favors smoothness of scrolling over JS effects synchronized with wheel handlers. In any case, Chrome is currently working towards switching to the Firefox behavior which will make sites like this scroll much more smoothly.
> It's just Firefox. Low importance.
Well, the reality is that it is low importance. Firefox is down to ~2.5% of our traffic, Firefox is bleeding users badly.
It's also not always a simple fix. In our current code base we have more workarounds for FF bugs than any other browser, and some of them are pretty nasty. e.g. monkey patching `getComputedStyle` to get around this: https://bugzilla.mozilla.org/show_bug.cgi?id=548397
So it tends to come down to whether or not it's worth carrying a bunch of technical debt to support a dying browser, not a simple choice and not a matter of sticking to web standards.
Well, the reality is that it is low importance. Firefox is down to ~2.5% of our traffic, Firefox is bleeding users badly.
It's also not always a simple fix. In our current code base we have more workarounds for FF bugs than any other browser, and some of them are pretty nasty. e.g. monkey patching `getComputedStyle` to get around this: https://bugzilla.mozilla.org/show_bug.cgi?id=548397
So it tends to come down to whether or not it's worth carrying a bunch of technical debt to support a dying browser, not a simple choice and not a matter of sticking to web standards.
> In our current code base we have more workarounds for FF bugs than any other browser, and some of them are pretty nasty. e.g. monkey patching `getComputedStyle` to get around this: https://bugzilla.mozilla.org/show_bug.cgi?id=548397
In that case, Blink and WebKit are changing to Firefox (and Edge)'s behavior, because it makes more sense. https://github.com/whatwg/html/issues/1813
In that case, Blink and WebKit are changing to Firefox (and Edge)'s behavior, because it makes more sense. https://github.com/whatwg/html/issues/1813
> In that case, Blink and WebKit are changing to Firefox (and Edge)'s behavior
The problem in FF isn't that they don't perform layout in the hidden iframe, it's that `getComputedStyle` returns `null`, which happens to be a side effect of not performing layout in Gecko.
If you read through the various related issues in your link I think you'll find that they are moving to standardize on not performing layout in hidden iframes, but `getComputedStyle` returning `null` is still a bug that Gecko intends to fix.
The problem in FF isn't that they don't perform layout in the hidden iframe, it's that `getComputedStyle` returns `null`, which happens to be a side effect of not performing layout in Gecko.
If you read through the various related issues in your link I think you'll find that they are moving to standardize on not performing layout in hidden iframes, but `getComputedStyle` returning `null` is still a bug that Gecko intends to fix.
"to support a dying browser"
Wow, this is the first time I read FF being described as a "dying browser".
Even though I don't think so and other sources https://www.netmarketshare.com/browser-market-share.aspx?qpr... say about 12% market share, the fact alone that someone describes it like that, is very sad ...
Wow, this is the first time I read FF being described as a "dying browser".
Even though I don't think so and other sources https://www.netmarketshare.com/browser-market-share.aspx?qpr... say about 12% market share, the fact alone that someone describes it like that, is very sad ...
> say about 12% market share
12% of desktop, ~5-6% of total. 3 years ago it was ~18% of total, there is certainly a consistent downward trend in usage.
12% of desktop, ~5-6% of total. 3 years ago it was ~18% of total, there is certainly a consistent downward trend in usage.
No doubt about the down thing, I also rarely use FF nowdays, but a downtrend is a different thing from "dying". Plus, I am optimistic about servo ...
It used to be much higher than 12%, so it is actually a dying browser.
How is that a bug when they say that's what the spec says. Also, both Edge and WebKit are going to adopt that behaviour since it makes sense.
I think there's one more reason people see less of Firefox. I know a LOT of people who have set their user agent string to Chrome to stop the idiotic banners on websites telling me to use Chrome even through the website works perfectly on FF. I hate it even more when websites simply won't allow me to load the page when I'm on FF.
I think there's one more reason people see less of Firefox. I know a LOT of people who have set their user agent string to Chrome to stop the idiotic banners on websites telling me to use Chrome even through the website works perfectly on FF. I hate it even more when websites simply won't allow me to load the page when I'm on FF.
> In our current code base we have more workarounds for FF bugs than any other browser
This can have several reasons. The one you're aiming at, "Firefox has more defects/divergences from the standards", is probably true to some extent. Another, also likely true, reason, is that your code base is dogfooded in Chrome, and hence, defects/divergences there are less likely to be noticed since they appear to be the standard/correct behaviour.
This can have several reasons. The one you're aiming at, "Firefox has more defects/divergences from the standards", is probably true to some extent. Another, also likely true, reason, is that your code base is dogfooded in Chrome, and hence, defects/divergences there are less likely to be noticed since they appear to be the standard/correct behaviour.
As a long time web developer, I worked through IE dominance. I was a Firefox early adopter and advocated for it amongst friends and family for years. Furthermore, I am very unhappy about the state of the landscape today. One browser should not be dominating all the others; it is an imbalance in the order of the web.
The hyperbole in your comment kinda kills me though. The glory days of web standards that you are talking about were largely glorious because Firefox came out from left field and started implementing standards and new features at a high velocity compared to Microsoft's IE. Firefox started to beat IE in tooling and platform features, and it was open source to boot. Firefox even had the edge on IE with regards to security (to be fair the bar was low in those days).
All of these details greatly endeared Firefox to me. As a web developer, I loved Firefox for what it stood for and also what it enabled me to do.
Chrome is "winning" the web browser game by taking the pages out of Firefox's playbook. Chrome is open source. Chrome is heavily involved in the standards process. Chrome takes a lot of credit for pushing browsers towards evergreen release cycles. Chrome offers the best developer tooling. Chrome implements standardized web platform features at a rapid clip.
I hate that Chrome is dominating the market. But I don't hate Chrome, and I definitely don't think the status quo today is worse than the one during the Internet Explorer regime. I hate it because it shows that there is a tremendous imbalance in the resources spent on other browsers compared to Chrome. I hate it because I don't think that the ecosystem is as great as it could be if the developer mindshare was more distributed across different browsers.
It's easy to forget that the "bar" for "gutter low" was set a long time ago by a company (M$) that decided the web was boring and could die for all it cared. I think it's simplistic and misleading to suggest that the situation today comes close to that.
The hyperbole in your comment kinda kills me though. The glory days of web standards that you are talking about were largely glorious because Firefox came out from left field and started implementing standards and new features at a high velocity compared to Microsoft's IE. Firefox started to beat IE in tooling and platform features, and it was open source to boot. Firefox even had the edge on IE with regards to security (to be fair the bar was low in those days).
All of these details greatly endeared Firefox to me. As a web developer, I loved Firefox for what it stood for and also what it enabled me to do.
Chrome is "winning" the web browser game by taking the pages out of Firefox's playbook. Chrome is open source. Chrome is heavily involved in the standards process. Chrome takes a lot of credit for pushing browsers towards evergreen release cycles. Chrome offers the best developer tooling. Chrome implements standardized web platform features at a rapid clip.
I hate that Chrome is dominating the market. But I don't hate Chrome, and I definitely don't think the status quo today is worse than the one during the Internet Explorer regime. I hate it because it shows that there is a tremendous imbalance in the resources spent on other browsers compared to Chrome. I hate it because I don't think that the ecosystem is as great as it could be if the developer mindshare was more distributed across different browsers.
It's easy to forget that the "bar" for "gutter low" was set a long time ago by a company (M$) that decided the web was boring and could die for all it cared. I think it's simplistic and misleading to suggest that the situation today comes close to that.
I too was an early-ish Firefox proponent, it was way ahead of IE on features (but behind Opera - the ads made opera unattractive to me). The devtools were revolutionary (Firebug!). Somewhere along the way, Mozilla lost momentum/focus - Chrom(e/ium) is what Firefox should have been. Hopefully Mozilla will find it's way again someday soon, for the moment I'm using Chromium- which I switched to primarily for the devtools.
What are you talking about? I'm using FF without any trouble at all on both desktop and mobile for each and everything, and so do many others, for its support of uBlock origin if nothing else. Also, the iOS devices out there have only Safari-Webkit.
There are some hipster web-sites built by amateurish developers who manage somehow to make them work correctly in Chrome only. I've faced those too and after reporting the bugs (like horizontal scrolling of menus) the reply is usually something along the lines of "most of our users prefer Chrome, so we won't fix it".
Standard response to bug-reports? "Just use Chrome. Works for me!", "It's just Firefox. Low importance." Etc.
I remember wanting to use Italki, but their website wouldn't let me input my credit card details when using firefox. I mentioned it to their support team, and they just suggested I use chrome.
I guess they're big enough that my lack of custom won't hurt, but I figured that since "inputting numbers into a field" was already a solved problem in front end web development, that they might as well sort it out.
I remember wanting to use Italki, but their website wouldn't let me input my credit card details when using firefox. I mentioned it to their support team, and they just suggested I use chrome.
I guess they're big enough that my lack of custom won't hurt, but I figured that since "inputting numbers into a field" was already a solved problem in front end web development, that they might as well sort it out.
Another reason for this is tooling.
No one I know develops on Firefox, mainly because of how amazing Google Chrome's developer tools have become over the years.
It's not even close. So yes, developers use Chrome because Google has an entire team dedicated to make their tooling cutting edge for developers.
No one I know develops on Firefox, mainly because of how amazing Google Chrome's developer tools have become over the years.
It's not even close. So yes, developers use Chrome because Google has an entire team dedicated to make their tooling cutting edge for developers.
The developer tools on Firefox Developer Edition(Aurora) are miles ahead on most things aside from the network view, to be fair. Just because they're not integrated into default firefox doesn't mean Chrome is the absolute best.
That attitude can work only for enterprise applications where people get paid to use the application. Not when you are a consumer app. We test even on Safari.
[deleted]
A good step would be if browsers other than Chrome had decent devtools built in.
It's unfortunate that IE 11 is still in such widespread use compared to Edge. Looks like IE 11 will be the boat anchor for web tech for a couple years at least.
There's a light at the end of the tunnel. Once IE 11 is mostly gone, everyone will be on an 'evergreen' browser that auto updates. Once we're there, new features won't take 10 years to be usable.
Unfortunately, I don't think it's fair to call Edge evergreen. Updates to Edge come via OS updates, which can be quite a hassle and many corporate environments might not perform at a regular basis.
This article goes into more depth: https://www.scirra.com/blog/173/just-how-evergreen-is-micros...
This article goes into more depth: https://www.scirra.com/blog/173/just-how-evergreen-is-micros...
And the same holds true for Safari (and other browsers) on iOS, I'm afraid. Then again, that probably won't be a matter of decades any more.
Well, Firefox in corporate environments may just as well be on its ESR version, which lags behind by up to a year.
Isn't windows 10 more evergreen as well? I thought IT departments had a lot less control over updates.
Yep. It's truly unfortunate.
As I said on another thread - the problem with that is that Windows 2016 server launched with IE11. So the flagship server OS for the next several years won't support Edge, which is why I'm sitting in enterprise Citrix deployments in 2107 trying to make IE11 work.
I hope we don't still have to make IE11 work in 2107, but considering how often some enterprises seem to keep ancient software around, it just might happen. :)
The market share for Edge is amazingly bad, and MS has basically zero usage on mobile.
http://caniuse.com/usage-table
http://caniuse.com/usage-table
What I really wish is for them to make decent developer tools. Other than that I love Edge!
Just curious, what would you like to see improved? Personally, I'd like dev tools to be more reliable/stable. Seems like half the time I use them in Edge they just randomly crash, freeze up, slow the entire browser to a crawl, or the network tab stops working with some obscure message until the next system reboot.
(I ask as somebody that is unaffiliated with Microsoft, but uses Edge as the daily driver.)
(I ask as somebody that is unaffiliated with Microsoft, but uses Edge as the daily driver.)
Performance and ease of use.
- The tabs are way too small
- The console input is super awkward
- HTML element viewer could show registered events (like Firefox does)
- It can be better looking
- The tabs are way too small
- The console input is super awkward
- HTML element viewer could show registered events (like Firefox does)
- It can be better looking
Better performance is always good. Excited for shared memory to come to JavaScript.
It is cool reading about the algorithms they introduced, and they are clever, but I am curious about how much of a difference they made. Are they any benchmarks to go with this?
Great to see WASM!
Why is this still tied to OS releases?
really really amazing
Also, I am not sure if it is Google breaking standards or if some feature not interpreted correctly in Edge but, Gmail still has some bugs on Edge (e.g., keyboard shortcut to add label doesn't automatically get the textbox in focus. In previous version, the text would be printed outside the box)
I hope more sites test on Edge and not just on Chrome.
Congrats to the team! Hope to see Edge decouple from Windows releases soon (as announced during Windows 10 launch)!