7 ms·

Experimental New Directions for Javascript

54 points by jashkenas 12y ago

pothibo 12y ago
Love the SaneScript idea, that could be very big.
eranation 12y ago
I am all for recreating JavaScript the way it should have been, but aren't the problems this tries to solve solvable with a good linter? (perhaps a very smart one, on the verge of a compiler, but still a linter) I think TypeScript et al provide the needed type safety (until ES6 is fully supported) I'm just not sure we need a new "the good parts only" language. Didn't Google already try to do that with Dart?, I think Dart is great, but it still long way to go. There a tons of bad things you can do with any language, Java, Scala, Ruby, Python that people don't do anymore and any automated style check / lint will fail. You don't go and remove parts from the language, you just have a good style check / lint plugin. I mean, you can use "go to" in the form of break to label in Java, but I don't see anyone using it much. This is very interesting, but I'm not sure it will get a lot of traction (mostly due to the need to rewrite huge parts of your code as they won't compile, vs gradually fixing your code using lint warnings). Am I missing something? p.s. took me a minute to realize who is the OP (Jeremy Ashkenas of Backbone and CoffeeScript fame), I would love to hear your opinion on this, I highly respect it!
- gavinpc 12y ago
  > a good linter No doubt this is an evolution of Google Closure, which you might call a "very smart" linter. As the author of the O'Reilly book put it, If JSLint will hurt your feelings, Closure will put you into therapy.
jashkenas 12y ago
* SoundScript (Google) * SaneScript (Google) * TypeScript (Microsoft) * ECMAScript 4 (Dead) * AtScript (Google) * Flow (Facebook) * Closure Compiler Strict Mode (Google) * Asm.js (Mozilla) * Dart (Google) * PureScript (OSS) Welcome to the Typed JavaScript Thunderdome! Ten contenders enter, one JS leaves! https://www.youtube.com/watch?v=pmRAiUPdRjk https://www.youtube.com/watch?v=pmRAiUPdRjk
- pests 12y ago
  Asm.js is just standard JS that happens to conform to Mozilla's performance guarantees.
  - TazeTSchnitzel 12y ago
    Indeed, and it benefits from ES6 stuff which was added for asm.js's sake.
- adamvalve 12y ago
  http://xkcd.com/927/ http://xkcd.com/927/
- _random_ 12y ago
  Google consists of openly competing departments as far as I understand? Java vs Go vs Dart vs Python vs AtScript vs Sane/Sound/Script. They are either non-general-purpose (DSL) or competing.
- mappu 12y ago
  You forgot * Dependent JavaScript (Mozilla + Microsoft) http://cseweb.ucsd.edu/~rchugh/research/nested/djs.pdf http://cseweb.ucsd.edu/~rchugh/research/nested/djs.pdf https://github.com/ravichugh/djs https://github.com/ravichugh/djs
