Recently the news broke that Microsoft may be working on another browser instead of IE. After reviewing the available evidence I’ve come to the conclusion that, although Microsoft is making a few adjustments, and a name change for IE might be a good idea, the new browser will essentially be IE12. Still, I think we web developers should support the “new browser” narrative.
This is how you start an article. I didn't read any farther, but my already high opinion of quirksmode.org is even higher.
It's probably one of the reasons why the BBC News website is popular. All articles were originally written so that the first three or four paragraphs could be cut off, and presented as full articles on teletext (a tv text service), so the whole story had to be summarized within that space. They still write their articles in that way, even though teletext is increasingly un-used.
I should say, though, that it does mean that the content of that summary, and of the headline, becomes extremely important. For instance, you could nominally cover a news story, but write a boring headline and summary, and very few people will trudge through that to find the really important details later on. You do sometimes find that occurring on the BBC site, especially when it's a story which might raise a lot of controversy within government.
Teletext was pretty big in the 90s before broadband took off. It was easily accessible to a lot of people, including older viewers. Television was the primary source of media for a lot of people (followed by radio and newspaper), and Teletext was pretty much the only way to get near real-time updates of what was happening at any point in time.
I used it pretty much daily in Sweden back in the 80s and 90s to check news, broadcasting schedule, weather, etc. There were a few hundred "pages" and each page had a 3 digit number that you'd punch in to retrieve it.
Absolutely agree. I cringe every time I see a long blog post with a self-effacing "tl;dr" block, especially when it's placed at the end of the article. Just follow this "journalistic" style instead and you'll be doing the reader a big favour.
Yeah, the first paragraph summarized the entire article, which is incredibly respectful of the reader's time. Presumably many sites intentionally leave this out in order to maximize revenue and "engagement."
It would save more time and avoid the appearance of impropriety if they declared their Microsoft sponsorship in the second paragraph, rather than after the article.
Edit: if it's unclear, this is not accusing anyone of bias: good writing should make any involvement in the subject matter explicit. See http://en.m.wikipedia.org/wiki/Appearance_of_impropriety The article is sponsored by modern.ie which is a Microsoft initative. I happen to agree with the article, however being forthright about these matters would strengthen its point.
No, it would just waste everyone's time. Why would you intentionally want to preface the meat of an article with disclaimers like that, especially if (as you say) the disclaimers wouldn't actually affect your interpretation of the article? That's pretty much the definition of cruft.
Although he left out all the details, after the first paragraph you know enough to decide whether you want to read the rest of the article or not.
The "inverted pyramid" someone else linked to here means that the information is presented from most to least important, so you can stop reading the article anytime when it starts to bore you, and still know you have read everything you want to know.
One of the things I really want to see is both IE and Safari move to the six weekly update cycle that Firefox and Chrome are using.
IE still has a major slice of the browser market share and this probably ain't going to change soon. IE>9 have all been decent browsers for the time that they were released, although they do seem a bit out of date 6 months later. At the moment, if both Firefox and Chrome implement a new web platform feature, it's often available to ~60% of web users within three months because of the release cycle and auto updates. IE going to a 6-week major release cycle could probably push this up to 80%-90% of users getting a feature within three months, which would be awesome. (IE mobile is pretty small for market share, so I'll ignore it at the objection of my Windows Phone using friends.)
Safari pretty much now works on a yearly major release cycle - which is better than waiting two or three years, but it still sucks. Switching on Mac OS X to Chrome or Firefox (or Opera) is simple enough. iOS, however, is pretty much limited to whatever mobile Safari happened to have when WWDC rolled around (save for minor updates whenever iOS 8 becomes 8.1, for example). I sort of hope Apple uncouples core app versioning and updates from iOS and Mac OS X updates soon, because that's mean they could move Safari to a much shorter release cycle. iOS Safari is probably the most widely used mobile browser, and keeping it at the bleeding edge would do wonders for the mobile web.
I firmly believe that Chrome's day one feature of in-place auto updates was one of the most important milestones in web browser development. The accelerated pace of fractional improvement and implementation of new standards (even in draft form) has been enormously powerful for the web as a whole.
IE is like the hare. It sprints ahead with each massive update, but then sleeps for a year or more, only pushing security fixes via Windows update. Chrome is the Tortoise, forever moving, always making progress.
One of the things I really want to see is both IE and Safari move to the six weekly update cycle that Firefox and Chrome are using.
Whereas I would really like IE not to do that, and ideally Firefox and Chrome to move to longer cycles (minimum 6 months, preferably annual) for their main public releases.
One good reason for this is that there is no point in having browsers support new features within moments of someone conceiving them unless developers are also keeping up with new developments at the same pace. Take three major browsers on a six-weekly cycle and you literally need to be updating your skill set every two weeks and have projects to work on where those new skills are actually useful. Unless all you do is write trendy web development blogs for a living, you are not likely to be in this category.
Another good reason is that both Firefox and Chrome have horrible records for quality since going to six-weekly release cycles, both in terms of bugs/regressions and because they frequently implement new features that tick boxes but have such poor quality of implementation that they aren't actually useful for production work anyway. For example, right now, both Firefox and Chrome have numerous glitches and performance problems in popular HTML/CSS features like animations, web fonts, multimedia elements, and SVG, to the extent that you can't reliably assume even relatively simple applications will work without extensive and ongoing testing.
Recent versions of IE stand in sharp contrast to that pattern, and as such I think IE now provides both a valuable brake on the industry and a demonstration that having a solid, fast implementation of some features is far more useful in practice than having unreliable and/or slow implementations of more features.
(Edit: It's disappointing to see multiple downvotes yet no responses. This happens all too often when I express the unpopular-but-based-on-hard-data view that Firefox and Chrome are often slow and/or buggy when it comes to new features, even though numerous articles and blog posts giving specific examples in the areas I mentioned are yours to read for the price of a Google search.)
Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs. Lets take a look at the last 4 releases of Chrome:
What argument could be made that longer release cycles would mean less bugs? Is there going to be better QA? More stringent testing? Why would shorter release cycles mean less testing?
No, longer release cycles would mean similar number of bugs, and security holes would just sit out there longer. Chrome and Firefox is an example of doing it right.
Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs.
Serious security issues should be fixed as soon as possible anyway. This has absolutely nothing to do with a regular schedule for planned releases, and all of the major browser developers will already issue an immediate out-of-band update for a sufficiently dangerous vulnerability.
What argument could be made that longer release cycles would mean less bugs?
Well, for one thing, you can't regress something if you don't change it. Both Firefox and Chrome typically introduce a bunch of breaking changes every update. Sometimes these are unintentional bugs. Sometimes they are deliberate policy decisions, and in this case newer features are at far greater risk of backward-incompatible changes, as with the CSS syntax and multimedia controls examples I mentioned in another post to this thread.
The thing is, if your site/app used to work and it doesn't work any more after your customer updated their browser, and now you're getting paged in the early hours to be second/third tier support, it is highly unlikely that you care about niceties like whether the browser developers consider the change to be desirable. So if nothing else, every time every browser pushes out a major update, a lot of people building sites or apps need to be testing that their own projects still work, which is clearly a much greater overhead if you do it eight or nine times per browser per year than if you only have to do it once or twice.
You can, but you still have to test against N different versions per year instead of 1, which is still an N-fold increase in testing overhead compared to annual releases.
You can automate some aspects of that testing to reduce the burden. However, in the nature of web sites, some things will always need manual examination. No unit test is going to tell you that Chrome has a layout bug where your element that is styled to have a 100px width is being calculated at width 50px anyway and your entire home page doesn't render properly as a result, nor that resizing a responsive page in Firefox so it satisfies different media queries and then changing it back to the original size might result in a different layout (both real examples I've personally seen in recent months, BTW).
I'll give you an upvote because I hear what you're saying; keeping up with new browser features is tough if you've got other things to do as well. But, you don't need to incorporate every new feature into your own web projects, and you don't need to follow the same rapid release cycle as the browsers.
If my project has an annual update cycle, I want to be certain that any new browser features I'd like to use are widely supported and have been tested in-the-wild for as long as possible before I commit to them. The rapid release cycles of the browsers gives me that, and also ensures that there will be blogs and StackOverflow questions providing useful documentation on the best ways to use the new features by the time I'm ready to learn about them.
But, you don't need to incorporate every new feature into your own web projects, and you don't need to follow the same rapid release cycle as the browsers.
Sure, but then if the features aren't going to be incorporated into new projects almost immediately, browsers don't need to push out new releases (and the attendant risk of regressions) every few weeks either. The biggest claimed advantage of the rapid release cycles doesn't stand up to scrutiny.
If my project has an annual update cycle, I want to be certain that any new browser features I'd like to use are widely supported and have been tested in-the-wild for as long as possible before I commit to them.
That seems perfectly reasonable to me. Unfortunately, I think it's also reasonable to assume that lots of other people who might be interested in that same feature will behave the same way. It's therefore not reasonable to assume that those new features have in fact been thoroughly tested in-the-wild before you rely on them.
A related concern is that with the very rapid release cycles, you never really know when an implementation is "final". We've seen fundamental changes over recent years in everything from the syntax for new CSS features to the layout of controls on multimedia elements, sometimes more than once in the same browser within a few months of each other. At least if you ship functionality updates several months apart you offer a degree of definitive behaviour and stability.
also ensures that there will be blogs and StackOverflow questions providing useful documentation on the best ways to use the new features by the time I'm ready to learn about them.
It seems you've had better luck than me. I frequently find that when we run into issues with relatively recent developments in browsers, there are a handful of other people writing blog posts or writing SO questions that show we're not alone, but no-one actually has the answer.
It's also worth considering that just because the main production release of a browser only updates, say, annually, that doesn't necessarily mean that the browser can't also have developer releases going out more regularly for those who want to experiment with new features.
Valid points. I think each new feature will likely interest a different set of developers, so the feature can still get pretty wide testing even if a lot of developers choose to wait for it to mature, or choose not to use it at all.
I do agree with your points about the rapid release of browser bugs alongside the new features. I've had multiple occasions where clients have told me "You changed something and broke the site" on a project I haven't been working on, only to find out it's only broken in Chrome. My response to them that it's a bug in Chrome that's been reported, affects lots of websites, and will probably be fixed in a few days/weeks, and there's little or nothing I can do about it, is never satisfying.
Chrome and Firefox don't support features within moments of someone conceiving them. I've seen discussions about what features will be coming to Chrome in the future - rarely does a feature take less than six months to go from idea to stable implementation in Chrome. Firefox is a little different because Mozilla is pumping APIs into Firefox OS and then moving them to the main Firefox browser.
IE has issues with implementations even with their slow release cycle, as does Safari. While in theory a quicker release cycle probably should result in less stability and more bugs, there doesn't really seem to be this correlation in practice. A good way to check this out is to have a look at caniuse.com and see which browsers have issues with feature implementations (although caniuse is lagging behind a bit of recent). IE, Firefox, Chrome and Safari will all have issues. To Apple's credit, Safari is the only browser which seems to be willing to regularly remove buggy features.
While in theory a quicker release cycle probably should result in less stability and more bugs, there doesn't really seem to be this correlation in practice.
Anecdotally, the bug tracker for every major project I currently work on would disagree. That's a fair range of projects, using very different sets of browser features but including quite a few relatively recent developments.
A good way to check this out is to have a look at caniuse.com and see which browsers have issues with feature implementations
Caniuse is great, but it's not even close to the level of detail I'm talking about here. For example, it currently lists no known issues with HTML5 video elements, where IIRC one project I work on that uses that feature extensively was tracking 17 related open issues as of a few days ago, including at least one for every major browser.
When I write about that kind of experience, I sometimes get asked why we don't do more to support the browser developers by filing detailed bug reports when we find these issues. Sadly, the answer is simple: the projects I work on all have relatively small teams and would literally have to hire another full time employee just to report browser bugs, because we find that many. And a heavy majority of them are in Firefox or Chrome.
It's a good idea to create a new browser that updates automatically every few weeks like chrome rather than IE, which normally can't update automatically because of corporate policies.
IE 11 has automatic updates, check out its "info" dialog! Though I saw several corporate PCs where the admins turned the autoupdate off.
Older IE got updates through Windows Update. The last IE version for WinXP was IE 8.
If IE 12 doesn't come with a transparent IE compatibility mode and just starts a IE 11 window, corporate admins will probably set IE 11 as default browser.
So developers of enterprise websites are stuck with IE 11 and its almost finished but a bit broken HTML5 support for years to come :(
It would be really nice if all browsers had an expiration date. If they haven't been updated in 12 months, they simply cease to operate in any way except to update themselves.
In which case I nominate you to field the billion support calls from people confused why their "Internet" is broken. No rather just silently update it.
But then corporations will simply disable automatic updates for PCs under their control. Don't underestimate the stubbornness of corporate IT departments!
Yes but... I used to work for a large financial institution that wouldn't let any of us do anything to our computers so we were all stuck with outdated IE that didn't update itself automatically
As a web developer, the reason for the problem is irrelevant. If your users are using an older browser, it doesn't matter why; you still have to support it. You and they probably have little influence over changing the policy.
It's a good idea to create a new browser that updates automatically every few weeks like chrome rather than IE, which normally can't update automatically because of corporate policies.
If IE is there primarily to access the corporate intranet and other work-related sites, as usually seems to be the case in this kind of environment, then that stability is a feature, not a bug.
The last thing you need as a sysadmin for an organisation with thousands of members is someone who thinks they know better "upgrading" their browser to a new version that no longer works properly with critical business sites/apps, has unknown or at least untested-by-IT security issues that therefore may or may not require mitigation at corporate tooling level, and so on. This is particularly true if, as almost invariably seems to be the case, that individual won't be the person who takes the flak when something breaks, violates regulatory compliance, creates a security problem, etc.
I doubt there is a single organisation anywhere in the world that has IE locked down at corporate level, yet where any legitimate business purpose would be better served by having browser software updated every few weeks.
I've heard once or twice that, after one of the IE-related antitrust cases, Microsoft has been imposed a pretty heavy official procedure to release a new version of IE, that contributes to the slowness of the release cycle.
If that's real, I wonder if this fork could have the additional benefit of circumventing this procedure.
ActiveX isn't a major concern, in current IE if you look in the security tab in the Internet context, it is pretty locked down and damn near depreciated.
Intranet is more liberal. But a lot of enterprises add their internal portals to the trusted list if they still depend on ActiveX (as a depressingly large number do).
Chrome and Firefox's extensions are better. Although Firefox's extension model is a little clunky due to how old it is (or at least it was last time I used it).
Chrome and Firefox's extensions are better. Although Firefox's extension model is a little clunky due to how old it is.
New-style "Jetpack" add-ons in Firefox and add-ons in Chrome are very similar. I have the same add-on for both platforms, and there's about 80% code commonality. If Microsoft does something reasonably similar, that would be convenient for add-on developers.
If Microsoft kills ActiveX in the new browser, it will force everyone to stop depending on ActiveX. You would be very surprised how many websites outside of the U.S. still depend on ActiveX, and these are critical websites like banking and government. Hence, killing ActiveX support is important to me.
Yes but a good browser with Chrome's features will be a great alternative. Right now Chrome has become a big memory hog and is slowly going to competition with old IE.
If you're having memory problems with Chrome, check to see if you have AdBlock Pro installed - it often results in vast amounts of additional memory required for Chrome[0]. I recommend µBlock[1] if you're using Chrome - it works quite well in my experience.
Lack of an addon architecture is what completely killed IE for me. No adblock is a no-go. (It's also the non-idealogical reason I use FF on Android: Chrome is locked down.)
Right but as I understand, it uses some binary hacking/undocumented APIs to go about it's job. I also use Vimperator, various tracking blockers, search redirectors (disconnect me for Google search), etc.
There are definitely supported APIs for extending IE (starting with IE 4.0 in 1997), but you do have to write native or .NET code, it's not "hack together some javascript and CSS" like Chrome/Safari/Firefox.
Possibly because he knows JS+CSS, but not C, C++ or C#.
Or possibly because the API's microsoft proposes are pretty horrible; I've worked on FF and chrome extensions, and I investigated IE support - but IE's extension model is truly terrible. Just take a look at that stackoverflow link you posted. What a mess. I wouldn't mind a clean C++ or .NET api, but the current API certainly isn't that.
Because the latter is a lot quicker to get started with. I'm not making a value judgement.
With the IE model, you need to create a VS project, add a ton of boilerplate (see that stackoverflow example), and generally it's a ton of work just to get started. With a Chrome extension, you get an itch (some website has some jank, or you just want to hide all images with a certain dimension), you peek at it with the inspector, write some lines of JS or a custom CSS file, add an XML file and you're good to go.
Being able to write a quick hack to scratch an itch makes the Chrome/FF/Safari model more approachable. Once you have your foot in the door you're then more likely to make the step to write a full-featured extension (your MVP gave you a bunch of ideas).
It's similar to why PHP is popular. "I have this HTML page and I just want to add this one dynamic visitor counter. Do I want to build a Rails application, or paste in 3 lines of PHP and change the filename extension?"
They should go full-circle with FrontPage (which inspired many folks to get into web apps back in the day) and call it Vermeer.
(From Vermeer Technologies, Inc., the original FrontPage server extensions folks - fun random fact: it's why SharePoint service URLs have "_vti_bin" in their path)
Eh? IE9 isn't the latest version available for any version of Windows.
8 is the latest for XP/Vista
11 is the latest for 7/8/8.1
9 is still popular because not everybody upgrades browsers, but giving users who don't upgrade browsers a new option is unlikely to be helpful.
Communicating to them that IE is going away and that they should upgrade to a modern browser, "Spartan" or otherwise, would possibly help this situation, as the author suggests.
My initial thought was it will be a stand alone version that you can download and run next to IE6+ instead of Chrome, FF, et. al.
So instead of replacing IE6 with the competition, replace it with Spartan and MS gets to keep their browser market share and Corp IT can keep running IE6 apps.
For some reason, I immediately pictured a product rewrite gone wrong and causing two versions of the same product appear, because the new one can never catch up to the legacy quirks of first.
Does anyone have idea if the idiocy of integrating the IE browser so deep inside the os is finally solved, that version updates are possible? And will spartan be stand alone binary, like IE should have been at launch?
IE is to Windows as Webkit is to iOS; it's componentised HTML rendering.
The whole browser choice lawsuit business was strange; it was far from the worst bit of anti-competitive behaviour, and has been superceded by closed platforms on phones. The "halloween" documents and funding of SCO were more objectionable to me.
There was a backstory. Janet Reno's DoJ forced Microsoft to sign a consent decree that forbade them from tieing products to Windows but allowed them to add functionality to Windows. Therefore, IE had to be a feature of Windows not a separate bundled product.
Otherwise, in the eventual anti-trust trial, Microsoft won the browser case 2-1 on appeal.
I don't have a good understanding of the history of IE but thought it was embedded as a way of breaking Netscape - if that was ever true the time has obviously passed for it to remain deeply embedded. However if this was the reason, isn't that a good argument for the way MS constructed IE (which isn't to say I agree with the strategy)?
IE was deeply embedded because it was created in the bubble of "web all the things!" so they went so far as using IE the renderer for the desktop wallpapers and the file browser (IIRC you could even set a custom index.html for a folder on your harddisk)
The root of it was that Microsoft thought of the web browser as a kind of competing alternate OS-on-top-of-the-OS (which, in many ways, it is - the OS and browser each feature their own arguably duplicative/redundant UI frameworks, launching/switching mechanisms, etc). They didn't think this situation could last - either the browser would be subsumed into the OS, or the OS would be subsumed into the browser, or they would merge somehow. This belief was shared by others at the time (e.g. Marc Andreessen's famous declaration that the web would reduce Windows to "a poorly debugged set of device drivers"). So everything they were trying to do with IE and Windows was based on the intention that the distinction between them would gradually disappear.
"Breaking" Netscape? A stand-alone application? Really?
Anticompetitive maybe, but Microsoft embedding IE into Windows didn't break Netscape or other browsers in any functional way from my recollection (and I was using NN 2/3/4, Opera, IE 3/4/5/6 on 28.8 and 56k modems at the time).
It was the fact that it came with windows and free that broke netscape. That the rendering engine is so embedded in the OS that the question is "will we be able to bring IE X to platform windows Y at all" is just stupid.
MS prevented vendors from bundling Netscape in Windows. MS used the fact that IE was tied so deeply into the OS as a reason for not being able to unbundle it. MS used APIs to favour IE over other software - MS made their OS work better with their browser than with other competitor browsers.
Rumors say it's the same rendering and javascript engine but the UI will get more similar to Chrome and FF and there'll be extensions. Also yeah no backwards compatibility it seems, and more regular updates. Sounds good to me.
I don't think this is a good thing at all. People choose to use different browsers partly because they have different UIs, and UI changes are particularly jarring as evidenced by all the "I'll use browser Y" complaints when browser X changes something about their UI... only to be followed later by "I'll use browser X" when Y changes. There's no longer any real choice, it's just an illusion of choosing between narrowing alternatives.
Especially to see browsers' UI turning into clones of Chrome is sad, since I personally hate the "hide everything away that could possibly confuse users" and the associated "treat users like idiots" mentality that's particularly prevalent in browsers today. IE is one of the few browsers remaining that had relatively more UI, but I'm not surprised to see it disappearing... the trend seems to be to turn browsers into glorified televisions, with UIs like this one: https://news.ycombinator.com/item?id=8670503
When IE6 came out, it was a breath of fresh air; the fastest, most stable, most featureful, most standards-compliant browser available. It was the final piece of the puzzle that let corporate developers move away from desktop apps and onto the web wholesale.
Sure it has overstayed its welcome. But I hate the revisionist attitude of some, who were still in school when all this went down.
I don't mean this to be a personal attack, so please don't take it that way, but comments like this read to me as being written by a young, inexperienced programmer. I happen to know that this is not your case, but without checking the username, I would immediately classify this comment as such.
The people over at Microsoft are not idiots - even though Microsoft is no longer the new hotness, they still pay developers well, and have some pretty tight engineering going on. So when you say "The Event constructor is broken out of the box", my first instinct is to assume that the Microsoft engineers have implemented the constructor in their way for reasons that you're not smart enough to have grasped.
But, as I said, I know that you aren't a young inexperienced programmer, so you probably have some good reasons to make the claim, which leads me to the point of this rambling post - why is the Event constructor broken in IE? I'm curious to know what specific problems you have with it.
Sorry, I didn't provide details because I probably just assume everyone here is a JS developer, which is probably a bad idea.
IE11 has no CustomEvent constructor. You have to polyfill it with https://developer.mozilla.org/en/docs/Web/API/CustomEvent.
Microsoft's official Twitter account @iedevchat has pointed people to the same one: note the article article says for IE10, but the issue and fix is required for IE11.
It's a simple fix, but CustomEvent is ancient, and it's surprising what didn't make it into IE11.
Any competition is good competition, no matter what the quality is. Or do you want a single monopolistic choice of Chrome to rule the world? Sorry, bit we've been there before. Embrace the variety.
Variety is good but Microsoft has an ugly history with standards and that is very hurtful to the ecosystem.
They promised that they have changed in regards to that, but those are just words in the wind, time will tell on that. Also, they were lagging behind HTML5 standards for a long time, then they sort of caught up, now they are lagging behind on ECMAScript 6 features.
Every time I check, it is Microsoft's fault that I still can't use an otherwise widely implemented feature.
Quality implementation and standards adoption is the name of the game in the browser market. After 10+ years in that market, my opinion is that they have neither. The only reason they are still playing is end-user and corporate inertia.
> Variety is good but Microsoft has an ugly history with standards and that is very hurtful to the ecosystem.
That's no longer the case.
> They promised that they have changed in regards to that, but those are just words in the wind, time will tell on that.
No, they aren't just words. For example, in the ES6 committee everything I've heard is that Microsoft has been doing fantastic work, right now.
> Quality implementation and standards adoption is the name of the game in the browser market. After 10+ years in that market, my opinion is that they have neither.
I don't think that's fair either. The implementation of canvas in IE9, for example, is a very high quality Direct2D-based GPU implementation. (D2D is still arguably the best widely-used GPU vector graphics implementation around.)
At this point, Microsoft has pulled the plug on so many of its products & services over the years that developers and users are cautiously avoiding everything it puts out. Even if it's good.
From Zune (iPod competitor), to Kin, to Origami (small touchscreen laptop), to Games for Windows Live (steam competitor), to Live.com (google competitor v1), Bing.com (google compeititor v2), Expo (craigslist competitor), whats-it-called? (twitter competitor for natural disasters), Expression, Silverlight (flash competitor), Windows Live Spaces (wordpress competitor), Windows Phone...
Microsoft loves to start things, then leaves them to rot.
Google abandons projects swiftly when they think that don't make sense; Wave, iGoogle, Reader, Glass?, Buzz, Plus?, Answers, Google Video, Google Checkout/Wallet, Orkut, Picasa, Gears, etc... When you are a large company you need to focus your resources into areas where you can be effective and not stretch yourself too thin.
But they are. Keep, Fit are prime examples of stretching but offering a mediocre "service".
The way I see it, Google turned hard into a direction from building services with APIs into data collection silos. Google+ with Photos, Keep, Fit, Now. The data is even isolated from each other or really hard to access :
- you can't access Keep data anywhere, or what you upload on it
- Google+ Photos are available on web, not in Drive. You can see Drive photos in it, but you can't edit them with auto awesome
Fit is so basic that it offers practically nothing that it doesn't already exists out there. Data representation is in a form of one graph of total calories/steps. It does require you to enable location tracking though, to be able to automatically track steps/workouts (how suprising), which takes a major effect on the battery life.
FYI you can access Keep anywhere at keep google.com Other than that I do agree with you in part, there's a few things now with multiple incompatible implementations and it'd be really nice to see them tidied up and merged sensibly.
They haven't yet, but with Android Wear replicating its functionality while being much less expensive and more socially acceptable, it's not hard to see that Glass doesn't have much of a future.
Microsoft also has tons of product they supported for years. From Windows, to SQL server, to Sharepoint, to dynamics, to Office, to Visual Studio, to xbox, to ...
Also live.com rebranded and bing,WP are still alive and well funded.
If you look for a company to never shutdown a product which isn't getting traction, you are living in a dreamspace and need to wakeup.
To be fair, the original Xbox was quietly removed from store shelves and software development halted immediately after the 360 was announced. Contrast this with the average console support cycle of several years into the new generation.
Probably referring to Windows Mobile. The platform that came out of nowhere, killed Palm and got total PDA/smartphone dominance... then suffered the IE fate because terrible management decided to remove resources since they had "won".
Not everyone remembers, but it was viewed as near-impossible to dethrone Palm, but inside of what, 5 years?, MS had Palm selling WM devices.
Yeah, Bing and Windows Phone are still going but Bing is losing $3 billion a year, and Windows phone is losing market share despite sales increasing. It's only a matter of time before their plugs are pulled.
Chances are that Bing and Windows Phone will never be pulled. They are there because Microsoft has to be in certain markets, regardless of actual performance, in order to sell its technology stack as fully-featured and comprehensive. In the same way, Xbox will never be pulled.
Microsoft can drop the occasional service, but they rarely run from big platform bets. Most above-mentioned products were small fish or even just websites -- with the exception of Silverlight (but that's because in-browser media plugins as a category have been basically obsoleted across the whole market) and Zune (again, mp3 players have been basically obsoleted), they don't really sit on the same shelf as Office, Windows, Xbox, Windows Phone, Bing, VisualStudio or SQLServer.
Where did you hear that? This is from June 2014 [0]:
Unfortunately Microsoft does not break out its Bing revenue separately (and a Microsoft spokesperson referred us back to the earnings release when asked) so exactly how much Bing rakes in is anyone's guess, but the company did note Bing managed a 40% ad revenue increase in its recent fourth quarter ended June. CEO Satya Nadella, one-time leader of the division, also noted Bing would reach breakeven within two years.
Microsoft loves to start things, then leaves them to rot. The Micro-Cycle...
You seem to be claiming this is going to happen to IE as well? Seems a bit far fetched, given it is still used by millions of people and something like 20% of all desktop browsers used is IE.
This is how you start an article. I didn't read any farther, but my already high opinion of quirksmode.org is even higher.