More Details About Project Spartan
blogs.windows.com
blogs.windows.com
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.
"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.
(Source: http://devchat.tv/js-jabber/124-jsj-the-origin-of-javascript...)
Or will a mobile world prove them right, but too early?
> 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.
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.
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.
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)
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.
Source: I attended the Microsoft Spartan preview event last week.
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().https://xhr.spec.whatwg.org/#the-timeout-attribute
Microsoft has documentation, from the time of IE8, which clarifies this. Apparently nobody at Microsoft cared to fix this since.
> The timeout property may be set only in the time interval between a call to the open method and the first call to the send method.
https://msdn.microsoft.com/en-us/library/ie/cc304105.aspx
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.
Microsoft still has much work to do.
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 IE folks are pretty responsive on Twitter also, with https://twitter.com/IEDevChat
https://github.com/w3c/web-platform-tests
http://testthewebforward.org/blog/2013/02/20/testing-the-ope...
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.
"...using performance enhancing equipment and augmentations to make them stronger and faster than previously thought possible..."
I think they should stick with it as well.
(on a side, I thought it was ironic how the article said "Cortana is more tightly embedded into the new browser". Like what next? HUDs!?!)
I mean it was that or resurrect clippy.
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.
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!!!").
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.
They could have > 90% browser market share again.
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.
IE6 was pretty much a monopoly, how well did that go?
IE6 was closed source, and under control of one company. Webkit is open source with contributions from many major organizations.
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.
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.
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.
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.
More pay-per-click than paperclip?
[1]http://www.pcworld.com/article/2891948/project-spartan-leake...
Clippy was apparently 1996.
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.
Having competition is great, I will give this browser a genuine shot.
A lot happened in those 2 years.
http://caniuse.com/#compare=ie+TP,firefox+39,chrome+44,safar...
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);
}
Output: [130, 35, 36, 48]
[35, 130, 61, 36]
[36, 61, 130, 57]
[48, 36, 57, 130]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.
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.