breckinloggins 12y ago
Programming language researchers always seem to miss the biggest selling point of manifest and (partly-)nominal typing. It's the thing that happens after a C# programmer types a "." in Visual Studio. Want someone to use a single language and voluntarily turn the play-doh of a prototype into a sound concrete foundation via gradual typing? Tell them they will get full IntelliSense. That Microsoft environments are STILL 15 years ahead of the Unix / web world on this (and modulo F# type providers, themselves 15 years behind Genera and SmallTalk) will be recorded in history as one of the tragic ironies of this age. Give up assuming that all programming must be done on a teletype from the 60's. It's time to move on to at LEAST the Lisp Machines of the 80's. Please?? By the way, for those who didn't understand what Kythe[1] was all about: THIS is what it's all about. It's possible without types, but it's MUCH better with them. [1] http://www.kythe.io/docs/schema/ http://www.kythe.io/docs/schema/
- beliu 12y ago
  This is a great point. The quality of the tooling around a given language/ecosystem has a huge impact on the productivity of people working in that ecosystem. See also https://srclib.org/ https://srclib.org/, a library with similar goals to Kythe supporting a different set of initial languages (including JavaScript, Python, Ruby, Java, Haskell, and Go) with editor plugin support for Emacs, Sublime, and Atom. (Disclaimer: I'm one of the authors.) The dynamic languages, and JavaScript in particular, are hard to support well. Libraries like tern.js make it doable, but life would be much easier with stronger static guarantees from the language itself. For now, it's a very hard problem, but there is so much to gain from Intellisense-level tooling around JS.
  - breckinloggins 12y ago
    That's awesome! What I'm hoping for is a "decoupling layer" that allows every text editor, IDE, and other code tool on the planet to hook into one end, and every language, compiler, interpreter, etc. to hook into the other. If I'm writing a new language (which, of course, I am) I know how important tooling is. But I don't use vim or Emacs so I personally don't care about vim or Emacs. Sublime Text maybe. It would be nice if I could upload a thing somewhere for my language and suddenly GitHub gets syntax highlighting for it and every editor and IDE in the world suddenly supports all the IntelliSense-like things for it. But we don't do it that way. Each of us has to re-invent 18 wheels. Needless to say, I hope approaches like yours and Kythe succeed. Then we can focus on the obvious utility of adding more metadata to our programs.
ep103 12y ago
I'm so tired of these "Why can't JavaScript be just like my favorite static-ly typed language" conversations. Leave my javascript alone please.
- Zikes 12y ago
  I think the issue is that it's literally the only option for web development. If there were a common bytecode that multiple languages could compile to so that everyone could use whatever language they preferred, that would be ideal.
  - bcheung 12y ago
    You can always create your own language that compiles to Javascript. There are multiple examples of this with languages that have type safety. With the Mozilla Parser API this becomes really easy.
- sanderjd 12y ago
  This is all purely opt-in and compatible with "your javascript".
transfire 12y ago
Seems that Javascript was named appropriately after all. With a few more iterations it will be Java.
bobajeff 12y ago
If I understand this correctly SaneScript is like asm.js in that it's a subset of JavaScript but rather being intended for compilers it's intended for humans so that JS engines can start to remove the insane parts of the language and transition it be SoundScript which is not to be compatible with JavaScript.
- olavk 12y ago
  SaneScript is AFAICT like the "use strict" directive in ES5 which defines a restricted subset of the language. Compilers might also take advantage of this by performing certain optimizations. SoundScript extends this restricted subset. It is incompatible with previous versions of JavaScript only in the same sense that ES5 is incompatible with ES3: It introduces new features not supported by older engines.
bcheung 12y ago
If I wanted a typed language I would use Java. Dynamic languages allow me to get the job done faster. It is extremely rare that I run into any issues regarding type. Every typed / object oriented language I have used so far forces me to jump through hoops to get at my data and I find myself needing to create way too many objects. I want to work with data, not objects, not types. Parsing JSON to a hash is especially problematic in typed languages. Often they force you to create a class that maps from the JSON to a class. This is extremely tedious and wastes time. Also, if the JSON can change dynamically then you are screwed as it can't be mapped to a class anymore. If you want type safety there are plenty of means to do this in a language that compiles to Javascript or some kind of linting step. Please don't turn Javascript into Java.
- Bahamut 12y ago
  What if the typing was optional?
  - bcheung 12y ago
    I'm down for that.
    - seasoup 12y ago
      I'm still not, it's adding complexity in exchange for performance. I prefer ease of use of the language over performance, JavaScript is fast enough for most things and is still getting faster without adding complexity for programmers.
  - enobrev 12y ago
    That's what I loved about the [basically] now-deceased Actionscript 3 [1]. It was an optionally typed Javascript with compile-time and runtime checking, packages, and namespaces. It was an absolute pleasure to code with. I would generally start my prototypes untyped to get something running quickly as a throwaway, and then rewrite strictly typed as I better understood the problem. I was very happy to ditch Flash years ago, but I would have loved to have AS3 replace Javascript. 1: http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0 http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0
