Scott Hanselman

Cool. Always been a JavaScript fan :) #Crockford

So then you agree TypeScript\Coffeescript is a complete waste of time then? (Only half kidding)

Brad - Here's my thoughts on TypeScript. It's useful, just like Clojure is useful.

It's sad, really. Out of all the awesome, well designed, well performing languages and runtimes in the world that JavaScript - that horribly cobbled-together mess of a language - is winning out. I have to believe that we can do better than this...

And asm.js is an interesting project, but the software engineer in me can't help but see it for the epically cringe-worthy kludge that it is...

Jon - Yep, that's true, but most successful things have problems. CSS, HTML, you get the idea. ;)

http://test262.ecmascript.org/ , the problem is that while the target arch/platform supports 100% of the Assembler for the target arch/platform, most browsers only support *most* of ECMA. IE fails what? 5-10% of the tests?

Needs an edit button - I'm not slagging off IE - other browsers have their own compatibility issues. But this is a Microsoftish blog, so IE it is!

I fully agree that JavaScript is the universal runtime we are developing for now - that's how far I like this analogy.

What I don't like is the actual "Assembly Language" analogy, because it implies that we need some other, higher-level language that compiles down to JavaScript. But JavaScript itself is already a high-level language - that's a thing we should always keep in mind.

Of course it has its flaws but because of that we should strive to move JavaScript forward as language and programming environment instead of considering it something we want to replace or completely abstract from.

Projects like TypeScript do a pretty good job in that and lay out a future path of JavaScript / ECMAScript that looks very promising for me as a developer.

In my opinion, tools like TypeScript, Clojurescript and coffeescript are solving the wrong problems with JS. Take TypeScript, which adds static typing to JS. Loose typing is not JavaScript's problem. Yes, it provides compile-time errors, but those errors are not the ones that are hard to solve. The real problems are the differences in API in different browsers, global variables, falsy/thruthy... These problems are not solved by compilation to JS.

I don't think compilation to JS is the solution. The solution is in frameworks. jQuery, Knockout, Backbone, AMD they are solving the real problems with JavaScript. And if you look at the usage, it proves my point. Another solution is a tool like js(l)(h)int, which provides you as much information as a compiler would give you (just different).

I think, despite of its obvious flaws, JS is a really beautiful language. From all the programming languages out there, it's the only one that has accomplished such a widespread use. It's the only language that is getting close to "write once, run everywhere", (in contrast to a lot of other languages which claim this).

One of the major problems with JavaScript is that people try to use it as if it were a static typed language. Here's another analogy: C# is a hammer, JavaScript a nailgun. They both do a good job, but if you try to use a nailgun to slam a nail into the wall, you're going to have a bad time. Is it a bad tool? No, just don't use it as a hammer.

I think we need to face the facts, and just (collectively) learn to use JavaScript as it was meant to be. It's different than C# (or Java, or ...) so we need to use it in a different way.

@Scott Reality is Chrome has majority on the browsers market and since it will contain Dart virtual machine my bet is Dartlang is the future technology of the web (seen recent Dart benchmarks? In some cases Dart beats even Java). Dart is done by the same people who have done fastest JS VM on the market (Google's V8)

Even more important killer Dart features JS asm.js and other compiled to JS langs will never have is:
a) snapshoting (allows app to start almost instantly)
b) consistent API (http://api.dartlang.org/docs/releases/latest/)
c) tooling (Dart IDE) for all platforms (Win, OSx Linux) with good ecosystem (Jetbrains, Adobe)

Dart will be what .NET could be if it was open source from the beginning. Hope some day we will see Dart VM on other browsers (it is open source)

One big difference is assembly compiles to a compact binary representation that can be delivered, JavaScript on the other hand...

If lots of games start using asm.js based games engines, the impact on web bandwidth could be almost as bad as pron.

@Kenneth,

Using the JavaScript The Good Parts actually has (very) negative impact on performance, so utterly useless for targetting high performance applications.

Look at the subset usable in asm.js!

@Rob G

I haven't worked with games in JS, but I did work on large scale JS applications and I have never found any major issues with performance. That's not to say that there aren't any, but I don't think you should optimize prematurely.

Also, I didn't say you should use only the good parts. What I'm saying is that compiling into JS is not the way forward and if you want to target the browser the easiest and best way IMO is learning JS. C# and JAVA also perform less than pure C / C++, but it's still very popular, since most of the time you don't need that extra gain.

