8 ms·

Miguel De Icaza: CLI on the Web.

65 points by kssreeram 16y ago

mkramlich 16y ago
what was Microsoft thinking when they coined a name whose acronym was already used and very well known in the field? I think it shows either a little contempt or ignorance, or just bad taste, to do that without first exhausting any reasonable alternative. The title and article confused the hell out of me due to their hijacking of CLI.
- rbanffy 16y ago
  They do it all the time. I had to explain a good couple times the difference between an application service provider and ASP the IIS thingie. I really wish they gave up software and kept doing their excellent keyboard and mice.
MichaelGG 16y ago
Microsoft had a similar project called Volta: http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta It worked at the bytecode level - it wasn't just compiling C# into JS or something like that. I seem to remember that it had a full runtime in Javascript. It was terribly slow. But, this kind of approach might not be so bad going forward, now that JS engines are faster. If the browser doesn't have a .NET runtime built-in, fallback to JS emulation.
RyanMcGreal 16y ago
<script runat="lawyers"> alert('Microsoft can pull the plug on your project at any time'); </script>
- postfuturist 16y ago
  No. The suggestion is for an implementation of ECMA CLI, which is not owned by Microsoft.
  - RyanMcGreal 16y ago
    "Microsoft and its partners hold patents for CLI. ECMA and ISO require that all patents essential to implementation be made available under 'reasonable and non-discriminatory (RAND) terms', but interpretation of this has led to much controversy, particularly in the case of Mono." http://en.wikipedia.org/wiki/Common_Language_Infrastructure#Standardization_and_licensing http://en.wikipedia.org/wiki/Common_Language_Infrastructure#...
    - postfuturist 16y ago
      Between the unproven nature of the patents in the case of third party implementations, the uncertainty of how enforceable software patents are at all given recent court precedence, the RAND terms, and the Community Promise, one can hardly say that Microsoft can "pull the plug" on an implementation of ECMA CLI. If anything, it would seem more protected from patent litigation than the average bit of software.
      - vidarh 16y ago
        The uncertainty is enough for them to "pull the plug" for all practical purposes simply by dragging people into court. If SCO were able to keep IBM and Novell fighting them in court for 7 years on the basis of ridiculous unfounded claims, then how long do you think a well funded company like Microsoft can keep third parties spending money defending themselves for?
        postfuturist 16y ago
        MSFT could drag any software company with a piece of software of significant complexity into court over patent infringement however spurious those claims may be. So nobody should ever write software, right?
      - RyanMcGreal 16y ago
        Miguel de Icaza disagrees: "Microsoft has shot the .NET ecosystem in the foot because of the constant threat of patent infringement that they have cast on the ecosystem." http://webcache.googleusercontent.com/search?q=cache:O6bmbLpdB1gJ:www.sdtimes.com/DOES_WINDOWS_COST_MICROSOFT_OPPORTUNITIES_/By_David_Worthington/About_NET_and_WINDOWS/34203+http://www.sdtimes.com/link/34203&cd=1&hl=en&ct=clnk http://webcache.googleusercontent.com/search?q=cache:O6bmbLp...
jhuckestein 16y ago
Can somebody explain what technical reason prevent me from using any scripting language to write my web-app's client-side code? The way I see it, web-apps today are downloading javascript code that calls back to the server from time to time and outputs a DOM tree. Any scripting language can do that, right? Why can't I write my client-side code in Ruby, Python or PHP?
- rbanffy 16y ago
  Because you would have to add runtimes for all those languages with ties to the DOM. It's hard enough to keep JavaScript secure. It would be a nightmare to keep different implementations of JavaScript, Ruby, Python and client-side PHP secure on different operating systems.