jsmadthrow 12y ago
Why do people keep on trying to fuck up Javascript? I don't want your shit OOP and classes, take them back. Do you even get javascript? And the beauty and ease of coding in it? JS is amazing because of two things: 1. VAR - yes var. it's 2015 and yet you want me to waste my time typing in useless int, float, char. Really? But wait! now that you have wasted hours adding useless types to your code, you can benefit from our IDE that will tell you where you missed one! So you see, we actually saved your ass! 2. JSON, and everything is an object. Instead of creating 20 functions, a single function(x) can handle multiple cases with flow enhancement. x is an array. x[0] is a number, x[1] is an optional object, x[2] is a freaking function. all dynamically changeable. f([1]), f([2, {}]), f([3, {}, callback]). you want to add another flow? no problem, extend your array or just set a property on the object, js serves you, you are the master. -- instead what we get? 'too few arguments throws'; typeof D < {new(x:T):D, s(x:T):U, ...C’s...}. WTF is that? Does that look like sound coherent code to you?
- pornel 12y ago
  It looks like you didn't fully understand what the presentation is about. • `var` is replaced by `let`, but it works mostly the same in sane situations. It's merely a bugfix for warts in `var`. It has nothing to do with static type declarations. • Types are optional. JSON is still allowed. For a bag of properties `Map` is suggested, since it doesn't have some of the quirks of using `Object` as a map. And the WTF is not a suggested syntax but an explanation of the type system in a more formal notation.
- tacos 12y ago
  Not even C++ requires you to type a "useless float or char" ahead of a variable any more. But declaring something before using it offers a number of benefits with a JIT compiler in a VM. If you choose to use it, it's available. In this case, you can have it both ways.
- _random_ 12y ago
  How can you f..k up something that is screwed up from the start? Oh, the beauty: http://wtfjs.com http://wtfjs.com
- 12y ago
olavk 12y ago
Mascara Compiler (http://www.mascaraengine.com/ http://www.mascaraengine.com/) supports many of these features already: - non-nullable types - proper scoping (no use before declare, block scope) - optional and rest arguments - calling with too few arguments is flagged by compiler - "this:" parameter - Function types are contravariant - classes, interfaces
azakai 12y ago
I think the motivations here are noble, but what troubles me is that this is trying to fix two problems with one big risky hammer. The problems are 1. JS has various annoying parts, like how comparisons work, or that x.y returns undefined if y isn't a property, etc. 2. JS is sometimes hard to optimize to Java-like speed. I think (1) is already well underway to being solved, through compiling to JS. Things like TypeScript, CoffeeScript, ClojureScript, Elm, Scala.js, GWT, JSIL, Emscripten, etc. Those let you compile whatever language you want, without all the JS oddities. You can use anything from a familiar language like Java or C# or C++ or Scala, to an almost-JS language like TypeScript. People aren't really limited by JavaScript's oddities anymore. It's true these languages sometimes have downsides when compiled, e.g. due to limitations on debugging. But progress is being made there and things are pretty good already. (2) is indeed something also worth solving. But I'm not sure the solution is the same solution, so trying to fix both at once sounds far, far riskier. For example, a lower-risk way to help with the perf issues might be work piece by piece, perhaps starting by proposing a hole-less array type for JavaScript, to avoid the sparse array problem.
tieTYT 12y ago
> [SaneScript] Accessing missing properties throws (on both reads & writes) Ah, I would love this. I have a small, thoroughly tested JS app (15k+ lines of code) but the biggest pain in the butt to debug is, "how did this 'undefined' get here?" I wish there was a way to fail early without putting tons of guard clauses everywhere.
- peterashford 12y ago
  I hear ya. One of my greatest frustrations with reading "Javascript: the good parts" is where Crockford dismisses the legions of faults with Javascript as 'things that never happen to him anyway". Well in my bloody world, these JS faults go undetected in production code, causes days lost to debugging, cause customer complaints etc... "Fail early" (and loudly!) ought to be design goals for all programming languages IMO.

54 points by jashkenas 12y ago

Love the SaneScript idea, that could be very big.

I am all for recreating JavaScript the way it should have been, but aren't the problems this tries to solve solvable with a good linter? (perhaps a very smart one, on the verge of a compiler, but still a linter) I think TypeScript et al provide the needed type safety (until ES6 is fully supported) I'm just not sure we need a new "the good parts only" language. Didn't Google already try to do that with Dart?, I think Dart is great, but it still long way to go. There a tons of bad things you can do with any language, Java, Scala, Ruby, Python that people don't do anymore and any automated style check / lint will fail. You don't go and remove parts from the language, you just have a good style check / lint plugin. I mean, you can use "go to" in the form of break to label in Java, but I don't see anyone using it much. This is very interesting, but I'm not sure it will get a lot of traction (mostly due to the need to rewrite huge parts of your code as they won't compile, vs gradually fixing your code using lint warnings). Am I missing something? p.s. took me a minute to realize who is the OP (Jeremy Ashkenas of Backbone and CoffeeScript fame), I would love to hear your opinion on this, I highly respect it!

