Safari is worse than IE, however. You could install an alternative.
Even if they weren't, I fully agree with progressive enhancement. It is always going to provide the right incentives for everyone. Only the features most used (by end-users) will become browser vendors' utmost priority.
The iOS version of Chrome doesn't use Chrome's rendering and JavaScript engines though, per the App Store rules it has to use WebKit [0]. So, any other browser app on iOS would have the same problems as mobile Safari.
Yea, I just really like that I can access all of my open tabs with it. It also context switches better with iOS outlook if you click on links you can quickly go back to outlook.
Not quite my area of expertise, but I believe that browsers on Android also tend to use the core Android browser components though they can dress them up slightly differently.
Browsers on Android are not required to use Android's built in WebViews. And several alternative browser engines are offered by the platform[0].
Android has no specific restrictions in place. Although it is the path of least resistance to use the built in WebView, since you now don't need to deploy your own.
[0] Including: Blink (Amazon Silk, Chrome, Opera), WebKit (BlackBerry, Dolphin, et al), Gecko (Firefox, Minimo), NetFront (Blazer). At the moment WebKit derivatives seem to be most popular, but several browsers re-build it from the source rather than just using Android's WebKit components.
> ...I believe that browsers on Android also tend to use...
The word 'also' doesn't belong here. Browsers on iOS don't tend to use core iOS components (WebView) : they are forced to. Your statement really isn't a counter point.
On iOS, all 3rd-party browsers (and even the upcoming Firefox for iOS) are using the rendering engine of Safari. The complaint is not about Safari the browser but more about its rendering engine.
Agreed. However, it still has the best perceived performance. Just open a page with a heavy layout and scroll up and down, or type an address or search term in the location bar and "feel" how fast it loads. Apple really put some effort in making it "feel" extremely fast.
I agree except for the back button. I hate how swiping to go back takes you back to a screenshot temporarily while the page reloads. I attempt to scroll up and down and interact with the screenshot until suddenly the page isn't how I remember it due to the reload.
It's such a terrible, terrible design and I check every new version in hopes that this would be addressed.
I really like this feature. A page redraw generally takes less time than the time needed for my eyes and brain to re-parse the page. When I have to stare at a blank page for a varying amount of time after having decided to go back, the entire navigation process feels very sluggish and slow. Using other browsers I find myself opening a lot more temporary tabs to account for this. Swipe and hold is also nice when you just need to go back to reread a few sentences, etc.
Most pages shouldn't need a refresh when you go back after a few seconds or minutes. What annoys me are websites that set stupid expiry times or Cache-Control values.
I use Safari daily as my primary browser on desktop. I don't doubt it presents challenges for developers, and hope they update faster.
But, not only is it fast on OS X, the battery life optimization is amazing. I run Safari without Flash installed, and only need to pop over to Chrome once and a while.
I've come to understand Chrome is making more power consumption adjustments in it's OS X version, and look forward to seeing if it can compare, but I'd also like to see memory usage addressed.
But for me, Safari loads everything I need, save for the odd video that is only available in flash, which now happens very rarely. And for me being able to use the web browser for hours and hours each day without a similar hit from Chrome to both power and memory is worth it for me.
Chrome is bloated and inefficient; even if it's not doing power-saving CPU scheduling. The "one process per tab" model seems great, but it allows Google to ignore performance problems in the browser and push them off to the page itself. That said, Google is a lot more active in pushing the envelope of browser development, so even though I personally stopped using Chrome, I still appreciate the work Google is doing on it.
Totally agree with the speed of Safari. I have Flash enabled, albeit with a plugin that forces click-to-load. Safari is a lot faster than Chrome at this point; it just feels more like the fast, stripped-down browser that I want.
Apple has stopped supporting Safari on Windows. SO yes, you are using Safari 5.0, from over 2 and a half years ago...of course every other browser will beat it.
However, [Safari] still has the best perceived performance.
Just open a page with a heavy layout and scroll up and
down, or type an address or search term in the location
bar and "feel" how fast it loads.
The performance gap is particularly noticeable on older Macs. Safari feels about the same as other browsers on my recent Mac... but there's a big gap in responsiveness between Safari and the other browsers on my wife's 2009-ish Core 2 Duo. [Edit: I mean that Safari is much more responsive than Chrome or FF]
This doesn't excuse Apple dragging their feet on web standards, of course.
It's just puzzling. Clearly Apple puts a lot of work into Safari. It's not the bastard child that IE was at Microsoft... recall how the IE team was disbanded after IE6 at one point.
And yet, frustratingly, Apple doesn't support modern web standards despite allocating a healthy slice of developer resources to Safari.
Its in Apple's interest to not have Safari work well on older machines (since they want people to buy new machines), or improve it in ways that would make the browser better compete against the app store (especially on mobile).
It is in their interest to have it be a very nice looking document viewing platform, which is where I imagine most of their developer resources are going towards.
Its in Apple's interest to not have Safari work well
on older machines (since they want people to buy new
machines)
Then they're failing miserably, because as I (and others in this conversation) have attested to... Safari is noticeably faster than Firefox or Chrome on older Mac hardware.
So I don't think your theory holds any water. Sorry.
(Edit: My post was unclear. I and others feel that Safari, despite its other shortcomings, is the most responsive browser on OSX - not the least.)
I think he interpreted your post as being the opposite of what you meant it to say. You said the performance gap is more noticeable but you probably mean in favor of safari, although it could be interpreted either way.
I did, and I should have read it more carefully. That being said, I think there is a balance that Apple tries to maintain here. If there experience on older systems is terrible, they run the risk of people switching to a different operating system and platform. If the experience isn't significantly better on newer hardware, however, customers won't be motivated to upgrade.
I would definitely not attribute it to any purposeful attempt at by a company to make things worse for older systems... human beings developing software on new hardware is already enough to make performance issues happen.
In reality, if the lead developers of some software find the experience to be good enough on their machines, that's going to lead to it becoming worse on old hardware, no matter what the company (as people have said in this thread, it's even worse with chrome and firefox.)
It takes huge amounts of effort to ensure that the development work you're doing is performant on a range of hardware. If you neglect doing that, I'd definitely chalk it up to laziness and not malice.
(In other words, I agree that performance gets worse from version to version, but you don't need to attribute to malice that which can equally be attributed to laziness.)
I don't necessarily attribute it to malice either. Their interest in making money and being successful will motivate where they spend their development dollars in maintaining older software and keeping current customers happy on their older systems versus developing new features and software that will increase sales.
If there experience on older systems is terrible, they
run the risk of people switching to a different operating
system and platform. If the experience isn't significantly
better on newer hardware, however, customers won't be
motivated to upgrade.
I'm certain the main engineering goal they have for Safari is energy efficiency.
Battery life is one of the two or three major selling points of all their devices, and improved (or at least equivalent) battery life is something they deliver with every iteration of OSX.
I believe Safari's performance/responsiveness is largely a happy accidental byproduct of this focus on energy efficiency.
Again, I'm not defending anything they do. I'm a OSX user and Firefox is my browser of choice, if that tells you anything!
I don't find this puzzling at all. I think Apple wants Safari to be a great browser for the limited role they think the web should play.
They are putting a lot of work into making the browsing experience better on Safari, very successfully I think, but adding tons of features that could expand the role of the web as an applications platform is just not in their interest.
Safari still has some pretty glaring problems. Take going back, for example. Going back, it loads an image of the previous page before it actually loads the real page. This gives the perception that it's loaded immediately, but it's not really loaded. This means the page is not responsive. It also looks fuzzy, and you can see it's fake. It's horrible, and while it's intended to fake being fast, it only serves to remind me that it's not actually fast.
Then their is the problem with black boxes. I don't know why, but all to often, safari loads a page and there are black boxes on that page. Just covering up portions of the web page. I have to resize the window or do something to get Safari to rerender the page so it will go away. This happens frequently.
Couple this with all the other issues OSX has, I can't but make the assumption that Apple is focused on Quantity rather than Quality.
Of the 3 big browsers in Mac, Firefox is still, in my mind, the most solid. Safari suffers some serious problems, not the least of which is that it's only for Mac.
Is he talking about the iOS version? Because I don't think the desktop version's market share is big enough for developers to really care about it (unlike IE).
Apple wants to make the best experience for users because then they'll keep buying Apple products. If users want the web, then they make the browser better. If Apps are more appropriate, then they make apps better.
Apple prioritizes stuff users care about -- battery life > IndexedDB, accessibility > WebGL.
Until you understand this and stop thinking like a conspiracy theorist, you won't understand Apple and will keep confusing your priorities with user priorities.
Again: pleasing users -> profit. Making web lose -> ???
This isn't "embrace and extend" -- Microsoft added huge swathes of proprietary functionality to IE and tended (and tends) to prioritize developer and corporate IT desires over users. Insofar as Apple extends the browser, they do it through standards and proposed standards and (mostly) open source the implementations.
Apple wants to make the best experience for users while maintaining vendor lock-in.
iOS users invest hundreds of dollars in apps and games and enjoy exclusive products. This creates a very significant barrier to switch to another mobile platform.
Quite obviously increased switching costs for users are important for iOS to maintain leadership in platform wars.
Therefore, rapid advancement of web apps user experience to the level of native apps in some categories would be detrimental to Apple's competitive positions.
Making web lose -> stronger competitive advantage.
Making web lose -> make users unhappy in short (and probably long) term, damage Apple's reputation in long term
It's totally awesome how Google created its Play store so that it seamlessly works on competing platforms -- after all it's a largely open-source stack that would easily run on (say) iPhones. No wait, they use it as a bludgeon to keep third parties in line (and create vendor lock-in).
> Making web lose -> make users unhappy in short term
Sure, it decreases user satisfaction for a SUBSET of users, who care about web apps. This subset seems to be strategically negligible for Apple. This is a trade-off which is absolutely rational from the shareholders/management perspective.
>It's totally awesome how Google created its Play store so that it seamlessly works on competing platforms
Your fanboyism shows. This thread is not about Google, also a corporation which actions are driven by interests of management and shareholders.
But that argument can justify any deficiency in Safari, so it's unconvincing. Eventually you're just saying, "Apple don't care about all these new web things." Which is the point of TFA.
How so? Let's suppose Safari has some horrible bug in it that exposes users to malware or whatever. (And it has had from time to time and Apple has been rightly pilloried for some of these cases.) Tell me how saying that Apple would rather improve user experience than add developer-friendly features justifies this.
Different people will draw the line at different places. To you, the hypothetical malware vuln should be fixed before e.g. improving battery life by 5%. To some other user who is on a long plane journey without a power adapter and doesn't e.g. click on .flv links on specialty forums, maybe it shouldn't. But to a greedy fruit executive who wants the web to be insecure? There's no question! b^)
This thread explores the possibility that, for strategic reasons, new web stuff is not implemented on Safari. That proposition is scarcely undermined by hypothesizing a typical user who doesn't care about new web stuff as much as she cares about battery life. She's hypothetical, why should she care about anything as much as she cares about battery life?
Let's ignore the fact you didn't address my argument.
There are diminishing returns.
It's not like Apple has provided a web browser that basically doesn't work but has great battery life. Most people consider Safari to be the best mobile browsing experience there is. (I just googled to make sure I wasn't quoting outdated opinions and it's still true.)
Safari in 10.11 has added a feature which tells you which browser tab is making noise so you can close it. Just now I was so wishing for it (in Chrome -- which is my primary browser, since I'm a web developer). Shame on Apple for doing that and not fixing bugs in their IndexedDB implementation! (BTW those bugs are horrible -- how on earth could they pass the simplest unit tests? -- and really should be fixed.)
> To you, the hypothetical malware vuln should be fixed before e.g. improving battery life by 5%.
Apple doesn't let users decide what's best for them... that's one of the things that's different about the company. Want to customize your UI? Nope, that's silly, you can't have it. Apple would decide what's good for the user and it would probably consider browser vulnerabilities more important than some obscure new feature.
> But to a greedy fruit executive who wants the web to be insecure? There's no question!
Safari in 10.11 has added a feature which tells you which browser tab is making noise so you can close it. Just now I was so wishing for it (in Chrome -- which is my primary browser, since I'm a web developer).
That's great -- I didn't know because chrome doesn't display those things if the tab is narrower than the caption, and I usually have a lot of tabs open. Argh!
(Especially with the trend to wide-screens, the placement of tabs on the top vs. the left side seems to me to be a gigantic misstep on everyone's part)
Not trolling -- just ignorant. (And the implementation is kind of flawed. Sufficiently flawed that I've never seen one of the icons. I wonder if Safari's is any better -- can't be bothered installing the beta.)
Not a big fan of your "b^)" emoticon -- doesn't look like anything to me, and doesn't show up in lists of common emoticons. But OK your most outrageous comment was in jest; fair enough.
I have only one eye and wear a patch over my right socket. Also I have a pointy nose. A friend of mine suggested that smiley a long time ago, and I've used it since.
If Apple really wanted to make Web Apps feel like a second class citizen, they wouldn't be adding Force Touch, custom AirPlay control support and Picture In Picture support to the upcoming version of Safari. Those are deep, native app level features that aren't even Web standards yet.
I assume Apple is underinvesting in safari simply because they have bigger fish to fry, and they are notoriously understaffed with competent engineers (or have bad project management).
They're adding APIs that only benefit people using their hardware. Unless they open source AirPlay and whatever else they need to do for Force Touch I'm failing to see why I should be excited by that.
Which has been stated again and again, but was never an issue with Apple.
First because what they make from the App Store is spare change for them.
Second because they did have the best browser for a while, and did very much to advance the state of the art (from WebSQL, to Canvas, CSS 3D and other stuff, all originating there, along with the original fast-JITed JS engine who started the JS-race to what we have know). And they did that for years after they had an App platform available too.
Not much lock-in. Most apps are either cross platform or for casual use, and I could buy an Android phone and be productive tomorrow, transferring all my images, documents, contacts and such in a couple of hours.
People don't feel locked with their app purchases. Case in point, the large volumes of people going from Android to iOS and vice versa.
Curious where you are basing your revenue numbers from. Per Apple's reported statistics for 2014[1], developers pulled in $10 billion dollars in revenue from the app store. That means that Apple's revenue from the app store should also be in the low billions (based on the 70/30 cut they take from app store sales and purchases).
All without manufacturing logistics and hardware production costs. Obviously the computing infrastructure, payment processing and software engineering of the app store has a cost, but I'd imagine much less than those involved with building, distributing and selling a computer or mobile device.
It may not generate as much as hardware sales do, but billions of dollars hardly seems like spare change.
>That means that Apple's revenue from the app store should also be in the low billions (based on the 70/30 cut they take from app store sales and purchases).
That makes it around $3 billion, before taxes and infrastructure expenses, payment deals, etc.
$3 billion is spare change for Apple. They have 200 times than in cash.
Again you post information without any sources. A more accurate figure is $178 billion in cash at the beginning of this year.[1] That means they have around 59 times more than that amount in cash, not the 200 you claimed. Also, I think its telling that Apple themselves mentioned App Store Sales as a main factor in their revenue earnings for Q4 of their 2014 fiscal year. [2] What's important is how much of their total annual revenue and profits are derived from App Store sales, not how it compares to the amount of cash they have on hand.
As others have mentioned, there are other benefits from native applications, like vendor lock-in, which Apple isn't going to get with web-based applications.
>That means they have around 59 times more than that amount in cash, not the 200 you claimed
Still, same order of magnitude, and still many times over their app profit.
>Also, I think its telling that Apple themselves mentioned App Store Sales as a main factor in their revenue earnings for Q4 of their 2014 fiscal year.
I don't see how you can justify being off on your facts by 3-4 times by saying its still in the same order of magnitude. You overestimated their cash on hand by about 422 billion dollars. Again, I see the cash on hand as a weak argument. What really matters is how much annual revenue and profit it brings in. Apple is going to be concerned about anything that adds or takes away from their revenue in a significant way.
Its telling that App Store sales are a significant source of revenue for Apple. One that could possibly justify not making improvements to Safari that could make it better compete with native applications.
It's not as if it's the first time Apple does it either. They positioned OS X as the best platform to run Java, yet ditched it a couple of years later. Even back then, people were complaining about it [0].
Developing on Mac has always been a chore (at least back in the XCode 1.1 and 2.0 days), with poorly documented APIs and APIs that are just flat out broken (OpenGL comes to mind, and is still broken to this day apparently).
Our running joke back then was that "Macs are very user friendly, except developers don't count as users." Still true to this day apparently.
The article misses the point. The browser is a document viewer, not an application delivery platform. Back in 2005 we all thought that web-based applications were going to take the world by storm, but now that we have slick application stores on all major platforms, this isn’t the case.
If you need functionality like you describe, ship a native application via an app store. It’s a much better experience than web development.
I think there is a lot more in this than you make out. Unless you really need specific hardware access that cannot be achieved in the browser alone, creating a mobile app is an unnecessary, very complicated set of hoops, to jump through, for each platform, as well as then making a desktop app/website.
A side comment would be that you can make your webapp perform remarkably well on mobile, with things like HW accelerated transitions, local storage, etc...
The browser has been and is a document viewer, but it's also becoming a application delivery platform and has been for quite some time. App delivery can be cross platform easily if Apple steps up their game.
I don't fully agree. Apps like gmail and google maps are often preferred to their native alternatives on desktop.
I have pretty much ditched native office suites in favor of google drive as well on my desktop system.
And things like Facebook hasn't even considered native desktop implementations.
So it is safe to say that the web is a great app delivery platform (at least on the desktop) and as such, I think it is completely reasonable to improve upon it and extend this benefit to mobile.
Have to parse that carefully. The web is a great delivery platform. But the apps ... not so much. They can be laggy, unresponsive, render poorly, double-process user events, and on and on. The apps are not great. In fact, only their mother could love them.
The browser will be the main application delivery platform. As a business or startup, you can afford to write an app on one platform at first. Choosing IOS over Andriod, or vise versa can have a severe limitation on your customer reach. However, the web will run everywhere. Mobile, desktop, tablet, all on the same code base written by the same developers. Especially if the app is not some social app where it needs the crazy UX. Most business applications are very good and feature rich in the web alone.
> If you need functionality like you describe, ship a native application via an app store. It’s a much better experience than web development.
That is a faf when you want to be cross platform though. With care I can write an application that covers pretty much all the users I care to cover, i.e. those using desktop or mobile browsers released in the last few years. In fact there are a couple I intend to develop once I've got certain other things out of the way that are eating my "personal project" time currently. Yes native apps have advantages, and for my projects there might be native apps later, but developing for browsers first (well, API first with browsers being the first major client) gives the best use of your initial time unless your app needs greater performance, access to hardware, or something else not possible/practical in the browser.
If Safari lags behind to the point where I can only support iDevices as secondary citizens (web first, followed by native apps for platforms that need them) then I am perfectly happy to do that. Thankfully that is a practical consideration, at least for my projects, unlike at some points in the past where not supporting IE6 locked you out of a much larger part of your potential audience then not supporting mobile safari does now.
If enough other developers take this route (Your platform doesn't work well unless I create something specifically for it? OK, I consider that later when I've got everything else working) maybe the direction of Safari will be forced to change in that respect.
My business customers strongly disagree with you. They use my (internal) web application to do all their business needs and are very happy with it. A native application would work as well (of course) but a web application is much better for their needs and is much, much better to support on our end. It is cheaper to develop and support which makes them happy. It also is cross platform. My business customers don't have access to any app stores. It's not a simple web app either.
On my end I don't want to have to download an app to do all the things I want to do. I keep as few apps on my phone/computer as possible.
Not all software development is making cutting edge social phone apps.
As a primarily web-based advertising company, Google benefits immensely from a more feature-packed web. So does Mozilla, both because they depend on ad revenue and because they are betting very heavily on the web as a platform. Even Microsoft is heavily invested in web technologies, not only because of Bing but also because HTML5 forms the backbone of Modern (Metro) UI.
Apple, on the other hand, has no reason to want the web to flourish. They make money by selling hardware, and by managing a closed ecosystem of apps and services that revolve around said hardware. iAd focuses exclusively on apps, not webpages. Cross-platform web technologies that try to close the gap between web apps and native apps are a threat to Apple's bottom line. The more people abandon the web in favor of native apps, the more money Apple makes.
At least in the days of IE6, Microsoft didn't really care about the web. Apple nowadays, on the other hand, has every incentive to sabotage the web. I don't think it's just technological purism that makes them reluctant to allow alternate rendering engines to work on iOS. They need to ensure that apps are the only way for developers to bring advanced features to iOS users. Because they're not competing on the web like the others. They're competing against the web.
Apple, on the other hand, has no reason to want the web
to flourish. They make money by selling hardware, and
by managing a closed ecosystem of apps and services
that revolve around said hardware.
You have the key thing correct: Apple makes money on hardware.
So it doesn't follow that they would want to stamp out or ignore the web. The web is a huge part of what customers use Macs and iOS devices for, and Apple makes the same amount of money on a piece of hardware whether you use it to browse the web or use the $0.00 Facebook app.
There's no denying that Apple wants you to buy into their ecosystem of apps: it helps bind you to their devices. But there's no incentive for them to extinguish the web.
At least in the days of IE6, Microsoft didn't really care about
the web.
No. The web was directly opposite to Microsoft's goals. Microsoft made money on operating systems and applications. If the web "won" then you wouldn't need a Microsoft OS any more, and Microsoft would "lose."
If Apple really wanted to make Web Apps feel like a second class citizen, they wouldn't be adding Force Touch, custom AirPlay control support and Picture In Picture support to the upcoming version of Safari. Those are deep, native app level features that aren't even Web standards yet.
I assume Apple is underinvesting in safari simply because they have bigger fish to fry, and they are notoriously understaffed with competent engineers (or have bad project management).
Factually incorrect, WinRT certainly supports HTML5 apps but it supports .Net and C++ too, all of the WinRT implementation code is either native C++ or .Net.
Safari isn't "lagging behind other browsers", it's just implementing different things. In fact, Safari is still the best browser when it comes to everything UI-related (animations, visual effects, …). You might disagree with Apple's priorities, but it doesn't mean other browsers are "better" per se, they're just different.
Safari's release cycle, however, is stupid per se.
Apple adds features based on what users seem to need, not what programmers want (Google) or programmers want to work on (Mozilla).
It should also be noted that Safari's accessibility support is head and shoulders above anything (including IE with dedicated third-party extensions -- our blind accessibility guy who has access to every accessible technology under the sun simply uses Apple devices at home).
Wake me up when IE is open source, Google gives flying f* about accessibility, and Firefox is better than a distant second.
> Safari isn't "lagging behind other browsers", it's just implementing different things. In fact, Safari is still the best browser when it comes to everything UI-related (animations, visual effects, …).
So then let's name these things, specifically, if you really believe that. I'm not aware of any new specs related to animations in the last couple of years. Can you name them?
I'm not really well informed here, but I'd guess that he means how the animations, visual effects, Ui, etc. actually look and behave, rather than new specs.
One thing I've noticed several times is that in chrome, many CSS animations aren't animated across sub-pixel boundaries. I don't know necessarily that safari does this (again, I'm not well informed here -- for all I know this has been fixed in Chrome), but if they did, that would count in my book, despite not being a new spec.
(Honestly, my suspicion is that they aren't though, since a high dpi screen removes most of the need for sub-pixel accuracy).
Examples are Reader Mode and Power Saver, both features designed to reduce the impact of, let's say, non-central content. Ad-supported browsers are not exactly eager to implement these, naturally.
This is all in window at the default 'theater mode' size of youtube. I can't full screen either of the VP9 options without completely maxing out the CPU, dropping frames and during my laptop into a frying pan. Its really hot even in window with chrome VP9 using ~175% CPU.
There is no reason for h264 decode to take much power at all, it's all done in hardware now (or should be done in hardware).
In other words, Safari's power number isn't surprising but I don't know how chrome manages to use so much processing power. Even my cell phone can decode 1080p60 without catching fire but chrome manages to bring a $2200 laptop to it's knees doing it.
Glad to see some hard numbers on Chrome video performance compared to Safari. I like Chrome because I like the integration with Google services and separate user profiles so I have 2 sessions going at once, but I often have to take Hangout meetings in Safari because Safari doesn't turn my laptop into a hairdryer heating element.
I am curious, though, do the Chrome devs have access to the video APIs that the Safari people would?
In fact, Safari is still the best browser when it comes to everything UI-related (animations, visual effects, …).
I'm a Safari user who develops first and foremost in Safari, and I completely disagree with this. Chrome runs rings around Safari in UI animation performance, it's almost embarrassing.
First: I'm not the one who made the original comment, and therefore not the person you should be taking this up with. So why have you written this to me?
Second: If you are going to involve me in this, then I'll point out that of course people care about their browser UI, otherwise everyone would be using something like Conkeror, except with an even more ascetic UI philosophy.
The definition of a web browser is enormous now. Even though Apple has massive resources, is it really fair to rant against them for not implementing every possible specification, five years old or not?
If web assembly is supposedly as fast as C, why can't we have web browsers with a smaller built-in feature set and implement new specifications as libraries?
While web assembly may give us performance, it doesn't give us access to new platform API. Web assembly can in no way replace Service Worker, IndexedDB or Web Manifests.
It also won't help with Web Components unless you're aming for a Web where we just draw on a big canvas.
I want a web where we just draw on a big canvas. That's a pretty simple API for implementers to get right. Then we could move the scene graph (DOM) and it's rendering engine entirely into the application language where it could be more readily hot-fixed. It'd be like PDFJS but for your whole fucking web browser.
Have you looked into the Famo.us project? It's not my cup of tea in terms of implementation, but it sounds like exactly what you're looking for. Alternatively, what's keeping you from just using <canvas>?
Evidence is anecdotal and based on browser compatibility bugs reported to me on web apps I develop. Chrome and Safari are best in class in this regard.
Firefox has gross UI elements that remind me of the 90s.
As a user, I love Safari. The hand off between my macbook and iphone is amazing, it feels smoother than other browsers.
As a developer, I would say they are just doing a few things differently. I think the web API and DOM/css should have a standard set that every browser has to implement in the same way. It's actually way way better than it used to be. However, I'm fine with additional api features as targeting browsers is not not difficult and may open up some cool features. Like perhaps native notifications API on IOS Safari, that would be sweet!
For the base Web API though, Safari has deviated on a few small things, but it's not really to the point where IE6 was.
Also, people will upgrade Safari. Unlike IE6, where IT shops would not upgrade because of Active X applications, Safari will at least be upgraded. So I think it's unfair to compare it to the old IE.
P.S., The new Windows Edge browser in Windows 10 is pretty amazing, it feels like Chrome. Very fast.
And if you are not familiar with the Mozilla Servo project, it's worth checking out. It still has a long way to go, but down the line could be very interesting.
Yeah I've never had any issues with it. It also works when I'm using Chrome on my macbook. Like, a safari tab will show up on Chrome, it's pretty sweet.
It isn't as bad as what led to IE's state that took several years of active development by Microsoft to even begin correcting. The gap between IE 6 and IE 7 was terrible, and IE 6 wasn't even that much more than IE 5, standards-wise.
What people often forget is that there was a time when IE6 was actually better than the alternatives (on Windows anyway). Around the time it was released Navigator was the main competitor and that was getting progressively less stable and failed to keep up with the way the web was evolving. And by "evolving" I don't just mean new techniques/standards/whatever - simply the way the size of things was growing as people started to commonly have access to decent bandwidth. A key example I remember well is large nested tables (semantic markup was even less easy to get right cross-browser at that point) - Navigator would sometimes spin the CPU for a full minute to render a page that IE would throw out in seconds.
This is the secondary reason IE gained share quickly (the primary one being bundling, of course). Then Netscpae fell over and it didn't have competition at all for a while so MS simply stopped trying (why work to improve when there is no competition and you can use the resources to work on something else?) so IE gained even more share on Windows (other OSs were not large enough in the desktop market to figure at that point, and mobile browsing was embryonic) without any effort from MS. It wasn't until Firefox got to the point of being enough better to attract a large share that the tables started turning and even then the change was slow. Opera was significant around the time too, but it not being free (or not free without adverts) was a sticking point that stopped it being widely adopted.
That is a key problem that hopefully can't play out the same way these days though. No one browser, even mobile safari, is so commonly used that if it fails to keep up it can't start to be ignored, and away from iDevices we don't have the pure binary choice so if B doesn't keep up with A C and D probably will and B will be forced to (or it won't matter so much if B dies).
Disagree with this assessment. IE was so bad because Microsoft tried to go off and create its own standards that were incompatible with Mozilla / Firefox / etc. (I'm thinking of IE6 specifically). And this was big, core functionality like page layout and CSS; not some data structures that can be implemented in other ways (albeit with a performance hit). This was doubly bad because "enterprise" companies (SAP, SAS, Oracle, etc) built their original web interfaces against IE6; and those systems are so costly to upgrade that many companies still run IE6-compatible browsers. Chrome even has an option that can be pushed out via GPO to render certain pages using an IE6-compatible renderer. Safari is nowhere near that bad; I have yet to run across a page that works in Chrome that doesn't work in Safari.
Safari, by comparison, is just behind the curve on some developer-centric features. But Safari also has some things going in its favor: in my experience, it's the fastest browser on OS X by a pretty wide margin. Chrome is so bloated and full of garbage at this point that when I have it open, I usually have at least one tab sitting at 100% CPU (and this is with FlashBlock enabled). Safari also manages to feel faster while using significantly less power -- I suspect Apple has done some optimizations through Grand Central on this front.
Safari on mobile is a bit of a different story; yes it has problems, but I don't know that supporting a larger feature set is the answer.
> Safari on mobile is a bit of a different story; yes it has problems
that's a understatement., working on ios safari has been a travesty: it steals a good 20% of view area and 25% of clickable area, it makes a mess with pages trying to be responsive by misreporting the viewport area, it has loads of bugs with resizing and orientation change events and just dies if one script in any page becomes unresponsive
Right, but the problems Safari has on mobile aren't going to be fixed by implementing IndexedDB; and honestly the WebSQL vs IndexedDB argument is irrelevant to most people: 95% of web developers will just use a framework that abstracts the differences. And I wouldn't claim that mobile Chrome is a whole lot better on this front, even (or especially) on Android. The limitations of mobile CPUs combined with higher user expectations on responsiveness mean you have to pull the plug on a runaway process a lot faster than on a PC, and neither Apple nor Google is immune to this.
There are already abstractions that work over both and work for nontrivial apps, including, IIRC, an indexedDB polyfill using WebSQL.
Going the other way might be harder, but every rdbms is, itself, an abstraction over a nonrelational storage system of some kind, so it's clearly not impossible.
The IndexedDB polyfills over WebSQL are horribly slow and buggy. You'd be hard pressed to do something non-trivial with them. Believe me, I've tried. Still better than using Safari's IndexedDB though!
Chrome on Android works great and experiences literally zero of the issues mentioned for Safari.
Chrome for Android is an app, not a system component, and does not require Android point releases to be updated. It is frequently updated on a regular schedule by Google and pushed out to devices.
Using sources like www.caniuse.com, I frequently find that Safari/iOS does not support a feature that is supported on Android browsers and desktop browsers.
When designing responsive in 2015, I limit myself to Safari/iOS, the worst browser I build for, then quickly and effortlessly make sure all other browsers work.
That's my reality, Safari/iOS is the worst platform to develop for for me. I can't even remember the last time Chrome/Android had any issues that weren't also present on Chrome/Firefox/Desktop. Safari iOS though, even with CSS Resets, even with custom CSS, always finds a way to be non-standard with text size, or font weight with bold, or some "feature" that breaks Safari and nothing else.
this. and don't get me started with the whole mess that happens if you dare to use a css transform on a positioned element, which works kind of differently according to every browser already, but is completely different than every other on safari/ios
What about the other 50% of Android users that don't have Chrome or Chrome WebView? I've been working mobile for a few years now and would love to drop anything before KitKat, but that's not something feasible given market share.
In practice, pre 4.4 embedded WebViews have worse support for standards than Mobile Safari. Chrome for Android was in part a system component in order to replace 4.4's embedded WebView, only until 5.0+ did it become decoupled.[1]
Google's evergreen approach reduces fragmentation of a core API and it's been a godsend. I know in the future, Safari will be left alone as a pain point. Just don't misrepresent the present situation, where older Android has worse standards support than Mobile Safari and can't even be debugged in devtools.
> "pre 4.4 embedded WebViews have worse support for standards than Mobile Safari"
My old Windows XP box also has worse support for standards than Mobile Safari.
OK, so XP also doesn't have market share. But it's hard to blame older versions of Android for not supporting standards that didn't exist when they were implemented, just because people continue to buy low-end devices running those old versions.
Right, but at the same time you can't say that Safari is the only thing holding mobile web development back. Because dropping users on "old" versions of Android isn't an option from a business standpoint, Safari isn't the only thing holding people back. And 4.4 really isn't that old; so there are tons of users on older devices.
The Android browser was a sore joke and didn't support years old standards. It was embarrassing for Google, the top web company, to release a browser that was so impaired and so slow at adopting standards, years after Mobile Safari. With Chrome, google has reverted the situation and they are now bleeding edge.
Android Chrome has about 13.3% global usage, and all versions of Android Browser have about 6.5%. If we do not count versions before 4.4, then Android Browser has about 2.5%.
Also worth pointing out that Chrome for Android is over the 1 billion mark (1,000,000,000 - 5,000,000,000)
This is the big issue for most people, I think. I would love to use Chrome, but when I do, (a) thighs burn to a crisp if my machine is on my lap directly and (b) the battery depletes, literally, 1.5x as fast.
Epiphany works pretty well for me, I've been forced to customize the User-Agent string to that of Chrome to make certain things like Outlook Web App treat it like a Real Browser(TM), on occasion I have to use Firefox still (Plex doesn't work in epiphany) but overall it works fine.
I should note that Epiphany is the only Linux web browser that seems to interact with touch screens correctly, drag-to-scroll works wonderfully on my XPS 13 meanwhile Chrome and Firefox just keep trying to highlight text.
I think it's just a lack of optimization for battery usage on OSX Chrome. Google seems to have recently realized it is an issue though and is making progress on improving things: https://plus.google.com/+PeterKasting/posts/GpL63A1K2TF
Nothing you've said here really addresses the problem discussed and really you're looking at this from the perspective of the consumer and not the developer.
> Safari is nowhere near that bad [as IE was in the past]
Doesn't address the problems developers are having.
> I have yet to run across a page that works in Chrome that doesn't work in Safari.
Try any webpage that uses WebRTC, and there's a growing number of these. But really it's because people are doing what they did with IE6 which is here is code that works everywhere, and here is some code to make it work on Safari so the user is none the wiser. The problem is still there.
> Safary, by comparison ... <insert swoon>
This has nothing to do with the post. Great you like Safari, but the problem still exists. Where's the WebRTC support? The Audio API? Right.
As to the original article, I prefer a 4th step not mentioned, just ignore Safari. Apple has a huge iOS userbase, sure, but as the HTML5 disparity between Safari and other browsers increase it's becoming increasingly not worth considering and really do iOS users even expect the HTML5 features that don't work in Safari? They'd probably prefer a native app for that.
Desktop users can use Chrome or Firefox when a site doesn't work in desktop Safari, and if that makes them mad, good. Maybe Apple will fix their shit then.
Edit:
Regarding downvotes: I know engineers are ignoring Safari. I ignore Safari, and other people I know ignore Safari. A convenient sample sure, but as this article points out developers aren't happy. Downvotes or no. Deal with it.
> Nothing you've said here really addresses the problem discussed and really you're looking at this from the perspective of the consumer and not the developer.
That's entirely the point: developers and users have different needs. But the developers will follow the users to whatever browser the users feel is best. Apple's priorities are on improving battery life, page responsiveness, etc. If users value Apple's browser development model that prioritizes user-facing features over developer features, then the developers will simply follow the users. If you want to build a product around features that a major browser doesn't support, go ahead.
To use the dreaded car analogy, you don't build a car to be easy to work on just to make the mechanics happy. You build a car that consumers want to buy, and it's the mechanic's job to figure out how to work on it.
> then the developers will simply follow the users.
That didn't happen with IE6. I think the web as platform is bigger than Apple as big as it may be. It's amazing to me that you're OK with a single company holding back the entire platform because of a single device. People use the web with machines that don't even have batteries.
Really to a developer who cares about the open web and standards, just throwing the whole concept of the web out of the window for the sake of Apple's priorities is so, so bad and it will never happen. At least that's my hope and prediction. The open web as a platform will guide my behavior with regards to how I engineer applications that run in the browser, whether Safari is on board or not.
Yes it did...but anyway, the detail is irrelevant; it's the point you're refusing to acknowledge:
A developer, building a product, is obsessed with growth metrics, OR, a slave to the pedantic demands of a client they're working for.
Either way, those demands require that a site be available to as many people as justifiably possible. The questions you have to ask are:
1) Is the the $ value of a customer using IE6 worth the time taken to make the site work in it? (No, almost certainly not)
2) In IE8? (Hopefully not, but you know, there are still a lot of these guys, and it's almost always a demand in the .gov space...)
3) In Safari? Yes. There are tonnes of these guys, especially on mobile where they don't have a choice, and no matter what fancy javascript 0-day API you're in love with, you can work around it without any significant effort.
The point:
Is safari holding things back? Yes.
Is it OK? Not really. It sucks.
Can you ignore safari and pretend it doesn't exist, and lose those customers? No. No you can't.
We're webdevs, sucking it up is what we're good at. We've had years of practice.
Suck it up.
The path forward, I think we'll find in the long run is going to be less native apis, more WebAssembly-style low level polyfills to implement new 'universal' features that run on all js runtimes.
Maybe you can, because either you work for yourself, or you work for some who doesn't care... but you're mistaken if you think you fall in the majority in that.
Yes it did. That's the entire reason IE6 was such a headache: IE6 was by far the worst browser platform out there, but everything in the corporate world was written with IE6 in mind. This made it a nightmare to support these sites -- because they didn't work in Firefox or Chrome. So when IE6 was finally deprecated, it was a mad scramble to try to patch internal tools (or hack an unsupported install of IE6) so your HR person could access payroll.
Rather then just downvote you, let me say that I (20+ years webdev) and my colleagues use our audience to determine what browsers we support, not our personal preferences. My job is to provide visitors to my clients websites with the best possible experience, not judge them on their technical choices.On the site I support, hundreds of thousands visits a year are from Safari users. Based on your comment ("deal with it"), you pretty clearly are not the kind of web developer I would ever hire. Or your engineer friends.
Yeah, the choice of which browsers to support is a business requirement informed by marketing, not a technical decision. Business requirements should inform the selection of technology, not the other way around. When you let technical requirements drive your business requirements, you end up with a product that is a poor fit to user's needs. It's hard enough to get users for a new product without engineering imposing arbitrary technical limitations.
> in my experience, it's the fastest browser on OS X by a pretty
> wide margin. Chrome is so bloated and full of garbage at this
> point that when I have it open, I usually have at least one tab
> sitting at 100% CPU (and this is with FlashBlock enabled). Safari
> also manages to feel faster while using significantly less power
> -- I suspect Apple has done some optimizations through Grand
> Central on this front.
This. As a developer... I sympathize with people who like developing on the desktop with Chrome and for Chrome, but as a user, I prefer the browser that doesn't spin up the fans on my MacBook Air.
As we adulate Tesla for their accomplishments with battery technology, we often point out that battery life is a software problem, and that it involves a specific set of engineering tradeoffs. Apple is simply making those tradeoffs. And it has to.
Google make a browser that runs on everything. If one platform is slower than another, or has less battery life than another, blame the platform vendor. Google doesn't care. But Apple sells hardware. If a MacBook gets so hot it burns your thighs, they lose sales. If the battery life on an iPad is terrible, they lose sales.
Safari gives their users a legitimate way to enjoy web browsing on a cool-running system with long battery life. That sells.
> I sympathize with people who like developing on the desktop with Chrome and for Chrome, but as a user, I prefer the browser that doesn't spin up the fans on my MacBook Air
For me it's just video perf, but the worst part is that it's Google own web services that are spinning up the fans, and their video services work 10x better in Safari!
I have a shiny new 15" Retina MBP, which heats up like a stove if I use Chrome to open a video Hangout or watch YouTube. So for work meetings I've made a habit of having my calendar always open in Safari so when I click the video link, I get the Hangout in Safari as well.
And Safari manages to not set my computer on fire, amazing!
> IE was so bad because Microsoft tried to go off and create its own standards
That's a common misconception, but what actually happened was that MS implemented draft CSS specs which ended up being a bit different from the final standard. At the time they were extremely eager to pack new stuff in IE (including a state-of-the-art XML/XSL processor!), so they rushed in a lot of stuff before other players had agreed how this stuff should really behave.
IE was then basically abandoned. MS just refused to fix their engine to adhere to newer standards. By the time this became to be seen as a problem, Netscape was dead, IE was dominant, and they were busy trying to plug the ActiveX security sieve, rebuilding on .Net and finding an alternative to Flash.
In this sense, Apple have done exactly the same with Safari: they poured resources into it while they were competing on the desktop. Now they only care about iDevices, where they have no competition at the browser level, the priority is battery time, and stability (aka rot) is preferable over innovation. Look at Safari for Windows: they built it only to support iTunes, and basically dropped it when iTunes on Windows became fundamentally unnecessary.
They went ahead when they wanted to be in the game, now they own the game so their incentives are different. Exactly what Microsoft did back in the days.
Safari's speed is a tossup for me, in that opening new tabs and typing in the address bar both are often preceded by several second (!) delays before the UI responds. This persists across multiple instances of clearing all of my browsing data and even migrating to a new laptop. That I continue to use it over Chrome in spite of that implies a lot about the sorry state of browsers in general right now.
Nolan, I'm not familiar with what you do or have done, but have you ever tried to make a website back in the day? Ever tried to support IE6? 7? 8? IE literally broke the web. CSS rules which worked in every browser ever wouldn't work in IE. Entire webpages weren't formatting correctly, having to spend hours, days, on workarounds. Comparing Safari to IE is just wrong. Safari doesn't break the web, it 'just' lacks support for some new javascript functions, not break standards/rules that had been there for tens of years.
In the same vain, Chrome does break web by introducing various custom features that can't be found in other browsers. See all those Google demos from past several years: "You need Chrome to view this" sounds very much like those "IE5+" warnings.
> See all those Google demos from past several years: "You need Chrome to view this" sounds very much like those "IE5+" warnings.
I'm in sympathy with the spirit of this post, but I'm not sure that I agree with this specific example. I think that there's a big difference between an 'everyday' web page requiring a specific browser, and the creator of a browser showing off what they see as its exceptional capabilities.
However much designers (and users) like adherence to standards, I think that it's clear that a lot of the innovations we take for granted have come from browsers leading the way; and there's not much point in having those innovations in the browser if the user doesn't know about them.
(I should be clear that I'm not advocating a functionality free-for-all, though; probably much more harm than good has come from this behaviour.)
Speech Recognition and Synthesis are in Safari -- though I don't know to the extent that it's as complete as Chrome. Safari definitely lagged behind though...
A lot of that is new features that are later implemented in competing browsers though, sometimes features that aren't even officially declared stable in Chrome yet. I'll happily allow "works best in X" for a tech demo. For a site/app I want to use for doing something, this is different of course.
I have to support IE11 for corporate software, websites, etc. I'll used it as my main browser for a day or so to test things out and its just incredible how its become a 2nd class citizen and how you pretty much need Chrome or Safari nowadays to get by. I'm partial to Firefox and it works well enough, but designers only have so much time and they'll hit big targets first - Chrome/Sarafi and leave IE be with FF support just working because Gecko and Webkit render very, very alike. Things are pretty much the opposite they've been just a few years ago. Obviously, supporting standards are good and IE11 is better at standards than anything before, but there's still bad blood here.
That said, I was just playing with Edge on Win10. Its like a pre-bundled Chrome. Fast, compliant, etc. It hilariously even breaks MS software, for example, I can't open the address book in Outlook Web Access because some deprecated html control that Chrome no longer supports. So if Chrome no longer supports, Edge doesn't either!
I guess we'll see if extensions ever take off for it. If they do I could see it hurting Chrome's marketshare. Personally, the Chrome/Google juggernaut needs to be knocked down a peg or two. I hope Edge gets popular just to keep Google's sometimes anti-consumer ambitions in check. For example, using FF in Android means Play Store links don't work right and a million other things. Google isn't incentivized to make alternative browsers work well in Android. They want use to use Chrome and all of its spying/tracking/marketing stuff cooked in.
It's one thing to be the first to implement standards, it's another to completely ignore them for years.
The "Chrome Experiments" was a way to show off the WebGL capability in chrome that no other browsers had at the time. (Now those demos will mostly work in all browsers)
Plus you are forgetting that those are experiments. They were never really meant to be actual "apps". Making an experiment/demo for one browser is fine IMO. Especially when only 1 or 2 browsers have implemented the standard currently.
It's like webRTC. I made a "demo" webRTC app about a year ago, and it only worked in chrome OR firefox (but they couldn't talk to each other). That's not chrome or firefox breaking the web, that's the other browsers not being at the cutting edge, but i don't blame them. WebRTC was (and still is) VERY new, it wasn't even finalized and i was using the app as a bit of a tech demo to see what may be possible in the near future.
The chrome experiments were the same way. WebGL wasn't fully finalized, it was one of the first implementations of it, and people wanted to try it out, so Chrome Experiments was born.
WebRTC is not really new any more - a couple of years old (and existed in other forms long before), and still not widely adopted. In fact, not adopted in a single further browser in that time, and the original two are not compatible.
I'm thinking, its almost time to consider WebRTC 'failure to achieve traction'?
I'm sure as hell not married to the idea of WebRTC, but i desperately want something like it.
The ability to do peer-to-peer communication from the browser is an amazing tool. It allows the creation of client-side-only web apps which can easily send massive amounts of data to others. With WebRTC (or any other service like it) you can add video chat to a web app with very little work, and no real server side infrastructure that is more secure than the alternatives.
If it needs to be re-done in the name of getting it implemented widely that's fine with me and i welcome it, but if it's just NIH syndrome at microsoft holding it back, that's not okay.
Mostly its an unprofessional wad of code written by some PhD's. It went through some hands and ended up at Google, who mercifully refactored it somewhat and renamed it.
I've been dealing with the code base for 5 years, and never liked it. Had to rewrite the APIs every time we got a new source version, to fit our model which isn't the 'conference call' model. I'd be glad to see something more app-agnostic that just dealt with negotiating P2P streams, without so many assumptions about what/why/when the streams are.
Still another conference-call-specific take on p2p communications. Application assumptions are laced throughout the design. Which in my experience is the usual problem with open source IP - its tied up with so many assumptions as to be brittle.
Not an expert, but hopeful that WebRTC will be a success in the end. Maybe I'm just overly optimistic?
> still not widely adopted
Certainly everyone involved with WebRTC wishes that it had the support of IE and Safari, but Chrome + Firefox + Opera is nothing to sneeze at, particularly if you're targeting a savvy audience.
> Original two are not compatible
Maybe I'm confused, are you saying that Firefox and Chrome aren't compatible via WebRTC? I've used them together and had success, but just for basic video calling.
> not adopted in a single further browser in that time
This is fair, but if Microsoft's latest moves come to fruition that will be a big change. There are hints that Edge will likely support WebRTC[0], though I don't think there has been any official word. Maybe that's just for ORTC?
All the important scalable features are incompatible - so-called 'bundling' where many streams use a single port etc. Aggregation of error feedback so an MCU can sensibly report bandwidth limits. Slow connect/reconnect times. No 'supernode' support. Pretty much anything that takes it from a toy with 3 or 4 p2p connections, to a product that can handle up to 100 streams with audio/video switching realtime through an MCU or P2P dynamically.
Other products can do this. WebRTC suffers from being based on RTP/RTCP and SIP-style signaling. There's not enough juice there to get the job done.
Yes, 2 years after it was released. And there are many levels of bundling. Will they both support all of them? Will the MCUs follow quickly? The WebRTC landscape is a disjoint map of features and support that evolves very slowly.
IMO this is directly related to the post. WebRTC is a technology that has huge potential on mobile (given phones have cameras etc) but Apple haven't/won't implement it.
WebGL is a good comparison here - it was pretty dead before Apple implemented it. When they did (in iOS8) you started seeing a ton more WebGL things popping up.
If it lacks very basic functionality, isn't the effect the same as breaking the web?
I think one unfortunate aspect of the article is that it focuses on some of the less common deficiencies of Safari. I would have called out mobile Safari being unable to download files, or Apple's insistence against video codecs that all other vendors are aligned in agreement on when it comes to video.
Well, I mentioned the two that I am most keenly aware of. I only know what I've come across, so I'm assuming there's lots more.
To my knowledge, file downloads worked in all browsers prior to mobile Safari being initially released. So Apple did release a browser that broke some quite basic web functionality.
I don't know how I missed that part of of your post. Sorry about that. Still. I find it quite a stretch to argue that not supporting file downloads "breaks" the web. Users don't perceive websites to be broken just because they can't download files. It would be akin to claiming that a device with no camera breaks the web by not supporting the camera API. Or that the Lynx browser breaks the web by not supporting CSS and JavaScript.
Regarding Apple's insistence on not supporting Ogg (Vorbis|Theora) (I assume that's what you're alluding to), those codecs were briefly recommended by the HTML5 standard, but were later dropped.[1] Again, I think its a stretch to say that Apple broke anything, simply because they resisted a proposed standard. I know a lot of developers were disappointed, but that's how committees work: You don't always get it your way.
What rules that had been there for tens of years were broken by IE6? IE6 was the best browser available when it was released, and the web standards ecosystem was nothing like it is today.
I think the analogy is very clear. If you want to code like it's 2000, supporting IE6 is easy, because IE6 is a very good 2000 browser. If you want to code like it's 2010, supporting Safari is easy, because Safari is a very good 2010 browser. But in both cases, if you want to use any new features that have been standardized and are supported by other browsers, you're fucked.
The main difference I see is that IE6 didn't get any updates at all. Safari gets updates, but many new features are missing or broken.
EDIT: Another difference is that MS never blocked you from installing a better browser, but Apple does that on iOS. That policy is becoming increasingly ridiculous...
It's so easy to be cavalier about random popular facts. I would love for someone to go back and load up the alternative browsers available at the time on some vms and take stock of their featuresets. Factoring in popularity at the time I'm pretty sure not much would have changed.
Also ironic given that most people have adopted some of that "broken CSS box model" in their CSS.
box-sizing: border-box;
Now there were many other problems but I'm not sure people appreciate how such features eventually got standardized. Similar issues happened around DOM serialization with APIs like innerHTML, which Netscape refused to adopt because of "series of pointing at standards". Developers ended up adopting the idea and it was later standardized. XHR is another case. There are many more.
In the case of Safari, I can think of canvas, touch (love or hate it vs pointer events it was before any of the alternatives), DPI independence, &c.
It's some of these quirks that seems to show how newer web standards might be rushed through by increasingly aggressive vendor involvement. Apple hasn't changed all that much from when it first released Safari. It's only our expectations for the pace of new additions that has.
Absolutely the truth. There was a reason the only answer was tables for a very long time.
A major source of hatred for IE was the fact the IE team did work prior to the browser standards, a practice which is now standard operating procedure. Where would be without ajax?
"Another difference is that MS never blocked you from installing a better browser, but Apple does that on iOS. That policy is becoming increasingly ridiculous..."
Why has that not resulted in anti competitive behavior lawsuits? MS got in to a fair bit of trouble for similar things. They didn't stop you installing an alternative.
Let's define it as apps that actually use a different browser engine, and aren't merely a reskin of the exact same engine used in Safari. In short, something that is actually capable of supporting new features that Safari doesn't.
This is not possible on iOS without a jailbreak, because Apple simply doesn't allow alternative browser engines to be used.
Why not? Apple also doesn't allow Flash, so the question is, why? Does Apple make money from Safari? Is there a technical reason that might preclude another browser engine?
My understanding was that they don't want to allow executing downloaded code that hasn't gone through the App Store review (such as JavaScript in web pages). I think they allow Lua for scripting in games, though.
So, basically, a 3rd party JavaScript engine is not allowed. I guess you could write your own browser engine that doesn't support JavaScript.
I guess Flash was not allowed for performance and security reasons (lots of vulnerabilities, right?)
MS was deemed to have a monopoly on desktop software, Apple is not. You're allowed to hinder competition for software on your operating system, if the user can reasonably easily choose another operating system.
Apple has a monopoly of taste – a self-defining market that won't switch OSes even if that constrains their other choices. But they could, so the "market of Apple users" isn't a discrete market under the law.
It doesn't need to be. MS in the late 90's dominated, and you could not do work with someone using MS products unless you also used MS products. One person having an iOS device and another having an Android device does not cause any issues between the two, they are fully able to communicate by the nature of cell phones. I would bet that the lawsuits against MS would not go through if they were brought up today (and, of course, MS was still doing the same things), because it's actually possible to switch desktop operating systems without ending up unable to collaborate with your coworkers and family.
Maybe, maybe not. That is what the person I was responding to claimed though.
I don't believe it is reasonably easy to choose/install another operating system on an i device. I could be wrong.
>One person having an iOS device and another having an Android device does not cause any issues between the two, they are fully able to communicate by the nature of cell phones.
By the nature of cell phones? What is the nature of cell phones?
Ethernet existed in the 90's and I personally setup networks using it that allowed Windows and Linux systems to communicate with each other.
I can't tell you how many times I've had to help people who switched away from their iPhone and then saw eternal, intermittent issues with not receiving text messages because their friends iPhones were convinced they should be sending iMessages and not SMS. The situation gets even worse with group messages.
Even tech-savvy users (read: me) sometimes get bitten by that. I wonder if it would make sense to auto-disable iMessage when a phone's SIM is removed? The problem probably isn't even on the radar, though (iPhone users never switch!).
Yeah, I know. In some cases this somehow still doesn't always work for some people. Even after you delete the old conversation, which also sometimes has to be done.
But the very idea that someone has to know this has to be done and disable iMessage is insane to me, and I suspect part of the reason it is the way it is is because Apple doesn't really mind what (to the average Joe) is a major annoyance when switching phones.
To be fair, matters were even worse before Apple released that tool. But this has been an ongoing issue for something like four years.
Netscape used to be a paid product* before Microsoft made IE free. What Microsoft did was make a free competitor and install it on every machine running their OS.
So what Microsoft did that was illegal was use their monopoly power to destroy an existing player. That's how they were "anti-competitive".
While Apple not allowing any competing rendering engines to be written for iOS is anti-competitive in the dictionary sense that they are preventing competition to be created, it isn't the type of behavior targeted by anti-trust law.
(IANAL, but my understanding is that if Apple had removed Spotify, Pandora and other music apps from the App Store while releasing their streaming music service, that would be an anti-trust violation.)
The real issue is just whether Apple has a monopoly or not. IANAL, but as I understand it what's illegal is using a monopoly in one market to muscle into another market via bundling deals. Just doing bundling deals if you're not a monopoly is perfectly OK.
If Apple sold the operating system used on the vast majority of computers you could have a case, as did the government when 95% of PCs were shipped with Windows.
Even by the most generous definition of "computer", Apple holds 20% market share at most.
Samsung won't get sued for anti-competitive practices because you can't switch the browser on their so-called smart TV for the same reason.
They also provided a free graphical text editor, thereby destroying the market for commercial text editors. It boggles the mind that they escaped punishment for notepad.exe.
There were also the facts that IE was deeply integrated with the OS to the point where r was impossible to remove and MS had anti-competitive agreements with OEMs preventing them from providing Netscape bundled.
>>> Why has that not resulted in anti competitive behavior lawsuits?
IANAL but folks over reddit explained it as this:
Microsoft was a software only vendor in the past but Apple is the hardware and software vendor. US and EU laws dictate that the hardware manufacturer to have full control over the ecosystem becuase of the industry behaviour in the past and who the end-consumer pays his money to.
So on one hand people say that Android has more market share, on the other hand they're anti-competitive with iOS and Safari. Is Apple preventing you from using another device? is Apple using its position to put Chrome out of business?
This will ultimately hurt Apple. They're giving away marketshare of end users who want or need to use some other browser than Safari.
Web browser is arguably the single most important app on any phone. Or a computer. How many browsers you have currently installed on yours?
I should be able to install any browser on iPhone, just like I can on my Macbook.
While I was still using iPhone, that forced me to always reach for Android phone when I wanted to read any page with wrong size font for me. Which is pretty often.
IMHO, there's just one good mobile browser, and it's Opera. Not mini version, but the proper mobile one.
The big feature? It can always reflow any div (paragraph) text to 100% screen width. Always the font size I want and never any horizontal scrolling.
I hope Apple will finally allow other browsers that are more than just embedded mobile Safaris. Including full Javascript JIT support, because that's what modern web requires. Currently on iOS only app that can allocate executable pages is Safari.
No, you can't. You can install wrappers around Safari, but you can't install any app that uses the rendering engine of Chrome, Firefox, IE, or any other browser better than Safari.
Chrome for ios is a wrapper for safari? Are you sure? Safari and chrome definitely render certain pages differently when both running on the same iOS device.
I'm also sure. At least for mobile devices. I can't speak to desktop Chrome. That's why it does the same weird rendering Safari does which has become more noticeable since the split from webkit.
There's one discernible difference between Chrome and Safari on iOS 8- try scrolling on both and you'll see that both render them differently. Much faster on Chrome and less so on Safari. Prior to iOS 8, scrolling on both browsers were very much the same.
If I'm not wrong, Apple allows you to install Chrome on iOS? Of course for a long time they didn't allow other browsers to use their Nitro Engine (so deliberately forced them to stay slower), but seems now they allow that as well ...
Again, it doesn't allow them to be made as the 'default' browser - which in itself is a big reason to criticize them.
Aah. I knew it 'used to be' the case, but didn't know that it is still the case, especially after Apple started allowing other apps to use the Nitro Engine (WKWebView). Just came to know that due to other technical limitations by Apple, Chrome still can't use it [0].
Apple does not block people from installing better browsers (I know a couple). They did, back in the day, when they couldn't find a way to make Nitro (their web engine) secure.
I had to do some work[1] with, basically, HTML4. Eventually I reached the stage whereby the feature worked in every other browser (IE8+, including Opera), using clean and completely hack-free code. In 3 days I had done my work.
Then I tested it in Safari. Two weeks later I gave up and basically had to `if (Safari)`. I don't know if the code still has that, but it probably does. This wasn't anything 'lacking'. Sure, it was contenteditable-related but the fact remains that I found a consistent subset in every browser except Safari.
So, yes, Safari broke my web - and it wasn't something that was missing, it was something that behaved very differently compared to other browsers. I can't remember what specifically broke it, but even ~2 years ago I had a significantly better development experience with IE than Safari with no new HTML5 features in sight.
If your target browser is IE8 and you write a bunch of html4 that looks great in IE8, I would expect it to not work anywhere else.
Not only is IE8 a snowflake but html4 is particularly hard to get a good layout working. Lots of nontrivial layouts in pure html4 (and css 1/2) require tons of browser specific hacks.
You missed his point. He mentioned IE8+ and Opera as working targets to highlight the fact Safari was being lame. He said every browser - that would include complaint ones like firefox and chrome. He also specifically said he avoided browser specific hacks.
Saying "I didn't use any browser-specific hacks" with HTML4 is a strange statement, seeing as how many non-trivial layouts in html4 (and I'm assuming the older CSS standards that would typically go along with it) require browser-specific hacks to work.
But honestly, I can't know because he's not naming anything specific anyway, just an anecdote about how IE8 was great at being standards-compliant and safari wasn't. Which is such an extraordinary claim (and is so contrary to established precedent) that without any extraordinary evidence, I have a lot of trouble accepting it.
(And it's amazing how many people think "I'm not doing any browser hacks" while they're using something like jQuery, which is a library 100% devoted to doing browser hacks for you while abstracting you from that fact.)
> Saying "I didn't use any browser-specific hacks" with HTML4 is a strange statement
I was working on top of a huge CSS framework - the majority of styling work I did was tiny tweaks to styles where the appropriate hacks had already been solved.
Also I didn't mention layout. The specific pain point was contenteditable in combination with JS - by the time I got to the code everything surrounding my little problem-space had been solved by the rest of the team. Again, specifically, Safari demonstrated wildly different behavior within that specific space, where other browsers only behaved marginally different (a relative term, contenteditable is a complete mess, sadly, still in HTML5) in a way that I could find a viable subset of functionality that worked consistently.
Well, that's the whole thing then, isn't it? The huge CSS framework probably had tons of hacks (as you say) to make things work in IE8... it's a bit disingenuous to say you wrote everything to be clean and without browser hacks, if the hacks all exist but are buried under a "huge CSS framework".
Your whole experience could probably be restated as "I was working with a CSS framework that did a bunch of cross-browser hacks for me, and the tweaks I made to it didn't work in safari", which is a pretty uninteresting statement, because it's equally likely that any issues you had in safari are the fault of the CSS, and not the browser. (In fact, much much more likely.)
Opera went out of its way to ensure non-standard stuff targeted towards specific IE versions also worked in Opera. The downsides of being a browser no one cares about.
Something working in opera doesn't mean it is standards compliant.
I use Chrome as my primary development browser and Safari and Firefox as my second and third choice. When I do get around to testing in IE 9+, it's almost an afterthought. Is it surprising then that IE is the browser that gives me the most trouble?
All browsers have quirks. It's inevitable when you have many competing implementations from companies that have different priorities. The browser you use the most is naturally the one whose quirks you will get used to.
I built websites during that entire period. I saw the rise and fall of Netscape, the "dark ages" of browser development when Microsoft let IE rot - I witnessed the birth of Firefox and the re-ignition of the "browser wars" when Google launched Chrome, and Apple got serious with Safari by moving to WebKit.
The author is right, the details aren't the same but the same attitude exists. The author is simply speaking up before the differences become extreme.
Microsoft didn't "break the web" they created their own web and then let it twist in the wind because they were pissed about the government beat down.
Apple didn't get their hand slapped, but they did build something so lucrative that evolving Safari became a smaller priority, which some would argue aligns well with their push to the App/closed ecosystem model.
Not only was Safari always WebKit based, WebKit is Apple's browser engine (forked from KHTML and open sourced) that Chrome used to use until they forked it.
Apple had little choice other than to Open Source Webkit unless they wanted to violate LGPL licence which forces - source code of any derivative work to be released back to the user.
My mistake, my comment was penned rather quickly and emotionally (typical). I should have verified my memory with actual homework, the revised timeline does not change my opinion ;)
Offtopic, but your first paragraph sounds like Roy Batty's final monologue in Blade Runner. I watched c-beams glitter in the dark near the Tannhauser Gate! :)
> Microsoft didn't "break the web" they created their own web
> and then let it twist in the wind because they were pissed
> about the government beat down.
I was around as well. My recollection is that they let it twist in the wind because SaaS competed with their two interdependent quasi-monopolies: Windows and Office.
Which is another instance of the Innovator's Dilemma: How can a successful company embrace technology that disrupts themselves?
> they let it twist in the wind because SaaS competed with their two interdependent quasi-monopolies
It wasn't called SaaS back then, but in any case -- they let it "twist in the wind" because their market had become the enterprise, and that's a market that wants stability, predictability and no updates if they can be avoided. By then they had killed all competition, so their incentives were to keep businesses locked-in through backward compatibility and security fixes. Add to that the big move to .Net and an effort to replace Flash...
IMHO it wasn't about the antitrust or platform control (they could have broken all the SaaS apps they wanted with each update, they had 95%+ of the market and were n.1 target for every website out there). They just had other priorities: the browser war had been won and attention was now on the enterprise market. Around that time, IIRC, Gates also retired, leaving Ballmer in charge; Ballmer was not the sort of technologist to lose much sleep over "the future of the web"...
Yah, although some more than others. Microsoft looks ironically (or perhaps fittingly) to be the first into the next lean cycle with Microsoft Edge.
The browser game has changed and become commoditized. Before they went towards being monoliths with everything from email, to apps and games, various services etc. Those parts are being usurped by stand-alone services and apps and need to longer be integrated into the browser. I think that's good! Browsers should focus at being browsers. Better to be a 'la carte than bundle everything under the sun.
Also, I think the vision of HTML as a "universal" app/game platform is slowly dying. We're coming to terms with HTML is really good for somewhat basic presentation and interfaces, but not much more than that.
Although doing advanced stuff is possible it seems we're coming to the realization that it's neither practical nor performant
Only in the sense that its missing all the features. People seem to forget when considering current browsers "bloated" that the bloat comes from the webpages containing all the cruft.
We've got one or two last perf fixes for the Edge dev tools going in before RTM, but the current perf in Edge (Tech Preview) is about what to expect. Have you tried the latest builds? Always happy to take a message about what to fix or add (this username @microsoft.com)
> Firefox Dev Edition is broken or slow every other build
Then just use release? Dev Edition is the alpha version with some different defaults, based on the assumption that "developers" are OK with an alpha quality build that has some new features faster. If that bothers you, use the release. It also contains the dev tools!
Yeah, I was a big believer in "screw it we'll just use tables" back then. When CSS finally caught on it basically was the end of dynamic-width websites for a few years.
Given that the author self identifies on his blog as a twenty-something I'm wondering if he's old enough to have ever really had to lift IE v. 4-7.
IE was a vast pile of shit for about a decade. It was pile of shit so high that Microsoft took out ads saying in so many words that its latest version "doesnt suck, honest". I tore my hair out for years over IE bugs. Fucking kids these days. Mobile Safari might not be as magical as you would desire but it is not even in the same league as the virtual genocide/superfund/WMD that IE was.
Oh the pain of having to use nested tables, various css parsing hacks, browser sniffing, two different box models, and changing significant-insignificant whitespace to support IE 5, 5.5, and 6. All with zero debugging tools.
Ha whoops, on mobile it looked like you were responding to the OP article instead of a top-level commenter. Mea culpa. It's just something of a pet peeve that there are people who call 'ad hominem' at every insult.
Considering that Safari fails to start on a regular basis (amongst a ton of bugs and problems with it), I'd say that breaks the web a lot more than IE6.
While the title is a bit click-baity, I think the overall point is: Company sees the value in the internet. Company wants to "play too". Company builds good browser that is fast and feature filled. Company realizes that they can throw their weight around and have company specific features. Company starts to care less and less about accepted standards, and cares more about their pet standards. Company refuses to let other, more capable browsers run on their OS. Company thinks that because they're the biggest and richest, that everyone should get onboard with their choices. It'll last for awhile. Something else will come along and give users and developers a better option. Let's hope Apple doesn't screw around for as many years as MS did before creating a decent browser.
The worst thing MS did with IE was implementing proprietary, and very aggressively protected, solutions to common problems. Developers, excited about the new features, rushed to support what they felt was the next generation of web technologies, only to get caught in Microsoft's trap. Once they held the marketshare majority, they stopped innovating.
Safari is nowhere close to a majority player in the market (not even on mobile). Thus, it could never be considered equivalent to the evils of IE.
Yeah there would definitely appear to be a generation of developers now on the scene that were doing something other than web development in the 2000s. 100% this. Web development was fucking hard ten years ago.
What your comment says to me is that you were not actually there back in the day. When IE6 was released it was the best, most compliant, fastest browser. That wasn't the problem. The problem is they then didn't update it for 5 years and people eventually wanted more which IE couldn't deliver, just like Chrome and Firefox really suck at HTML6 at the moment.
The point is that Safari is the browser that destroys the ability to universally use new standards. It is the odd one out that makes it hard for all the others.
The point is that Safari is the browser that destroys the ability to universally use new standards. It is the odd one out that makes it hard for all the others.
Yep, I have had to support IE7 and 8. IE6 was, thankfully, a bit before my time.
And yeah, the title is pretty clickbaity; guilty as charged! But my blog has no ads, so it's not like I'm making money off of it. I'm just trying to draw attention to what I think is an important issue.
As others have pointed out, it's all a matter of perspective. If you're trying to build for Web 2.0, then Safari is a fine browser. But if you're trying to build for Web 3.0 (or the "next web" or "appy web" or whatever you want to call it), then prepare to be disappointed.
> Now, after one year, Apple has fixed a whopping two bugs in IndexedDB (out of several), and they’ve publicly stated that they don’t find much value in working on it, because they don’t see “a huge use.” Well duh, nobody’s going to use IndexedDB if the browser support is completely broken. (Microsoft, I’m looking at you too.)
Well, the reason for this is clear: offline web apps are supported in iOS but without a reliable way to store larger amounts of data, web apps get pretty much useless and so people have to go through the Crapp Store.
But, I have to defend Apple, IndexedDB is a ridiculous steaming pile of junk when compared to WebSQL. Writing a single-line SQL statement with multiple WHERE clauses and a couple ORDER BY, takes metric tons of boilerplate crap in addition to callback hell because the IndexedDB crap is async.
I recently ditched Chrome as my default desktop browser in favour of Safari because of its lower power consumption. Apple may well have made a conscious choice to eschew staying up to date with cutting-edge web technologies in favour of a better overall user experience for the majority of users.
Hey Nolan, It was good to "meet" you at edgeconf (really we were just throwing the mic back and forth, and I couldnt make it to the afterparty). I really enjoyed your panel intro and insight.
I agree with your assessment that IndexedDB is laughably bad in Safari, but maybe they haven't bothered because its really not such a great solution in general? I'm going to reassert that I think we could do much better - since IndexedDB is too low-level for what it is, but too specific for alternate solutions. I've been kicking around a blog post that I haven't got out yet - but we really need something more stream like and generic than a NoSQL index in the browser - especially something fundamental to address the future influx of WebAssembly apps. Cheers!
> I agree with your assessment that IndexedDB is laughably bad in Safari, but maybe they haven't bothered because its really not such a great solution in general?
I still have a soft spot for WebSQL over IndexedDB - way easier to work with, incredibly powerful, brought the speed and reliability of SQLite. However, WebSQL only ever managed to have one implementation (Chrome and Safari shared WebKit at the time), and the other vendors besides Opera didn't want to touch it. So it's long since time to accept that it's dead.
What bothered me most about the IndexedDB fiasco with iOS8 is that Apple not only held out for so many years, but then they deployed a broken implementation. Anybody who had written an app using an IndexedDB shim either had a crashed site at best or lost user data at worst. YDN-DB author Kyaw Tun had the best quote: "I don't understand how they can release this."
Whether you like an API or not, a browser vendor should at least release it in good faith if they're going to release it.
"There was one company not in attendance, though, and they served as the proverbial elephant in the room that no one wanted to discuss. I heard them referred to cagily as “a company in California” or “a certain fruit company.” Their glowing logo illuminated nearly every laptop in the room, and yet it seemed like nobody dared speak their name. "
Why wouldn't people just say "Apple?" Is this hyperbole or is there some reason why people are afraid to directly criticize apple at a conference that apple isn't even at?
Happy thousand day anniversary on HN! (I accidentally clicked your name.) The author is exaggerating, like he did with the title. IE was until recently a big drag on web dev, but Safari is not. Speaking about Apple in hushed tones seems like a joke by the author, because it seems to me that some devs who use Apple products really over-rate Apple's importance. I don't use Apple products and don't feel I am missing anything. Most important innovations in web dev are in the much bigger eco-system outside of Apple. My only concern is that Apple is onboard with WebAssembly, because it would be unfortunate if they did not implement that, but as the author said, WebKit is open source and someone will do it.
Nope, people literally did say things like "a certain company in California." But yeah, I'm exaggerating a bit, because the name "Apple" did come up occasionally.
The problem is that when everybody wants to discuss the hot new browser features, mentioning Apple is just a big downer. We all know we're going to have to polyfill at best, or just not support Safari at worst. Nobody wants to be reminded of that sad fact when you're trying to get excited about the potential of the web platform.
Here is an unpopular opinion: Maybe we should chill down on the constant innovation of "the web". I think we are at the point that we need some stablity, such that technologies (and companies!) build on top of it get some time to focus on maintainability, safety and usability instead of having to constantly spend time playing catch up.
I wouldn't say it is an unpopular opinion. I can imagine most have had a similar thought at one point or the other about some technology.
But what looks like constant innovation to one, is probably a long awaited feature to someone else.
Don't feel like you have to catch up. You don't have to (and probably can't) follow every single innovation. Rather try to limit what you follow. Yes, you might miss out on things, but that's happening anyway.
It's not unpopular but unrealistic. It's like asking scientists to "improve, standarize and organize" what exists instead of seeking new knowledge and making more experiments that confuse everyone even further.
You can't force companies to stop innovating. Specially when history shows that, the best innovations survive in a sort of tech-evolutionary process.
The difference between IE and (iOS) Safari is that Microsoft got fined for bundling IE ( http://cs.stanford.edu/people/eroberts/cs181/projects/micros... ) while Apple get away with not only bundling a browser but banning competing implementations on their platform.
At the time Windows had more than 95% (pulling percentage out of thin air but I think it is realistic) of the desktop operating system market. Apple is less than half of the mobile market. This doesn't mean I agree with the limitations but it is certainly legally relevant to whether they are "get away" with doing it.
Comparing a webkit-based browser of any kind to the agony of supporting something like IE6 back in the day is like comparing a paper cut to a stab wound.
Nice clickbait title, though, got you to #1, aren't you proud. :P
The real thing I'm worried about is that no one is working on an open app ecosystem. The only thing we have are browsers - which are horribly inefficient and have huge discrepancies with one another.
We're so terribly behind.
Really, Safari's problems are just a symptom. The real problem is browser existence.
>I heard them referred to cagily as “a company in California” or “a certain fruit company.”
Oh, come on. Nobody does this. Why would anybody do this?
Hyperbole for effect is all well and good -- and the clickbait title makes it quite clear that that's what we're wading into here -- but this borders on self-parody, like saying MICRO$OFT or chanting "don't be evil!" or "WWSJD" it makes you look like a partisan rather than someone with a valid point to make.
Safari does lack IndexedDB, and their 'powersaver plugin' thing has caused me headaches. Firefox is the most likely to go unresponsive under CPU load, IME, and a nasty growing habit of pushing new monetization strategies into their toolbar. Chrome has poor performance, broken video event handling, and is the one that seems most likely to break my app every time they push an update. IE8-11 have various issues with animation and SVG, and most irritatingly there are four versions of it still in active use, each with their own quirks. Edge is, I'll guiltily admit, not really on my radar yet, but I'm sure it'll have its advantages and disadvantages as well.
None of them are the new IE. Even IE isn't the new IE. There's never going to be another IE6 for the web -- we've all, developers and customers alike, learned the lesson about proprietary extensions and platform lock-in.
367 comments
[ 5.6 ms ] story [ 479 ms ] threadEven if they weren't, I fully agree with progressive enhancement. It is always going to provide the right incentives for everyone. Only the features most used (by end-users) will become browser vendors' utmost priority.
[0] http://daringfireball.net/linked/2012/06/28/chrome-ios (linked by the article btw)
Android has no specific restrictions in place. Although it is the path of least resistance to use the built in WebView, since you now don't need to deploy your own.
[0] Including: Blink (Amazon Silk, Chrome, Opera), WebKit (BlackBerry, Dolphin, et al), Gecko (Firefox, Minimo), NetFront (Blazer). At the moment WebKit derivatives seem to be most popular, but several browsers re-build it from the source rather than just using Android's WebKit components.
That makes it possible to use extensions like ublock, for much better browsing experience than any browser without ad blocker can provide.
The word 'also' doesn't belong here. Browsers on iOS don't tend to use core iOS components (WebView) : they are forced to. Your statement really isn't a counter point.
[1]: https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....
It's such a terrible, terrible design and I check every new version in hopes that this would be addressed.
Most pages shouldn't need a refresh when you go back after a few seconds or minutes. What annoys me are websites that set stupid expiry times or Cache-Control values.
But, not only is it fast on OS X, the battery life optimization is amazing. I run Safari without Flash installed, and only need to pop over to Chrome once and a while.
I've come to understand Chrome is making more power consumption adjustments in it's OS X version, and look forward to seeing if it can compare, but I'd also like to see memory usage addressed.
But for me, Safari loads everything I need, save for the odd video that is only available in flash, which now happens very rarely. And for me being able to use the web browser for hours and hours each day without a similar hit from Chrome to both power and memory is worth it for me.
Totally agree with the speed of Safari. I have Flash enabled, albeit with a plugin that forces click-to-load. Safari is a lot faster than Chrome at this point; it just feels more like the fast, stripped-down browser that I want.
This doesn't excuse Apple dragging their feet on web standards, of course.
It's just puzzling. Clearly Apple puts a lot of work into Safari. It's not the bastard child that IE was at Microsoft... recall how the IE team was disbanded after IE6 at one point.
And yet, frustratingly, Apple doesn't support modern web standards despite allocating a healthy slice of developer resources to Safari.
It is in their interest to have it be a very nice looking document viewing platform, which is where I imagine most of their developer resources are going towards.
So I don't think your theory holds any water. Sorry.
(Edit: My post was unclear. I and others feel that Safari, despite its other shortcomings, is the most responsive browser on OSX - not the least.)
In reality, if the lead developers of some software find the experience to be good enough on their machines, that's going to lead to it becoming worse on old hardware, no matter what the company (as people have said in this thread, it's even worse with chrome and firefox.)
It takes huge amounts of effort to ensure that the development work you're doing is performant on a range of hardware. If you neglect doing that, I'd definitely chalk it up to laziness and not malice.
(In other words, I agree that performance gets worse from version to version, but you don't need to attribute to malice that which can equally be attributed to laziness.)
Battery life is one of the two or three major selling points of all their devices, and improved (or at least equivalent) battery life is something they deliver with every iteration of OSX.
I believe Safari's performance/responsiveness is largely a happy accidental byproduct of this focus on energy efficiency.
Again, I'm not defending anything they do. I'm a OSX user and Firefox is my browser of choice, if that tells you anything!
They are putting a lot of work into making the browsing experience better on Safari, very successfully I think, but adding tons of features that could expand the role of the web as an applications platform is just not in their interest.
Then their is the problem with black boxes. I don't know why, but all to often, safari loads a page and there are black boxes on that page. Just covering up portions of the web page. I have to resize the window or do something to get Safari to rerender the page so it will go away. This happens frequently.
Couple this with all the other issues OSX has, I can't but make the assumption that Apple is focused on Quantity rather than Quality.
Of the 3 big browsers in Mac, Firefox is still, in my mind, the most solid. Safari suffers some serious problems, not the least of which is that it's only for Mac.
Apple wants to make the best experience for users because then they'll keep buying Apple products. If users want the web, then they make the browser better. If Apps are more appropriate, then they make apps better.
Apple prioritizes stuff users care about -- battery life > IndexedDB, accessibility > WebGL.
Until you understand this and stop thinking like a conspiracy theorist, you won't understand Apple and will keep confusing your priorities with user priorities.
Again: pleasing users -> profit. Making web lose -> ???
This isn't "embrace and extend" -- Microsoft added huge swathes of proprietary functionality to IE and tended (and tends) to prioritize developer and corporate IT desires over users. Insofar as Apple extends the browser, they do it through standards and proposed standards and (mostly) open source the implementations.
iOS users invest hundreds of dollars in apps and games and enjoy exclusive products. This creates a very significant barrier to switch to another mobile platform.
Quite obviously increased switching costs for users are important for iOS to maintain leadership in platform wars.
Therefore, rapid advancement of web apps user experience to the level of native apps in some categories would be detrimental to Apple's competitive positions.
Making web lose -> stronger competitive advantage.
It's totally awesome how Google created its Play store so that it seamlessly works on competing platforms -- after all it's a largely open-source stack that would easily run on (say) iPhones. No wait, they use it as a bludgeon to keep third parties in line (and create vendor lock-in).
Sure, it decreases user satisfaction for a SUBSET of users, who care about web apps. This subset seems to be strategically negligible for Apple. This is a trade-off which is absolutely rational from the shareholders/management perspective.
>It's totally awesome how Google created its Play store so that it seamlessly works on competing platforms
Your fanboyism shows. This thread is not about Google, also a corporation which actions are driven by interests of management and shareholders.
It's like Betteridge's Law for discussions involving Apple.
This thread explores the possibility that, for strategic reasons, new web stuff is not implemented on Safari. That proposition is scarcely undermined by hypothesizing a typical user who doesn't care about new web stuff as much as she cares about battery life. She's hypothetical, why should she care about anything as much as she cares about battery life?
There are diminishing returns.
It's not like Apple has provided a web browser that basically doesn't work but has great battery life. Most people consider Safari to be the best mobile browsing experience there is. (I just googled to make sure I wasn't quoting outdated opinions and it's still true.)
Safari in 10.11 has added a feature which tells you which browser tab is making noise so you can close it. Just now I was so wishing for it (in Chrome -- which is my primary browser, since I'm a web developer). Shame on Apple for doing that and not fixing bugs in their IndexedDB implementation! (BTW those bugs are horrible -- how on earth could they pass the simplest unit tests? -- and really should be fixed.)
> To you, the hypothetical malware vuln should be fixed before e.g. improving battery life by 5%.
Apple doesn't let users decide what's best for them... that's one of the things that's different about the company. Want to customize your UI? Nope, that's silly, you can't have it. Apple would decide what's good for the user and it would probably consider browser vulnerabilities more important than some obscure new feature.
> But to a greedy fruit executive who wants the web to be insecure? There's no question!
Good grief.
http://chrome.blogspot.com/2014/01/everyone-can-now-track-do...
Good grief.
The smiley b^) means it's a joke. At this point I have to wonder who is trolling whom...
(Especially with the trend to wide-screens, the placement of tabs on the top vs. the left side seems to me to be a gigantic misstep on everyone's part)
Not trolling -- just ignorant. (And the implementation is kind of flawed. Sufficiently flawed that I've never seen one of the icons. I wonder if Safari's is any better -- can't be bothered installing the beta.)
Not a big fan of your "b^)" emoticon -- doesn't look like anything to me, and doesn't show up in lists of common emoticons. But OK your most outrageous comment was in jest; fair enough.
I assume Apple is underinvesting in safari simply because they have bigger fish to fry, and they are notoriously understaffed with competent engineers (or have bad project management).
First because what they make from the App Store is spare change for them.
Second because they did have the best browser for a while, and did very much to advance the state of the art (from WebSQL, to Canvas, CSS 3D and other stuff, all originating there, along with the original fast-JITed JS engine who started the JS-race to what we have know). And they did that for years after they had an App platform available too.
People don't feel locked with their app purchases. Case in point, the large volumes of people going from Android to iOS and vice versa.
All without manufacturing logistics and hardware production costs. Obviously the computing infrastructure, payment processing and software engineering of the app store has a cost, but I'd imagine much less than those involved with building, distributing and selling a computer or mobile device.
It may not generate as much as hardware sales do, but billions of dollars hardly seems like spare change.
[1] http://www.apple.com/pr/library/2015/01/08App-Store-Rings-in...
That makes it around $3 billion, before taxes and infrastructure expenses, payment deals, etc.
$3 billion is spare change for Apple. They have 200 times than in cash.
As others have mentioned, there are other benefits from native applications, like vendor lock-in, which Apple isn't going to get with web-based applications.
[1] http://money.cnn.com/2015/01/28/investing/apple-cash-178-bil...
[2] http://www.apple.com/pr/library/2014/10/20Apple-Reports-Four...
Still, same order of magnitude, and still many times over their app profit.
>Also, I think its telling that Apple themselves mentioned App Store Sales as a main factor in their revenue earnings for Q4 of their 2014 fiscal year.
Telling towards what?
Its telling that App Store sales are a significant source of revenue for Apple. One that could possibly justify not making improvements to Safari that could make it better compete with native applications.
Back when the first iPhone was released Jobs was all "We have a great way for you to develop apps! ... HTML5!"
All the developers were disappointed and wanted a native API. So here we are.
Developing on Mac has always been a chore (at least back in the XCode 1.1 and 2.0 days), with poorly documented APIs and APIs that are just flat out broken (OpenGL comes to mind, and is still broken to this day apparently).
Our running joke back then was that "Macs are very user friendly, except developers don't count as users." Still true to this day apparently.
[0] http://www.artima.com/weblogs/viewpost.jsp?thread=13058
If you need functionality like you describe, ship a native application via an app store. It’s a much better experience than web development.
A side comment would be that you can make your webapp perform remarkably well on mobile, with things like HW accelerated transitions, local storage, etc...
I have pretty much ditched native office suites in favor of google drive as well on my desktop system.
And things like Facebook hasn't even considered native desktop implementations.
So it is safe to say that the web is a great app delivery platform (at least on the desktop) and as such, I think it is completely reasonable to improve upon it and extend this benefit to mobile.
That is a faf when you want to be cross platform though. With care I can write an application that covers pretty much all the users I care to cover, i.e. those using desktop or mobile browsers released in the last few years. In fact there are a couple I intend to develop once I've got certain other things out of the way that are eating my "personal project" time currently. Yes native apps have advantages, and for my projects there might be native apps later, but developing for browsers first (well, API first with browsers being the first major client) gives the best use of your initial time unless your app needs greater performance, access to hardware, or something else not possible/practical in the browser.
If Safari lags behind to the point where I can only support iDevices as secondary citizens (web first, followed by native apps for platforms that need them) then I am perfectly happy to do that. Thankfully that is a practical consideration, at least for my projects, unlike at some points in the past where not supporting IE6 locked you out of a much larger part of your potential audience then not supporting mobile safari does now.
If enough other developers take this route (Your platform doesn't work well unless I create something specifically for it? OK, I consider that later when I've got everything else working) maybe the direction of Safari will be forced to change in that respect.
On my end I don't want to have to download an app to do all the things I want to do. I keep as few apps on my phone/computer as possible.
Not all software development is making cutting edge social phone apps.
Apple, on the other hand, has no reason to want the web to flourish. They make money by selling hardware, and by managing a closed ecosystem of apps and services that revolve around said hardware. iAd focuses exclusively on apps, not webpages. Cross-platform web technologies that try to close the gap between web apps and native apps are a threat to Apple's bottom line. The more people abandon the web in favor of native apps, the more money Apple makes.
At least in the days of IE6, Microsoft didn't really care about the web. Apple nowadays, on the other hand, has every incentive to sabotage the web. I don't think it's just technological purism that makes them reluctant to allow alternate rendering engines to work on iOS. They need to ensure that apps are the only way for developers to bring advanced features to iOS users. Because they're not competing on the web like the others. They're competing against the web.
So it doesn't follow that they would want to stamp out or ignore the web. The web is a huge part of what customers use Macs and iOS devices for, and Apple makes the same amount of money on a piece of hardware whether you use it to browse the web or use the $0.00 Facebook app.
There's no denying that Apple wants you to buy into their ecosystem of apps: it helps bind you to their devices. But there's no incentive for them to extinguish the web.
No. The web was directly opposite to Microsoft's goals. Microsoft made money on operating systems and applications. If the web "won" then you wouldn't need a Microsoft OS any more, and Microsoft would "lose."I assume Apple is underinvesting in safari simply because they have bigger fish to fry, and they are notoriously understaffed with competent engineers (or have bad project management).
Factually incorrect, WinRT certainly supports HTML5 apps but it supports .Net and C++ too, all of the WinRT implementation code is either native C++ or .Net.
Safari's release cycle, however, is stupid per se.
Apple adds features based on what users seem to need, not what programmers want (Google) or programmers want to work on (Mozilla).
It should also be noted that Safari's accessibility support is head and shoulders above anything (including IE with dedicated third-party extensions -- our blind accessibility guy who has access to every accessible technology under the sun simply uses Apple devices at home).
Wake me up when IE is open source, Google gives flying f* about accessibility, and Firefox is better than a distant second.
So then let's name these things, specifically, if you really believe that. I'm not aware of any new specs related to animations in the last couple of years. Can you name them?
One thing I've noticed several times is that in chrome, many CSS animations aren't animated across sub-pixel boundaries. I don't know necessarily that safari does this (again, I'm not well informed here -- for all I know this has been fixed in Chrome), but if they did, that would count in my book, despite not being a new spec.
(Honestly, my suspicion is that they aren't though, since a high dpi screen removes most of the need for sub-pixel accuracy).
I use Safari for all my general browsing for one reason: It uses 1/2 to 1/5 the power that chrome does.
Here is a simple test I just ran:
Using https://github.com/erkserkserks/h264ify for blocking VP9
2015 rMBP 13", 3.1Ghz i7, 16GB (defaults to software rasterization in chrome)
https://www.youtube.com/watch?v=nK9Im1eP3DI (1080p60 video)
Power is CPU Package Total (core + GPU).
Chrome VP9: 26W
Chrome VP9 + Force GPU Acceleration: 28W
Chrome h264: 19W
Chrome h264 + Force GPU Acceleration: 13W
Safari: 4W
Additional comments:
This is all in window at the default 'theater mode' size of youtube. I can't full screen either of the VP9 options without completely maxing out the CPU, dropping frames and during my laptop into a frying pan. Its really hot even in window with chrome VP9 using ~175% CPU.
In other words, Safari's power number isn't surprising but I don't know how chrome manages to use so much processing power. Even my cell phone can decode 1080p60 without catching fire but chrome manages to bring a $2200 laptop to it's knees doing it.
I am curious, though, do the Chrome devs have access to the video APIs that the Safari people would?
I'm a Safari user who develops first and foremost in Safari, and I completely disagree with this. Chrome runs rings around Safari in UI animation performance, it's almost embarrassing.
Second: If you are going to involve me in this, then I'll point out that of course people care about their browser UI, otherwise everyone would be using something like Conkeror, except with an even more ascetic UI philosophy.
Fanboyism 101 2nd Edition
Chapter 1
How to spot an Apple fanboy 1000 miles away
Which is exactly what makes safari the new IE. Going it's own way and not even bothering to try to implement the new standards used in other browsers.
If web assembly is supposedly as fast as C, why can't we have web browsers with a smaller built-in feature set and implement new specifications as libraries?
It also won't help with Web Components unless you're aming for a Web where we just draw on a big canvas.
edit: not speed, but aesthetic quality and parity with Chrome/Safari
Firefox has gross UI elements that remind me of the 90s.
cf. http://murphyapps.co/blog/2015/6/24/an-hour-with-safari-cont...
As a developer, I would say they are just doing a few things differently. I think the web API and DOM/css should have a standard set that every browser has to implement in the same way. It's actually way way better than it used to be. However, I'm fine with additional api features as targeting browsers is not not difficult and may open up some cool features. Like perhaps native notifications API on IOS Safari, that would be sweet!
For the base Web API though, Safari has deviated on a few small things, but it's not really to the point where IE6 was.
Also, people will upgrade Safari. Unlike IE6, where IT shops would not upgrade because of Active X applications, Safari will at least be upgraded. So I think it's unfair to compare it to the old IE.
P.S., The new Windows Edge browser in Windows 10 is pretty amazing, it feels like Chrome. Very fast. And if you are not familiar with the Mozilla Servo project, it's worth checking out. It still has a long way to go, but down the line could be very interesting.
Here's an overview of what's new in Safari (WebKit) as it ships with OS X El Capitan: https://developer.apple.com/library/prerelease/mac/releaseno...
This is the secondary reason IE gained share quickly (the primary one being bundling, of course). Then Netscpae fell over and it didn't have competition at all for a while so MS simply stopped trying (why work to improve when there is no competition and you can use the resources to work on something else?) so IE gained even more share on Windows (other OSs were not large enough in the desktop market to figure at that point, and mobile browsing was embryonic) without any effort from MS. It wasn't until Firefox got to the point of being enough better to attract a large share that the tables started turning and even then the change was slow. Opera was significant around the time too, but it not being free (or not free without adverts) was a sticking point that stopped it being widely adopted.
That is a key problem that hopefully can't play out the same way these days though. No one browser, even mobile safari, is so commonly used that if it fails to keep up it can't start to be ignored, and away from iDevices we don't have the pure binary choice so if B doesn't keep up with A C and D probably will and B will be forced to (or it won't matter so much if B dies).
Safari, by comparison, is just behind the curve on some developer-centric features. But Safari also has some things going in its favor: in my experience, it's the fastest browser on OS X by a pretty wide margin. Chrome is so bloated and full of garbage at this point that when I have it open, I usually have at least one tab sitting at 100% CPU (and this is with FlashBlock enabled). Safari also manages to feel faster while using significantly less power -- I suspect Apple has done some optimizations through Grand Central on this front.
Safari on mobile is a bit of a different story; yes it has problems, but I don't know that supporting a larger feature set is the answer.
that's a understatement., working on ios safari has been a travesty: it steals a good 20% of view area and 25% of clickable area, it makes a mess with pages trying to be responsive by misreporting the viewport area, it has loads of bugs with resizing and orientation change events and just dies if one script in any page becomes unresponsive
Going the other way might be harder, but every rdbms is, itself, an abstraction over a nonrelational storage system of some kind, so it's clearly not impossible.
Chrome for Android is an app, not a system component, and does not require Android point releases to be updated. It is frequently updated on a regular schedule by Google and pushed out to devices.
Using sources like www.caniuse.com, I frequently find that Safari/iOS does not support a feature that is supported on Android browsers and desktop browsers.
When designing responsive in 2015, I limit myself to Safari/iOS, the worst browser I build for, then quickly and effortlessly make sure all other browsers work.
That's my reality, Safari/iOS is the worst platform to develop for for me. I can't even remember the last time Chrome/Android had any issues that weren't also present on Chrome/Firefox/Desktop. Safari iOS though, even with CSS Resets, even with custom CSS, always finds a way to be non-standard with text size, or font weight with bold, or some "feature" that breaks Safari and nothing else.
What about the other 50% of Android users that don't have Chrome or Chrome WebView? I've been working mobile for a few years now and would love to drop anything before KitKat, but that's not something feasible given market share.
In practice, pre 4.4 embedded WebViews have worse support for standards than Mobile Safari. Chrome for Android was in part a system component in order to replace 4.4's embedded WebView, only until 5.0+ did it become decoupled.[1]
Google's evergreen approach reduces fragmentation of a core API and it's been a godsend. I know in the future, Safari will be left alone as a pain point. Just don't misrepresent the present situation, where older Android has worse standards support than Mobile Safari and can't even be debugged in devtools.
[1] https://developer.chrome.com/multidevice/webview/overview
My old Windows XP box also has worse support for standards than Mobile Safari.
OK, so XP also doesn't have market share. But it's hard to blame older versions of Android for not supporting standards that didn't exist when they were implemented, just because people continue to buy low-end devices running those old versions.
Android Chrome has about 13.3% global usage, and all versions of Android Browser have about 6.5%. If we do not count versions before 4.4, then Android Browser has about 2.5%.
Also worth pointing out that Chrome for Android is over the 1 billion mark (1,000,000,000 - 5,000,000,000)
This is the big issue for most people, I think. I would love to use Chrome, but when I do, (a) thighs burn to a crisp if my machine is on my lap directly and (b) the battery depletes, literally, 1.5x as fast.
I should note that Epiphany is the only Linux web browser that seems to interact with touch screens correctly, drag-to-scroll works wonderfully on my XPS 13 meanwhile Chrome and Firefox just keep trying to highlight text.
> Safari is nowhere near that bad [as IE was in the past]
Doesn't address the problems developers are having.
> I have yet to run across a page that works in Chrome that doesn't work in Safari.
Try any webpage that uses WebRTC, and there's a growing number of these. But really it's because people are doing what they did with IE6 which is here is code that works everywhere, and here is some code to make it work on Safari so the user is none the wiser. The problem is still there.
> Safary, by comparison ... <insert swoon>
This has nothing to do with the post. Great you like Safari, but the problem still exists. Where's the WebRTC support? The Audio API? Right.
As to the original article, I prefer a 4th step not mentioned, just ignore Safari. Apple has a huge iOS userbase, sure, but as the HTML5 disparity between Safari and other browsers increase it's becoming increasingly not worth considering and really do iOS users even expect the HTML5 features that don't work in Safari? They'd probably prefer a native app for that.
Desktop users can use Chrome or Firefox when a site doesn't work in desktop Safari, and if that makes them mad, good. Maybe Apple will fix their shit then.
Edit:
Regarding downvotes: I know engineers are ignoring Safari. I ignore Safari, and other people I know ignore Safari. A convenient sample sure, but as this article points out developers aren't happy. Downvotes or no. Deal with it.
That's entirely the point: developers and users have different needs. But the developers will follow the users to whatever browser the users feel is best. Apple's priorities are on improving battery life, page responsiveness, etc. If users value Apple's browser development model that prioritizes user-facing features over developer features, then the developers will simply follow the users. If you want to build a product around features that a major browser doesn't support, go ahead.
To use the dreaded car analogy, you don't build a car to be easy to work on just to make the mechanics happy. You build a car that consumers want to buy, and it's the mechanic's job to figure out how to work on it.
That didn't happen with IE6. I think the web as platform is bigger than Apple as big as it may be. It's amazing to me that you're OK with a single company holding back the entire platform because of a single device. People use the web with machines that don't even have batteries.
Really to a developer who cares about the open web and standards, just throwing the whole concept of the web out of the window for the sake of Apple's priorities is so, so bad and it will never happen. At least that's my hope and prediction. The open web as a platform will guide my behavior with regards to how I engineer applications that run in the browser, whether Safari is on board or not.
Yes it did...but anyway, the detail is irrelevant; it's the point you're refusing to acknowledge:
A developer, building a product, is obsessed with growth metrics, OR, a slave to the pedantic demands of a client they're working for.
Either way, those demands require that a site be available to as many people as justifiably possible. The questions you have to ask are:
1) Is the the $ value of a customer using IE6 worth the time taken to make the site work in it? (No, almost certainly not)
2) In IE8? (Hopefully not, but you know, there are still a lot of these guys, and it's almost always a demand in the .gov space...)
3) In Safari? Yes. There are tonnes of these guys, especially on mobile where they don't have a choice, and no matter what fancy javascript 0-day API you're in love with, you can work around it without any significant effort.
The point:
Is safari holding things back? Yes.
Is it OK? Not really. It sucks.
Can you ignore safari and pretend it doesn't exist, and lose those customers? No. No you can't.
We're webdevs, sucking it up is what we're good at. We've had years of practice.
Suck it up.
The path forward, I think we'll find in the long run is going to be less native apis, more WebAssembly-style low level polyfills to implement new 'universal' features that run on all js runtimes.
Actually we can, and where I work we do. Never has anyone complained about it. SO everything is just fine. So I don't need to "Suck it up".
Yes it did. That's the entire reason IE6 was such a headache: IE6 was by far the worst browser platform out there, but everything in the corporate world was written with IE6 in mind. This made it a nightmare to support these sites -- because they didn't work in Firefox or Chrome. So when IE6 was finally deprecated, it was a mad scramble to try to patch internal tools (or hack an unsupported install of IE6) so your HR person could access payroll.
They might've done the math and realize that the amount of safari users they might gain is not worth the cost of the extra development (time & money).
You obviously do.
As we adulate Tesla for their accomplishments with battery technology, we often point out that battery life is a software problem, and that it involves a specific set of engineering tradeoffs. Apple is simply making those tradeoffs. And it has to.
Google make a browser that runs on everything. If one platform is slower than another, or has less battery life than another, blame the platform vendor. Google doesn't care. But Apple sells hardware. If a MacBook gets so hot it burns your thighs, they lose sales. If the battery life on an iPad is terrible, they lose sales.
Safari gives their users a legitimate way to enjoy web browsing on a cool-running system with long battery life. That sells.
It's dev tools aren't adequate for my use, but for being a user of other sites, it has been wholly sufficient.
For me it's just video perf, but the worst part is that it's Google own web services that are spinning up the fans, and their video services work 10x better in Safari!
I have a shiny new 15" Retina MBP, which heats up like a stove if I use Chrome to open a video Hangout or watch YouTube. So for work meetings I've made a habit of having my calendar always open in Safari so when I click the video link, I get the Hangout in Safari as well.
And Safari manages to not set my computer on fire, amazing!
That's a common misconception, but what actually happened was that MS implemented draft CSS specs which ended up being a bit different from the final standard. At the time they were extremely eager to pack new stuff in IE (including a state-of-the-art XML/XSL processor!), so they rushed in a lot of stuff before other players had agreed how this stuff should really behave.
IE was then basically abandoned. MS just refused to fix their engine to adhere to newer standards. By the time this became to be seen as a problem, Netscape was dead, IE was dominant, and they were busy trying to plug the ActiveX security sieve, rebuilding on .Net and finding an alternative to Flash.
In this sense, Apple have done exactly the same with Safari: they poured resources into it while they were competing on the desktop. Now they only care about iDevices, where they have no competition at the browser level, the priority is battery time, and stability (aka rot) is preferable over innovation. Look at Safari for Windows: they built it only to support iTunes, and basically dropped it when iTunes on Windows became fundamentally unnecessary.
They went ahead when they wanted to be in the game, now they own the game so their incentives are different. Exactly what Microsoft did back in the days.
But I'm sure this title gets you more clicks.
I'm in sympathy with the spirit of this post, but I'm not sure that I agree with this specific example. I think that there's a big difference between an 'everyday' web page requiring a specific browser, and the creator of a browser showing off what they see as its exceptional capabilities.
However much designers (and users) like adherence to standards, I think that it's clear that a lot of the innovations we take for granted have come from browsers leading the way; and there's not much point in having those innovations in the browser if the user doesn't know about them.
(I should be clear that I'm not advocating a functionality free-for-all, though; probably much more harm than good has come from this behaviour.)
That said, there are some cases where things are Chrome-only simply because other vendors are far behind. (eg. speech recognition & synthesis)
That said, I was just playing with Edge on Win10. Its like a pre-bundled Chrome. Fast, compliant, etc. It hilariously even breaks MS software, for example, I can't open the address book in Outlook Web Access because some deprecated html control that Chrome no longer supports. So if Chrome no longer supports, Edge doesn't either!
I guess we'll see if extensions ever take off for it. If they do I could see it hurting Chrome's marketshare. Personally, the Chrome/Google juggernaut needs to be knocked down a peg or two. I hope Edge gets popular just to keep Google's sometimes anti-consumer ambitions in check. For example, using FF in Android means Play Store links don't work right and a million other things. Google isn't incentivized to make alternative browsers work well in Android. They want use to use Chrome and all of its spying/tracking/marketing stuff cooked in.
But it's still better than Safari's IndexedDB support, though, even though they've basically not touched it since IE10!
The "Chrome Experiments" was a way to show off the WebGL capability in chrome that no other browsers had at the time. (Now those demos will mostly work in all browsers)
Plus you are forgetting that those are experiments. They were never really meant to be actual "apps". Making an experiment/demo for one browser is fine IMO. Especially when only 1 or 2 browsers have implemented the standard currently.
It's like webRTC. I made a "demo" webRTC app about a year ago, and it only worked in chrome OR firefox (but they couldn't talk to each other). That's not chrome or firefox breaking the web, that's the other browsers not being at the cutting edge, but i don't blame them. WebRTC was (and still is) VERY new, it wasn't even finalized and i was using the app as a bit of a tech demo to see what may be possible in the near future.
The chrome experiments were the same way. WebGL wasn't fully finalized, it was one of the first implementations of it, and people wanted to try it out, so Chrome Experiments was born.
I'm thinking, its almost time to consider WebRTC 'failure to achieve traction'?
The ability to do peer-to-peer communication from the browser is an amazing tool. It allows the creation of client-side-only web apps which can easily send massive amounts of data to others. With WebRTC (or any other service like it) you can add video chat to a web app with very little work, and no real server side infrastructure that is more secure than the alternatives.
If it needs to be re-done in the name of getting it implemented widely that's fine with me and i welcome it, but if it's just NIH syndrome at microsoft holding it back, that's not okay.
I've been dealing with the code base for 5 years, and never liked it. Had to rewrite the APIs every time we got a new source version, to fit our model which isn't the 'conference call' model. I'd be glad to see something more app-agnostic that just dealt with negotiating P2P streams, without so many assumptions about what/why/when the streams are.
Maybe some of the good ideas will end up in an improved WebRTC standard, but ORTC itself is not "the new version".
> still not widely adopted
Certainly everyone involved with WebRTC wishes that it had the support of IE and Safari, but Chrome + Firefox + Opera is nothing to sneeze at, particularly if you're targeting a savvy audience.
> Original two are not compatible
Maybe I'm confused, are you saying that Firefox and Chrome aren't compatible via WebRTC? I've used them together and had success, but just for basic video calling.
> not adopted in a single further browser in that time
This is fair, but if Microsoft's latest moves come to fruition that will be a big change. There are hints that Edge will likely support WebRTC[0], though I don't think there has been any official word. Maybe that's just for ORTC?
[0]:http://blogs.windows.com/msedgedev/2015/05/13/announcing-med...
Other products can do this. WebRTC suffers from being based on RTP/RTCP and SIP-style signaling. There's not enough juice there to get the job done.
AFAIK this is being fixed. Firefox should support the standard and Chrome is fixing their implementation to conform as well.
WebGL is a good comparison here - it was pretty dead before Apple implemented it. When they did (in iOS8) you started seeing a ton more WebGL things popping up.
I think one unfortunate aspect of the article is that it focuses on some of the less common deficiencies of Safari. I would have called out mobile Safari being unable to download files, or Apple's insistence against video codecs that all other vendors are aligned in agreement on when it comes to video.
No. If what worked before continues to work, it means it's not broken.
Also: What "very basic functionality" doesn't the latest versions of Safari support?
IE6 continues to work fine for what it supported originally as well.
To my knowledge, file downloads worked in all browsers prior to mobile Safari being initially released. So Apple did release a browser that broke some quite basic web functionality.
Regarding Apple's insistence on not supporting Ogg (Vorbis|Theora) (I assume that's what you're alluding to), those codecs were briefly recommended by the HTML5 standard, but were later dropped.[1] Again, I think its a stretch to say that Apple broke anything, simply because they resisted a proposed standard. I know a lot of developers were disappointed, but that's how committees work: You don't always get it your way.
[1] https://en.wikipedia.org/wiki/Use_of_Ogg_formats_in_HTML5
I think the analogy is very clear. If you want to code like it's 2000, supporting IE6 is easy, because IE6 is a very good 2000 browser. If you want to code like it's 2010, supporting Safari is easy, because Safari is a very good 2010 browser. But in both cases, if you want to use any new features that have been standardized and are supported by other browsers, you're fucked.
The main difference I see is that IE6 didn't get any updates at all. Safari gets updates, but many new features are missing or broken.
EDIT: Another difference is that MS never blocked you from installing a better browser, but Apple does that on iOS. That policy is becoming increasingly ridiculous...
In the case of Safari, I can think of canvas, touch (love or hate it vs pointer events it was before any of the alternatives), DPI independence, &c.
It's some of these quirks that seems to show how newer web standards might be rushed through by increasingly aggressive vendor involvement. Apple hasn't changed all that much from when it first released Safari. It's only our expectations for the pace of new additions that has.
Web dev was "fun" in the early 2000s.
Also console.log and javascript debuggers didn't exist. Working with complex JS got really interesting really quickly.
A major source of hatred for IE was the fact the IE team did work prior to the browser standards, a practice which is now standard operating procedure. Where would be without ajax?
Why has that not resulted in anti competitive behavior lawsuits? MS got in to a fair bit of trouble for similar things. They didn't stop you installing an alternative.
But then again that depends on how you define browsers...
This is not possible on iOS without a jailbreak, because Apple simply doesn't allow alternative browser engines to be used.
So, basically, a 3rd party JavaScript engine is not allowed. I guess you could write your own browser engine that doesn't support JavaScript.
I guess Flash was not allowed for performance and security reasons (lots of vulnerabilities, right?)
Thoughts on Flash https://www.apple.com/hotnews/thoughts-on-flash/
Apple has a monopoly of taste – a self-defining market that won't switch OSes even if that constrains their other choices. But they could, so the "market of Apple users" isn't a discrete market under the law.
[Edited: gosh I type slow.]
Maybe, maybe not. That is what the person I was responding to claimed though.
I don't believe it is reasonably easy to choose/install another operating system on an i device. I could be wrong.
>One person having an iOS device and another having an Android device does not cause any issues between the two, they are fully able to communicate by the nature of cell phones.
By the nature of cell phones? What is the nature of cell phones?
Ethernet existed in the 90's and I personally setup networks using it that allowed Windows and Linux systems to communicate with each other.
But the very idea that someone has to know this has to be done and disable iMessage is insane to me, and I suspect part of the reason it is the way it is is because Apple doesn't really mind what (to the average Joe) is a major annoyance when switching phones.
To be fair, matters were even worse before Apple released that tool. But this has been an ongoing issue for something like four years.
I wonder if Apple could really fix it any way short of asking the phone companies to know when someone switched.
So what Microsoft did that was illegal was use their monopoly power to destroy an existing player. That's how they were "anti-competitive".
While Apple not allowing any competing rendering engines to be written for iOS is anti-competitive in the dictionary sense that they are preventing competition to be created, it isn't the type of behavior targeted by anti-trust law.
(IANAL, but my understanding is that if Apple had removed Spotify, Pandora and other music apps from the App Store while releasing their streaming music service, that would be an anti-trust violation.)
*Netscape was $49 in 1996 http://www.fastcompany.com/27743/nothing-netscape
Even by the most generous definition of "computer", Apple holds 20% market share at most.
Samsung won't get sued for anti-competitive practices because you can't switch the browser on their so-called smart TV for the same reason.
This stuff is rampant.
IANAL but folks over reddit explained it as this:
Microsoft was a software only vendor in the past but Apple is the hardware and software vendor. US and EU laws dictate that the hardware manufacturer to have full control over the ecosystem becuase of the industry behaviour in the past and who the end-consumer pays his money to.
http://www.reddit.com/r/explainlikeimfive/comments/39q25f/el...
I am not sure how correct it is but at least it makes sense.
Web browser is arguably the single most important app on any phone. Or a computer. How many browsers you have currently installed on yours?
I should be able to install any browser on iPhone, just like I can on my Macbook.
While I was still using iPhone, that forced me to always reach for Android phone when I wanted to read any page with wrong size font for me. Which is pretty often.
IMHO, there's just one good mobile browser, and it's Opera. Not mini version, but the proper mobile one.
The big feature? It can always reflow any div (paragraph) text to 100% screen width. Always the font size I want and never any horizontal scrolling.
I hope Apple will finally allow other browsers that are more than just embedded mobile Safaris. Including full Javascript JIT support, because that's what modern web requires. Currently on iOS only app that can allocate executable pages is Safari.
https://developer.apple.com/app-store/review/guidelines/
"2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript"
Again, it doesn't allow them to be made as the 'default' browser - which in itself is a big reason to criticize them.
[0] : Chromium Bug: https://code.google.com/p/chromium/issues/detail?id=423444
Then I tested it in Safari. Two weeks later I gave up and basically had to `if (Safari)`. I don't know if the code still has that, but it probably does. This wasn't anything 'lacking'. Sure, it was contenteditable-related but the fact remains that I found a consistent subset in every browser except Safari.
So, yes, Safari broke my web - and it wasn't something that was missing, it was something that behaved very differently compared to other browsers. I can't remember what specifically broke it, but even ~2 years ago I had a significantly better development experience with IE than Safari with no new HTML5 features in sight.
[1]: http://help.k2.com/onlinehelp/k2smartforms/userguide/1.0.6/c...
Not only is IE8 a snowflake but html4 is particularly hard to get a good layout working. Lots of nontrivial layouts in pure html4 (and css 1/2) require tons of browser specific hacks.
But honestly, I can't know because he's not naming anything specific anyway, just an anecdote about how IE8 was great at being standards-compliant and safari wasn't. Which is such an extraordinary claim (and is so contrary to established precedent) that without any extraordinary evidence, I have a lot of trouble accepting it.
(And it's amazing how many people think "I'm not doing any browser hacks" while they're using something like jQuery, which is a library 100% devoted to doing browser hacks for you while abstracting you from that fact.)
I was working on top of a huge CSS framework - the majority of styling work I did was tiny tweaks to styles where the appropriate hacks had already been solved.
Also I didn't mention layout. The specific pain point was contenteditable in combination with JS - by the time I got to the code everything surrounding my little problem-space had been solved by the rest of the team. Again, specifically, Safari demonstrated wildly different behavior within that specific space, where other browsers only behaved marginally different (a relative term, contenteditable is a complete mess, sadly, still in HTML5) in a way that I could find a viable subset of functionality that worked consistently.
Well, that's the whole thing then, isn't it? The huge CSS framework probably had tons of hacks (as you say) to make things work in IE8... it's a bit disingenuous to say you wrote everything to be clean and without browser hacks, if the hacks all exist but are buried under a "huge CSS framework".
Your whole experience could probably be restated as "I was working with a CSS framework that did a bunch of cross-browser hacks for me, and the tweaks I made to it didn't work in safari", which is a pretty uninteresting statement, because it's equally likely that any issues you had in safari are the fault of the CSS, and not the browser. (In fact, much much more likely.)
Did you miss the whole of my second paragraph?
> Also I didn't mention layout
Something working in opera doesn't mean it is standards compliant.
(emphasis mine)
I use Chrome as my primary development browser and Safari and Firefox as my second and third choice. When I do get around to testing in IE 9+, it's almost an afterthought. Is it surprising then that IE is the browser that gives me the most trouble?
All browsers have quirks. It's inevitable when you have many competing implementations from companies that have different priorities. The browser you use the most is naturally the one whose quirks you will get used to.
The author is right, the details aren't the same but the same attitude exists. The author is simply speaking up before the differences become extreme.
Microsoft didn't "break the web" they created their own web and then let it twist in the wind because they were pissed about the government beat down.
Apple didn't get their hand slapped, but they did build something so lucrative that evolving Safari became a smaller priority, which some would argue aligns well with their push to the App/closed ecosystem model.
Moving to WebKit? Only if you count CyberDog, I guess. Safari was always WebKit based.
Also, your phrasing could be read as if Chrome came before Safari, but Safari is from 2003 (https://en.wikipedia.org/wiki/Safari_version_history), Chrome from 2008 (https://en.wikipedia.org/wiki/Google_Chrome_release_history).
Which is another instance of the Innovator's Dilemma: How can a successful company embrace technology that disrupts themselves?
It wasn't called SaaS back then, but in any case -- they let it "twist in the wind" because their market had become the enterprise, and that's a market that wants stability, predictability and no updates if they can be avoided. By then they had killed all competition, so their incentives were to keep businesses locked-in through backward compatibility and security fixes. Add to that the big move to .Net and an effort to replace Flash...
IMHO it wasn't about the antitrust or platform control (they could have broken all the SaaS apps they wanted with each update, they had 95%+ of the market and were n.1 target for every website out there). They just had other priorities: the browser war had been won and attention was now on the enterprise market. Around that time, IIRC, Gates also retired, leaving Ballmer in charge; Ballmer was not the sort of technologist to lose much sleep over "the future of the web"...
Everything is cyclical: Lean - Average - Bloated - Lean - Average - Bloated
- Chrome sucks up RAM like Photoshop.
- Firefox Dev Edition is broken or slow every other build
- IE is "ok"but their dev tools are incredibly sluggish and useless.
The browser game has changed and become commoditized. Before they went towards being monoliths with everything from email, to apps and games, various services etc. Those parts are being usurped by stand-alone services and apps and need to longer be integrated into the browser. I think that's good! Browsers should focus at being browsers. Better to be a 'la carte than bundle everything under the sun.
Also, I think the vision of HTML as a "universal" app/game platform is slowly dying. We're coming to terms with HTML is really good for somewhat basic presentation and interfaces, but not much more than that.
Although doing advanced stuff is possible it seems we're coming to the realization that it's neither practical nor performant
Then just use release? Dev Edition is the alpha version with some different defaults, based on the assumption that "developers" are OK with an alpha quality build that has some new features faster. If that bothers you, use the release. It also contains the dev tools!
I will readily agree that the evolutionary path of OSX seems to have gone off the rails. But hey, why do I use Safari instead of Chrome?
IE was a vast pile of shit for about a decade. It was pile of shit so high that Microsoft took out ads saying in so many words that its latest version "doesnt suck, honest". I tore my hair out for years over IE bugs. Fucking kids these days. Mobile Safari might not be as magical as you would desire but it is not even in the same league as the virtual genocide/superfund/WMD that IE was.
GET OFF MY LAWN
The worst thing MS did with IE was implementing proprietary, and very aggressively protected, solutions to common problems. Developers, excited about the new features, rushed to support what they felt was the next generation of web technologies, only to get caught in Microsoft's trap. Once they held the marketshare majority, they stopped innovating.
Safari is nowhere close to a majority player in the market (not even on mobile). Thus, it could never be considered equivalent to the evils of IE.
And yeah, the title is pretty clickbaity; guilty as charged! But my blog has no ads, so it's not like I'm making money off of it. I'm just trying to draw attention to what I think is an important issue.
As others have pointed out, it's all a matter of perspective. If you're trying to build for Web 2.0, then Safari is a fine browser. But if you're trying to build for Web 3.0 (or the "next web" or "appy web" or whatever you want to call it), then prepare to be disappointed.
Well, the reason for this is clear: offline web apps are supported in iOS but without a reliable way to store larger amounts of data, web apps get pretty much useless and so people have to go through the Crapp Store.
But, I have to defend Apple, IndexedDB is a ridiculous steaming pile of junk when compared to WebSQL. Writing a single-line SQL statement with multiple WHERE clauses and a couple ORDER BY, takes metric tons of boilerplate crap in addition to callback hell because the IndexedDB crap is async.
If so, it was a wise choice.
I agree with your assessment that IndexedDB is laughably bad in Safari, but maybe they haven't bothered because its really not such a great solution in general? I'm going to reassert that I think we could do much better - since IndexedDB is too low-level for what it is, but too specific for alternate solutions. I've been kicking around a blog post that I haven't got out yet - but we really need something more stream like and generic than a NoSQL index in the browser - especially something fundamental to address the future influx of WebAssembly apps. Cheers!
So where's their alternative spec?
What bothered me most about the IndexedDB fiasco with iOS8 is that Apple not only held out for so many years, but then they deployed a broken implementation. Anybody who had written an app using an IndexedDB shim either had a crashed site at best or lost user data at worst. YDN-DB author Kyaw Tun had the best quote: "I don't understand how they can release this."
Whether you like an API or not, a browser vendor should at least release it in good faith if they're going to release it.
Why wouldn't people just say "Apple?" Is this hyperbole or is there some reason why people are afraid to directly criticize apple at a conference that apple isn't even at?
The problem is that when everybody wants to discuss the hot new browser features, mentioning Apple is just a big downer. We all know we're going to have to polyfill at best, or just not support Safari at worst. Nobody wants to be reminded of that sad fact when you're trying to get excited about the potential of the web platform.
But what looks like constant innovation to one, is probably a long awaited feature to someone else.
Don't feel like you have to catch up. You don't have to (and probably can't) follow every single innovation. Rather try to limit what you follow. Yes, you might miss out on things, but that's happening anyway.
You can't force companies to stop innovating. Specially when history shows that, the best innovations survive in a sort of tech-evolutionary process.
Comparing a webkit-based browser of any kind to the agony of supporting something like IE6 back in the day is like comparing a paper cut to a stab wound.
Nice clickbait title, though, got you to #1, aren't you proud. :P
The real thing I'm worried about is that no one is working on an open app ecosystem. The only thing we have are browsers - which are horribly inefficient and have huge discrepancies with one another. We're so terribly behind.
Really, Safari's problems are just a symptom. The real problem is browser existence.
Oh, come on. Nobody does this. Why would anybody do this?
Hyperbole for effect is all well and good -- and the clickbait title makes it quite clear that that's what we're wading into here -- but this borders on self-parody, like saying MICRO$OFT or chanting "don't be evil!" or "WWSJD" it makes you look like a partisan rather than someone with a valid point to make.
Safari does lack IndexedDB, and their 'powersaver plugin' thing has caused me headaches. Firefox is the most likely to go unresponsive under CPU load, IME, and a nasty growing habit of pushing new monetization strategies into their toolbar. Chrome has poor performance, broken video event handling, and is the one that seems most likely to break my app every time they push an update. IE8-11 have various issues with animation and SVG, and most irritatingly there are four versions of it still in active use, each with their own quirks. Edge is, I'll guiltily admit, not really on my radar yet, but I'm sure it'll have its advantages and disadvantages as well.
None of them are the new IE. Even IE isn't the new IE. There's never going to be another IE6 for the web -- we've all, developers and customers alike, learned the lesson about proprietary extensions and platform lock-in.