joehewitt 16y ago
This isn't just about replacing JavaScript with a CLI VM. It is about replacing the entire web stack, from HTML, CSS, and SVG all the way down to JavaScript. The primary benefit of this would be that high-level languages like HTML would be implemented on top of the VM, and would no longer be hard-coded into the browser. This would allow you to, for instance, link to the latest version of the HTML runtime the same way you would link to the latest jQuery. This would mean that we would no longer have to wait for the browser vendors and standards bodies to bring us cutting edge technologies. This would also mean that alternative UI toolkits and languages would play on the same level field as HTML and JavaScript.
- mmastrac 16y ago
  Doesn't this just push the problem up the stack one layer? Now the W3C needs to define a specification for a virtual machine that can implement all of the current web specifications performantly. If your VM is missing an API to perform some new form of user input (like multitouch) or a rendering method for a new standard (like webgl) you'll need to head back to a standards body to add more hooks, leaving us in the same position. I think the idea has merit, but the current landscape of software development highly favours the statically compiled C++ browser engines, especially on mobile devices.
  - joehewitt 16y ago
    That is true, but it is much easier to accurately implement a VM spec correctly than complex high-level specs like CSS and HTML, which leave a lot of ambiguity. New hardware interfaces are also a lot easier to specify when you're talking about functions which are rarely going to be called directly by human programmers, since they will usually be accessed through higher-level frameworks. Overall, the goal is to make implementing a browser a much simpler and direct process, and to defer as much complexity as possible to libraries which can be easily downloaded and updated. This would not only result in more a heterogeneous ecosystem for web developers, but fewer browser bugs and incompatibilities.
  - ricmo 16y ago
    Complex VM? New UI metaphors? ...W3C? Sure, that spec oughta be ready in 20 years or so.... It's a vendor job, not a committee spec. They can take the arrows in the back, keep what works, toss what doesn't. I personally think that modern JS+JIT implementations are nearly fast enough: it's become the DOM and its legacy behavior that's becoming the problem now.
drawkbox 16y ago
Javascript/html/css etc were designed to be very small, use very little bandwidth. Flash also thrived and won with this aim. Going this route sounds nice but the battles and bloat would be immense. The web is a thin client, it can do fat client stuff but it is ultimately designed to be thin. That is what made it ubiquitous, not being a fat client... What this is, is making an application for the desktop. They can take a branch of Webkit or Firefox and add CLI but they could also just make their own downloadable app to do this. I like the idea I just think this might wreck the one standard thing we got going in javascript as the glue of the web. A scripting language can bend to the changes as it has done with minimal versions. It could be faster and bytecode itself sure but still it has worked well to tie things together. Silverlight and Flash can partially do this but you still have sandbox issues, which it would also have to have. You'd still have limitations yet it would be a jungle. Right now the jungle is the plugin. Lots of innovation but also lots of differentiation, legacy, etc. I do think that the browser cache needs more space, Javascript engines could be faster, Canvas support and hardware acceleration are needed quickly. Maybe the CLI would be the way but everything we do with the web is design by committee, most of the stuff that made it in that works so well was made when they were still small and non-existent as a market. Everything from here on out will be slowwww to change. HTML/Javascript/css is all just text. If this new system could have app descriptions as small and as readable/runnable by future generations then I think it could work.
mmastrac 16y ago
We have this already: <applet>. As we all know, it didn't work out so well. Having a compact format for classfiles is great. Loading java.util.* for every applet is not so great. Putting .NET into the browser would repeat this horrible experiment. Miguel and Joe and solving the wrong problem. The problem is lack of a standard, compact bytecode format for Javascript, not lack of a complex built-in set of framework classes. Throwing a whole runtime (Mono+CLI) with all of its legacy baggage at the problem won't solve this problem. Once you provide a bytecode format for the browser, web-native tools like GWT can generate more efficient, web-native application. Couple the JS bytecode format with a global, cryptographically-secure long-term JS cache and you've built something just as powerful as Java or .NET but without the platform impedance mismatches.
- Silhouette 16y ago
  > We have this already: <applet>. As we all know, it didn't work out so well. I hear that a lot, but I think Java applets didn't gain widespread traction more because of the arrival of Flash as an easier format for simple animations and interactions than anything else. Java applets remain a useful tool for browser-based UIs today; one of my current projects involves writing one. The biggest technical hurdle is that not everyone installs a modern JRE with their browser any more, which is a downer for casual use because it means there's stuff to install locally. For tools you're going to use every day it's no big hurdle, though. The primary alternatives are Flash (which is well-established but looking more awkward and proprietary with all the current politics, and somewhat limited in its applicability) and JavaScript (which has potential, but isn't even close to being a good language for developing serious UIs of moderate or large size today, and no amount of HTML5 canvas/multimedia hype is going to change that).
- est 16y ago
  > The problem is lack of a standard, compact bytecode format for Javascript, IE can embed javascript bytecode <script language = JScript.Encode>#@~^EQAAAA==C^+.D`Et+^VK~CgBbgQUAAA==^#~@</script> save the above line to 1.html and open it in IE (version<9) it's not standard, though.
  - 16y ago