gavinpc 12y ago
> a good linter No doubt this is an evolution of Google Closure, which you might call a "very smart" linter. As the author of the O'Reilly book put it, If JSLint will hurt your feelings, Closure will put you into therapy.

jashkenas 12y ago

* SoundScript (Google) * SaneScript (Google) * TypeScript (Microsoft) * ECMAScript 4 (Dead) * AtScript (Google) * Flow (Facebook) * Closure Compiler Strict Mode (Google) * Asm.js (Mozilla) * Dart (Google) * PureScript (OSS) Welcome to the Typed JavaScript Thunderdome! Ten contenders enter, one JS leaves! https://www.youtube.com/watch?v=pmRAiUPdRjk https://www.youtube.com/watch?v=pmRAiUPdRjk

pests 12y ago
Asm.js is just standard JS that happens to conform to Mozilla's performance guarantees.
- TazeTSchnitzel 12y ago
  Indeed, and it benefits from ES6 stuff which was added for asm.js's sake.
adamvalve 12y ago
http://xkcd.com/927/ http://xkcd.com/927/
_random_ 12y ago
Google consists of openly competing departments as far as I understand? Java vs Go vs Dart vs Python vs AtScript vs Sane/Sound/Script. They are either non-general-purpose (DSL) or competing.
mappu 12y ago
You forgot * Dependent JavaScript (Mozilla + Microsoft) http://cseweb.ucsd.edu/~rchugh/research/nested/djs.pdf http://cseweb.ucsd.edu/~rchugh/research/nested/djs.pdf https://github.com/ravichugh/djs https://github.com/ravichugh/djs

breckinloggins 12y ago

Programming language researchers always seem to miss the biggest selling point of manifest and (partly-)nominal typing. It's the thing that happens after a C# programmer types a "." in Visual Studio. Want someone to use a single language and voluntarily turn the play-doh of a prototype into a sound concrete foundation via gradual typing? Tell them they will get full IntelliSense. That Microsoft environments are STILL 15 years ahead of the Unix / web world on this (and modulo F# type providers, themselves 15 years behind Genera and SmallTalk) will be recorded in history as one of the tragic ironies of this age. Give up assuming that all programming must be done on a teletype from the 60's. It's time to move on to at LEAST the Lisp Machines of the 80's. Please?? By the way, for those who didn't understand what Kythe[1] was all about: THIS is what it's all about. It's possible without types, but it's MUCH better with them. [1] http://www.kythe.io/docs/schema/ http://www.kythe.io/docs/schema/

