131–140 of 326 posts
Competition is good. Nobody wants to be left behind by Google, so time for Apple and MS to step it up again.
That's an interesting way of looking at it. Apple no longer get a free ride. On the other hand, now that Firefox is using WebKit perhaps Mozilla just replaces Google there.
Earlier quoted context omitted.
I, for one, can't wait to cut 20% of the code in my stylesheets.
In the meantime, you can use LESS mixins to reduce duplication. This library is pretty handy: http://lesselements.com/
So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…
Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…
So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…
Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…
> Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day
"tree-gardening"?
Can someone explain this benefit: > Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day "tree-gardening"?
So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…
Apple's current commit approval policies appear to be fairly hostile to non-Apple developers and users of WebKit, and especially to non-Apple users of WebKit2. They now reserve the right to break builds on non-Apple platforms randomly and delay patches to fix them, amongst other things.
So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…
Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…
I don't know all the history here, but my understanding is that Chrome's engine was never offered in that same sort of way. It was just part of the chromium project, apparently a part that increased the difficulty of integrating with WebKit, not an api intended to be taken by others and integrated into their browser.
Earlier quoted context omitted.
Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…
Sincerely curious: why are you still a full-time Safari user in light of all those complaints?
That being said, I do like the way Safari "feels" a lot more than Chrome. I think Chrome is actually quite ugly, and bad from a UI perspective. For example, Safari's overflow tab menu is a much nicer solution than Chrome's insistence on shrinking tabs ever smaller until you can't tell them apart at all.
Additionally Chrome is missing a killer feature I use all the time: zoom, and more specifically, double tap to zoom. I find it hard to read a lot of text on websites, and double tap, centered, zoom, is amazing. Its too bad everything else feels like its gotten way worse in the last 5 or so years.
So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…
Actually, they didn't say that the pain of maintaining their own work was too much of a burden, they said the pain of maintaining their model within the constraints and obligations WebKit had was too much of a burden (and, imposed too much of a burden on WebKit with regard to what WebKit wanted to do), so they decided fork so that WebKit can do what it wants to do without worrying about Chrome while Blink does what is needed for Chrome without worrying about WebKit.
> Why can't Chrome implement WebKit 2?
Implementing WebKit 2 wouldn't solve the problem going forward. Changes to WebKit to serve Chrome's needs would still have to meet all of the commitments WebKit has, and Chrome would still be placing demands on WebKit.
> This seems like a failure of open source.
Forking isn't failure. The purpose of open source isn't to create a monoculture, it is to enable groups to share effort when they have common goals, and to allow groups with divergent goals (including where those goals diverged after a period of shared work) to continue to benefit from the shared work without having to start back at square one. This is a success of open source.