4 ms·

Why do so many languages choose JS as a 'middle' language? Is it something inherent to the language itself that makes it particularly easy/attractive? Or is it

Why do so many languages choose JS as a 'middle' language? Is it something inherent to the language itself that makes it particularly easy/attractive? Or is it simply because of the availability of the interpreter in the browser?

quarterto 14y ago
Almost certainly the latter. And it's not so much "I want to design a language. Ooh, I'll make it compile to JavaScript!" as "Dammit, why is X so hard in JavaScript X but trivial in language Y? Hmm, I know...". To me, it's testament to just how dynamic JavaScript and prototypal inheritance are.
TazeTSchnitzel 14y ago
It's pretty much the web's bytecode. When minified and gzipped, it's pretty small, too.
ghenne 14y ago
In our case (NS Basic/App Studio) we wrote a translator for VB style BASIC to JavaScript. We wanted to create a cross platform development that could target iOS, Android and other mobile platforms. We started the project about 2 years ago, and saw a few key developments in the JavaScript space. 1. HTML5: the extensions did a lot to move it from a web scripting language to something that could be used for real applications. The Cache Manifest allowed the developer to specify a list of files to be stored on the device, so the app could run offline, with no access to a server. 2. Home Screen: The mobile platforms added the ability to pin web apps to the Home screen with their own icon, making it possible to start them much like native apps. 3. Performance: Work by the browser folks on the internals of the JavaScript engine resulted in huge boosts in performance. The results are in this table: http://www.nsbasic.com/speedtest.htm http://www.nsbasic.com/speedtest.htm. You can see the transition from early BlackBerrys being able to run a few hundred JS loops per second to the Motorola Xoom at 718,000. The benchmark is simplistic, but the message is clear: JavaScript on mobile device is 1000 times faster than a few years ago. It turned out that it was fairly straight forward to write the Translator. Yes, there were enough weird edge cases to question anyone's sanity to do this again, but the result works well. All the control structures translated one to one, so there was little or no drop in performance. We then built a Visual Studio style IDE around it, with support for frameworks like jQuery Mobile, jqWidgets and Sencha to build a complete dev environment. It's been a lot of fun. (and yes, you can use JavaScript instead of BASIC if you want!)
drostie 14y ago
When Rich Hickey announced ClojureScript he said "Why are we doing this? Because Clojure rocks, and JavaScript reaches." The simplest reason is because JS is the Language of the Web. It's worth wondering why this is, and I don't really have an answer. In JS's infancy, Java was meant to be the Language of the Web and JS was its asthmatic younger brother. There are probably purely aesthetic problems which led to Java being overtaken by Flash, but I don't know. I sometimes like to say that Java looked consistent in every browser -- but consistently ugly. But Java is not necessarily fun to develop in either, and getting people to install Java always seemed like it was more pain than getting them to install the Flash plugin. You can treat it as a black box, of course: even to this day, for lots of people, Java on the web just plain doesn't work. But I think you're asking why it doesn't work, and that's much more subtle. You know who would be an interesting person to ask? An advertiser. You see flash ads, you see JS ads, you see flat image ads -- but you never see Java ads. In any case, I think JS won because it gave immediate gratification: you took the image that you had already placed on the page and, onmouseover, you replaced it with an animated GIF which you'd already loaded and cached. It was event-driven design with a GUI language that you already needed to know when you were making a web app in the first place -- you didn't have to learn AWT and Swing and such before you could make and place a drop-down menu; you just placed a SELECT with OPTIONs, the same as for a form. When CSS replaced FONT tags and ECMA partly solved the problem of Microsoft trying to kill Javascript in favor of JScript, it became clear to me that JS was indeed the Language of the Web, and that HTML and CSS were just very smart declarative domain-specific languages for its GUIs. If you want a single lesson, there it is: make sure your language allows for declarative programming, and make sure your GUI language is declarative and event-driven. Its other strengths would not necessarily have been strengths elsewhere. It's an asynchronous language with no race conditions. That's perfect for a responsive GUI, but it's probably wrong for anything which needs lots of processing power. It's got light objects and first-class functions, which is beautiful when you want to package data and write jQuery, but the cool stuff you can do with the Haskell type checker is pretty much not allowed by this model. But those are the reasons why you might still prefer JS, even when other middle languages exist.
- stcredzero 14y ago
  That's perfect for a responsive GUI, but it's probably wrong for anything which needs lots of processing power. Perhaps not so wrong? http://news.ycombinator.com/item?id=3902319 http://news.ycombinator.com/item?id=3902319 As far as why JS, source-map for debugging is a big deal here. This makes it a very good host language because it enables source debugging even when used as a compiler target.
