Sort of off topic - but Django was actually created by the author of this post! But in Lawrence, KS to run a small little newspaper's site (Lawrence Journal-World). WaPo then adopted it, which was obviously a huge boon to the growth of the framework.
On the other hand, there were 10-15 more possessions per game in Kareem's career relative to LeBron's and, on average, approximately equivalent points per game. So a lot of this is a wash.
Because then any pull request introducing something into Chromium essentially becomes the web standard. For example, Google has a ton of influence on the project. If they want to, they can introduce something that benefits their services but eschews the web standard.
but if Microsoft is moving to Blink, wouldn't they, as well, have (as you say) influence on the project?
What, really, is a downside to having an open-source web engine that all browsers use? I'm failing to see one. The web would become less fragmented; the web standard would be (only slightly) irrelevant, and we would move forward without having to deal with browsers interpreting the spec/standard differently, which is what happens currently in a lot of cases.
well, if you look at it now, webkit is BY FAR not the dominant engine.
So, by your own logic, if Microsoft ends up in a disagreement with Google about the direction of chromium, whats to stop them from just forking it and becoming the new dominant engine?
Chrome will only remain the dominant web browser as long as its users view it as worth the hassle. If Edge is built upon chromium in the future, I'm not going to sit here and say that Chrome will remain the dominant browser following that.
We can sit here and talk about 'what ifs' all day.
No, by my own logic Microsoft cannot win in case of a fork, because Microsoft is superficial in pumping resources into browsers, as history is showing us ever since IExplorer 6.
Them switching to Chromium is essentially admitting defeat and inability in building a modern browser.
> Since Android 4.4 (KitKat), the WebView component is based on the Chromium open source project. (...) Webviews also share the same rendering engine as Chrome for Android. [0]
KitKat was released in 2013[1] as well as Blink in the same year[2].
Apart from Blink being a WebKit fork, WebKit itself is not "the dominant engine" anymore at least since 2014.
Not since android.. 6? It defaults to the chrome browser. You can choose the other chrome browsers too (beta dev canary if installed, via the developer settings) and the web view might actually also be chrome. WebKit on android is from ages ago.
https://developer.chrome.com/multidevice/webview/overview Since 4.4 it is based on Chrome, not WebKit. Since I think version 6, on all the Google phones it defaults to using Chrome for WebView instead of the "WebView for Android" browser.
Our team is staffed by engineers. We respond well to discussions of tradeoffs. If you'd like to present a proposal for writing parts of Chromium in Rust and speak in depth to the exact costs and benefits, we'd absolutely consider it. I know this because we _have_ been doing some of this consideration; a number of people on the team have floated the idea of using Rust for some parts of Chromium.
But a real plan to do this requires a great deal of thought and serious consideration about how you get from here to there, whether there are long-term engineering velocity costs, etc. You don't just say "Rust is more memory-safe" and let that phrase alone mean "so obviously you're a dinosaur if you don't switch to it".
Even Mozilla is taking a lot of time and effort to introduce Rust-based components to Firefox. Making big changes to enormous projects used by huge numbers of people is not something you do lightly.
In late 2018, using Rust is a lot more serious of a proposal. But, in practice, I don't think the case for Rust in the browser would be nearly as compelling if we hadn't shown that it can be done. That's one strong reason for browser engine diversity: different engines can try different things.
I think it's fair to say that a Rust proposal would have been dead-on-arrival a couple of years ago. It'd be seen as far too risky. It would have remained so in a world where Blink was the only browser engine.
It's a classic innovator's dilemma: with fewer browser engines, the fewer risks the industry will take. More browser engines allow more seemingly-risky innovations (such as parallel styling/layout, or Rust) to break through.
A very nice property of open source software is that you can fork it, "show that it can be done" without having to start from scratch, and if the results are provably better, get your approach adopted.
The trickiest part is the proving that the different approach technology is enough better to warrant a switch. Very often, new approaches don't live up to expectations (not saying this is the case for the tech you're talking about).
1. This is actually discouraged for many projects (e.g. LLVM), because of the possibility that someone does a lot of work and then their results are not accepted.
2. The issues here don't have to do with whether the technology "works" (it does), but rather "developer velocity" and other more social/political concerns.
I understand your points, but I would suggest to consider a different point of view:
1. When you're experimenting with a seriously new technology or approach, the most likely outcome is that you'll fail, especially at the market adoption level. Being able to conduct your experiment at a lower cost is still a net positive, except for one point: having invested less, you are more likely to abandon the experiment early, because of the sunken costs fallacy. That doesn't necessarily need to be the case.
2. Developer velocity/productivity is something that you can demonstrate - as long as the difference is consistent, like, not 10% faster, but 80% faster. Other social/political concerns are a different thing, but really, gaining market adoption based only on those is VERY difficult - if that wasn't the case, I don't think we would be having this discussion at all, because Firefox would have a much higher penetration.
So, the point is, how is having a completely separate codebase going to help with having success? It could attract a higher number of idealistic developers, but the additional work required is very likely to negate that advantage.
Rust as a language was significantly less mature a few years ago; I think that's the bigger factor here.
It certainly doesn't hurt to do compelling things in Rust in a browser engine, but doing compelling things in Rust in some other project entirely would also be motivating.
To look at it from another angle, Mozilla itself had a reason to try to tackle some problems with Rust. It didn't need a competing browser engine using Rust in order to move forward with that plan. And the plan wasn't "well, we'll try this because we can somehow fall back on a competing engine if this doesn't work". So if your argument were true, I don't see how Mozilla could have moved on this either.
In the end people do things because the potential benefit justifies the costs and risks, and having a competitor do something is not the only way of determining potential benefit.
Would Google consider using Play Ready on Windows instead of Widevine?
Widevine perf is worse on WIndows, because it's all software frame decoding, and because of that, doesn't support 1080p or 4k Netflix videos on Windows.
The same way you would convince any other browser vendor to do the same thing. Good luck with that. But let's not forget that Firefox, Opera, et al, are not going away and no one is forcing you to use Chrome or chromium and there probably won't be any real downside either.
As a web developer, why would I even care about that? I care more about whether it adheres to web standards; or in the absence of a standard, whether it is in-line with other leading browsers.
If all of our leading browsers use the same engine, the answer to that is one and the same.
I mean, I get the point you're trying to make, but the argument doesn't really fit with what I'm saying. As far as I'm concerned go ahead and rewrite Blink in Rust or Go or Common Lisp. As long as it is the main engine, or adheres to the web standards, it really makes no difference to me.
I generally agree with your sentiment on this. The only real downside I can think of is similar to the issues that motivated the renewed investment in OpenBGPD recently: that standards and ecosystems are made stronger when there is some level of competition and diversity.
For example, a security bug in chromium becomes vastly more dangerous if everyone is working off that code. That said, hopefully there’ll be fewer of those because everyone is focused on the same codebase.
The questions seem to be “how many browser engine implementations is truly necessary for a healthy ecosystem?” And “has the spec gotten so bad that it’s not feasible for the ecosystem to support a sufficient number of independent implementations?”
Seems like <5, and maybe <3 is the answer to the first, and the answer to the second is we’ll see what happens to servo in 2019...
I assume this is a big incentive to improve those lines and Amazon will hopefully lobby for such. Similar to their support for public transportation in Seattle.
Office Fabric React has some good React + TypeScript code that has good testing which is very necessary with the level of commit activity into a shared component library.
I think it makes it more concrete to have actual victims talking about specifics of their incidents and then applying those to the bigger picture. A hashtag movement is much more abstract and harder for readers to connect to, which would be less powerful and do a lesser job of getting the message across.