beliu 12y ago
This is a great point. The quality of the tooling around a given language/ecosystem has a huge impact on the productivity of people working in that ecosystem. See also https://srclib.org/ https://srclib.org/, a library with similar goals to Kythe supporting a different set of initial languages (including JavaScript, Python, Ruby, Java, Haskell, and Go) with editor plugin support for Emacs, Sublime, and Atom. (Disclaimer: I'm one of the authors.) The dynamic languages, and JavaScript in particular, are hard to support well. Libraries like tern.js make it doable, but life would be much easier with stronger static guarantees from the language itself. For now, it's a very hard problem, but there is so much to gain from Intellisense-level tooling around JS.
- breckinloggins 12y ago
  That's awesome! What I'm hoping for is a "decoupling layer" that allows every text editor, IDE, and other code tool on the planet to hook into one end, and every language, compiler, interpreter, etc. to hook into the other. If I'm writing a new language (which, of course, I am) I know how important tooling is. But I don't use vim or Emacs so I personally don't care about vim or Emacs. Sublime Text maybe. It would be nice if I could upload a thing somewhere for my language and suddenly GitHub gets syntax highlighting for it and every editor and IDE in the world suddenly supports all the IntelliSense-like things for it. But we don't do it that way. Each of us has to re-invent 18 wheels. Needless to say, I hope approaches like yours and Kythe succeed. Then we can focus on the obvious utility of adding more metadata to our programs.

ep103 12y ago

I'm so tired of these "Why can't JavaScript be just like my favorite static-ly typed language" conversations. Leave my javascript alone please.

Zikes 12y ago
I think the issue is that it's literally the only option for web development. If there were a common bytecode that multiple languages could compile to so that everyone could use whatever language they preferred, that would be ideal.
- bcheung 12y ago
  You can always create your own language that compiles to Javascript. There are multiple examples of this with languages that have type safety. With the Mozilla Parser API this becomes really easy.
sanderjd 12y ago
This is all purely opt-in and compatible with "your javascript".

transfire 12y ago

Seems that Javascript was named appropriately after all. With a few more iterations it will be Java.

bobajeff 12y ago

If I understand this correctly SaneScript is like asm.js in that it's a subset of JavaScript but rather being intended for compilers it's intended for humans so that JS engines can start to remove the insane parts of the language and transition it be SoundScript which is not to be compatible with JavaScript.

olavk 12y ago
SaneScript is AFAICT like the "use strict" directive in ES5 which defines a restricted subset of the language. Compilers might also take advantage of this by performing certain optimizations. SoundScript extends this restricted subset. It is incompatible with previous versions of JavaScript only in the same sense that ES5 is incompatible with ES3: It introduces new features not supported by older engines.

bcheung 12y ago

If I wanted a typed language I would use Java. Dynamic languages allow me to get the job done faster. It is extremely rare that I run into any issues regarding type. Every typed / object oriented language I have used so far forces me to jump through hoops to get at my data and I find myself needing to create way too many objects. I want to work with data, not objects, not types. Parsing JSON to a hash is especially problematic in typed languages. Often they force you to create a class that maps from the JSON to a class. This is extremely tedious and wastes time. Also, if the JSON can change dynamically then you are screwed as it can't be mapped to a class anymore. If you want type safety there are plenty of means to do this in a language that compiles to Javascript or some kind of linting step. Please don't turn Javascript into Java.

Bahamut 12y ago
What if the typing was optional?
- bcheung 12y ago
  I'm down for that.
  - seasoup 12y ago
    I'm still not, it's adding complexity in exchange for performance. I prefer ease of use of the language over performance, JavaScript is fast enough for most things and is still getting faster without adding complexity for programmers.
- enobrev 12y ago
  That's what I loved about the [basically] now-deceased Actionscript 3 [1]. It was an optionally typed Javascript with compile-time and runtime checking, packages, and namespaces. It was an absolute pleasure to code with. I would generally start my prototypes untyped to get something running quickly as a throwaway, and then rewrite strictly typed as I better understood the problem. I was very happy to ditch Flash years ago, but I would have loved to have AS3 replace Javascript. 1: http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0 http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0

jsmadthrow 12y ago