On a side note, compiling into JS usually has a negative impact on performance (asm.js is an exception here).

How can you tell someone's an MS developer?
They say "TypeScript/CoffeeScript".

I have nothing against TypeScript, and I don't use CoffeeScript.

The catch phrase used to be Flash/Silverlight.

Kosh rocks!

"Yep, that's true, but most successful things have problems. ~Hanselman"

That's what I'm learning. Facebook is a big example of that in my mind. I get frustrated every time I see it, but as I heard one person say before: it's where the people are.

@K - IE10 passes 99.93% of the ES5 tests.

This is SOOOO WRONG. Javascript is a pain of a language for the programmer (it's not really easy to learn an use) AND for the machine as it is so hard to compile to something that runs fast (pretending that programs don't need to run fast is missing the point of computers altogether).

There is one very elegant way to solve the horrible mess that client side web programming is: define a strong, machine oriented, byte code and make it a standard so that web browsers can compile this byte code on the client and run the code very fast. We don't even have to create a special complex new project for that to happen: just use LLVM and declare a subset of its internal language as "the web byte code". This would enable anyone to create compiler front ends for whatever languages they want to use and not bother with javascript anymore.

LLVM runs almost anywhere, is now a mature project, it can produce executable code for most relevant and modern architectures, it's open source yet not GPL so we can use it in close sources products as well as free software. It's not even that big compared to all the crap we now find in web browsers code. (you should have a look at the code base for the three main javascript engines to see what I mean).

Last but not least, it would also mean that we could have more people working on the future LLVM instead of diluting all the manpower of 4 different JS engines, and that would mean better optimisations for statically compiled code as well.

Stop making excuses and accept a horrible status quo: the web inherits a lot of crap and we should FIX IT. We should not pretend that it's ok and look elsewhere.

PS: the CLI byte code could also be awesome but I'm not sure about its licensing status and if the mono project could be easily adapted to that end.

@Sebastien

Exactly. JavaScript is great for what it is, but if we want to start writing high-performance applications for the web we should move towards browsers that support a standard, low-level bytecode in addition to JS.

There are only 4 major browser vendors...can't they just get together in a room and decide which byte code that they can agree to support? LLVM and CLI both seem like good candidates...

You seem to be ignoring PNaCl entirely. It's portable, faster than asm.js, and arguably its security is better. Wouldn't all of these be criteria you'd want to expand upon?

When you start to compare javascript with an assembly language, you hava a funny situation. From assembly to c++ to c# and java, one would argue that Javascript is a very high level language. So it can seem a bit strange to compile a medium or even low level language into a high level language ? Maybe I am oldschool, but comparing javascript to a new assembly language seems a bit far reeched, but I assume it serves the purpose of the article. Why not call it a Web Language Runtime or some such thing? :)

Anyway, I think that html serves well for content, css is very powerfull for layout and javascript for functionality. It is quite normal so manipulate html or css dynamically, so why not javascript? So the fact that I can create html from almost any language, why not create javascript? The web are more then pages.

My vision of the future of the web is WebIL - language-independent intermediate language that is then natively compiled into platform-specific code the browser.

Nice article Scott. When do you think we going to see a .NET Framework subset implemented in JS ?

Because while I love C++ and C, C# is easier and I use it a lot more these days than C++.

Thanks!

@kennith

Good comments. Agreed native code rocks. Dynamic langages have their place.

@scott

Are you referring to MVC as well? :)

Sebastien,

> define a strong, machine oriented, byte code and make it a standard so that web browsers can compile this byte code on the client and run the code very fast

http://www.youtube.com/watch?v=tNfGyIW7aHM

The problem is that JavaScript absolutely sucks at the one thing assembly language is generally good at: raw computation. It inherits JavaScript's number type almost verbatim, only stopping to distinguish between 32-bit int and 64-bit float for no reason. Want 64-bit ints? 32-bit floats? Have fun emulating them. Why are we shoving something every platform has had—powers of two sized registers—into a language that ignores their existence almost completely?

This is what I don't get about asm.js... it seems designed to allow us to do what JS can already do pretty well, rather than what we currently can't. It's like everyone's forgotten that this stuff is not new, that running Unreal engine in a browser is not really something we should be particularly impressed with in 2013.

Of course asm.js is inevitable at this point. But then, so was XML. We all know how that ended, and that JSON was what we really wanted all along. But we're stuck with XML, e.g. the way SVG encodes vertices is doubly stringly typed for the rest of time: numbers encoded as strings encoded as arrays. Because who needs types in universal formats and languages, right?