alanh 16y ago
Thought this was talking about "Command Line Interface" for a while. It in fact refers to Microsoft's "Common Language Infrastructure" (I thought this was CLR, or Common Language Runtime, but I’ve been out of the MSFT camp for a while). Anyway — what’s the difference between this and plugins/Java applets (anything that compiles to Java bytecode)/ActiveX? I suppose the biggest is that this proposes that 1) they have access to the DOM and 2) the browser implements the CLI environment.
- DrJokepu 16y ago
  The Common Language Runtime (CLR) is Microsoft's implementation of the Common Language Interface (CLI). It's not unlike CPython being the "official" implementation of Python.
ricmo 16y ago
The pain of developing web applications is largely dealing with cross-browser DOM and CSS issues. Swapping in a different scripting language may give you faster code execution, classic class-based inheritance and a packaging system, but as far as I can see it does nothing to help with layout issues, widget creation and other UI issues.
- wmf 16y ago
  If you have a fast VM and <canvas>, you can do all your UI that way (see Mozilla Thunderhead) with virtually no cross-browser problems. (Edit: I see that you already mentioned this further down the thread.)
- jerf 16y ago
  The pain of developing web apps today. Having faster execution makes a new class of web apps possible. (The other two things you mention are incidental next to having native code speed.) The longer you've been developing on the web, the worse your blinders are when it comes to what we could really do with native-code speeds.
  - ricmo 16y ago
    OK, how exactly? Web apps now, and presumably in the future, are essentially engines focused on manipulating a DOM structure, which is then rendered (with any luck, correctly) by the browser, right? So unless you're talking about effectively ignoring the DOM and rendering applications solely via use of Canvas or SVG, what is the magic sauce that flavors this <i>new</i> class of web apps?
    - jerf 16y ago
      Image and video manipulation, alternate widget sets (which nowadays tend to require at least one of heavy image manipulation or OpenGL to really work correctly), 3D applications that actually work and aren't just static models rotating (because now you can actually afford to manipulate vertexes with some intelligence). Online games that use a combination of these techniques. Apps that grab video from your webcam and do something with it. (Mozilla demonstrated that: http://arstechnica.com/open-source/news/2009/02/mozilla-demos-impressive-firefox-31-features-at-scale.ars http://arstechnica.com/open-source/news/2009/02/mozilla-demo... ) The dream of doing distributed computing by just visiting a web page could come true (like for X@Home). An OS in your browser would become not-a-joke. Native VNC instead of flash. Native encryption run by the app instead of the browser, possibly permitting ssh-in-the-browser. Actual typesetting could be implemented (surprisingly computationally expensive) allowing actual competition in the Office space. You rather proved my point, unfortunately. Web apps are not about "DOM manipulation". They are about delivering no-install applications over the internet. They have historically been about DOM manipulation because that was all they could afford to do performantly (and that only barely at times). As that changes, so does the web. We're getting a ways along this path anyhow (http://code.google.com/p/quake2-gwt-port/ http://code.google.com/p/quake2-gwt-port/ ), just with increasingly fast JS and other tech, but it's only going to grow more.
tptacek 16y ago
How much of the web's inflexibility comes from Javascript and cross-platform JS issues, and how much of it comes from things like "Canvas is only reliable in 40% of browsers" and "HTML5 video only works reliably in Chrome and Safari"? Because, CLI could address the former (it seems sensible to standardize a bytecode runtime rather than an entire language and its associated libraries), but probably not the latter.
Parabola 16y ago
The work on dynamic JITs in the Javascript world completely outclasses anything the DLR or whatever the Java version is now being called can offer without major overhauls. I mean, look at the computer language benchmarks. Lua and Javascript are starting to inch into compiled language territory, and they are getting better by the day. There is a thriving, competitive atmosphere. CLI and the JVM on the other hand are bloated, slow moving monsters. They just happen to have the static typing crutch keeping them afloat for a while. No, we don't need CLI on the web. We need the CLI to go away entirely. Now, maybe we want to target different languages to the Javascript engines, sure. That actually shouldn't be that hard. A portable bytecode format might be nice. Given the generic nature of Javascript, the semantics of other languages map quite nicely onto it. If you think a bit, the lack of indirection in static languages is really a fancy way of saying "I'm declaring a bunch of things 'const' and letting the compiler get rid of indirection that might otherwise be there." That concept could be brought into dynamic language engines writ large if we really wanted to.

65 points by kssreeram 16y ago

what was Microsoft thinking when they coined a name whose acronym was already used and very well known in the field? I think it shows either a little contempt or ignorance, or just bad taste, to do that without first exhausting any reasonable alternative. The title and article confused the hell out of me due to their hijacking of CLI.

rbanffy 16y ago
They do it all the time. I had to explain a good couple times the difference between an application service provider and ASP the IIS thingie. I really wish they gave up software and kept doing their excellent keyboard and mice.

MichaelGG 16y ago

Microsoft had a similar project called Volta: http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta http://en.wikipedia.org/wiki/Microsoft_Live_Labs_Volta It worked at the bytecode level - it wasn't just compiling C# into JS or something like that. I seem to remember that it had a full runtime in Javascript. It was terribly slow. But, this kind of approach might not be so bad going forward, now that JS engines are faster. If the browser doesn't have a .NET runtime built-in, fallback to JS emulation.

RyanMcGreal 16y ago

postfuturist 16y ago
No. The suggestion is for an implementation of ECMA CLI, which is not owned by Microsoft.
- RyanMcGreal 16y ago
  "Microsoft and its partners hold patents for CLI. ECMA and ISO require that all patents essential to implementation be made available under 'reasonable and non-discriminatory (RAND) terms', but interpretation of this has led to much controversy, particularly in the case of Mono." http://en.wikipedia.org/wiki/Common_Language_Infrastructure#Standardization_and_licensing http://en.wikipedia.org/wiki/Common_Language_Infrastructure#...
  - postfuturist 16y ago
    Between the unproven nature of the patents in the case of third party implementations, the uncertainty of how enforceable software patents are at all given recent court precedence, the RAND terms, and the Community Promise, one can hardly say that Microsoft can "pull the plug" on an implementation of ECMA CLI. If anything, it would seem more protected from patent litigation than the average bit of software.
    - vidarh 16y ago
      The uncertainty is enough for them to "pull the plug" for all practical purposes simply by dragging people into court. If SCO were able to keep IBM and Novell fighting them in court for 7 years on the basis of ridiculous unfounded claims, then how long do you think a well funded company like Microsoft can keep third parties spending money defending themselves for?
      - postfuturist 16y ago
        MSFT could drag any software company with a piece of software of significant complexity into court over patent infringement however spurious those claims may be. So nobody should ever write software, right?
    - RyanMcGreal 16y ago
      Miguel de Icaza disagrees: "Microsoft has shot the .NET ecosystem in the foot because of the constant threat of patent infringement that they have cast on the ecosystem." http://webcache.googleusercontent.com/search?q=cache:O6bmbLpdB1gJ:www.sdtimes.com/DOES_WINDOWS_COST_MICROSOFT_OPPORTUNITIES_/By_David_Worthington/About_NET_and_WINDOWS/34203+http://www.sdtimes.com/link/34203&cd=1&hl=en&ct=clnk http://webcache.googleusercontent.com/search?q=cache:O6bmbLp...

jhuckestein 16y ago

Can somebody explain what technical reason prevent me from using any scripting language to write my web-app's client-side code? The way I see it, web-apps today are downloading javascript code that calls back to the server from time to time and outputs a DOM tree. Any scripting language can do that, right? Why can't I write my client-side code in Ruby, Python or PHP?

rbanffy 16y ago
Because you would have to add runtimes for all those languages with ties to the DOM. It's hard enough to keep JavaScript secure. It would be a nightmare to keep different implementations of JavaScript, Ruby, Python and client-side PHP secure on different operating systems.

joehewitt 16y ago

This isn't just about replacing JavaScript with a CLI VM. It is about replacing the entire web stack, from HTML, CSS, and SVG all the way down to JavaScript. The primary benefit of this would be that high-level languages like HTML would be implemented on top of the VM, and would no longer be hard-coded into the browser. This would allow you to, for instance, link to the latest version of the HTML runtime the same way you would link to the latest jQuery. This would mean that we would no longer have to wait for the browser vendors and standards bodies to bring us cutting edge technologies. This would also mean that alternative UI toolkits and languages would play on the same level field as HTML and JavaScript.

mmastrac 16y ago
Doesn't this just push the problem up the stack one layer? Now the W3C needs to define a specification for a virtual machine that can implement all of the current web specifications performantly. If your VM is missing an API to perform some new form of user input (like multitouch) or a rendering method for a new standard (like webgl) you'll need to head back to a standards body to add more hooks, leaving us in the same position. I think the idea has merit, but the current landscape of software development highly favours the statically compiled C++ browser engines, especially on mobile devices.
- joehewitt 16y ago
  That is true, but it is much easier to accurately implement a VM spec correctly than complex high-level specs like CSS and HTML, which leave a lot of ambiguity. New hardware interfaces are also a lot easier to specify when you're talking about functions which are rarely going to be called directly by human programmers, since they will usually be accessed through higher-level frameworks. Overall, the goal is to make implementing a browser a much simpler and direct process, and to defer as much complexity as possible to libraries which can be easily downloaded and updated. This would not only result in more a heterogeneous ecosystem for web developers, but fewer browser bugs and incompatibilities.
- ricmo 16y ago
  Complex VM? New UI metaphors? ...W3C? Sure, that spec oughta be ready in 20 years or so.... It's a vendor job, not a committee spec. They can take the arrows in the back, keep what works, toss what doesn't. I personally think that modern JS+JIT implementations are nearly fast enough: it's become the DOM and its legacy behavior that's becoming the problem now.

drawkbox 16y ago

Javascript/html/css etc were designed to be very small, use very little bandwidth. Flash also thrived and won with this aim. Going this route sounds nice but the battles and bloat would be immense. The web is a thin client, it can do fat client stuff but it is ultimately designed to be thin. That is what made it ubiquitous, not being a fat client... What this is, is making an application for the desktop. They can take a branch of Webkit or Firefox and add CLI but they could also just make their own downloadable app to do this. I like the idea I just think this might wreck the one standard thing we got going in javascript as the glue of the web. A scripting language can bend to the changes as it has done with minimal versions. It could be faster and bytecode itself sure but still it has worked well to tie things together. Silverlight and Flash can partially do this but you still have sandbox issues, which it would also have to have. You'd still have limitations yet it would be a jungle. Right now the jungle is the plugin. Lots of innovation but also lots of differentiation, legacy, etc. I do think that the browser cache needs more space, Javascript engines could be faster, Canvas support and hardware acceleration are needed quickly. Maybe the CLI would be the way but everything we do with the web is design by committee, most of the stuff that made it in that works so well was made when they were still small and non-existent as a market. Everything from here on out will be slowwww to change. HTML/Javascript/css is all just text. If this new system could have app descriptions as small and as readable/runnable by future generations then I think it could work.

mmastrac 16y ago

We have this already: <applet>. As we all know, it didn't work out so well. Having a compact format for classfiles is great. Loading java.util.* for every applet is not so great. Putting .NET into the browser would repeat this horrible experiment. Miguel and Joe and solving the wrong problem. The problem is lack of a standard, compact bytecode format for Javascript, not lack of a complex built-in set of framework classes. Throwing a whole runtime (Mono+CLI) with all of its legacy baggage at the problem won't solve this problem. Once you provide a bytecode format for the browser, web-native tools like GWT can generate more efficient, web-native application. Couple the JS bytecode format with a global, cryptographically-secure long-term JS cache and you've built something just as powerful as Java or .NET but without the platform impedance mismatches.

Silhouette 16y ago
> We have this already: <applet>. As we all know, it didn't work out so well. I hear that a lot, but I think Java applets didn't gain widespread traction more because of the arrival of Flash as an easier format for simple animations and interactions than anything else. Java applets remain a useful tool for browser-based UIs today; one of my current projects involves writing one. The biggest technical hurdle is that not everyone installs a modern JRE with their browser any more, which is a downer for casual use because it means there's stuff to install locally. For tools you're going to use every day it's no big hurdle, though. The primary alternatives are Flash (which is well-established but looking more awkward and proprietary with all the current politics, and somewhat limited in its applicability) and JavaScript (which has potential, but isn't even close to being a good language for developing serious UIs of moderate or large size today, and no amount of HTML5 canvas/multimedia hype is going to change that).
est 16y ago
> The problem is lack of a standard, compact bytecode format for Javascript, IE can embed javascript bytecode <script language = JScript.Encode>#@~^EQAAAA==C^+.D`Et+^VK~CgBbgQUAAA==^#~@</script> save the above line to 1.html and open it in IE (version<9) it's not standard, though.
- 16y ago

