Microsoft's secret weapon in browser wars: Mozilla's supercharged Asm.js Microsoft has included a surprise feature in its new Edge web browser for Windows 10, in the form of support for the ultra-optimizable Asm.js JavaScript dialect. First developed by Mozilla and championed by the nonprofit's former CTO Brendan Eich, Asm.js is a strict subset of JavaScript that aims to be the "assembly language …
A thumb down ?
How about this then:
<!--[if lt IE 6]>
<link href="css/ie6.css" rel="stylesheet" type="text/css" media="screen" />
<![endif]-->
...etc etc
<!--[if IE 11]>
<link href="css/ie11.css " rel="stylesheet" type="text/css" media="screen" />
<![endif]-->
AND A NEW LINE:
<!--[if IE Edge]>
<link href="css/Edge.css " rel="stylesheet" type="text/css" media="screen" />
<![endif]-->
IE hasn't used the COM JavaScript engine since IE9. IE9 moved to implementing the DOM type system in JS. Justin Rogers of the Edge team posted an interesting look at how this works at http://www.justrog.com/2015/05/javascript-type-system-evolution-from.html?m=1
Conditional comments are not supported in 'edge' and IE10 document modes in IE10 and 11. Only when emulating IE 9 or older. https://msdn.microsoft.com/library/hh801214(v=vs.85).aspx
Microsoft Edge removes the concept of document modes. http://blogs.windows.com/msedgedev/2015/05/06/a-break-from-the-past-part-2-saying-goodbye-to-activex-vbscript-attachevent/
While I happen to believe that javascript is basically a pants language by design, it has to be said that it is the lowest common denominator for web applications and they are jolly useful ways of deploying software/services to end users.
Anything that allows fast and usable code cross-platform to be developed without resorting to flaky and/or propriety systems like ActiveX, Java applets, or NaCl stuff is to be praised.
Hopefully the MS implementation will remain "standard" and thus be fully cross-platform (browser, OS, and CPU) and future web developers will look at using this best (OK, fastest) sub-set for writing stuff.
Having had to work with it and coming from a C, C++, Java career progression it is unbelievably annoying.
The reason can be summed up in two words that define its' philosophy : weak datatyping.
So, just declare everything as dtatype "var" and off you go on your merry way. And once you have to debug someone else's rubbish code to hunt down horrible bugs caused by side effects of intrinsic type coversion rules may I wish you the best of luck.
In other words it's "cheesy C language programming tricks coming back to cost you dearly" all over again. I will never, ever work on a project using raw javascript code again after my last experience with it (libraries using tried and tested javascript such as ICEFaces, but hiding all of the javascript from you I'm completely OK with).
So maybe this is a good idea that will help define a more strongly typed subset of javascript that becomes a de-facto standard and extinguishes the worst abuses of it? Could be a good thing in the end, if there are some genuinely smart MS backroom boffins who have realised that this could happen, and if this turns out to be "embrace and improve" rather than "embrace and extend", well I criticise MS often enough on here but I'd welcome this wholeheartedly. Because at the end of the day, whatever you think about it, javascript is going to be around for a long time yet.
the lack of strong data typing to catch mistakes in data use is the single biggest thing by far
Is that with the type features of ECMAScript 5? Which is now six years old? Or 5.1, which is three years old?
In my experience, many of the people complaining about ECMAScript ("Javascript" is the name of Mozilla's implementation) aren't terribly familiar with the language, and are using a fairly ancient subset. Now, sure, some folks have a compelling need to support old implementations; but many don't.
That said, yes, LiveScript / Javascript / ECMAScript wasn't designed for large programs, and doesn't do a lot to enforce implicit contracts. And most of the people who write ECMAScript code are pretty bad at it - including self-professed experts like John "Property iteration must work the way I want it to!" Reisig. And arguably the language can be blamed for that, just as C often is.
But ambitious software can be written, and written well, in ECMAScript. It requires knowledge and discipline, but it can be done. And terrible software can be written in any language.
This post has been deleted by its author
>to have a virtual machine for the web that's programmable in simple opcodes
And even today its a giant security hole/malware vector which SUN's original garbage implementation (that lives on) aside points to how hard it is to build a VM that can safely run unknown hostile code off the tubes with no risk to the host.
>points to how hard it is to build a VM that can safely run unknown hostile code off the tubes with no risk to the host.
I suppose JS' virtue is that it was never designed to have access to much of the local host's resources, which makes sandboxing easier.
If you're running web-apps with high levels of unpredictable user interaction, you often want to execute locally and just store remotely. If you can get close to C speeds, it would be interesting to see some desktop apps appear in a browser.
>I suppose JS' virtue is that it was never designed to have access to much of the local host's resources
You nailed it, upvoted. But this is such a key aspect of JS that it deserves more than grudging appraisal, IMHO.
And to extend this a bit, I hope, but do not expect, that MS has learned not to integrate Edge itself too tightly to the OS. A suitably hands-off and paranoid relationship is all for the best in this case. Firefox and Chrome manage, even on Windows and as a result also release for older Windows too.
p.s. is it just me or is the number of MS Windows articles under El Reg's software section a tad over the top these days?
points to how hard it is to build a VM that can safely run unknown hostile code off the tubes with no risk to the host
Not really. It demonstrates that when you let your library authors poke all sorts of holes in the sandbox for "performance" and "features", then a lot of sand is going to leak out.
There's a lot of research and good practice in securing execution environments. Java, from fairly early in its evolution, has chosen to ignore much of it.
Of course, even so Java remains a suitable execution environment for many applications. As a browser plug-in not so much, though even then it can be safe enough in the hands of a knowledgeable user who enables it only for particular resources from trusted locations.
Oh I dunno. Have you actually SEEN any Asm.js? It doesn't look much like stock JavaScript. In fact, the conventional wisdom is that coding by hand in Asm.js is too tricky for mere mortals. It requires the rigor of real assembly language, but because it's JavaScript you have a million opportunities to write bad code because of what you think you know about JavaScript. It's mainly meant as an output target for compilers. In other words, when you want a program to run in a browser as Asm.js, you'd write your actual source code in C.
This guy's page has a little sample of what output from the Emscripten compiler looks like: http://ejohn.org/blog/asmjs-javascript-compile-target/
Note that even that snippet has been "beautified" with indentation etc. Normal Asm.js output doesn't bother with any of that.
Is the syntax really like a processor's assembly language? I guess not. But the description still fits, I think.
It's probably better to think of Asm.js as a form of intermediate representation. A lot of compilers go from source code, to intermediate code, to machine code. Among other advantages, this lets you combine various different front end language translaters with different back end machine code generators. In the case of Asm.js, the intermediate representation just happens to be a sub-set of Javascript.
The Pypy Python JIT takes a somewhat analogous approach in that it uses a subset of Python called RPython which can be highly statically optimized into machine code by the compiler. I say "somewhat analogous" because they don't use it as a compiler target for writing user supplied programs. Instead, it's just part of the toolkit they use to write interpreters and JIT compilers in, including Pypi, along with PHP, Ruby, and others (it's a general purpose language toolkit).
The basic idea behind both is that speed has nothing to do with "compiler" versus "interpreter". Both Javascript and Python are compiled. The real issue is "static" versus "dynamic". Both Javascript and Python (along with Ruby, PHP, and various others) are very dynamic languages which can only really be analysed completely by observing them at run time to see what they are actually doing. However, if you strip out the dynamic features from them and leave a core which can be analysed statically, then you have something which can be statically compiled, that is analysed and optimized in advance, just as much as something like C or C++. Without that, you need to either use an interpreter, or a JIT compiler, or a combination of both working together (like most current Javascript and some Python systems do, oh and like Java does even though it's not dynamic).
If course it's those dynamic features which attract developers because dynamic features let you write less code, writing code takes time, and time is money. It's all a trade off, and the best tool for the job depends on the type of project and the market. That's why we have so many programming languages.
The way that Asm.js is meant to be used is that you take libraries written in something like C++, and you compile them using their compiler to Asm.js code. Games is the big market being looked at, although no doubt there are loads of other applications. It won't replace run of the mill Javascript code though, just the stuff that has to be highly optimized for CPU performace.
The real competitor to Asm.js is Google's NaCl, which also uses an intermediate representation, although in their case its special NaCl code rather than a subset of Javascript. Looking at market acceptance though, it looks like Asm.js has pretty much won that battle, and NaCl is a dead end. It's also one of the final nails in the coffin for Flash and Silverlight.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
