Linked by Thom Holwerda on Sun 11th Mar 2012 22:21 UTC
Permalink for comment 510404
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
More News »
Sponsored Links



Member since:
2007-09-08
OK, I'll bite.
Hardware acceleration - fine. Networking - fine. Maybe. "Dynamic language runtime"? No.
Sure, you can use Microsoft's JavaScript implementation to write an app, but you can't embed that as a scripting language inside a web browser. The API does not permit it.
There's no way to get any other modern JavaScript interpreter running inside Metro. None. Not possible. Any application that attempted to do this would fail validation, and not be available from the store.
I don't see the relevance of a validating XML parser, either. Modern browsers don't really use XML for anything. Certainly not a validating parser.
In order to integrate properly into the OS (and Metro, like Android, is built around the idea of things integrating), the web browser has to be the default web browser.
In order for a browser to be the default web browser in the Metro environment, it must also be the default web browser in the desktop environment. It must also be a hybrid Win32 / Metro application.
That's just the way Microsoft built the thing. There is simply no other way to build a web browser for this platform. A pure native browser would not integrate into the platform as well as a hybrid browser. It could also never perform nearly as well.
No. No part of that description resembles a modern web browser.
Once the page is parsed, it doesn't matter. Once it's converted into an internal representation, it doesn't matter how it got there. It'll be exactly as fast.
XML parsers are not necessarily faster than HTML parsers. I believe they may be slower, because despite the extra error handling, HTML is not nearly as complex as XML.
Besides, the time taken to parse an HTML document is very low, compared to the time taken to fetch it from the network. And you can parse the document while it's downloading, so you don't even need to wait for it to finish.
OK... I don't understand what you're trying to say. Are you saying that JavaScript runtime performance is irrelevant because modern web pages contain large amounts of JavaScript?
Basic fact - if you give developers more power, they will use it. You may not have noticed web pages getting faster because of faster JavaScript interpreters. Instead, they've been adding functionality. Modern web applications simply wouldn't be feasible without a modern JavaScript runtime.
It's important. It wasn't five years ago, because there weren't many websites that really pushed JavaScript that hard, but it's important now.