It seems to me that one reason IE declined was because developers hated it. So we stopped using it, we stopped relying on IE-only features, we started implementing features IE didn't support, we threw our weight behind alternatives, and we labeled IE as uncool. Maybe I'm overestimating how big of an influence we were, but I don't think our influence was trivial, either.
That's why I'm kind of surprised that this preview of Spartan is not really developer centric.
You can talk to and write on web pages?
As an end user ... cool. Not really revolutionary, but cool.
As a developer, though, I don't really care, unless it is easy to build things in IE. For years, IE gave us headaches and heartaches. Give us something that makes up for that, please.
IE lagged behind other browsers. It did not implement the open standards that the others did. That has nothing to do with developers not liking IE. It has everything to do with how Microsoft had a monopoly on the browser market.
To hear Brendan Eich tell it, Microsoft's mindset went beyond simply "We have a monopoly so we can do whatever we want." It was a conscious "The web isn't the future" attitude. From the JavaScript Jabber podcast:
"After IE6 they took the team down to a skeleton crew and they stopped fixing bugs. They had horrendous security bugs and page layout bugs and DOM bugs and networking bugs. And they just said, 'Ah, the web is over. We’re going to do Windows presentation foundation,' which became Silverlight. 'We're going to do .NET. The web, that was a passing fad, sort of like television.' So…"
Now whether or not Eich is the absolute authority or not on this, I can't say, but he certainly interacted with them enough to have a deeper perspective than the average, frustrated dev in 00's.
I interned at Microsoft when they were trying to ramp up from from the skeleton crew. The impression I got was that this was part of it, but also that Microsoft was averse to innovating on IE after the US antitrust case.
Microsoft didn't need to do any "innovating." They just needed to adhere to existing and emerging standards. Also, Microsoft needs to seriously stop using that word "innovation,"because the more they talked about it, the less they actually did. It got to the point that Microsoft fooled themselves into thinking that everything they did was innovation.
And, while I don't have a source at hand (I should be asleep!), it's also worthwhile to know that the IE team that shipped 6 didn't have any idea it was about to ramped down — had they known that, they'd have pushed much harder to fix more bugs before shipping.
> I understand that they were late to the game, but late, then invested, and then flippant?
Yeah. At the time when the IE team was disbanded, Internet usage was still exploding in the US and all over the world.
There's just literally no way they could have looked at that and concluded that it was some kind of fad that had run its course. If Brendan Eich honestly believes Microsoft thought that, I'm glad he wound up not being CEO of Mozilla.
Instead, I think it's incredibly clear that Microsoft understood the web's power very well. Once they achieved near-total market share with IE6, they clearly made a conscious, strategic decision to retard the growth of the web by ceasing to improve their browser because they knew that the growth of the web would render one's operating system mostly irrelevant someday.
And it actually worked for a few years in the early 2000's. Sort of. Dragging their heels on IE6 did buy Microsoft some time; they just didn't manage to use it very well (thankfully).
Things stagnated on the client-side web for a while in the early 2000s (because anything you built still had to work on IE6) and Microsoft continued to incrementally improve Windows, Office, they started Silverlight, and their server-side dev tools inched ahead as well.
Maybe true, but the bits he's picking out are kinda wrong IMHO. WPF hasn't changed much since it was first done in the mid 00s, Microsoft didn't put the same improvement into developer productivity for WPF as they have for ASP.NET (Webforms -> ASP.NET MVC, vNext etc). WPF workflow is still painful despite it being around for nearly 10 years and Xaml as a concept being around longer.
But Silverlight has been retired. The original plan was for WPF to be separated into the Windows part and the web part. The web part failed miserably. It was yet another attempt to make a Microsoft only solution for a common problem.
I think that Microsoft needs to put itself in a position to revolutionize. One of the historical problems of IE is it tried to do things "its way" ignorant of where it was positioned in the browser landscape. That caused a slow but massive loss in market share.
They talk a lot about working on the "modern web", that's marketing-speak for it uses established technologies that IE refused to use. I hope this means that I can develop for Spartan with zero handholding (unlike the IE headache/handholding)- I think this is the "just works" claim they keep repeating.
If I don't have to worry about my site working on Spartan, then Microsoft is in a position that it can start revolutionizing. And from that perspective, focusing on cool stuff for the end user is a pretty good strategy. Throw a bunch of interesting innovations that don't break the fundamental rules of "it just works" and no extra developer work, and they might catch lightning in the bottle.
That might just start crawling marketshare back into Microsoft hands.
> They talk a lot about working on the "modern web", that's marketing-speak for it uses established technologies that IE refused to use.
IE pioneered much of the modern web (AJAX...)! The problem with IE is that it got entranched in the enterprise and couldn't change very easily! Ya, sure, we get to go off and use Firefox and Chrome, but there are literally tons of internal web apps that only work in IE, making IE difficult to change and evolve.
> If I don't have to worry about my site working on Spartan, then Microsoft is in a position that it can start revolutionizing.
It is not actually about you, but about the corporates. Anyways, the same effect: now IE legacy has been tossed away with Spartan (the corporates can still use IE as a legacy app), MS can move forward without worrying so much about the past.
The approach taken previously, IE 10+ with a compat mode for legacy IE 6 web sites, didn't work well. Many just saw "IE" in the user agent string for IE 10+ and immediately thought "IE 6"! So Spartan lacks a compat mode, getting rid of that problem completely.
Honestly, it would have even been an improvement to take IE 11, throw away compat mode, and just call it something other than IE. I'm sure Spartan does much more than that since it would be a wasted opportunity otherwise.
(disclosure: MS employee, but far away from web browser development and speaking for self with only anecdotal knowledge about the history; also an avid Chrome user)
> IE pioneered much of the modern web (AJAX...)! The problem with IE is that it got entranched in the enterprise and couldn't change very easily! Ya, sure, we get to go off and use Firefox and Chrome, but there are literally tons of internal web apps that only work in IE, making IE difficult to change and evolve.
This is...overstating things. I really like the belated recognition that the early IE team got for the work they did for the web, but that was 15 years ago. At some point you have to address the intervening years.
Meanwhile, maintaining backwards compatibility was a problem IE has had, but is not at all the reason for the pain of almost a decade of IE dominance during that time. "established technologies that IE refused to use" is a fair assessment of at least some of that, although for almost five of those years there wasn't even an IE team to refuse to use standards as it had been disbanded.
In any case, as a web developer, I'm for the most part thrilled with Spartan's plan of attack and look forward to seeing it succeed.
I agree that the long gap between IE6 and IE7 was really bad (when the IE team was in China, btw, but does that count?), and I'm not saying these problems aren't self inflicted. But once more modern IEs started coming out with standard compliant features, they were ignored (supporting IE still meant IE 6). But once those web standard features were there (along with lots of effort on compliance), they were still not being used! Spartan seems to fix that current problem.
The big change to make Spartan developer friendly is by having fast update cycles that are not bound to a specific OS version. That's the only change I'd care about. Has Microsoft announced anything about that?
Yes, but the caveat to the caveat is that Windows 10 will both be free and is intentionally being made to run on very dated hardware. As far as has been released that I can see, 10 will run on anything that will run Vista (which was released eight years ago and ran on Pentium IIIs and Celerons.) While this won't necessarily make the army of XP machines that still live out there go away, Microsoft is pushing really hard to get everyone up to date on the OS.
Source: I attended the Microsoft Spartan preview event last week.
Th 10+ requirement makes me doubt that MS is on the right path. OS version independence only really works if the dependencies are rolled out together with the browser instead of the OS. So what in Spartan makes it dependent on Win10? It's not like Win10 will be a huge departure in terms of its kernel, correct?
The number one reason IE fell out of favor was extensions. Firefox introducing extensions revolutionized the browser experience, and MS sat with the head in the sand for FARRRR too long. That combined with the repeated spyware targeted at IE, and it quickly got a reputation as being slow (as a result of the spyware, I personally never had an issue with IE speed out of the box), insecure, and with fewer features to boot.
I seem to recall at least early on, IE also refused to implement tabs, which were vital to a power user. I can't even imagine going back to having a window per website... ugh, the bad old days.
Maybe one reason, but not the number one reason... I mean it took Microsoft ~5 years just to update from IE6 to 7. That alone can explain their downfall. They waited until developers had almost 6+ years to use and evangelize a non-IE browser, and by then they just kept falling behind. Lack of extensions was more like the nail in the coffin than the ultimate cause of death for IE.
I'm still very wary of this new browser. Microsoft keeps saying since IE9 that they finally delivered, but it's not the case yet. IE still lags behind and still has quirks.
I actually downloaded the IE11 VM from http://modern.ie the other day to give it another chance. A not very pleasant experience. After boot, I was greeted with a desktop background with some instructions, presented as a badly compressed JPEG. I'll be honest, and vote me down if you must, but I'd be ashamed to have delivered this kind of work. Make it a PNG or a BMP even, it's not going to inflate the 4GB download size noticeably.
As for IE itself, I cannot really judge its rendering because VirtualBox doesn't seem to run Windows 10 accelerated, and I think the font rendering in particular suffers from this. I can't say though.
It still has some quirks that need to be worked around. I noticed this particular JavaScript problem.
var xhr = new XMLHttpRequest;
xhr.timeout = 1000;
xhr.ontimeout = function() {console.log('Error')};
xhr.open('GET', '/');
xhr.send();
This throws an exception in IE11. IE only allows timeout to be set between open() and send(). It's allowed to be set at any point per specs, even after send().
So I tried to report this as a bug. IE doesn't have a public bug tracker, only what appears to be a way to send "suggestions" to the IE team. I read a few of them. There is little activity. You basically only get a formal PR-like response.
Windows 10 introduced a major VM-screen-breaking bug a few builds ago. Screens can't be sized properly anymore. And acceleration seems to be broken (at least, I hope so, otherwise there's a huge perf regression). Users of VMware and VirtualBox are complaining. Posts to the forums get "answered" by idiot moderators that insist this is a VMware problem (despite VirtualBox not being made by VMware).
VMware says MS broke the APIs for screen resolution and they won't fix and hope MS does. OTOH, VMware Workstation is pretty much an end-of-life product with no real updates in quite a while.
Overall, it's bizarre. You'd think that in a beta, usage in a VM would be really high, leading to not having regressions on such common "hardware".
If you didn't already submit the above, I'd recommend you try. I've had my items looked at (you get status updates) within a month of posting it (yeah, not the best turn around, but far from the worst)
The software engineering process in browser development seems completely broken. W3C delivers only human-readable specs, and no reference implementation, and no complete test suite. How can we ever expect browsers to be functionally correct?
To be fair, until a few years ago the testsuites were mostly terrible and laughably bad — little more than skeletal things to ensure there was some basic interoperability (and not necessarily covering all the features of a spec). It took a huge push from a lot of people to get to where we are today; I remember pushing for the CSS 2.1 testsuite, which was one of the first to have a reasonable number of tests though it's still far too shallow, to be largely automatable and getting a fair bit of resistance (because of fear of delaying the testsuite and the spec demonstrating interoperability of implementations and reaching REC), and that was in 2010 (though, holy cow, that's almost five years ago now!).
As far as reference implementations go — I'm on the whole against them (you can end up having to implement bug-for-bug compatibility, which doesn't help anyone and if those bugs fall out of implementation details they can lock you down into specific implementation designs). It's better to have clear, unambiguous specs (preferably with next to nothing undefined) and multiple interoperable implementations — because it shows that the spec is clear enough for multiple people to implement it and come up with the same result. The machine readable route is a dangerous one — you don't want to end up in a situation where everyone just uses the same implementation, because monocultures aren't at all great.
First I thought Spartan was supposed to be a browser that embraced standards and got rid of years of IE non-standard workarounds.
Now they're extending that model with "Inking and sharing", and distraction free reading view. So the baseline browser is going to be different on different devices unless all of the devices are from Microsoft.
I think they're over estimating their ability to control the market's standard user expectations.
Inking, sharing and reading mode are user facing features. Standards in web browsers have to do with the APIs and rendering and such conforming to standards.
I wish they would commit to the name "Spartan." I don't think the full "Project Spartan" is a good name for a browser. And replacing it at this point with something completely different would squander the goodwill from all the prerelease buzz.
I think halo is a good smart marketing move to associate future Microsoft consumer products with halo. The 360 is by far microsoft's biggest consumer electronic success, and halo it's flagship franchise. Kids growing up now with the 360 will know it, and it's not associated with the boring windows enterprise stuff. And if you don't know halo, the names sound okay anyways.
Now with new inking capabilities, Project Spartan enables you to write or type directly on the page, comment on what’s interesting or clip what you want – then easily share this “Web Note” via mail, or a social network.
I'm really, really not sure how this is going to work in an era of single page apps. Presumably it can only really send the URL, so unless a developer has been very strict about using pushState (and good on them if they have) I think we'll see a lot of broken experiences with anything other than article web pages.
I assume it's similar to how OneNote does things, which is to create a metadata-rich copy of the page you select (as opposed to a screenshot, which isn't searchable) while keeping as much of the formatting intact as possible.
It's probably very useful if you ever do web research or need to review web content (I do), but I'm not sure this is as big a deal as they're making it out to be. Might be some box-ticking for marketing ("make sure you find a use for the pen!!!").
It looks to me that they are thinking about some sort of use case that was popular in a management meeting in an attempt to make a browser that does something different than the others. Unfortunately, this forces the dev team to implement a browser, something made for the purpose of general applications, as something more feature specific.
0. Fix the font rendering. Enough of this WPF/Metro blurry style crap.
1. Give me an addon/extension system so I can get vim bindings and blocking systems.
2. Fix the ugly, unfinished blocky UI around the tabs and address bar, and stop wasting so much space on the top window border. I know this sounds superficial, and it is, but IE just looks so ugly, or like an unfinished dev preview, and for some reason that bothers me.
WPF font rendering was fixed in .NET 4 back in 2010.
IE10+ on Windows 8+, Office 2013+ on Windows 8+ and the Modern/Metro/Immersive environment on Windows 8+, on the other hand, are doomed to have poor font rendering thanks to their use of the Direct Manipulation APIs: http://blogs.msdn.com/b/oldnewthing/archive/2015/01/29/10589...
I doubt this will be fixed - the world is slowly moving towards high DPI screens where subpixel font smoothing isn't as important. For existing hardware, though, it stinks.
I don't notice it much in Office because the font sizes in use tend to be a bit larger. Whereas small fonts are much more common on the web, and the bad rendering is really noticeable.
This is not a universal law of the world. There are times when using a common technology is better.
In this specific case why is "competition good" and who cares about boring when it comes to developer's productivity. Being able to code against one browser and being certain that it works properly in all browsers would be a tremendously wonderful thing for everyone.
To sacrifice that ideal vision so that things aren't "boring" doesn't seem worth it to put it kindly.
We had developer productivity with IE5. But it's also good to get innovation on browser platforms. Maybe it's possible that a single browser, today, would get all the love and continued development. But it seems more likely that without pressure to improve (even if it means improving runtime perf/memory usage) we could easily see stagnation.
Webkit does not include the JS engine. And the different approaches to rendering is also incorrect. Google has Blink which is - for all intents and purposes - Webkit.
IE6 was closed source, and under control of one company. Webkit is open source with contributions from many major organizations.
A) That would probably be politically unpalatable within MS
B) That would definitely be a bad move for consumers. Monoculture is bad, and even though a fork would allow them to go their own way to some degree their existing codebase is probably more pliable to what they have in mind.
Because of legacy. Spartan based on the old Trident engine, but refactored and without "compatibility" modes and quirks (as they promise). They need Trident to render old sites. Just imagine how huge is amount of old IE-only sites in corp. segment.
Completely true. But is it so hard to imagine a fallback instead of a rewrite / refactor?
I mean, aren't you tired to develop for X renderers? Couldn't Microsoft adopt something like the Khronos group for once and stop fucking around with proprietary bullshit?
What's the PPI of the display you're using? I don't have access to anything >200PPI to test on and I'm curious to know how much better it looks under those conditions. It would be nice to have a Cleartype toggle since the vast majority of current Windows consumers won't have a display that will make the "blurry" fonts look good.
I'm using normal screens with whatever the default DPI setting is. 1080 on a 12-20" depending on laptop or desktop.
Microsoft has been going on about high-dpi displays since 2003 (Longhorn PDC) and they aren't really around yet on Windows machines. So they absolutely should have this toggle, and set it to properly render unless the user has high-dpi.
This is just a stubborn thing they're doing. Similar to the ALL CAPS phase or the Win8 junk they went through. Or similar to how WPF had messed up font rendering until Visual Studio started using it.
I run 150 DPI on my desktop, 220 DPI on my laptop. High resolution screens are definitely around for Windows machines if you can pay the extra few hundred dollars for them. I'm not going back to low res displays, though I do much prefer OS X font smoothing for those screens.
Well it's 2015, and the only real X series ThinkPad maxes out at 1080p. So, yeah, I could go HiDPI and lose all the screen real-estate, but that seems like a poor tradeoff. I'd have to get a larger, more limited, device like the X1 (really, the only other option) to enjoy HiDPI without having a small desktop.
And, all things considered, I don't think hidpi is ready yet. ThinkPads already overheat and have shitty battery life. Having to handle 4x the pixels seems like it'll only hurt things. Though I must admit, I am always blown away when looking at the Macbook Retina screen.
Plenty of ultra books have HiDPI displays these days. It really is a better experience, even just for coding. I can't wait for 4X to become the standard so we don't have to ship duplicate bitmaps with everything.
Any recommendations on something as good as the old X series? Ultrabooks tend to have crap keyboards and no-button, Maclike clickpads. And many are considerably larger than 12", even when they do strange things to get "thin".
"going to a restaurant's home page will bring up a message, reading “I've got directions, hours, and more.” Clicking the message brings up a sidebar with the restaurant's contact information, location, reviews and an OpenTable reservation link" [1]
Afaik, that's about the same point machine learning was going through a renaissance away from expert systems.
As a comment on a previous HN story quipped, most of the 90s ideas weren't fundamentally bad, just impossible to realize with the knowledge and technology of the time.
So how about its speed? Internet Explorer on mobile and other devices (like Xbox) has always had horrifically bad canvas performance, rendering the majority of HTML5 games unplayable on those devices. Will Spartan be addressing that in any way?
WebKit doesn't belong to Google (Apple started the project as a fork from KHTML), and they don't even use it anymore, they forked it in to Blink, which is what Opera uses.
"They don't even use it anymore" is a bit of an exaggeration. "They made a fork of WebKit and renamed their fork Blink" is more accurate. It's still pretty close to the same thing.
Well, sure, but a lot more happened in the preceding 10-15 years. Blink still has more in common with WebCore than it does with, say, Gecko, Trident or Presto.
As a web developer or user, you can't really see the similarities anymore. The basic stuff like CSS 2.1 works the same everywhere. It's the new features where the browsers differ.
Chrome matches Safari in 57 cases. However, Chrome matches Firefox in 61 cases. So, going by the implementation status of those features, Chrome might as well be using a fork of Gecko.
Here is the script I used:
for (let b = 1; b < 5; b++) {
let r = [0, 0, 0, 0];
[].forEach.call($$('tbody tr'), function (row) {
for (let i = 0; i < 4; i++) {
r[i] += +(row.cells[i + 1].className === row.cells[b].className);
}
});
console.log(r);
}
They say that. 20 years ahead is way too hard to predict with any meaningful features. (Does Spartan ship with JavaScript events for brain interfaces?) Really it just boils down to the fact they're starting a big browser project with a fresh slate from today.
The most a browser can really do is make the architecture sufficiently modular and extensible based on a layered architecture. The web stack has always done pretty well at that anyway and even more so with the newer low-level standards like fetch and service workers.
I actually asked the IE team about that. They said they weren't planning on doing that.
Which I think is a shame because I like being able to follow comments in Mozilla's/WebKit's/Chromium's issue trackers and mailing lists. It gives you a much clearer idea on what's being put into the browser's and when they'll be available (or why they won't).
Their are other reasons such as not having to worry about them trying to lock me into their OS because websites will only work on their browser and it's exclusive to their OS. Also, making everyone have to reverse engineer bugs to get sites to work.
That's why I'm kind of surprised that this preview of Spartan is not really developer centric.
You can talk to and write on web pages?
As an end user ... cool. Not really revolutionary, but cool.
As a developer, though, I don't really care, unless it is easy to build things in IE. For years, IE gave us headaches and heartaches. Give us something that makes up for that, please.