tomjen3 14y ago
Javascript is the webs assembler code. Given how much of what we do we do on the web, it is not strange that it should be the target.
vibrunazo 14y ago
How would you not make it a middle language if you want a web front-end language? The only other way I can think of is baking it up with the browser. Like Google is doing with Dart. But even they are making Dart compile to JavaScript to make sure you don't lose compatibility between different browsers who opt to not cook Dart in. I remember an interview with one of the Dart developers where he said that having it as a requirement that Dart compiles to JS was greatly limiting the potential of what they can do with Dart. But they can't opt out of it, because compatibility with other browsers is too important. In short, they're using JS as a middle language because there's no other way to do it. JS is a terrible language, but because of how the web historically developed, we're forced to use it.
- azakai 14y ago
  > In short, they're using JS as a middle language because there's no other way to do it. JS is a terrible language, but because of how the web historically developed, we're forced to use it. Like any language, some people like it and some people hate it. I love it. If you stay away from the bad parts, it's a cool, flexible dynamic language. And it is pretty good to compile to, benchmarks of C compiled to JS for example are quite good.
  - vibrunazo 14y ago
    I've heard that same argument for a long time from PHP people. Yea, these are all but tools we use for the job. But bottom line is, some tools are just worse than others at pretty much any real practical use. [1] You make it sound like you've read the Javascript: The Good Parts book [2]. I've read it too, and it's a great book I recommend for anyone who must work with Javascript and have no way out of it. But keep in mind that an important premise of the book is aid those who are in this position where they can't run away from Javascript. As shown by this thread of languages that compile to it, it's often perfectly possible to dodge the shortcomings of JS by just not using it. You shouldn't torture yourself for no good reason. If you are in a position where you must work with JavaScript. Then I recommend reading this book to learn to stay away from the bad parts, as you said. But if you can work with any of the compilable languages, I highly recommend you stay away from JS as much as you can. I would repeat the exact same argument for using SASS or LESS instead of CSS. There is no good reason to torture yourself with CSS instead of these better languages. It's very clear that there is such thing as one language that is much better than another in every practical sense. [1] http://www.flickr.com/photos/raindrift/sets/72157629492908038/ http://www.flickr.com/photos/raindrift/sets/7215762949290803... [2] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742 http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...
muyuu 14y ago
This is possibly going to be downvoted to oblivion because it's a "negative" post, but it's very true for many of us. A lot of people, myself included, would rather not do any Javascript at all. Particularly those of us who dealt with it early on, since the 90s. It's a pain, a moving target of practices, compatibility and libraries, and quite simply, we hate it. There is massive demand for anything that successfully abstracts as much JS as possible out of the picture. Libraries like Jquery, Prototype, Mootools, ... and whole substitutive systems like Coffeescript, Clojurescript and those others listed. Happens to Java too. These languages are intensely disliked by many people who have to deal with them because they are infrastructural in their environments. Their architecture is often forced on people who'd much rather program in something else.

quarterto 14y ago

Almost certainly the latter. And it's not so much "I want to design a language. Ooh, I'll make it compile to JavaScript!" as "Dammit, why is X so hard in JavaScript X but trivial in language Y? Hmm, I know...". To me, it's testament to just how dynamic JavaScript and prototypal inheritance are.

TazeTSchnitzel 14y ago

It's pretty much the web's bytecode. When minified and gzipped, it's pretty small, too.

ghenne 14y ago

In our case (NS Basic/App Studio) we wrote a translator for VB style BASIC to JavaScript. We wanted to create a cross platform development that could target iOS, Android and other mobile platforms. We started the project about 2 years ago, and saw a few key developments in the JavaScript space. 1. HTML5: the extensions did a lot to move it from a web scripting language to something that could be used for real applications. The Cache Manifest allowed the developer to specify a list of files to be stored on the device, so the app could run offline, with no access to a server. 2. Home Screen: The mobile platforms added the ability to pin web apps to the Home screen with their own icon, making it possible to start them much like native apps. 3. Performance: Work by the browser folks on the internals of the JavaScript engine resulted in huge boosts in performance. The results are in this table: http://www.nsbasic.com/speedtest.htm http://www.nsbasic.com/speedtest.htm. You can see the transition from early BlackBerrys being able to run a few hundred JS loops per second to the Motorola Xoom at 718,000. The benchmark is simplistic, but the message is clear: JavaScript on mobile device is 1000 times faster than a few years ago. It turned out that it was fairly straight forward to write the Translator. Yes, there were enough weird edge cases to question anyone's sanity to do this again, but the result works well. All the control structures translated one to one, so there was little or no drop in performance. We then built a Visual Studio style IDE around it, with support for frameworks like jQuery Mobile, jqWidgets and Sencha to build a complete dev environment. It's been a lot of fun. (and yes, you can use JavaScript instead of BASIC if you want!)

drostie 14y ago