Why do people keep on trying to fuck up Javascript? I don't want your shit OOP and classes, take them back. Do you even get javascript? And the beauty and ease of coding in it? JS is amazing because of two things: 1. VAR - yes var. it's 2015 and yet you want me to waste my time typing in useless int, float, char. Really? But wait! now that you have wasted hours adding useless types to your code, you can benefit from our IDE that will tell you where you missed one! So you see, we actually saved your ass! 2. JSON, and everything is an object. Instead of creating 20 functions, a single function(x) can handle multiple cases with flow enhancement. x is an array. x[0] is a number, x[1] is an optional object, x[2] is a freaking function. all dynamically changeable. f([1]), f([2, {}]), f([3, {}, callback]). you want to add another flow? no problem, extend your array or just set a property on the object, js serves you, you are the master. -- instead what we get? 'too few arguments throws'; typeof D < {new(x:T):D, s(x:T):U, ...C’s...}. WTF is that? Does that look like sound coherent code to you?

pornel 12y ago
It looks like you didn't fully understand what the presentation is about. • `var` is replaced by `let`, but it works mostly the same in sane situations. It's merely a bugfix for warts in `var`. It has nothing to do with static type declarations. • Types are optional. JSON is still allowed. For a bag of properties `Map` is suggested, since it doesn't have some of the quirks of using `Object` as a map. And the WTF is not a suggested syntax but an explanation of the type system in a more formal notation.
tacos 12y ago
Not even C++ requires you to type a "useless float or char" ahead of a variable any more. But declaring something before using it offers a number of benefits with a JIT compiler in a VM. If you choose to use it, it's available. In this case, you can have it both ways.
_random_ 12y ago
How can you f..k up something that is screwed up from the start? Oh, the beauty: http://wtfjs.com http://wtfjs.com
12y ago

olavk 12y ago

Mascara Compiler (http://www.mascaraengine.com/ http://www.mascaraengine.com/) supports many of these features already: - non-nullable types - proper scoping (no use before declare, block scope) - optional and rest arguments - calling with too few arguments is flagged by compiler - "this:" parameter - Function types are contravariant - classes, interfaces

azakai 12y ago

I think the motivations here are noble, but what troubles me is that this is trying to fix two problems with one big risky hammer. The problems are 1. JS has various annoying parts, like how comparisons work, or that x.y returns undefined if y isn't a property, etc. 2. JS is sometimes hard to optimize to Java-like speed. I think (1) is already well underway to being solved, through compiling to JS. Things like TypeScript, CoffeeScript, ClojureScript, Elm, Scala.js, GWT, JSIL, Emscripten, etc. Those let you compile whatever language you want, without all the JS oddities. You can use anything from a familiar language like Java or C# or C++ or Scala, to an almost-JS language like TypeScript. People aren't really limited by JavaScript's oddities anymore. It's true these languages sometimes have downsides when compiled, e.g. due to limitations on debugging. But progress is being made there and things are pretty good already. (2) is indeed something also worth solving. But I'm not sure the solution is the same solution, so trying to fix both at once sounds far, far riskier. For example, a lower-risk way to help with the perf issues might be work piece by piece, perhaps starting by proposing a hole-less array type for JavaScript, to avoid the sparse array problem.

tieTYT 12y ago

> [SaneScript] Accessing missing properties throws (on both reads & writes) Ah, I would love this. I have a small, thoroughly tested JS app (15k+ lines of code) but the biggest pain in the butt to debug is, "how did this 'undefined' get here?" I wish there was a way to fail early without putting tons of guard clauses everywhere.

peterashford 12y ago
I hear ya. One of my greatest frustrations with reading "Javascript: the good parts" is where Crockford dismisses the legions of faults with Javascript as 'things that never happen to him anyway". Well in my bloody world, these JS faults go undetected in production code, causes days lost to debugging, cause customer complaints etc... "Fail early" (and loudly!) ought to be design goals for all programming languages IMO.