alanh 16y ago

Thought this was talking about "Command Line Interface" for a while. It in fact refers to Microsoft's "Common Language Infrastructure" (I thought this was CLR, or Common Language Runtime, but I’ve been out of the MSFT camp for a while). Anyway — what’s the difference between this and plugins/Java applets (anything that compiles to Java bytecode)/ActiveX? I suppose the biggest is that this proposes that 1) they have access to the DOM and 2) the browser implements the CLI environment.

DrJokepu 16y ago
The Common Language Runtime (CLR) is Microsoft's implementation of the Common Language Interface (CLI). It's not unlike CPython being the "official" implementation of Python.

ricmo 16y ago

The pain of developing web applications is largely dealing with cross-browser DOM and CSS issues. Swapping in a different scripting language may give you faster code execution, classic class-based inheritance and a packaging system, but as far as I can see it does nothing to help with layout issues, widget creation and other UI issues.

wmf 16y ago
If you have a fast VM and <canvas>, you can do all your UI that way (see Mozilla Thunderhead) with virtually no cross-browser problems. (Edit: I see that you already mentioned this further down the thread.)
jerf 16y ago
The pain of developing web apps today. Having faster execution makes a new class of web apps possible. (The other two things you mention are incidental next to having native code speed.) The longer you've been developing on the web, the worse your blinders are when it comes to what we could really do with native-code speeds.
- ricmo 16y ago
  OK, how exactly? Web apps now, and presumably in the future, are essentially engines focused on manipulating a DOM structure, which is then rendered (with any luck, correctly) by the browser, right? So unless you're talking about effectively ignoring the DOM and rendering applications solely via use of Canvas or SVG, what is the magic sauce that flavors this <i>new</i> class of web apps?
  - jerf 16y ago
    Image and video manipulation, alternate widget sets (which nowadays tend to require at least one of heavy image manipulation or OpenGL to really work correctly), 3D applications that actually work and aren't just static models rotating (because now you can actually afford to manipulate vertexes with some intelligence). Online games that use a combination of these techniques. Apps that grab video from your webcam and do something with it. (Mozilla demonstrated that: http://arstechnica.com/open-source/news/2009/02/mozilla-demos-impressive-firefox-31-features-at-scale.ars http://arstechnica.com/open-source/news/2009/02/mozilla-demo... ) The dream of doing distributed computing by just visiting a web page could come true (like for X@Home). An OS in your browser would become not-a-joke. Native VNC instead of flash. Native encryption run by the app instead of the browser, possibly permitting ssh-in-the-browser. Actual typesetting could be implemented (surprisingly computationally expensive) allowing actual competition in the Office space. You rather proved my point, unfortunately. Web apps are not about "DOM manipulation". They are about delivering no-install applications over the internet. They have historically been about DOM manipulation because that was all they could afford to do performantly (and that only barely at times). As that changes, so does the web. We're getting a ways along this path anyhow (http://code.google.com/p/quake2-gwt-port/ http://code.google.com/p/quake2-gwt-port/ ), just with increasingly fast JS and other tech, but it's only going to grow more.

tptacek 16y ago

How much of the web's inflexibility comes from Javascript and cross-platform JS issues, and how much of it comes from things like "Canvas is only reliable in 40% of browsers" and "HTML5 video only works reliably in Chrome and Safari"? Because, CLI could address the former (it seems sensible to standardize a bytecode runtime rather than an entire language and its associated libraries), but probably not the latter.

Parabola 16y ago

The work on dynamic JITs in the Javascript world completely outclasses anything the DLR or whatever the Java version is now being called can offer without major overhauls. I mean, look at the computer language benchmarks. Lua and Javascript are starting to inch into compiled language territory, and they are getting better by the day. There is a thriving, competitive atmosphere. CLI and the JVM on the other hand are bloated, slow moving monsters. They just happen to have the static typing crutch keeping them afloat for a while. No, we don't need CLI on the web. We need the CLI to go away entirely. Now, maybe we want to target different languages to the Javascript engines, sure. That actually shouldn't be that hard. A portable bytecode format might be nice. Given the generic nature of Javascript, the semantics of other languages map quite nicely onto it. If you think a bit, the lack of indirection in static languages is really a fancy way of saying "I'm declaring a bunch of things 'const' and letting the compiler get rid of indirection that might otherwise be there." That concept could be brought into dynamic language engines writ large if we really wanted to.