Putting aside pedantic arguments about whether "the assembly language of the web" is an appropriate description for JavaScript, Scott is right about JavaScript is the standard runtime/language/whatever of the web, and tools are popping up to compile various other languages to JavaScript.

I disagree with Scott on several points, however:

Point 1: "At the very least, JavaScript is a totally reasonable compile target."

Reasonable for whom? For what kinds of programs is JavaScript "reasonable"? How do you determine what is reasonable? All of these things depend on who you are and what kind of software you might attempt to compile to javascript. I would argue that the notion that JavaScript is a reasonable compilation target is biased by the fact that in most cases where it ISN'T a reasonable compilation target, it is simply not used as one. I would also argue that it is a very big stretch to say that a 40-60% drop on performance would qualify as reasonable under almost any scenario. "Tolerable, for some scenarios" is the best I could possibly agree to.

Point 2: The implication that the unreal 3 demo is evidence to support the suitability of JavaScript as a compilation target.

The unreal 3 demo shows very little support for the argument that *JavaScript* is a suitable compilation target. Almost all of the computational work being done in that demo is done not in the javascript runtime, but by the graphics card. The code running on the graphics card in the form of shaders isn't even translated to javascript first - it stays in its original form - the opengl shading language, before being compiled into the graphics card's native format. The javascript runtime is not, in fact, doing much work at all in this demo. There are no AI characters running around, and even what little physics that is incorporated in the demo is probably also done on the graphics card (or should be, anyway).

What's left is collision detection and construction/reconstruction of the scene graphs as you move around - in essence figuring out what parts of the scene need to be sent to the graphics card. And, if you look closely, it is precisely at times when the JavaScript has to actually do some work that the demo begins to choke. Notice a significant drop in framerate and stuttering as you turn a corner bringing more of the scene into view, or moving from inside a building to outside? That's when the JS engine has to actually do some calculation in the CPU. And, the fact is that that exact same demo, running on my nexus 4 as a native app, runs at a higher framerate (with no noticeable stuttering) than on my quad-core i7 and a GTX 560 as a web app. I am not impressed.

And if you think this only matters for games, imagine what would happen if your enterprise desktop app was replaced with a web app that did exactly the same thing but was 40-60% slower. I would not envy your support department (which might also be you).

Point 3: The "and that's OK" part of "Java is Web Assembly language and that's ok".

I don't disagree with the idea that JavaScript is becoming/has become the universal runtime of all the things. I am reminded of this trend every day. What I disagree with is the idea that this is just the way things have to be and we should all just suck it up and live with it.

The industry should NOT tolerate an inferior technology simply because it is ubiquitous. That attitude leads to a colossal waste of resources, both in human time and effort and in lost potential. Being the only ubiquitous runtime that doesn't need to be installed is NOT a good enough reason to waste time with a dead-end technology. Massive amounts of human effort has, in my opinion, been completely wasted on A) making javascript runtimes run fast enough to be usable for modern software, B) struggling with using JavaScript for large scale software development, when it isn't and will never be optimal for that purpose, and C) Working on compilers and alternate languages such as Dart, CoffeeScript, TypeScript and cross-compilers/JS subsets like GWT, JSIL, XMLVM, emscripten and asm.js.

If all of that human effort had, instead, been poured into creating NEW standards for the web, then we would be lightyears ahead of where we are. We already have several great candidates - the Java runtime, the .net runtime, and LLVM in a sandbox environment, like google's PNaCl runtime. LLVM would have probably had the best chance at succeeding, since it has a mature open source implementation with a permissive license. And, it is low enough level that Java, .NET, and even JavaScript could run on top of it. But, the fact that it's *Google* that is working on PNaCl means it won't ever be implemented by Microsoft or Apple, which is a shame.

.NET would also be a good choice, if LLVM isn't adopted. It already is an international standard, with copyright and patent grants (if I'm understanding it correctly). The runtime supports efficient interop between native and managed code. And, it already has two mature implementations of the full runtime (MS .NET and Mono), and some special case implementations (Silverlight, .net CF, and the open source, apache 2.0 licensed .net microframework). Mono is a great implementation, which already works on ARM, x86, and I believe even MIPS. It works on iOS, Android, PC, Linux, and Mac. If Xamarin would re-license the core runtime library as Apache 2.0 instead of LGPL, then adoption would be fast and far reaching, since all of the class libraries, some of the JIT codegen, and even the SGEN garbage collector code are already Apache 2.0 or MIT. In theory someone could implement a drop-in replacement for the core runtime and license it as apache 2.0, then continue to use the rest of Mono.

