Chrome is the new IE(medium.com)
medium.com
Chrome is the new IE
https://medium.com/@bdc/chrome-is-the-new-ie-1a21c1efc133#.3uae32q82
83 comments
Can't agree with this. Safari definitely tends to lag behind the other browsers in terms of implementing more recent standards, but that's just nothing like the situation was back in IE 6 times.
Have you ever tried to embed a webm into a webpage? iOS devices will hide the website then play the video in full-screen.
That's likely because the iPhone is so low resolution at only a 750p screen (640p for the iPhone SE/5/5s). If you're browsing in portrait, it can't even fit a 16x9 480p video without scaling it down.
In fairness, wouldn’t that have less to do with custom behavior and more to do with the limited size of a phone’s screen? Seems that Apple is just trying to avoid ridiculous scaling and making a reasonable judgment call.
In fairness, wouldn’t that have less to do with custom behavior and more to do with the limited size of a phone’s screen?
As someone who builds a video-based site often used on mobile devices: I don’t think that really matters. Not all sites using HTML5 video elements are just wrapping a single video in a player and some supporting content, the way you see on sites like YouTube or Vimeo. There are numerous applications for video where that content is integrated with other content on the page and not the only star of the show. There are standards for how HTML elements are supposed to work, and work together. And Apple is completely ignoring those standards in this case, which makes it literally impossible to provide the kinds of presentation styles and UIs we should be able to for visitors using iPhones.
As someone who builds a video-based site often used on mobile devices: I don’t think that really matters. Not all sites using HTML5 video elements are just wrapping a single video in a player and some supporting content, the way you see on sites like YouTube or Vimeo. There are numerous applications for video where that content is integrated with other content on the page and not the only star of the show. There are standards for how HTML elements are supposed to work, and work together. And Apple is completely ignoring those standards in this case, which makes it literally impossible to provide the kinds of presentation styles and UIs we should be able to for visitors using iPhones.
My $30 Windows Phone plays 720p <video> elements I've embedded in websites as a background flawlessly. Safari Mobile screws with the standard [1]. (The argument for preserving bandwidth is moot, you shouldn't mess with the standard. It even adds a giant play button on the video and allows clicking to play it, as if pausing wasn't bad enough.)
On another note, IMO, Safari has the worst support for printing webpage elements to scale. IE 9 is actually great for printing support. Browsers suck at this in general -- have you tried printing a 2cm square (in the physical world) cross browser and page size? Really difficult.
Not to mention as the article says, support for IndexedDB that isn't completely broken and Workers.
It seems like every time I create a webpage or webapp I have to fix it on Safari. These are just a few annoying examples I've encountered in day-to-day work.
IMO, a larger problem with Chrome is it randomly regressing and breaking crap before fixing it in the next release.
[1] http://stackoverflow.com/questions/12496144/can-you-autoplay...
On another note, IMO, Safari has the worst support for printing webpage elements to scale. IE 9 is actually great for printing support. Browsers suck at this in general -- have you tried printing a 2cm square (in the physical world) cross browser and page size? Really difficult.
Not to mention as the article says, support for IndexedDB that isn't completely broken and Workers.
It seems like every time I create a webpage or webapp I have to fix it on Safari. These are just a few annoying examples I've encountered in day-to-day work.
IMO, a larger problem with Chrome is it randomly regressing and breaking crap before fixing it in the next release.
[1] http://stackoverflow.com/questions/12496144/can-you-autoplay...
Actually I am very happy Safari Mobile does not support autoplay. I have disabled it on my desktop Firefox as well.
In a perfect world, it would be a valuable feature. In a world governed by the attention economy, it invites abuse. If I wanted to have websites come on all blaring sound at full volume and distract me with video playing, I'd buy an $50 Android tablet.
In a perfect world, it would be a valuable feature. In a world governed by the attention economy, it invites abuse. If I wanted to have websites come on all blaring sound at full volume and distract me with video playing, I'd buy an $50 Android tablet.
It's unreasonable since <video> is a standard embedded media tag from w3c. If the user wants to see the video in full-screen they can click the full-screen icon in the player.
IIRC for a while apple wasn't even letting native apps use their own video player chrome. Considering how awful the experience of using embedded video players is on android (on chrome and Firefox mobile at least), I'm not surprised apple decided it would be better for users to force an actually OK video player. It has its disadvantages I'm sure, like when webms are used as animated gif substitutes. But on android I have to go through extra steps to use an external video player.
Even on desktop I use a youtube-dl/mpv setup to watch web videos in an external player.
If that's the worst spec violation example you can come up with then your argument is weak.
Even on desktop I use a youtube-dl/mpv setup to watch web videos in an external player.
If that's the worst spec violation example you can come up with then your argument is weak.
And have you ever tried doing that in Chrome? You can’t even control the video from JS, and sometimes it chooses to show it in fullscreen, sometimes it chooses to show it inline.
> but that's just nothing like the situation was back in IE 6 times.
Agreed, but if the author says "Chrome is the new IE6", which is a hyperbole, then saying that Safari is much more "like" IE6 than Chrome makes sense as a response.
Agreed, but if the author says "Chrome is the new IE6", which is a hyperbole, then saying that Safari is much more "like" IE6 than Chrome makes sense as a response.
IE 11 is the new IE 6.
[deleted]
I'm a full time engineer on the web and I don't really agree with this. I much prefer working with Chrome than any other browser. Even IE edge (supposedly Microsoft's fresh start) doesn't have all the full support for various features as Chrome does -- just head over to look at the comparison tables at caniuse (ex: http://caniuse.com/#search=blend-mode).
And the developer experience in other browsers (save for maybe Firefox) are vastly inferior to Chrome's dev tools. Firebug in firefox used to be the best, but even with Mozilla's new efforts at the developer edition of Firefox, the experience is still poor. Lack of correct support for sourcemaps, performance, and general UI polish of their tools are still lacking.
Another point I feel should be made is that IE still doesn't have a native Max OS or Linux release. This is an embarrassment to Microsoft, and its why I still don't take anything they do seriously on the web. If you're going to create a new browser, you should at least make it accessible to most of the devs -- many of whom don't even use your OS anymore.
Chrome also has a few very useful projects, such as Chromium, node webkit and Electron (what slack uses). Where is this kind of support from the other browser vendors? Why doesn't Apple have a fully integrated native browser development envrionment for Safari? Why did Mozilla's FireFox OS die on the vine and why haven't they come up with something like Electron? The executives and senior technical leadership at these projects and companies should be embarrassed.
And the developer experience in other browsers (save for maybe Firefox) are vastly inferior to Chrome's dev tools. Firebug in firefox used to be the best, but even with Mozilla's new efforts at the developer edition of Firefox, the experience is still poor. Lack of correct support for sourcemaps, performance, and general UI polish of their tools are still lacking.
Another point I feel should be made is that IE still doesn't have a native Max OS or Linux release. This is an embarrassment to Microsoft, and its why I still don't take anything they do seriously on the web. If you're going to create a new browser, you should at least make it accessible to most of the devs -- many of whom don't even use your OS anymore.
Chrome also has a few very useful projects, such as Chromium, node webkit and Electron (what slack uses). Where is this kind of support from the other browser vendors? Why doesn't Apple have a fully integrated native browser development envrionment for Safari? Why did Mozilla's FireFox OS die on the vine and why haven't they come up with something like Electron? The executives and senior technical leadership at these projects and companies should be embarrassed.
> Why did Mozilla's FireFox OS die on the vine and why haven't they come up with something like Electron? The executives and senior technical leadership at these projects and companies should be embarrassed.
That's more than a little hyperbolic, given that Electron and node-webkit aren't Google projects and are in fact coded to an API Google explicitly considers unstable and liable to break at any time.
Disclaimer: I'm probably included in the group of people you claim "should be embarrassed".
That's more than a little hyperbolic, given that Electron and node-webkit aren't Google projects and are in fact coded to an API Google explicitly considers unstable and liable to break at any time.
Disclaimer: I'm probably included in the group of people you claim "should be embarrassed".
When last I was looking into this, Chrome's embed API is much better documented and supported than Gecko's. It seems that the Gecko API that does exist is largely due to the efforts the Sailfish OS / Jolly people put into it. Hopefully servo doesn't follow the same path. I'm hoping to be able to get into that code base soon-ish. :)
> When last I was looking into this, Chrome's embed API is much better documented and supported than Gecko's.
Sure, but WebKit2 is better than both, as only WebKit2 is a stable API that is C-based and can be used from multiple languages [1].
> Hopefully servo doesn't follow the same path.
Proper embedding support, with a supported API, is a key goal of Servo.
[1]: https://trac.webkit.org/wiki/WebKit2
Sure, but WebKit2 is better than both, as only WebKit2 is a stable API that is C-based and can be used from multiple languages [1].
> Hopefully servo doesn't follow the same path.
Proper embedding support, with a supported API, is a key goal of Servo.
[1]: https://trac.webkit.org/wiki/WebKit2
It's great to hear Servo is focusing on embedding support. The developers seems pretty responsive to feedback as well, which is great. Thanks for the info on webkit, need to follow up on it.
> doesn't have all the full support for various features as Chrome does
But isn’t that exactly what IE did?
Embrace the standards,
Extend the standards with their custom things – be they ActiveX, Silverlight, or NaCl
Extinguish the competition.
But isn’t that exactly what IE did?
Embrace the standards,
Extend the standards with their custom things – be they ActiveX, Silverlight, or NaCl
Extinguish the competition.
Yeah? And what "custom extensions" does Chrome push? NaCl is almost dead, to be replaced by the standard WebAssembly. Everything else is a standard ES2015 spec that Chrome, Edge, and Firefox have implemented (to varying degrees) and Safari has thus far failed to implement.
Chrome pretty significantly jumped the gun on shipping Shadow DOM and other Custom Element features unprefixed and on by default two years ago while there were significant outstanding objections from other vendors and no stable spec. We're only just now digging out from that mess.
> Chrome pretty significantly jumped the gun on shipping Shadow DOM
The Atom editor uses shadow dom because Atom is chrome-only. I don't know what is going to happen now that it is deprecated. I see warnings to not use it in the dev console every time I start Atom.
The Atom editor uses shadow dom because Atom is chrome-only. I don't know what is going to happen now that it is deprecated. I see warnings to not use it in the dev console every time I start Atom.
[deleted]
The only objections I remember hearing were from Apple. And implementing something that is in the standardization process with the TC39 still doesn't strike me as "custom extensions".
Dart? They pushed that one reasonably hard until the writing was on the wall.
Was dart ever part of chrome? I didn't follow that closely, seemed like a separate effort from Google.
Dart never shipped to mainline chrome. Developers could download a special version of chrome with Dart.
Additionally, there was the aborted upstream WebKit effort to allow abstraction over multiple languages with the goal of supporting Dart, and the Oilpan effort had Dart support as a major motivation.
Their custom behaviour in the JS apis for HtmlMediaElement come to mind.
Half of which plain don’t work, and the other half work on mobile only in onClick handlers.
Half of which plain don’t work, and the other half work on mobile only in onClick handlers.
That's one hell of a clickbait title. In order for any browser to be "the new IE", developers would have to hate it and dread developing for it/supporting it. Ask any web developer today which browser is their favourite, go-to browser for development. This statement holds absolutely no water.
Secondly, the author cherry picks a couple things that haven't been implemented in Chrome, glossing over the fact that Chrome tends to support way more features than any other browser on the market, and is more often than not the first and the best implementor of web standards. A quick perusal of caniuse.com or the support matrices on MDN will drive this point home (honourable mention to Firefox).
Secondly, the author cherry picks a couple things that haven't been implemented in Chrome, glossing over the fact that Chrome tends to support way more features than any other browser on the market, and is more often than not the first and the best implementor of web standards. A quick perusal of caniuse.com or the support matrices on MDN will drive this point home (honourable mention to Firefox).
> In order for any browser to be "the new IE", developers would have to hate it and dread developing for it/supporting it.
Oh, so Safari then?
Oh, so Safari then?
"Chrome is unfortunately contributing to the web’s bad reputation by caring more about developers than end-users."
Actually, this is my favourite part about it. It's fast and it has its priorities in the right spot: me, as a developer. If you don't like Chrome, well, then don't use Chrome :)
Another point I would like to make is Apple's ridiculous refusal to allow anything other than Safari on the App Store. I feel that this is holding back the web more than anything, at the moment.
Actually, this is my favourite part about it. It's fast and it has its priorities in the right spot: me, as a developer. If you don't like Chrome, well, then don't use Chrome :)
Another point I would like to make is Apple's ridiculous refusal to allow anything other than Safari on the App Store. I feel that this is holding back the web more than anything, at the moment.
Hows is refusing anything other than Safari legal when Mirosoft got done for pre-installing IE on its OS? They didn't stop any other browsers being installed.
Microsoft got in trouble because they:
1. Were engaging in anti-competitive behavior.
2. Had an effective monopoly.
MS had a de-facto monopoly on the desktop at the time and got in trouble for abusing that position. Apple, optimistically, has around half of the US smartphone market and maybe like 10% of the global market. Apple can't remove consumer choice from the entire market when there's Android stuff which is functionally very similar, readily available, and usually cheaper.
How do you feel about Google disallowing anything other than Chrome on their desktop OS?
To be honest, this isn't true.
Chrome Packaged Apps allow developers to build alternative browsers using Native Client.
Just no one has bothered to do so because it wouldn't make much of an impact, plus alternate browsers wouldn't be able to set themselves as the default browser.
Chrome Packaged Apps allow developers to build alternative browsers using Native Client.
Just no one has bothered to do so because it wouldn't make much of an impact, plus alternate browsers wouldn't be able to set themselves as the default browser.
Wha?? That's not the same thing at all. ChromeOS is basically a browser, and ChromeOS applications are basically webapps.
(Or are you suggesting that some competitor will write a browser in JavaScript, which be disallowed from the appstore.)
(Or are you suggesting that some competitor will write a browser in JavaScript, which be disallowed from the appstore.)
That's not really fair, in the case of ChromeOS, the browser is the OS.
And honestly, this is why people say Chrome is slow or Chrome is a memory hog. There's so much non-web-browser stuff in Chrome it's just become tremendously heavy. That doesn't make it bad, and Google has recently done things to lighten it (like removing the feature of mirroring Now cards in Chrome), but it's the truth.
> I feel that this is holding back the web more than anything, at the moment.
Perhaps a little exaggerated? Sure, it'd be nice if Apple were a little more welcoming to products from other vendors that are in the same market as their own but personally I feel isn't such a big deal in the grand scheme of things.
If the MAS was the only way to get software on Apple computers (as the app store on is on iOS where chrome is available) it'd be another matter.
Perhaps a little exaggerated? Sure, it'd be nice if Apple were a little more welcoming to products from other vendors that are in the same market as their own but personally I feel isn't such a big deal in the grand scheme of things.
If the MAS was the only way to get software on Apple computers (as the app store on is on iOS where chrome is available) it'd be another matter.
Apple's not exactly in the browser market. It's not competition to anything they sell.
> iOS where chrome is available
That is a chrome shell for the safari engine. Not actual chrome.
> iOS where chrome is available
That is a chrome shell for the safari engine. Not actual chrome.
iOS Chrome doesn't use the Blink renderer.
Similarly, iOS Firefox.
While it's great to have some choice, from a developer's point of view these browsers aren't especially interesting.
Similarly, iOS Firefox.
While it's great to have some choice, from a developer's point of view these browsers aren't especially interesting.
There are legitimate reasons for not allowing non-webkit browsers. The biggest one that comes to mind is security; because of the vast complexity of web engines, the moment Apple allows a third party engine in is also the moment that they can no longer keep control of web-based holes. The security of millions of handsets, many of which belong to individuals with zero tech savvy, suddenly falls into the hands of third parties. This is a serious problem.
The other problem is that given their track record on the desktop, Google and Mozilla are highly unlikely to prioritize battery life the way Apple does, and if Chrome or Firefox cuts into someone's battery in a big way they're more likely to point fingers at iOS and Apple than at third party vendors. It's the same problem that Flash on iOS presented except not quite as severe.
The other problem is that given their track record on the desktop, Google and Mozilla are highly unlikely to prioritize battery life the way Apple does, and if Chrome or Firefox cuts into someone's battery in a big way they're more likely to point fingers at iOS and Apple than at third party vendors. It's the same problem that Flash on iOS presented except not quite as severe.
Other app stores like Google Play don't prohibit third party browsers
There's also a crap ton of malware on the Play store
A response from a Google engineer working on Chrome: https://medium.com/@slightlylate/cards-on-the-table-i-m-an-e...
Great response. A couple key points:
-The author was comparing an unreleased version of Safari to Chrome Stable. Comparing stable-to-stable would be more fair, and when comparing the unreleased Safari to Chrome Dev or Canary, some of their complaints are moot.
-Apple only has to support 2 platforms and a limited amount of hardware. Google supports 4+ platforms and a huge variety of hardware. That means things like GPU rasterization take longer to ship.
-The author was comparing an unreleased version of Safari to Chrome Stable. Comparing stable-to-stable would be more fair, and when comparing the unreleased Safari to Chrome Dev or Canary, some of their complaints are moot.
-Apple only has to support 2 platforms and a limited amount of hardware. Google supports 4+ platforms and a huge variety of hardware. That means things like GPU rasterization take longer to ship.
Apple has to support 4 different GPU manufacturers, in fact. And Chrome isn't using the native Direct2D on Windows, which would have made this easier: rather they chose to reinvent it with Ganesh. Ganesh is OpenGL only (also Vulkan) instead of using native Direct3D. I don't think the cross-platform burden is that much higher for Chrome in this specific area.
That's hardly accurate summary of the situation.
Chrome uses Skia, a 2D rendering library.
Skia uses Direct2D (DirectWrite) on Windows for font rendering (https://github.com/google/skia/blob/master/src/ports/SkTypef...)
Skia has a GPU backend that uses OpenGL where that's native.
On Windows, those OpenGL calls are translated to DirectX with a very sophisticated OpenGL translator called Angle (https://github.com/google/skia/blob/master/gyp/angle.gyp)
Therefore Chrome does use DirectX on Windows, via translation layer from OpenGL.
Saying that Chrome i.e. in this context Skia, doesn't use Direct2D for rendering is like saying "On Windows Chrome doesn't use native Chakra JavaScript engine".
Skia IS Direct2D, except it's cross-platform and being improved by Google literally every day (https://github.com/google/skia/commits/master). It makes engineering sense for Google to have their own, cross-platform, high-performance 2d rendering engine instead of a thin layer of whatever the common-denominator they could implement on top of 2d functionality provided by the OS.
Chrome uses Skia, a 2D rendering library.
Skia uses Direct2D (DirectWrite) on Windows for font rendering (https://github.com/google/skia/blob/master/src/ports/SkTypef...)
Skia has a GPU backend that uses OpenGL where that's native.
On Windows, those OpenGL calls are translated to DirectX with a very sophisticated OpenGL translator called Angle (https://github.com/google/skia/blob/master/gyp/angle.gyp)
Therefore Chrome does use DirectX on Windows, via translation layer from OpenGL.
Saying that Chrome i.e. in this context Skia, doesn't use Direct2D for rendering is like saying "On Windows Chrome doesn't use native Chakra JavaScript engine".
Skia IS Direct2D, except it's cross-platform and being improved by Google literally every day (https://github.com/google/skia/commits/master). It makes engineering sense for Google to have their own, cross-platform, high-performance 2d rendering engine instead of a thin layer of whatever the common-denominator they could implement on top of 2d functionality provided by the OS.
I wasn't aware of the use of DirectWrite, thanks.
> On Windows, those OpenGL calls are translated to DirectX with a very sophisticated OpenGL translator called Angle (https://github.com/google/skia/blob/master/gyp/angle.gyp)
I'm aware of that. But ANGLE can't possibly be better than Direct3D; in fact, it tends to lag behind new D3D releases for obvious reasons.
> Saying that Chrome i.e. in this context Skia, doesn't use Direct2D for rendering is like saying "On Windows Chrome doesn't use native Chakra JavaScript engine".
Yet that's still a true statement. And if Chakra were technically ahead of V8, then that would be a valid criticism of Chrome's choice here.
> It makes engineering sense for Google to have their own, cross-platform, high-performance 2d rendering engine instead of a thin layer of whatever the common-denominator they could implement on top of 2d functionality provided by the OS.
I don't think that's clear at all. Direct2D is very good for what it is (although neither Skia nor D2D is a good API for GPUs really, as NVIDIA and others have pointed out in for example [1]). There's no architectural advantage that Skia has over D2D; they both feature very similar immediate mode APIs. D2D is being improved by Microsoft all the time, with a multi-year head start on Ganesh and the advantage of tight integration with the graphics drivers. In fact, the entire point of Alex's post is to acknowledge that Ganesh's rollout has been slower than that of CG::OGL (Apple's Ganesh equivalent, which has been shipping in stable Safari for a while) and Direct2D (which has been shipping in IE since 9 and Firefox since 4).
[1]: http://developer.download.nvidia.com/devzone/devcenter/gameg...
> On Windows, those OpenGL calls are translated to DirectX with a very sophisticated OpenGL translator called Angle (https://github.com/google/skia/blob/master/gyp/angle.gyp)
I'm aware of that. But ANGLE can't possibly be better than Direct3D; in fact, it tends to lag behind new D3D releases for obvious reasons.
> Saying that Chrome i.e. in this context Skia, doesn't use Direct2D for rendering is like saying "On Windows Chrome doesn't use native Chakra JavaScript engine".
Yet that's still a true statement. And if Chakra were technically ahead of V8, then that would be a valid criticism of Chrome's choice here.
> It makes engineering sense for Google to have their own, cross-platform, high-performance 2d rendering engine instead of a thin layer of whatever the common-denominator they could implement on top of 2d functionality provided by the OS.
I don't think that's clear at all. Direct2D is very good for what it is (although neither Skia nor D2D is a good API for GPUs really, as NVIDIA and others have pointed out in for example [1]). There's no architectural advantage that Skia has over D2D; they both feature very similar immediate mode APIs. D2D is being improved by Microsoft all the time, with a multi-year head start on Ganesh and the advantage of tight integration with the graphics drivers. In fact, the entire point of Alex's post is to acknowledge that Ganesh's rollout has been slower than that of CG::OGL (Apple's Ganesh equivalent, which has been shipping in stable Safari for a while) and Direct2D (which has been shipping in IE since 9 and Firefox since 4).
[1]: http://developer.download.nvidia.com/devzone/devcenter/gameg...
This response is interesting. The engineer attempts to differentiate the philosophy behind chromes feature prioritization as being due to
their desire to implement features in a manner that conforms with the ideals behind the "extensible web" manifesto.
But there is a sense to which "extensible web" focused engineering is inherently at odds with a desire to contain browser complexity and to prioritize the security, performance, and stability of the average web site browsing experience across platforms.
My general experience with using the web these days (with any browser) is that on average sites I visit seem:
1. More broken 2. Slower 3. More invasive
There's definitely an extent to which this is "not browser makers fault, this is the fault of site developers" -- however to completely abdicate platform vendors responsibility and say that it's not a requirement for browser technology to solve is to (potentially) watch the whole web platform erode to the point where it is no longer sufficient to satisfy users needs. In a way it's balmer on stage chanting "developers developers developers" vs jobs in a drum circle meditating "users users users". Not that I necessarily think Safari is the best drum circle development example -- I'm more tempted by "brave".
But there is a sense to which "extensible web" focused engineering is inherently at odds with a desire to contain browser complexity and to prioritize the security, performance, and stability of the average web site browsing experience across platforms.
My general experience with using the web these days (with any browser) is that on average sites I visit seem:
1. More broken 2. Slower 3. More invasive
There's definitely an extent to which this is "not browser makers fault, this is the fault of site developers" -- however to completely abdicate platform vendors responsibility and say that it's not a requirement for browser technology to solve is to (potentially) watch the whole web platform erode to the point where it is no longer sufficient to satisfy users needs. In a way it's balmer on stage chanting "developers developers developers" vs jobs in a drum circle meditating "users users users". Not that I necessarily think Safari is the best drum circle development example -- I'm more tempted by "brave".
This is a pretty terrible article. It asserts the point that Google is doing a disservice by focusing on things that improve developer productivity, but doesn't even entertain the idea that reducing the overhead on more technical matters allow developers to focus more on UX.
The author should come back when Safari fixes some of its blatant issues/missing features that directly impact being able to improve UX.
The author should come back when Safari fixes some of its blatant issues/missing features that directly impact being able to improve UX.
Well the author is UI designer. I guess that says a lot.
Concerning web pages, HN seems to be split into two sides: one side wants to use the newest shiny stuff to make shiny apps while the other wants to have simple pages that are loading fast. The OP blatantly seems on the first side, and I am on the second one.
> The web deserves efficient, innovative, delightful experiences, and Chrome is holding the web back by making it hard (if not impossible) to create them.
Nope, the web deserves pages that are loading fast, and don't require a new hardware that the majority of the viewers don't have to be read properly.
Also, OP works at Stripe, I see no need to add "position:sticky", "backdrop-filter", or "scroll-snap-type" (not sure I know what those are) to a page that does payment processing.
> The web deserves efficient, innovative, delightful experiences, and Chrome is holding the web back by making it hard (if not impossible) to create them.
Nope, the web deserves pages that are loading fast, and don't require a new hardware that the majority of the viewers don't have to be read properly.
Also, OP works at Stripe, I see no need to add "position:sticky", "backdrop-filter", or "scroll-snap-type" (not sure I know what those are) to a page that does payment processing.
On any platform other than iOS, Safari is the 3rd best browser on its best day. Just because something is pretty, doesn't make it good. This guy is clearly a student of the Jony Ive school of thought.
> Just because something is pretty, doesn't make it good.
I understand that you are taking a shot a Apple's focus on design, but what part of Safari makes you think they sacrificed function for form?
If you don't like Safari then give some detailed insight on why that is. A comment like that would move the discussion forward and be interesting.
I understand that you are taking a shot a Apple's focus on design, but what part of Safari makes you think they sacrificed function for form?
If you don't like Safari then give some detailed insight on why that is. A comment like that would move the discussion forward and be interesting.
Chrome on OS X destroys my battery so I use Safari, no matter how much new shiny Chrome supports. 3rd best by what measure?
The "Safari is the new IE" article was about them being slow to adopt APIs and the yearly release cycle attached to OS updates.
This is about visuals and UI based APIs that can be polyfilled. They matter but not as much as stuff like WebRTC and Service Workers IMO.
Google can fix these problems with updates and polyfills. Apple can't do that. Some iOS and Mac OS users will at some point be left out.
Nothing in this article matter that much "position:sticky, no backdrop-filter, no scroll-snap-type, gradients" they're useful, but not critical.
Doubt we'll see apps that aren't possible without these. They just make the experience nicer, they don't make products happen though.
Meanwhile on the Chrome end we've got web apps like Emojoy (https://jakearchibald-gcm.appspot.com/), Offline Wikipedia (https://wiki-offline.jakearchibald.com/), Instant.io (https://instant.io/), PeerCloud (https://peercloud.io/) and even Facebook (http://Facebook.com/) all providing features and services in Chrome (WebRTC, Service Workers, Background Sync) that can't be polyfilled or will have to provide a far lesser experience in Safari because it lacks even a way to polyfill these features (only things I can think of are AppCache and WebSockets which don't get the job done for these services).
This is about visuals and UI based APIs that can be polyfilled. They matter but not as much as stuff like WebRTC and Service Workers IMO.
Google can fix these problems with updates and polyfills. Apple can't do that. Some iOS and Mac OS users will at some point be left out.
Nothing in this article matter that much "position:sticky, no backdrop-filter, no scroll-snap-type, gradients" they're useful, but not critical.
Doubt we'll see apps that aren't possible without these. They just make the experience nicer, they don't make products happen though.
Meanwhile on the Chrome end we've got web apps like Emojoy (https://jakearchibald-gcm.appspot.com/), Offline Wikipedia (https://wiki-offline.jakearchibald.com/), Instant.io (https://instant.io/), PeerCloud (https://peercloud.io/) and even Facebook (http://Facebook.com/) all providing features and services in Chrome (WebRTC, Service Workers, Background Sync) that can't be polyfilled or will have to provide a far lesser experience in Safari because it lacks even a way to polyfill these features (only things I can think of are AppCache and WebSockets which don't get the job done for these services).
Chrome as the new IE seems like a stretch without mentioning Firefox.
Firefox can't be the new IE. It doesn't have the market share that IE did, even still does, have.
Sorry you misunderstand me. I didn't mean that Firefox is the new IE, but rather that it's difficult for anything to be the new IE, because of the choice now available. Chrome, Firefox, IE, and safari all now have reasonable market share.
The article is for some reason ignoring all but two browsers.
The article is for some reason ignoring all but two browsers.
Chrome is the "new IE" but for a whole different set of reasons than what the author mentions in the piece. It seems that a lot of designers aren't testing their designs against other browsers other than Chrome. I routinely find pieces of web pages that don't look (or work) as they are supposed to but they work once I perform the same action in Chrome. It's ridiculous.
I struggle to think of how an article could be more wrong. It's just nonsense. All browsers - Chrome, Safari, IE/Edge and Firefox are constantly adding new features, improving performance, and fixing bugs. Obviously they have different priorities, but this is just nothing like the age of IE.
I find it interesting that the author himself accepts (or doesn't oppose, to be more correct) that the title is linkbait[0].
[0]: https://twitter.com/bdc/status/626200664520044544
[0]: https://twitter.com/bdc/status/626200664520044544
A more buttery web doesn't necessarily equate to a more bettery web ;P
>Mobile Safari can easily handle, say, a Photos.app-like interface with a translucent navigation bar, native-like swipe gestures and smooth animations. Chrome handles none of this. No position:sticky, no backdrop-filter, no scroll-snap-type
It's interesting that the things he lists as Safari having only work via a -webkit vendor prefix.
It's interesting that the things he lists as Safari having only work via a -webkit vendor prefix.
These features are all standards track but not final, much like the features that people praise Chrome for having that are not in Safari. Chrome's policy is not to prefix when they ship a feature to everyone, even if the spec is not finalized yet. Safari's policy has been to prefix in such a situation but there is consideration of changing it.
One big problem I had with IE was the update cycle. Whereas Chrome (and subsequently other browsers) updated every six weeks or so, non-technical Windows users just had whatever the OS installed by default, e.g. IE6, etc.
So while Chrome might does have quirks and issues, the frequent update cycle compensates for it.
So while Chrome might does have quirks and issues, the frequent update cycle compensates for it.
Browser monocultures are bad.
The author should read the response from Chrome.
Just two web browsers, surely some mistake
Hell yeah!!
Safari is the new IE to me, and he reinforces my point.
His example is that Safari opts not to implement web standards in favor of those things that make Apple specific websites better.
This is the exact behavior that created the stimga of Microsoft's IE. We need more standards and collaboration and less browser vendors working to create their own specific experiences.