Chrome is the new IE
medium.com
medium.com
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.
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.
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...
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.
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.
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.
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.
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".
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.
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.
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.
Half of which plain don’t work, and the other half work on mobile only in onClick handlers.
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).
Oh, so Safari then?
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.
1. Were engaging in anti-competitive behavior.
2. Had an effective monopoly.
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.
(Or are you suggesting that some competitor will write a browser in JavaScript, which be disallowed from the appstore.)
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.
> iOS where chrome is available
That is a chrome shell for the safari engine. Not actual chrome.
Similarly, iOS Firefox.
While it's great to have some choice, from a developer's point of view these browsers aren't especially interesting.
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 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.
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.
> 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...
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".
The author should come back when Safari fixes some of its blatant issues/missing features that directly impact being able to improve UX.
> 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.
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.
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).
The article is for some reason ignoring all but two browsers.
It's interesting that the things he lists as Safari having only work via a -webkit vendor prefix.
So while Chrome might does have quirks and issues, the frequent update cycle compensates for it.