Java wouldn't be my personal choice, but it has much wider adoption among the web community than .net. The problem here is that Oracle has too tight a grip on it. Browser vendors are going to avoid a technology that would prove to be an IP liability.

Licensing issues aside, any of these options would be far superior to JavaScript. And, they all have mature implementations, and a mature set of tooling (MonoDevelop, Eclipse, IntelliJ, Visual Studio, etc...). In the past, this industry was not afraid to experiment with new things - new technologies. Even HTTP itself wasn't the only standard in use on the web. Now it seems we must all be content to settle on one software stack, even with several much better alternatives that are already implemented.

As an agent-provacateur you are nonpareil, Scott ! :)

The point of the seizure-inducing herky-jerk graphic at the start of the article was ... ?

I must respectfully disagree with your thesis: I think JavaScript (which has nothing to do with "Java" ab origine) aka ECMAScript has become, by default, a current "standard," in spite of the fact that it's a pss-poor high-level language, that took the coming of libraries like jQuery to make it halfway usable.

JavaScript is an abominable tool for OO development.

It's a standard because Apple and Microsoft, and all the standards-committees in the world, were not able to develop/promote anything more universal, consumers be damned.

But, as agit-prop artist, you have succeeded, again.

yours Anonymo

p.s. sorry about the anonymous response; there are good reasons for it

I just write javascript, and really enjoy it - it is a very powerful language. Prototypical inheritance is genius.

The difficult part is handling brower differences, mostly around IE. It's always so far behind the curve with html5, and to this day, more people still using IE8 than IE9 !

That said, in the past, I recall researching and trying out Script# (C# to javascript). Actually, quite brilliant. But at the time at least, it was not open source, it was maintained by one person, and finding good documentation and help was a serious pain. The creator worked at Microsoft. But it didn't seem to get much support. I'd came it a bit to GWT.

The problem I have with an abstraction over javascript is the the same way I felt 15 years ago when it was 'learn html' or 'use frontpage' - in the end, it was good to just know html to solve problems, etc...

I've used KnockoutJS for awhile, and now I'm really interested in AngularJS. I think the way AngularJS works is a great setup. NodeJS has been great as well. I use Express and SocketIO to build out some great websites in a short amount of time.

Having better tooling helps. I am a JSHint fan for one. Would like to see more done to help in that area. ES6 constructs should help as well. Above a comment was made on 'Typescript'. Typescript is mostly just looking ahead to ES6, and I like it's direction.

It's an exciting time to be a web dev and I'm 100% sure future advances will be amazing. I look forward to seeing it continue to evolve!

Anonymo - There's rarely a need to by anonymous, that is needlessly provocative itself.

JavaScript is "an abominable tool for OO development" because it's not an object oriented language, per se. It's prototype-based programming, in the family of Self, Cecil, and REBOL. Sure, you can try to write OO code in JavaScript, but you'll always be fighting with its true nature. You can say that English is lousy Spanish, as well. But that's because it's not Spanish.

http://www.bartleby.com/70/3822.html
"What’s in a name? that which we call a rose
By any other name would smell as sweet;"

However, that would not make the rose into something it's not, for example, it would never be a frying pan.

Sorry Scott, i'm not buying it. JavaScript is not and never will be analogous to assembler.

Let me explain.

My first assembler language was Autocoder for the IBM 141 (sic). From there, i moved on to System\360 mainframe assembler; in addition to IBM minicomputer flavours, i'm also somewhat experienced in Intel architecture.

Think of a black box. That black box is a computer; it runs on machine code; it's like your brain in that it controls everytime from the inside out.

Generically, assemler is any language that for all intents and purposes has a one to one relationship with machine language.

Here's a brief c# example that runs easily in LINQPad 4:

Char[] blogger = "Hanselman".ToCharArray();
foreach (Char letter in blogger) Console.WriteLine (letter);

Here's the IL:

IL_0001: ldstr "Hanselman"
IL_0006: callvirt System.String.ToCharArray
IL_000B: stloc.0 // blogger
IL_000C: nop
IL_000D: ldloc.0 // blogger
IL_000E: stloc.2 // CS$6$0000
IL_000F: ldc.i4.0
IL_0010: stloc.3 // CS$7$0001
IL_0011: br.s IL_0022
IL_0013: ldloc.2 // CS$6$0000
IL_0014: ldloc.3 // CS$7$0001
IL_0015: ldelem.u2
IL_0016: stloc.1 // letter
IL_0017: ldloc.1 // letter
IL_0018: call System.Console.WriteLine
IL_001D: nop
IL_001E: ldloc.3 // CS$7$0001
IL_001F: ldc.i4.1
IL_0020: add
IL_0021: stloc.3 // CS$7$0001
IL_0022: ldloc.3 // CS$7$0001
IL_0023: ldloc.2 // CS$6$0000
IL_0024: ldlen
IL_0025: conv.i4
IL_0026: clt
IL_0028: stloc.s 04 // CS$4$0002
IL_002A: ldloc.s 04 // CS$4$0002
IL_002C: brtrue.s IL_0013

FWIW, JavaScript is and always will be closer to c#, whereas IL could plausibly be an analog to assembler.

Bottom line: with assembler, given enough time, skill, knowledge, and patience, one can do anything that the hardware is capable of doing.

OTOH, higher level languages, like HTML and JavaScript are more like pieces of a jigsaw puzzle that alone are quite useless.

Plus, for many web applications we can cut JavaScript out of the picture altogher and do our processing server side.

Additionally, our end-users, or their systems administrators can shutdown JavaScript altogether.

Just because c/c++ can be compiled to JavaScript does not make JavaScript into assembler, no more than Nikhilk's Script# makes JavaScript into assembler.

YMMV

Thanks for the post. Was interesting to know that they ported the Unreal engine so quickly, wow.

@Scott: Fully agree on your comment about OO-development in JS. That is exactly one of the biggest problems of JS, it looks like it's OO, but it's not. When you start to use it as an OO-language, you'll run into problems.

To build further upon my analogy, it looks like a hammer but it actually is a nailgun.

I like to think that EcmaScript is a kind of assembly.
But in reality every Turing complete language can be an assembly if you go that way. Only need arrays and conditional branch and simple math library to create a VM and run anything on top of it.
But EcmaScript is a kind of platform, like x86 is a platform. X86 is also a target for compilers. With JavaScript you can say that, but you cant say that it is a assembly, because it is not the last step on chain. It is not atom and indivisible (of course there is microcode and we can split atoms), then I don't consider it the assembly of the web.

"but there's only one language that works everywhere without installation or trouble and that's JavaScript".

This is hardly a worthy justification for not getting off our asses and doing something about the situation. We can do better, We must do better. There are so many glorious examples out there of why JavaScript is a pig, and for all the efforts out there (TypeScript, CoffeeScript, e.t.c e.t.c) of people to say - "Hey guys, you don't have to work with the pig any more, here's your pig lipstick", one thing remains true...

You can put all the lipstick you want on a pig.....But it's still a pig. JavaScript is one ugly pig.

Great post Scott. Once I was reluctant to use it, but once it clicked I just loved it. I would really encourage people not disregard it just because it's different of what you're used to.

By the way, you have a little typo, it says "anther" instead of "another".

Hi Guys

I read all your comments and I have one conclusion, there is not even one comment from a girl. Girls should take an active interest in Coding.

Don't blame me, I am from the Social Sciences.

@Kenneth,

re. premature optimisation

For many, many applications (most) that is true, but for anything like games, or other applications that are compute intensive, that becomes an issue. In these environments, performance is really an issue and needs to be designed in from the start. The subset of JS used in asm.js provides a model using byte arrays and a restricted set of javascript constructs, more closely corresponding to the facilities offered by assembly language.

My issue is that the overhead of downloading and translating text-based code, at runtime, imposes significant overhead. I really cannot believe that this is the best a 21st century computing environment can offer. I really hope not, otherwise it may be time to try to change career.

@Scott,

I beg to differ, but Prototype-based programming IS object-oriented programming. In most senses closer to Alan Kay's original meaning of the term than any of the later languages where polymorphic dispatch got restricted to be related to static types (from the Simula/C++ tradition).