When Rich Hickey announced ClojureScript he said "Why are we doing this? Because Clojure rocks, and JavaScript reaches." The simplest reason is because JS is the Language of the Web. It's worth wondering why this is, and I don't really have an answer. In JS's infancy, Java was meant to be the Language of the Web and JS was its asthmatic younger brother. There are probably purely aesthetic problems which led to Java being overtaken by Flash, but I don't know. I sometimes like to say that Java looked consistent in every browser -- but consistently ugly. But Java is not necessarily fun to develop in either, and getting people to install Java always seemed like it was more pain than getting them to install the Flash plugin. You can treat it as a black box, of course: even to this day, for lots of people, Java on the web just plain doesn't work. But I think you're asking why it doesn't work, and that's much more subtle. You know who would be an interesting person to ask? An advertiser. You see flash ads, you see JS ads, you see flat image ads -- but you never see Java ads. In any case, I think JS won because it gave immediate gratification: you took the image that you had already placed on the page and, onmouseover, you replaced it with an animated GIF which you'd already loaded and cached. It was event-driven design with a GUI language that you already needed to know when you were making a web app in the first place -- you didn't have to learn AWT and Swing and such before you could make and place a drop-down menu; you just placed a SELECT with OPTIONs, the same as for a form. When CSS replaced FONT tags and ECMA partly solved the problem of Microsoft trying to kill Javascript in favor of JScript, it became clear to me that JS was indeed the Language of the Web, and that HTML and CSS were just very smart declarative domain-specific languages for its GUIs. If you want a single lesson, there it is: make sure your language allows for declarative programming, and make sure your GUI language is declarative and event-driven. Its other strengths would not necessarily have been strengths elsewhere. It's an asynchronous language with no race conditions. That's perfect for a responsive GUI, but it's probably wrong for anything which needs lots of processing power. It's got light objects and first-class functions, which is beautiful when you want to package data and write jQuery, but the cool stuff you can do with the Haskell type checker is pretty much not allowed by this model. But those are the reasons why you might still prefer JS, even when other middle languages exist.

stcredzero 14y ago
That's perfect for a responsive GUI, but it's probably wrong for anything which needs lots of processing power. Perhaps not so wrong? http://news.ycombinator.com/item?id=3902319 http://news.ycombinator.com/item?id=3902319 As far as why JS, source-map for debugging is a big deal here. This makes it a very good host language because it enables source debugging even when used as a compiler target.

tomjen3 14y ago

Javascript is the webs assembler code. Given how much of what we do we do on the web, it is not strange that it should be the target.

vibrunazo 14y ago

How would you not make it a middle language if you want a web front-end language? The only other way I can think of is baking it up with the browser. Like Google is doing with Dart. But even they are making Dart compile to JavaScript to make sure you don't lose compatibility between different browsers who opt to not cook Dart in. I remember an interview with one of the Dart developers where he said that having it as a requirement that Dart compiles to JS was greatly limiting the potential of what they can do with Dart. But they can't opt out of it, because compatibility with other browsers is too important. In short, they're using JS as a middle language because there's no other way to do it. JS is a terrible language, but because of how the web historically developed, we're forced to use it.

azakai 14y ago
> In short, they're using JS as a middle language because there's no other way to do it. JS is a terrible language, but because of how the web historically developed, we're forced to use it. Like any language, some people like it and some people hate it. I love it. If you stay away from the bad parts, it's a cool, flexible dynamic language. And it is pretty good to compile to, benchmarks of C compiled to JS for example are quite good.
- vibrunazo 14y ago
  I've heard that same argument for a long time from PHP people. Yea, these are all but tools we use for the job. But bottom line is, some tools are just worse than others at pretty much any real practical use. [1] You make it sound like you've read the Javascript: The Good Parts book [2]. I've read it too, and it's a great book I recommend for anyone who must work with Javascript and have no way out of it. But keep in mind that an important premise of the book is aid those who are in this position where they can't run away from Javascript. As shown by this thread of languages that compile to it, it's often perfectly possible to dodge the shortcomings of JS by just not using it. You shouldn't torture yourself for no good reason. If you are in a position where you must work with JavaScript. Then I recommend reading this book to learn to stay away from the bad parts, as you said. But if you can work with any of the compilable languages, I highly recommend you stay away from JS as much as you can. I would repeat the exact same argument for using SASS or LESS instead of CSS. There is no good reason to torture yourself with CSS instead of these better languages. It's very clear that there is such thing as one language that is much better than another in every practical sense. [1] http://www.flickr.com/photos/raindrift/sets/72157629492908038/ http://www.flickr.com/photos/raindrift/sets/7215762949290803... [2] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742 http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

muyuu 14y ago

This is possibly going to be downvoted to oblivion because it's a "negative" post, but it's very true for many of us. A lot of people, myself included, would rather not do any Javascript at all. Particularly those of us who dealt with it early on, since the 90s. It's a pain, a moving target of practices, compatibility and libraries, and quite simply, we hate it. There is massive demand for anything that successfully abstracts as much JS as possible out of the picture. Libraries like Jquery, Prototype, Mootools, ... and whole substitutive systems like Coffeescript, Clojurescript and those others listed. Happens to Java too. These languages are intensely disliked by many people who have to deal with them because they are infrastructural in their environments. Their architecture is often forced on people who'd much rather program in something else.