Linked by Kroc Camen on Sat 29th May 2010 20:41 UTC
Permalink for comment 427483
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/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
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
More News »
Sponsored Links



Member since:
2006-05-30
Can you define ‘scale’? HTML has scaled horizontally to the entire world. It’s appeared on almost every platform on innumerable devices from an Apple II and Commodore 64 to smart phones. It has scaled to devices and uses far and beyond its original design or even what Sir Tim envisioned. Java cannot even come close to what HTML has achieved. "
HTML is about compromise though. I think that is the point. HTML doesn't scale, it simply drops to the lowest common denominator. It always has, and will continue to.
The other factor is, HTML used to be a simple mark-up, it described a document. It's now massaged in to being more than just a mark-up. It doesn't necessarily do this in a nice or even stylish way. It's still feasible to write HTML in a text editor, but it isn't practical. In truth, without using the minimum of 3 browsers for testing, you will not get even get a fully functioning page in many cases. Much of this is related to Javascript implementations, but Javascript and HTML are so intertwined these days, it is hard to do much without using both together.
Javascript is still a horribly clunky language to code for. It is imprecise, it has a completely nasty object model and the lack of firm typing leads to crufty code. The thing that Actionscript has going for it is that it uses the ECMA Script as a basis (as does Javascript), but adds useful stuff on top - like a real object model that is not a clunky hack and actual typing so that stupid mistakes are less easy to happen. Honestly, I code in Javascript regularly, it is horrible. One can only hope that HTML6 (or whatever standard covers Javascript) tries to address this kind of stuff.
How much of that is to do with processor speed? Try doing all of that on a mid spec ARM processor - Javascript is still running in treacle mode. I would also dispute the "near native speed" claim. I think the truth is, the disparity between processor speed and Javascript performance has been reduced enough to make Javascript feel as fast as a native application. I think if you did any really complex recursive maths with Javascript, it would still be order of magnitudes slower than a natively compiled app.
SPDY. "
"An experimental protocol for faster web". Google specific. Time will tell, but it would need to be supported widely at server level to make any inroads.
JSON is the new XML, thank goodness. "
Ah, so you don't actually understand what XML is, versus JSON. That's okay. JSON is not the new XML, JSON doesn't even come vaguely close to replacing XML. JSON is pretty much a serialised Javascript Object. that's it. You need to interpret it in exactly the same way as you need to interpret XML, in the context of the document. It might be marginally fatster in the Web, as generally you can theoretically write Javascript that directly accesses the elements of the JSON object instance, but in practice, it's not really all that much different. For simple tasks JSON is usable. Could I replace a XML file that contains a full word processor style document mark-up? Not really. Horses for courses, use the right tool for the right job, etc.