In many senses, Self is more object-oriented than Smalltalk as the only organising constructs are objects and all computation is performed by messages. (Smalltalk was not quite purist on this - a few methods are instrinsic and handled specially in the VM). The work of VPRI (Kay's latest project) largely uses a prototype-based language as its basis.

Kay has previously stated that the message-passing mechanism is more fundamental to OOP than the object part. The ability for any object to respond to a message is severely limited in most OO languages, requiring kludges like interfaces to get some semblance back.

I like to refer to class-based (or classical) object-oriented languages as COOLs, and prototype-based object-oriented languages as POOL. Self includes a subsystem that behaves like Smalltalk-80, and its quite tiny. I like to refer to this as being COOL in the POOL, but I'm a fan of Holger Czukay's music, so that's natural.

Self also pioneered many of the approaches in VMs that have since enabled languages like Java and JavaScript to achieve reasonable performance.

No, it's not the assembler of the web, it's the C of the web. It's ubiquitous enough to be a universal backend for other languages, but also high-end enough to be very usable for hand-crafted code.

"You can say that English is lousy Spanish, as well. But that's because it's not Spanish". This sums it up so well. And its funny ! Well said. I am a bilingual South African, and there are things I can say in Afrikaans that a dictionary of English words would have no poetic equivalent. In those cases I speak Afrikaans. I am a C# programmer, a JavaScript programmer , a C++ programmer and even had my fair share of php and C . "I don't always program the web , but when I do I use JavaScript ;-)"

How do you achieve vendor lock in with an open source implementation of an open standard?

You could do what xamarin did with mono, which is licensed under the LGPL. The LGPL is an open source license, and .net is an open iso standard, but you can't use it at all on iOS unless your app is also open source, or you provide object files for your users to relink from (translation: give your app for free or make it trivial to pirate). Xamarin will sell you a commercial license, but they are the only vendor with the legal authority to do this. Thus, if you want your .net app on iOS, and you don't want to give it away for free or be pirated, then you are locked into one vendor only: xamarin, and the prices of the commercial licenses reflect this monopoly - even the lowest single developer license for one year (and one app?) costs more than my revenue across my six mobile apps for the last two years.

But, the original comment regarding TypeScript is still incorrect. TypeScript isn't LGPL, it is Apache 2.0. That means you can freely use it, even in packaged app stores. People use it for html apps in windows 8 for example. The worst the copyright holder can do to an open source, apache 2.0 licensed library is fork it, relicense the fork, then stop development of the original. Not that this hasn't happened before, but it's a pretty blatant vendor lock-in power grab.

I would say it is the runtime of the web.. as for comments about a 40-60% drop in performance being unacceptable.. we run GUI OSes that have a lot of garbage running in the background, and build line of business apps in higher level languages (C#, Java, Python, etc) that see that kind of performance drop on servers that are handling thousands of users. Here we're talking a drop on a client machine that likely isn't doing too much else.

I'd say that when you don't treat JS like an OO hole, you can build with square pegs just fine. I tend to write my JS with more similarities to C than more OO paradigms. Libraries that pass entities, and manipulate/communicate against them. You can create reusable modules.. but more often than not, I do not "new" anything up.

I find that NodeJS has brought far more to JS development and a lot of paradigms that are working very well than most of what has happened in the browser for over a decade. I don't like AMD as much as CommonJS, but it is a better fit in the browser... I also think that jQuery's monad-like interfaces are being overused and badly.

All that said, I feel that JS is a pretty nice, expressive language that using modern techniques such as modularization and testability, it works well. IMHO TDD is far nicer in JS than any static language I've ever used.

We can argue semantics. But there is no denying that JS is the most available glue language we have on the web. Maybe we should call it the web glue.

then i guess magix illuminate is a 5th generation programming language, abstracted away through assembly programming languages, such that the ide is reachable from within your browser, or something ...? ;)

@Kenneth Truyers -- "Take TypeScript, which adds static typing to JS. Loose typing is not JavaScript's problem. Yes, it provides compile-time errors, but those errors are not the ones that are hard to solve."

Not last week, four experienced Javascript coders (with years of experience each) plus myself spent no less than four days tracking down a bug in a Node application that would have taken a static compiler 0.00000015 seconds to detect. The RCA for this bug was pretty clear: in essence, it was a type mismatch error. It took two lines of code to fix: an if-statement to serve as a run-time type check.

That's a total of five engineers, across four days. You're right that the solution was trivial once detected. The problem was the detection. Given industry average pay rates for software engineers, you can do the math and try to tell me that these bugs don't warrant first-class solutions with a straight face.

Writing a browser-detection and wrapper library can be (and has been) done in far less time, assuming the billions and billions available on the web don't already meet your needs. Solving the human factors in code correctness -- that's where the real gains are to be had.

Apple has a big hand in LLVM, and an interesting patent regarding Javascript/LLVM IR conversion.