22 ms·

Strengthening JavaScript

343 points by jashkenas 12y ago

azakai 12y ago
> Any program running “correctly” in strong mode should run unchanged as ordinary JS. Thus, strong mode programs can be executed on all VMs that can handle ES6, even ones that don’t recognise the mode. This worries me. If it's running "correctly", then sure, it will run elsewhere. But if it hits something that Strong Mode considers "incorrect", then things diverge, and other browsers will execute something different. This can be avoided if Strong Mode just issues warnings, not errors. Which seems sufficient, if the goal is to inform people about stuff they should optimize. For those that want more rigorous checking, browsers could add a developer mode, in which those warnings become errors. This way, there is no risk of production code working differently on different browsers. We have seen "use strict" cause errors in production. Avoiding that with "use strong" seems like a safer path, with no significant downsides that I can see.
- nickclaw 12y ago
  You should never use "use strict" or "use strong" in production, they're very useful during development but can really only hurt you in production.
  - joshstrange 12y ago
    Could you expand on how it could hurt you? All I was able to find was this [0] > I found two opinions about using strict mode in production: > > There is no reason to ship “use strict” in your production code. There is no performance gain (verified with V8 team and Brendan a while ago) and I don’t need my users’ VMs doing the extra checks as well. Keep it development only, strip it out during build. This way you also avoid the concatenation issue you reference. > And: > > There may not be a performance gain, but there’s also not a performance loss. In production, even more than in development, is where you want to be sure you’re noticing errors. Minimizing the changes between the development and production versions of the code is key to being able to debug issues quickly and efficiently. Yes it helps during development, but there’s no reason to pull it out of production code. > The source is in the comments at the bottom [1] > And of course those 12b weight of "use strict" won't change a thing. [0] http://stackoverflow.com/a/10986793/1072106 http://stackoverflow.com/a/10986793/1072106 [1] http://www.nczonline.net/blog/2012/03/13/its-time-to-start-using-javascript-strict-mode/ http://www.nczonline.net/blog/2012/03/13/its-time-to-start-u...
    - azakai 12y ago
      In practice there have definitely been perf losses from "use strict" (emscripten used to emit it until we noticed that). "use strict" sounds easier to optimize - it's stricter - but in practice, JS engines didn't get around to optimizing it, at least that was the case a few years ago. There have also been breakage issues. "use strict" changes semantics. Before all browsers implemented "use strict", some had it and some didn't, which meant scripts with "use strict" ran differently in different browsers.
      - reissbaker 12y ago
        I remember when it was generally suggested to avoid "use strict", because there wasn't great browser support. You could write "strict" code that would work at the time (due to browsers not actually enforcing strict mode), but in the future the same code might break in conformant releases of those browsers. That said, these days it's invaluable. Getting errors early saves time and prevents subtle bugs. It's become a widely accepted best practice, as noted by other posters. I definitely share your concerns about mode switches, but as long as there's a conformant implementation to test against, it seems like strong mode could move the language forward without too much of the "use strict" early adoption pain. Strict mode wasn't completely smooth sailing, but I think in the long run it helped.
    - rmrfrmrf 12y ago
      The biggest potential problem is using a file/global-scoped "use strict" directive in a .js file that gets concatenated and minified with other files that are not strict mode compliant, thus unintentionally modifying the behavior of any code that's concatenated after the strict mode script. This issue bit Amazon in the ass a while back and gave rise to JSHint checking for function-level strict mode declarations only and the general rule-of-thumb to not use strict mode in production code.
  - azakai 12y ago
    I agree that you shouldn't. But sometimes people will make the mistake and do it, if it doesn't cause a problem on their dev machines. Then it could break on the open web. Not changing JS semantics would avoid this. All the developer benefits are still possible without semantic changes.
  - lkbm 12y ago
    Won't keeping the pragma be a useful signal for the compiler to know it can use the more efficient language subset? Those that don't support it can just ignore the pragma and go with standard Javascript.
  - dgreensp 12y ago
    The point of "use strong" is to enable optimizations that wouldn't be possible otherwise, among other things. If you remove it in production, you won't get the optimizations. "use strict" is used in production all the time. Google and Facebook use it. The Babel transpiler (formerly 6to5) adds it to your code by default. It's one thing to get JS programmers to write their code in a certain way, but if the VM knows they are doing so, it's even more powerful.
    - azakai 12y ago
      I think there are 2 points - the one you said, to enable optimizations, and the other, to guide people to writing code that is easy to optimize. I guess the question is, how much better can you do, over easy-to-optimize code. Or in other words, once something is valid in Strong Mode, how much do extra Strong Mode optimizations get you. Such code should already be quite fast in current JS engines. The big, big difference is between the engine getting hard-to-optimize vs easy-to-optimize code. So I would bet that the bigger deal is the devtool aspect here. But, these are empirical questions.
  - pbreit 12y ago
    But isn't "use strict/strong" required to get some/many of the optimizations?
  - logicallee 12y ago
    isn't it like why you would remove asserts? the only thing an assert will do is fail (or do nothing) - why do you want to fail for users? (when you could not fail, or at least not on that line) - so they can see that you messed up? It's kind of like protocols: be strict in what you send out but lenient in what you accept. be strict in the javascript you write but then lenient when your users are actually running it.
    - svachalek 12y ago
      A failed assertion means the program no longer has any idea what's happening. If it continues past that point it can either get lucky or start to do lots of damage. Whether that's an acceptable risk depends a lot on what type of program it is.
    - Igglyboo 12y ago
      What if you're writing HFT software and an error causes you to spend millions of dollars on the wrong thing? If you had that assert in there then the program would have just crashed instead of bankrupting your company. Similar problems could easily arise in JS with e-commerce type applications, failing is sometimes a good thing.
  - philbo 12y ago
    This attitude really surprises me. I've been deploying 'use strict' code to live environments since 2012 and genuinely can't recall a single occasion where it has caused us a problem. We lint, unit-test and acceptance-test aggressively (including legacy browsers), and the strict directive itself is of course scoped to our own IIFE. Perhaps that explains why I've not witnessed the hurt you mention. The mechanics of strict mode are very clearly defined too, so I've not seen any cases were developer confusion caused unwanted side-effect (although I have heard straw-man arguments made where people predict it would). The benefits, on the other hand, are real and tangible. Errors that might otherwise be difficult to diagnose fail hard and obviously. Browsers are better able to optimise strict code than non-strict. And culturally, I suspect that a use-strict policy has forced everyone to be more clinical in their approach. Hand on heart, I would never go back to deploying non-strict code, so would be really interested to hear from anyone else in the opposite camp.
Firegarden 12y ago
Another +1 for TypeScript. Does anyone else see TypeScript as being a big player in the coming years?
- joshstrange 12y ago
  I've largely ignored it so far. I'm not a huge fan of writing in something like Coffeescript/TypeScript/etc because when the underlying JS changes (Like ES5->ES6) it can cause big breakage and/or confusion (Will CS classes work like classes do in ES6?). I am a fan of Babel (formally 6to5) because writing JS in the new standard format and transpiling to ES5 seems a lot cleaner and it's all still just JS. Also ES6 is a MUCH easier sell to other developers (who might not use JS as much but still need to interact with it) than moving to CS/TS IMHO.
  - findjashua 12y ago
    The breakage argument is valid for Coffeescript, but Typescript has always made it clear that it supports ES6. Am I missing something?
    - joshstrange 12y ago
      I apologise, I have read very little on TS due to me lumping it in with CS. If this is not the case then I would like to retract my statements on TS. It appears I need to read up more on TS. I was also put off by it due to when it was released there was very little IDE support and IMHO it was a little murky on how to use it (Also MS released it AFAIK and I'm a little skeptical of anything involving MS + Web, IE scars don't heal fast). I need to look into the tooling available for it now.
      - hammerandtongs 12y ago
        Works great in emacs.
    - aikah 12y ago
      TS doesn't support ES6 today. It doesn't support generators, it doesn't support ES6 modules , quasis ... For that you need to wait For Microsoft to implement those features.
scotty79 12y ago
What's the point of all this? If you need more rigid language to feel safe just write your programs in this language and then compile to javascript. Why extend javascript instead of treating it as VM for anything you like?
- stymaar 12y ago
  Great idea, the web need more help to fragment more efficilently. TypeScript, Flow and CoffeScript aren't enough. We need moar langages, so you can't find two web developers that use the same !
  - virmundi 12y ago
    Fragmentation at this level is even annoying. Heck, I might use ClojureScript in the near future. But there are two facts. 1) At the end of the day everything is literally just JavaScript. 2) If a person is working on X Transpiled Language (XTL) then they could work in JavaScript.
- krapp 12y ago
  Javascript isn't bytecode. It's a language that people do actually write and have to deal with on its own terms. Transpiling to javascript is a hack to make up for percieved deficiencies in the language itself - but as with any other language, javascript can still be improved upon and evolve. Requiring that anyone who wants to write javascript for the web do so through a Java or C compiler is actually the worst option.
- stupidcar 12y ago
  Because many legal constructs in javascript preclude various optimisations that could otherwise deliver near-native performance. Compiling a more rigid language to JS doesn't help with this, because the runtime and JIT compiler has no way to know what the original constraints were, so it has to remain open to the possibility that this is plain old JS and any of those weird and unoptimisable -- but legal! -- constructs may occur. Of course, you can write runtimes and JIT compilers with optimistic fast paths, that assume certain constraints apply and bail out to slower paths if they encounter something they can't handle. But this only gets you so far. It adds a lot of complexity to your implementation, and provides no clue to developers that they've violated a particular constraint and their code is running 10x slower than it could do. Furthermore, different runtime implementations from different vendors may have different heuristics and fast path behaviours. Having a standardised subset of the language, marked by a backwards compatible pseudo-pragma (like 'use strong') lets developers opt in to explicit constraints that enable greater optimisation. These constraints are common across different runtimes, properly documented, and are enforced by fail-early checking. The latter gives clear feedback to developers when they violate a constraint, and means the fast-path code can work without escape hatches, because the code it's running is guaranteed not to violate the constraints.
cpeterso 12y ago
So the V8 team doesn't want to add optimizations for the "use asm" subset of JS, but does want to add optimizations for the "use strong" subset of JS? I do see the difference: strong mode is an aid for web developers writing JS whereas asm.js is usually a compilation target for porting C++ code (and a competitor to Google's NaCl).
- treeform 12y ago
  In the article they they are doing both. People from chrome team said they are doing asm.js. "Q: How does SoundScript compare to asm.js? A: They have different goals: asm.js is a low-level language designed to be a compilation target for other (mostly low-level) languages. SoundScript is a user-facing type system for direct use of JavaScript as a high-level language. Both are complementary, both are useful, and V8 is committed to both."
- mythz 12y ago
  V8 is adding optimizations for asm: https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/ https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/ Asm.js isn't a solution for JavaScript developers, it provides an efficient compilation target for porting C/C++ code-bases to JS by leveraging Emscriptem or Mandreel compilers. But this doesn't benefit the 99+% of websites running normal JavaScript. Whereas the goal of StrongMode is to carve out a safer and faster "subset" of JavaScript that's less error prone and easier to optimize with more predictable performance. Only SoundScript is proposing adding (TypeScript-compatible) optional typing that's built into V8. ES6 is source compatible with TypeScript which can be transpiled to strip its type annotations so it runs in ES5 JS VMs. Essentially this is an evolutionary enhancement to JS.
  - josteink 12y ago
    > But this doesn't benefit the 99+% of websites running normal JavaScript. Whereas the goal of StrongMode is to carve out a safer and faster "subset" of JavaScript That still wont be used by 99%+ of the websites out there. At least not unless they want to forgo standards, or forgo strict-mode in all browsers but Chrome, and last but not least: they will have to update the code which is already there, and IE6 told us how that works in practice. Let's not help Google forge the internet a new MSIE with Chrome.
eldude 12y ago
This is dead on arrival: Some examples of strong mode changes we are aiming for are: accessing missing properties throws, arrays cannot have holes, all scoping errors are static, classes are immutable. Specifically, "accessing missing properties throws" will undermine how developers use the language. Options objects require this as a feature. Immutable classes might also be an issue as language extensibility / monkey patching is another feature, enabling a whole swath of Aspect Oriented Programming solutions like New Relic's monitoring or the node.js async trycatch library. I do wonder though, in fighting for its life against native, whether JavaScript will need to adopt optimizing solutions like "strong mode" to strengthen where it's weak. EDIT: It's really unfortunate that I'm getting down voted so severely (from +3 to -3 in <10m). HN increasingly discourages discussion and debate. I don't think there's any question that my comment adds to the conversation. At most, I could have added, "In my opinion..." to the beginning of my comment.
- masklinn 12y ago
  > Options objects require this as a feature. Object.assign(defaults, options) The defaults object has all the necessary properties, no missing property access is necessary.
  - eldude 12y ago
    I think this is part of the problem. Adopting "strong mode" will make lots of modern code obsolete. At least there are sane alternatives though, but it would also require setting empty properties on classes and undermine duck-typing. Yes, it's doable, but it fundamentally requires a non-dynamic approach to JavaScript programming, a highly dynamic language.
    - masklinn 12y ago
      Object.assign (or equivalent with libraires like jQuery or Underscore or what have you) is very much modern code. Hell, Object.assign is ES6.
      - 12y ago
donbronson 12y ago
This just shows that the current state of Javascript is a confusing mess. Where do new developers start now when they are been fed ES6 transpilers and ReactJS. I think Google (as usual) is getting ahead of this problem. But they shouldn't be alone in the fight for clarity.
- ndesaulniers 12y ago
  If having more options "leads to a confusing mess", I fail to see how having an additional option gets "ahead of this problem."
  - mtrpcic 12y ago
    Having a solution pushed forward by arguably the most influential implementation team is what pushes it forward, not the fact that it's "just another option". Regardless of what Chrome implements (whether it's this, or raw TypeScript, or CofeeScript), the fact that it works directly in V8 is what pushes that solution to the top of the stack.
    - ryanisinallofus 12y ago
      Ehem, Dart.
- Raphael 12y ago
  Perhaps new developers shouldn't transpile at all, or may use a single transpiler. It certainly could get confusing working with multiple transpilation layers.
- dietrichepp 12y ago
  > But they shouldn't be alone in the fight for clarity. They're starting with TypeScript which was Hejlsberg's project at Microsoft. Microsoft wants people to develop web apps for Microsoft server platforms, and you can use TypeScript with intellisense in Visual Studio. We'll see if Microsoft puts it in the browser but it seems like they already have a stake in the success, at least.
- 12y ago
swang 12y ago
I don't really like this, or at least how it sounds. 1. Google implements this 2. Chrome becomes the fastest browser by a wide margin 3. Other browsers die or become minor players 4. Google leverages this to enforce their own changes into the HTML/Javascript domain, "for the better" of the web and maybe even into mobile. 5. Web is broken unless you use Chrome The pain developers suffered before dealing with IE4-6 will be nothing to the repercussions we face now if we have to continue being backwards compatible with some version of Chrome because website X is "Chrome only" in the future. Hell it's already happened a bit with the new HTML5 features. Hell Korea is still paying for the mistakes of committing to go with IE. Feel like it ends up being Google's version of EEE. Also, keep in mind, this "SoundScript", even if its in the early stages, has not been declared as being open source, so it is closed source at the moment. This makes me feel that at best SoundScript will be open source like Android is open source. Release stuff but keep the latest version for Google to use.
- krapp 12y ago
  I've already encountered a number of sites which appear to only work in Chrome, so arguably that ship has already sailed.
- zodiakzz 12y ago
  Your comment is so unnecessarily cynical it made me giggle. You don't think like that in real life hopefully.
  - swang 12y ago
    If you were not on the web from ~1998-2004, and then had to dig out of the glut of crap that IE4 dumped behind it from 2005-Now, you probably think this is cynical. It's merely considering the historical record of what happens when you allow one company to control the web. Why do people want an open web? Because if you allow one entity to gain too much influence, you become locked into their whims rather than what is best for the web.
    - stupidcar 12y ago
1st1 12y ago
Overall the proposal looks good. BUT: please provide a way to construct classes dynamically (or allow functions to have [[construct]]).
- yoklov 12y ago
  They seem to mention this at the end of the slides.
rurban 12y ago
I'm only having a problem with default sealed classes on block level. With perl, which has similar characteristics we decided to seal classes only from the main application, with "use oo :final", and modules, libraries, implementations of classes do not seal their classes. Thus you can easily allow duck-typing in the calling application for testing, or go fast and disallow adding or changing methods and properties. So you cannot pre-compile modules per se, but js has no static block compiler anyway.
pugio 12y ago
This will be great for things like node-webkit or atom-shell (and node in general). There are many use cases where using an optimized subset is a big win, like atom.io or any cross-platform app with an embedded V8. Granted, it won't speed up DOM operations much, but JS is being used in so many non-browser places... it's good to know that the language performance isn't stuck against a wall.
hajile 12y ago
Pragmatically, how does subsetting matter? ES6 transpilation will be a requirement for many more years. Once you transpile, all the ES6 requirements blow up (eg. not extending prototypes). A more particular criticism. How does forcing let statements on everyone improve performance? All it does is force implicit (rather than explicit) scoping rules on JS developers because devs from other languages don't seem to be able to understand functional scoping or hoisting. It's a huge case of X language isn't like Y language that I already know, so let's change the unfamiliar language.
- stupidcar 12y ago
  Not really. It's a way to enable increased performance by disallowing certain hard-to-optimise constructs.
  - ryanisinallofus 12y ago
    Which ones specifically?
    - runeks 12y ago
      > [...] accessing missing properties throws, arrays cannot have holes, all scoping errors are static, classes are immutable.
- octatone2 12y ago
  I think it's important for the VM, which is what I got as to why they are proposing strong mode and sound types. I imagine that let and const afford optimizations to the VM.
  - hajile 12y ago
    The flag offers optimizations -- except they don't exist unless you compile a version of ES6 code for chrome only. Sure other ES6 browsers will ignore the string and move on, but they will have other ES6 compatibility issues. For example, Chrome's "fat arrow" doesn't do the lexical bind to the parent scope that the current spec requires. There are a ton of situations where this would break your code if you ran it on FF (and there are other differences). The only option is to transpile into ES5.1, but ES5.1 breaks the optimization requirements. Thus, using the optimization flag means building to Google's JS engine (we've been there with IE), while building a shared version means you cannot use the flag. Let adds scopes. Scopes are bad for performance (this is why closure compiler removes them). Removing them (if safe) is one more thing for the JIT to do. It's has little to do with efficiency and a lot to do with forcing another language's preferences on users.
rmrfrmrf 12y ago
JavaScript has been in the throes of an identity crisis since its inception, and IMO we're just now starting to get to a point where developers are leveraging its power and dynamism in its own right rather than trying to cram into a statically-typed, OOP box. To that effect, it seems like strong mode and SoundScript are a step in the wrong direction. I noticed the very deliberate and self-aware FAQ entry "Are you turning JavaScript into Java?" along with the canned denial, but that still doesn't change the fact that strong mode and SoundScript aim to remove dynamic typing and prototypes from a dynamically-typed prototypal language.
- Touche 12y ago
  That was a classic non-denial denial[1]. [1] http://en.wikipedia.org/wiki/Glomar_response http://en.wikipedia.org/wiki/Glomar_response
- dietrichepp 12y ago
  > we're just now starting to get to a point where developers are leveraging its power and dynamism in its own right It's damning that you say it took 20 years for us to "start" to leverage JavaScript's power. Compare to C#, which appeared 15 years ago, or Go which is from 2009, or Swift, which hasn't even celebrated its first birthday yet. Better comparisons might be Python and Ruby, which are both fully dynamic and have cool metaprogramming facilities like JavaScript does, but they'll both give you hard errors when you type the equivalent of [].lenght. And they give you proper stack traces and error messages, too: none of "undefined is not a function" which took until 2015 to get fixed in Chrome (try it). Working with Node.js will make you fall into despair when you realize that your program crashes, and it has stack traces, but none of the stack frames are in your code because everything has been threaded through callbacks. Python's major implementation has serious problems with concurrency (re: the GIL, global interpreter lock) and it too has dynamic types everywhere but it's still far easier to work with. What I want is to be able to refactor a JavaScript project without feeling like I'm crossing the river Styx. Where are the call sites for this function... who knows? TypeScript seems to at least give me some of those tools, it's a shame that the tooling isn't really ready--the compiler takes ages to run (timed it at 2.0 seconds on a small project... I might as well be using C++ at those speeds). And if Google has been using TypeScript as a basis, as they say, then you can keep using JavaScript the way you want and you don't even have to type anything in differently. Just let us add some type checking if we want it.
sandstrom 12y ago
Some of the suggestions seems reasonable, e.g. 'arrays cannot have holes', 'Length always in sync' and 'Sane Coercions'. It's also a good gesture that they'll try to work with others to standardize. SPDY -> http/2 is great example of this! I disagree with 'Accessing missing properties' and a few others. I don't want Javascript turned into Java. Also sounds a bit like a hammer looking for nails, i.e. they've already optimized everything, so to optimize more they'll need to rewrite the language. Again, I think some ideas are good, but may be slightly misdirected.
al2o3cr 12y ago
Clickbaitier headline: "You won't believe what new color of lipstick V8 engineers have found to put on this pig!"
crimsonalucard 12y ago
This is a bit of a tangent but sometimes I wish browsers would just open up some kind of standardized assembly language like interface to the vm and the dom. This would effectively make development for the browser virtually identical to the desktop; and also as a side effect, completely end this debate about "strengthening javascript."
- stupidcar 12y ago
  They already do. The standardised assembly language is called "javascript".
  - eatonphil 12y ago
    See http://asmjs.org/ http://asmjs.org/
  - crimsonalucard 12y ago
    Standardized? yes, assembly-like? No. Essentially I am saying expose a layer even closer to the metal in the browser so that these optimization problems can be moved to front end development.
    - BrendanEich 12y ago
      See past HN threads and posts that spawned them, e.g., this one: https://news.ycombinator.com/item?id=5707088 https://news.ycombinator.com/item?id=5707088 Apart from syntax wins, you can't get much lower-level semantically and keep both safety and linear-time verifiability. Java bytecode with unrestricted goto and type confusion at join points makes for O(n^4) verification complexity. asm.js type checking is linear. New and more concise syntax may come, but it's not a priority (gzip helps a lot), and doing it early makes two problem-kids to feed (JS as source language; new syntax for asm.js), which not only costs more but can make for divergence and can overconstrain either child. (This bit Java, pretty badly.) /be
ianbicking 12y ago
Looking at the referenced strawman: * Why is `delete` such a problem? * Closed objects (under "Dynamic Restrictions") seem like a really heavy change from current common JS usage. You basically can't use objects as a hash. This would break a ton of code. ES6 Weak Maps seem like an odd replacement. Especially because they are weak, that's semantically totally different than an object. * Not being able to add properties to Arrays I assume will cause quite a bit of problem, as that pattern is common. Or maybe subclassing Array will work fine? * Under Functions they seem to be disallowing traditional class definitions, so you can only use ES6 classes. So you can't write ES5 that is also StrongScript :( * Under Classes, it sounds like you can't call methods of this? I guess this is so you can't call methods on an object that is not entirely initialized. This will break a lot of code, or at least most classes I've written. I'd rather see all the possible instance attributes get pre-filled with undefined. * Both this proposal and ES6 seem to dislike non-method properties on prototypes. Why? * Disallowing `for in` is also annoying. I like the concept, but I'm not excited by the proposal.
mavdi 12y ago
This presentation makes me want to punch the next person I see https://drive.google.com/file/d/0B1v38H64XQBNT1p2XzFGWWhCR1k/view https://drive.google.com/file/d/0B1v38H64XQBNT1p2XzFGWWhCR1k... "let is the new var". No it's fucking not! "let" promotes procedural block scoped code. Moves people away from thinking properly about flow in their code. "var" has it's places, "let" can be a good addition is SOME circumstances. And calling code with "var" in it as insane, is itself insane.
- BrendanEich 12y ago
  What is "procedural block scoped code" and why do you think var as a binding construct (ignoring the initialiser) is control-flow sensitive? It's not. /be
  - mavdi 12y ago
    I mean people will widely use for, while, switch statements instead of maps, hashes, weak maps etc. They will be setting variables in parent scope, procedural step by step thinking, rather than passing functions, chaining things etc. I personally don't like some of the ES6 additions, but this one is just a step too far. For us mere mortals that is.
    - BrendanEich 12y ago
      let composes nicely with all the statement forms. You can even do `for (let x ...)` and have a proper let binding per iteration, for closures that capture x in the body. /be
      - mavdi 12y ago
        Yep and it's awesome to have that but I personally hardly ever use for loops.
- tree_of_item 12y ago
  I don't really understand what you're saying here. `let` is the way JavaScript should have worked from the beginning: a sensible implementation of lexical scope. How can you possibly make an argument for `var`? What is "procedural block scope"? Why does a proper implementation of lexical scope damage "thinking properly about flow"? I just don't get it.
shadowmint 12y ago
What what, a javascript subset that runs in existing browsers instead of a new language that you have to transpile into a 5MB binary chunk you drop in for negligible performance improvements? Mmm... yes please.
masswerk 12y ago
I'm especially concerned about the loss of "var". The web (as in HTML + JS) has always been about backward "interpretability" (meaning, a new feature won't break existing clients). The incompatibility of "var" and "strong mode" seems to be the most important break in this concept since JavaScript 1.1 and the introduction of the Array-constructor. (Some may remember the days, when we had to write two scripts, one for Netscape 2 and newer, and another one for older clients, each defining the same functions and producing comparable results. – Most of this was owed to features related to DOM-interaction. – Alas, the language-attribute ...) Realistically, not everyone will have a fully updated (or even fairly current) browser, and this really shouldn't be an issue which necessarily breaks things. "strong mode" will thus limit access to only those clients with at least some support of ES6 (as in "let"). Please add some basic support of "var"!
- masswerk 12y ago
  And while we're at it, why not add a backward compatible type declaration, like a string "use type a: int, s: string;" immediately following any declaration or declaration list?
- otikik 12y ago
  They are not removing var from the language - they are removing it from the "sane mode" only. If you don't write "use sane mode", you can still use var AFAIK.
DustinCalim 12y ago
Dear google, don't you have anything better to do?
Ciantic 12y ago
Conversion to TypeScript has been going inside Google for a year at least. Angular team started to do slides in TypeScript about year ago. What I do find annoying is the constant rebranding the teams in Google tries to do to TypeScript. Angular team called TypeScript + runtime typechecking a "AtScript". Now this document calls something of similar a "SoundScript". Can't the Google just admit it's using TypeScript? Adding a runtime checking doesn't change the fact it's just a TypeScript.
- sjrd 12y ago
  It is absolutely not TypeScript. SoundScript is supposed to have a sound type system (one that can be the basis for optimizations). TypeScript was designed with an unsound type system.
- sangnoir 12y ago
  > Can't the Google just admit it's using TypeScript? What makes you think they haven't "admitted" it yet? > AtScript is TypeScript: We’ve been collaborating with the TypeScript team on our proposed productivity [1] They have been collaborating with Microsoft, and it's no secret[2] 1. http://angularjs.blogspot.com/2015/03/announcements-from-ng-conf-were.html http://angularjs.blogspot.com/2015/03/announcements-from-ng-... 2. http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx http://blogs.msdn.com/b/typescript/archive/2015/03/05/angula...
  - Ciantic 12y ago
    It's good to know, it just didn't seem like that last year. I know that Hjelsberg went to meet Angular team after this lecture https://www.youtube.com/watch?v=b69vwMIphic&t=3928 https://www.youtube.com/watch?v=b69vwMIphic&t=3928 (QA position 1:05:30) As a little note about your references: 1. was posted 23 hours ago. 2. six days ago. I'm actually not checking their plans daily.
xiaoma 12y ago
Classes are not an improvement. See Crockford: https://www.youtube.com/watch?v=bo36MrBfTk4 https://www.youtube.com/watch?v=bo36MrBfTk4
- randomguy7788 12y ago
  it used to not be, but with the reversal of the `this` creation and addition and use of `target.new` in constructor functions we are now able to extend Exotic types like array.
  - BrendanEich 12y ago
    `new.target` ;-). /be
    - randomguy7788 12y ago
      Thanks for the correction :)
- BrendanEich 12y ago
  Out of date, as usual :-P.
otikik 12y ago
I like most of what I see in the sane mode. I would even go further and make "" and 0 truthy in that mode. I don't think I would use the type system. Maybe it should have its own proposal instead of being "bundled up" with sane mode. At least it is optional.
- BrendanEich 12y ago
  Making 0 and "" truthy is just asking for trouble, whatever your opinion of current JS semantics. The hope with sane mode (or whatever less able-ist name it should have) is to have no runtime semantic change if the mode directive is not recognized (as it won't be, if a quoted prologue directive aka useless string-literal expression-statement, in any downrev browser). Doubling the testing load, making hidden time bombs for older browsers to find blowing up in their faces at later dates: Not Good. Elsewhere here, both Alon Zakai I question the wisdom of using an erased "use sanity"; mode directive, given that runtime semantics will diverge for any code not in the new subset. The hope is that people will test fully with checks on, and find all code that doesn't follow the rules. I think TC39 will balk at this hope. Murphy was an optimist. /be
  - say2joe 12y ago
    I, for one, sincerely hope the semantics of truthy/falsy operations of which I've grown accustomed to these past 19 years don't change. I tend to appreciate these expressions in JS moreso on actual user input operations.
    - BrendanEich 12y ago
      The likely TC39 debate is between Dart-like Puritanism: no implicit conversion from primitive values or object references to Boolean values; vs. implicit conversion of primitives but not of object refs. I'm in the latter camp. Update: this does not say 0 == "" of course, separate issue. /be
  - otikik 12y ago
    Hi there, thanks for taking the time to comment. > The hope with sane mode (or whatever less able-ist name it should have) is to have no runtime semantic change if the mode directive is not recognized From my limited understanding, old browsers can't handle 'let' anyway, which is supposed to be used exclusively on this mode (as there will be no 'var'). But you probably know more about this than me. > making hidden time bombs for older browsers to find blowing up in their faces at later dates: Not Good. Doesn't that happen all the time? What I mean is: If ES6 becomes widely supported in browsers, pages written on it will make old browsers "blow up", too. Unless the people who program those make two versions, which defeats the point of using ES6 in the first place. The same when a new version of CSS comes out - use that, and the old browsers "blow up", too. It seems to me it is the nature of the beast - new features make old browsers blow up.
outside2344 12y ago
Why not just join the TypeScript project instead of subvert it with a fork?
dandare 12y ago
Can someone give me an example of TypeScript declaration that is not "sound"? I thought that "It guarantees that (1) an expression that has a static type T can never evaluate to a value that is not a T, and that (2) evaluation cannot run into unexpected runtime type errors." is already supported in TypeScript.
- lmm 12y ago
  Generics are bivariant in TypeScript and so unsound: class Base {} class Derived1 extends Base {} class Derived2 extends Base {} class Box<T> { constructor(public value: T) {} }; var a: Derived1 = new Derived1(); var b: Box<Base> = new Box<Base>(a); var c: Box<Derived2> = b; var d: Derived2 = c.value;
  - barrkel 12y ago
    TypeScript is structurally typed; there's nothing in your example that suggests that Derived1 and Derived2 have different types, instances of each are the same type.
    - lmm 12y ago
      Point, but add a differently-named field to each and it will still compile.
- xxgreg 12y ago
  My understanding is that gradually typed code, i.e. using "any", introduces unsoundness. var s : String = "bar"; var a : any = s; var i : int = a; Not sure, but I think Typescript's assignability rules, which use structural typing, also introduce unsoundness. class A { foo() { print('A'); } } class B { foo() { print('B'); } } var a : A = new A(); var b : B = a;
cdnsteve 12y ago
This is starting to sound like what Google is doing to JavaScript as Facebook has done to PHP. Customize to meet their own needs based on performance. This "testbed" could be good or bad, time will tell.

343 points by jashkenas 12y ago

> Any program running “correctly” in strong mode should run unchanged as ordinary JS. Thus, strong mode programs can be executed on all VMs that can handle ES6, even ones that don’t recognise the mode. This worries me. If it's running "correctly", then sure, it will run elsewhere. But if it hits something that Strong Mode considers "incorrect", then things diverge, and other browsers will execute something different. This can be avoided if Strong Mode just issues warnings, not errors. Which seems sufficient, if the goal is to inform people about stuff they should optimize. For those that want more rigorous checking, browsers could add a developer mode, in which those warnings become errors. This way, there is no risk of production code working differently on different browsers. We have seen "use strict" cause errors in production. Avoiding that with "use strong" seems like a safer path, with no significant downsides that I can see.

nickclaw 12y ago
You should never use "use strict" or "use strong" in production, they're very useful during development but can really only hurt you in production.
- joshstrange 12y ago
  Could you expand on how it could hurt you? All I was able to find was this [0] > I found two opinions about using strict mode in production: > > There is no reason to ship “use strict” in your production code. There is no performance gain (verified with V8 team and Brendan a while ago) and I don’t need my users’ VMs doing the extra checks as well. Keep it development only, strip it out during build. This way you also avoid the concatenation issue you reference. > And: > > There may not be a performance gain, but there’s also not a performance loss. In production, even more than in development, is where you want to be sure you’re noticing errors. Minimizing the changes between the development and production versions of the code is key to being able to debug issues quickly and efficiently. Yes it helps during development, but there’s no reason to pull it out of production code. > The source is in the comments at the bottom [1] > And of course those 12b weight of "use strict" won't change a thing. [0] http://stackoverflow.com/a/10986793/1072106 http://stackoverflow.com/a/10986793/1072106 [1] http://www.nczonline.net/blog/2012/03/13/its-time-to-start-using-javascript-strict-mode/ http://www.nczonline.net/blog/2012/03/13/its-time-to-start-u...
  - azakai 12y ago
    In practice there have definitely been perf losses from "use strict" (emscripten used to emit it until we noticed that). "use strict" sounds easier to optimize - it's stricter - but in practice, JS engines didn't get around to optimizing it, at least that was the case a few years ago. There have also been breakage issues. "use strict" changes semantics. Before all browsers implemented "use strict", some had it and some didn't, which meant scripts with "use strict" ran differently in different browsers.
    - reissbaker 12y ago
      I remember when it was generally suggested to avoid "use strict", because there wasn't great browser support. You could write "strict" code that would work at the time (due to browsers not actually enforcing strict mode), but in the future the same code might break in conformant releases of those browsers. That said, these days it's invaluable. Getting errors early saves time and prevents subtle bugs. It's become a widely accepted best practice, as noted by other posters. I definitely share your concerns about mode switches, but as long as there's a conformant implementation to test against, it seems like strong mode could move the language forward without too much of the "use strict" early adoption pain. Strict mode wasn't completely smooth sailing, but I think in the long run it helped.
  - rmrfrmrf 12y ago
    The biggest potential problem is using a file/global-scoped "use strict" directive in a .js file that gets concatenated and minified with other files that are not strict mode compliant, thus unintentionally modifying the behavior of any code that's concatenated after the strict mode script. This issue bit Amazon in the ass a while back and gave rise to JSHint checking for function-level strict mode declarations only and the general rule-of-thumb to not use strict mode in production code.
- azakai 12y ago
  I agree that you shouldn't. But sometimes people will make the mistake and do it, if it doesn't cause a problem on their dev machines. Then it could break on the open web. Not changing JS semantics would avoid this. All the developer benefits are still possible without semantic changes.
- lkbm 12y ago
  Won't keeping the pragma be a useful signal for the compiler to know it can use the more efficient language subset? Those that don't support it can just ignore the pragma and go with standard Javascript.
- dgreensp 12y ago
  The point of "use strong" is to enable optimizations that wouldn't be possible otherwise, among other things. If you remove it in production, you won't get the optimizations. "use strict" is used in production all the time. Google and Facebook use it. The Babel transpiler (formerly 6to5) adds it to your code by default. It's one thing to get JS programmers to write their code in a certain way, but if the VM knows they are doing so, it's even more powerful.
  - azakai 12y ago
    I think there are 2 points - the one you said, to enable optimizations, and the other, to guide people to writing code that is easy to optimize. I guess the question is, how much better can you do, over easy-to-optimize code. Or in other words, once something is valid in Strong Mode, how much do extra Strong Mode optimizations get you. Such code should already be quite fast in current JS engines. The big, big difference is between the engine getting hard-to-optimize vs easy-to-optimize code. So I would bet that the bigger deal is the devtool aspect here. But, these are empirical questions.
- pbreit 12y ago
  But isn't "use strict/strong" required to get some/many of the optimizations?
- logicallee 12y ago
  isn't it like why you would remove asserts? the only thing an assert will do is fail (or do nothing) - why do you want to fail for users? (when you could not fail, or at least not on that line) - so they can see that you messed up? It's kind of like protocols: be strict in what you send out but lenient in what you accept. be strict in the javascript you write but then lenient when your users are actually running it.
  - svachalek 12y ago
    A failed assertion means the program no longer has any idea what's happening. If it continues past that point it can either get lucky or start to do lots of damage. Whether that's an acceptable risk depends a lot on what type of program it is.
  - Igglyboo 12y ago
    What if you're writing HFT software and an error causes you to spend millions of dollars on the wrong thing? If you had that assert in there then the program would have just crashed instead of bankrupting your company. Similar problems could easily arise in JS with e-commerce type applications, failing is sometimes a good thing.
- philbo 12y ago
  This attitude really surprises me. I've been deploying 'use strict' code to live environments since 2012 and genuinely can't recall a single occasion where it has caused us a problem. We lint, unit-test and acceptance-test aggressively (including legacy browsers), and the strict directive itself is of course scoped to our own IIFE. Perhaps that explains why I've not witnessed the hurt you mention. The mechanics of strict mode are very clearly defined too, so I've not seen any cases were developer confusion caused unwanted side-effect (although I have heard straw-man arguments made where people predict it would). The benefits, on the other hand, are real and tangible. Errors that might otherwise be difficult to diagnose fail hard and obviously. Browsers are better able to optimise strict code than non-strict. And culturally, I suspect that a use-strict policy has forced everyone to be more clinical in their approach. Hand on heart, I would never go back to deploying non-strict code, so would be really interested to hear from anyone else in the opposite camp.

Firegarden 12y ago

Another +1 for TypeScript. Does anyone else see TypeScript as being a big player in the coming years?

joshstrange 12y ago
I've largely ignored it so far. I'm not a huge fan of writing in something like Coffeescript/TypeScript/etc because when the underlying JS changes (Like ES5->ES6) it can cause big breakage and/or confusion (Will CS classes work like classes do in ES6?). I am a fan of Babel (formally 6to5) because writing JS in the new standard format and transpiling to ES5 seems a lot cleaner and it's all still just JS. Also ES6 is a MUCH easier sell to other developers (who might not use JS as much but still need to interact with it) than moving to CS/TS IMHO.
- findjashua 12y ago
  The breakage argument is valid for Coffeescript, but Typescript has always made it clear that it supports ES6. Am I missing something?
  - joshstrange 12y ago
    I apologise, I have read very little on TS due to me lumping it in with CS. If this is not the case then I would like to retract my statements on TS. It appears I need to read up more on TS. I was also put off by it due to when it was released there was very little IDE support and IMHO it was a little murky on how to use it (Also MS released it AFAIK and I'm a little skeptical of anything involving MS + Web, IE scars don't heal fast). I need to look into the tooling available for it now.
    - hammerandtongs 12y ago
      Works great in emacs.
  - aikah 12y ago
    TS doesn't support ES6 today. It doesn't support generators, it doesn't support ES6 modules , quasis ... For that you need to wait For Microsoft to implement those features.

scotty79 12y ago

What's the point of all this? If you need more rigid language to feel safe just write your programs in this language and then compile to javascript. Why extend javascript instead of treating it as VM for anything you like?

stymaar 12y ago
Great idea, the web need more help to fragment more efficilently. TypeScript, Flow and CoffeScript aren't enough. We need moar langages, so you can't find two web developers that use the same !
- virmundi 12y ago
  Fragmentation at this level is even annoying. Heck, I might use ClojureScript in the near future. But there are two facts. 1) At the end of the day everything is literally just JavaScript. 2) If a person is working on X Transpiled Language (XTL) then they could work in JavaScript.
krapp 12y ago
Javascript isn't bytecode. It's a language that people do actually write and have to deal with on its own terms. Transpiling to javascript is a hack to make up for percieved deficiencies in the language itself - but as with any other language, javascript can still be improved upon and evolve. Requiring that anyone who wants to write javascript for the web do so through a Java or C compiler is actually the worst option.
stupidcar 12y ago
Because many legal constructs in javascript preclude various optimisations that could otherwise deliver near-native performance. Compiling a more rigid language to JS doesn't help with this, because the runtime and JIT compiler has no way to know what the original constraints were, so it has to remain open to the possibility that this is plain old JS and any of those weird and unoptimisable -- but legal! -- constructs may occur. Of course, you can write runtimes and JIT compilers with optimistic fast paths, that assume certain constraints apply and bail out to slower paths if they encounter something they can't handle. But this only gets you so far. It adds a lot of complexity to your implementation, and provides no clue to developers that they've violated a particular constraint and their code is running 10x slower than it could do. Furthermore, different runtime implementations from different vendors may have different heuristics and fast path behaviours. Having a standardised subset of the language, marked by a backwards compatible pseudo-pragma (like 'use strong') lets developers opt in to explicit constraints that enable greater optimisation. These constraints are common across different runtimes, properly documented, and are enforced by fail-early checking. The latter gives clear feedback to developers when they violate a constraint, and means the fast-path code can work without escape hatches, because the code it's running is guaranteed not to violate the constraints.

cpeterso 12y ago

So the V8 team doesn't want to add optimizations for the "use asm" subset of JS, but does want to add optimizations for the "use strong" subset of JS? I do see the difference: strong mode is an aid for web developers writing JS whereas asm.js is usually a compilation target for porting C++ code (and a competitor to Google's NaCl).

treeform 12y ago
In the article they they are doing both. People from chrome team said they are doing asm.js. "Q: How does SoundScript compare to asm.js? A: They have different goals: asm.js is a low-level language designed to be a compilation target for other (mostly low-level) languages. SoundScript is a user-facing type system for direct use of JavaScript as a high-level language. Both are complementary, both are useful, and V8 is committed to both."
mythz 12y ago
V8 is adding optimizations for asm: https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/ https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/ Asm.js isn't a solution for JavaScript developers, it provides an efficient compilation target for porting C/C++ code-bases to JS by leveraging Emscriptem or Mandreel compilers. But this doesn't benefit the 99+% of websites running normal JavaScript. Whereas the goal of StrongMode is to carve out a safer and faster "subset" of JavaScript that's less error prone and easier to optimize with more predictable performance. Only SoundScript is proposing adding (TypeScript-compatible) optional typing that's built into V8. ES6 is source compatible with TypeScript which can be transpiled to strip its type annotations so it runs in ES5 JS VMs. Essentially this is an evolutionary enhancement to JS.
- josteink 12y ago
  > But this doesn't benefit the 99+% of websites running normal JavaScript. Whereas the goal of StrongMode is to carve out a safer and faster "subset" of JavaScript That still wont be used by 99%+ of the websites out there. At least not unless they want to forgo standards, or forgo strict-mode in all browsers but Chrome, and last but not least: they will have to update the code which is already there, and IE6 told us how that works in practice. Let's not help Google forge the internet a new MSIE with Chrome.

eldude 12y ago

This is dead on arrival: Some examples of strong mode changes we are aiming for are: accessing missing properties throws, arrays cannot have holes, all scoping errors are static, classes are immutable. Specifically, "accessing missing properties throws" will undermine how developers use the language. Options objects require this as a feature. Immutable classes might also be an issue as language extensibility / monkey patching is another feature, enabling a whole swath of Aspect Oriented Programming solutions like New Relic's monitoring or the node.js async trycatch library. I do wonder though, in fighting for its life against native, whether JavaScript will need to adopt optimizing solutions like "strong mode" to strengthen where it's weak. EDIT: It's really unfortunate that I'm getting down voted so severely (from +3 to -3 in <10m). HN increasingly discourages discussion and debate. I don't think there's any question that my comment adds to the conversation. At most, I could have added, "In my opinion..." to the beginning of my comment.

masklinn 12y ago
> Options objects require this as a feature. Object.assign(defaults, options) The defaults object has all the necessary properties, no missing property access is necessary.
- eldude 12y ago
  I think this is part of the problem. Adopting "strong mode" will make lots of modern code obsolete. At least there are sane alternatives though, but it would also require setting empty properties on classes and undermine duck-typing. Yes, it's doable, but it fundamentally requires a non-dynamic approach to JavaScript programming, a highly dynamic language.
  - masklinn 12y ago
    Object.assign (or equivalent with libraires like jQuery or Underscore or what have you) is very much modern code. Hell, Object.assign is ES6.
    - 12y ago

donbronson 12y ago

This just shows that the current state of Javascript is a confusing mess. Where do new developers start now when they are been fed ES6 transpilers and ReactJS. I think Google (as usual) is getting ahead of this problem. But they shouldn't be alone in the fight for clarity.

ndesaulniers 12y ago
If having more options "leads to a confusing mess", I fail to see how having an additional option gets "ahead of this problem."
- mtrpcic 12y ago
  Having a solution pushed forward by arguably the most influential implementation team is what pushes it forward, not the fact that it's "just another option". Regardless of what Chrome implements (whether it's this, or raw TypeScript, or CofeeScript), the fact that it works directly in V8 is what pushes that solution to the top of the stack.
  - ryanisinallofus 12y ago
    Ehem, Dart.
Raphael 12y ago
Perhaps new developers shouldn't transpile at all, or may use a single transpiler. It certainly could get confusing working with multiple transpilation layers.
dietrichepp 12y ago
> But they shouldn't be alone in the fight for clarity. They're starting with TypeScript which was Hejlsberg's project at Microsoft. Microsoft wants people to develop web apps for Microsoft server platforms, and you can use TypeScript with intellisense in Visual Studio. We'll see if Microsoft puts it in the browser but it seems like they already have a stake in the success, at least.
12y ago

swang 12y ago

I don't really like this, or at least how it sounds. 1. Google implements this 2. Chrome becomes the fastest browser by a wide margin 3. Other browsers die or become minor players 4. Google leverages this to enforce their own changes into the HTML/Javascript domain, "for the better" of the web and maybe even into mobile. 5. Web is broken unless you use Chrome The pain developers suffered before dealing with IE4-6 will be nothing to the repercussions we face now if we have to continue being backwards compatible with some version of Chrome because website X is "Chrome only" in the future. Hell it's already happened a bit with the new HTML5 features. Hell Korea is still paying for the mistakes of committing to go with IE. Feel like it ends up being Google's version of EEE. Also, keep in mind, this "SoundScript", even if its in the early stages, has not been declared as being open source, so it is closed source at the moment. This makes me feel that at best SoundScript will be open source like Android is open source. Release stuff but keep the latest version for Google to use.

krapp 12y ago
I've already encountered a number of sites which appear to only work in Chrome, so arguably that ship has already sailed.
zodiakzz 12y ago
Your comment is so unnecessarily cynical it made me giggle. You don't think like that in real life hopefully.
- swang 12y ago
  If you were not on the web from ~1998-2004, and then had to dig out of the glut of crap that IE4 dumped behind it from 2005-Now, you probably think this is cynical. It's merely considering the historical record of what happens when you allow one company to control the web. Why do people want an open web? Because if you allow one entity to gain too much influence, you become locked into their whims rather than what is best for the web.
  - stupidcar 12y ago

1st1 12y ago

Overall the proposal looks good. BUT: please provide a way to construct classes dynamically (or allow functions to have [[construct]]).

yoklov 12y ago
They seem to mention this at the end of the slides.

rurban 12y ago

I'm only having a problem with default sealed classes on block level. With perl, which has similar characteristics we decided to seal classes only from the main application, with "use oo :final", and modules, libraries, implementations of classes do not seal their classes. Thus you can easily allow duck-typing in the calling application for testing, or go fast and disallow adding or changing methods and properties. So you cannot pre-compile modules per se, but js has no static block compiler anyway.

pugio 12y ago

This will be great for things like node-webkit or atom-shell (and node in general). There are many use cases where using an optimized subset is a big win, like atom.io or any cross-platform app with an embedded V8. Granted, it won't speed up DOM operations much, but JS is being used in so many non-browser places... it's good to know that the language performance isn't stuck against a wall.

hajile 12y ago

Pragmatically, how does subsetting matter? ES6 transpilation will be a requirement for many more years. Once you transpile, all the ES6 requirements blow up (eg. not extending prototypes). A more particular criticism. How does forcing let statements on everyone improve performance? All it does is force implicit (rather than explicit) scoping rules on JS developers because devs from other languages don't seem to be able to understand functional scoping or hoisting. It's a huge case of X language isn't like Y language that I already know, so let's change the unfamiliar language.

stupidcar 12y ago
Not really. It's a way to enable increased performance by disallowing certain hard-to-optimise constructs.
- ryanisinallofus 12y ago
  Which ones specifically?
  - runeks 12y ago
    > [...] accessing missing properties throws, arrays cannot have holes, all scoping errors are static, classes are immutable.
octatone2 12y ago
I think it's important for the VM, which is what I got as to why they are proposing strong mode and sound types. I imagine that let and const afford optimizations to the VM.
- hajile 12y ago
  The flag offers optimizations -- except they don't exist unless you compile a version of ES6 code for chrome only. Sure other ES6 browsers will ignore the string and move on, but they will have other ES6 compatibility issues. For example, Chrome's "fat arrow" doesn't do the lexical bind to the parent scope that the current spec requires. There are a ton of situations where this would break your code if you ran it on FF (and there are other differences). The only option is to transpile into ES5.1, but ES5.1 breaks the optimization requirements. Thus, using the optimization flag means building to Google's JS engine (we've been there with IE), while building a shared version means you cannot use the flag. Let adds scopes. Scopes are bad for performance (this is why closure compiler removes them). Removing them (if safe) is one more thing for the JIT to do. It's has little to do with efficiency and a lot to do with forcing another language's preferences on users.

rmrfrmrf 12y ago

JavaScript has been in the throes of an identity crisis since its inception, and IMO we're just now starting to get to a point where developers are leveraging its power and dynamism in its own right rather than trying to cram into a statically-typed, OOP box. To that effect, it seems like strong mode and SoundScript are a step in the wrong direction. I noticed the very deliberate and self-aware FAQ entry "Are you turning JavaScript into Java?" along with the canned denial, but that still doesn't change the fact that strong mode and SoundScript aim to remove dynamic typing and prototypes from a dynamically-typed prototypal language.

Touche 12y ago
That was a classic non-denial denial[1]. [1] http://en.wikipedia.org/wiki/Glomar_response http://en.wikipedia.org/wiki/Glomar_response
dietrichepp 12y ago
> we're just now starting to get to a point where developers are leveraging its power and dynamism in its own right It's damning that you say it took 20 years for us to "start" to leverage JavaScript's power. Compare to C#, which appeared 15 years ago, or Go which is from 2009, or Swift, which hasn't even celebrated its first birthday yet. Better comparisons might be Python and Ruby, which are both fully dynamic and have cool metaprogramming facilities like JavaScript does, but they'll both give you hard errors when you type the equivalent of [].lenght. And they give you proper stack traces and error messages, too: none of "undefined is not a function" which took until 2015 to get fixed in Chrome (try it). Working with Node.js will make you fall into despair when you realize that your program crashes, and it has stack traces, but none of the stack frames are in your code because everything has been threaded through callbacks. Python's major implementation has serious problems with concurrency (re: the GIL, global interpreter lock) and it too has dynamic types everywhere but it's still far easier to work with. What I want is to be able to refactor a JavaScript project without feeling like I'm crossing the river Styx. Where are the call sites for this function... who knows? TypeScript seems to at least give me some of those tools, it's a shame that the tooling isn't really ready--the compiler takes ages to run (timed it at 2.0 seconds on a small project... I might as well be using C++ at those speeds). And if Google has been using TypeScript as a basis, as they say, then you can keep using JavaScript the way you want and you don't even have to type anything in differently. Just let us add some type checking if we want it.

sandstrom 12y ago

Some of the suggestions seems reasonable, e.g. 'arrays cannot have holes', 'Length always in sync' and 'Sane Coercions'. It's also a good gesture that they'll try to work with others to standardize. SPDY -> http/2 is great example of this! I disagree with 'Accessing missing properties' and a few others. I don't want Javascript turned into Java. Also sounds a bit like a hammer looking for nails, i.e. they've already optimized everything, so to optimize more they'll need to rewrite the language. Again, I think some ideas are good, but may be slightly misdirected.

al2o3cr 12y ago

Clickbaitier headline: "You won't believe what new color of lipstick V8 engineers have found to put on this pig!"

crimsonalucard 12y ago

This is a bit of a tangent but sometimes I wish browsers would just open up some kind of standardized assembly language like interface to the vm and the dom. This would effectively make development for the browser virtually identical to the desktop; and also as a side effect, completely end this debate about "strengthening javascript."

stupidcar 12y ago
They already do. The standardised assembly language is called "javascript".
- eatonphil 12y ago
  See http://asmjs.org/ http://asmjs.org/
- crimsonalucard 12y ago
  Standardized? yes, assembly-like? No. Essentially I am saying expose a layer even closer to the metal in the browser so that these optimization problems can be moved to front end development.
  - BrendanEich 12y ago
    See past HN threads and posts that spawned them, e.g., this one: https://news.ycombinator.com/item?id=5707088 https://news.ycombinator.com/item?id=5707088 Apart from syntax wins, you can't get much lower-level semantically and keep both safety and linear-time verifiability. Java bytecode with unrestricted goto and type confusion at join points makes for O(n^4) verification complexity. asm.js type checking is linear. New and more concise syntax may come, but it's not a priority (gzip helps a lot), and doing it early makes two problem-kids to feed (JS as source language; new syntax for asm.js), which not only costs more but can make for divergence and can overconstrain either child. (This bit Java, pretty badly.) /be

ianbicking 12y ago

Looking at the referenced strawman: * Why is `delete` such a problem? * Closed objects (under "Dynamic Restrictions") seem like a really heavy change from current common JS usage. You basically can't use objects as a hash. This would break a ton of code. ES6 Weak Maps seem like an odd replacement. Especially because they are weak, that's semantically totally different than an object. * Not being able to add properties to Arrays I assume will cause quite a bit of problem, as that pattern is common. Or maybe subclassing Array will work fine? * Under Functions they seem to be disallowing traditional class definitions, so you can only use ES6 classes. So you can't write ES5 that is also StrongScript :( * Under Classes, it sounds like you can't call methods of this? I guess this is so you can't call methods on an object that is not entirely initialized. This will break a lot of code, or at least most classes I've written. I'd rather see all the possible instance attributes get pre-filled with undefined. * Both this proposal and ES6 seem to dislike non-method properties on prototypes. Why? * Disallowing `for in` is also annoying. I like the concept, but I'm not excited by the proposal.

mavdi 12y ago

This presentation makes me want to punch the next person I see https://drive.google.com/file/d/0B1v38H64XQBNT1p2XzFGWWhCR1k/view https://drive.google.com/file/d/0B1v38H64XQBNT1p2XzFGWWhCR1k... "let is the new var". No it's fucking not! "let" promotes procedural block scoped code. Moves people away from thinking properly about flow in their code. "var" has it's places, "let" can be a good addition is SOME circumstances. And calling code with "var" in it as insane, is itself insane.

BrendanEich 12y ago
What is "procedural block scoped code" and why do you think var as a binding construct (ignoring the initialiser) is control-flow sensitive? It's not. /be
- mavdi 12y ago
  I mean people will widely use for, while, switch statements instead of maps, hashes, weak maps etc. They will be setting variables in parent scope, procedural step by step thinking, rather than passing functions, chaining things etc. I personally don't like some of the ES6 additions, but this one is just a step too far. For us mere mortals that is.
  - BrendanEich 12y ago
    let composes nicely with all the statement forms. You can even do `for (let x ...)` and have a proper let binding per iteration, for closures that capture x in the body. /be
    - mavdi 12y ago
      Yep and it's awesome to have that but I personally hardly ever use for loops.
tree_of_item 12y ago
I don't really understand what you're saying here. `let` is the way JavaScript should have worked from the beginning: a sensible implementation of lexical scope. How can you possibly make an argument for `var`? What is "procedural block scope"? Why does a proper implementation of lexical scope damage "thinking properly about flow"? I just don't get it.

shadowmint 12y ago

What what, a javascript subset that runs in existing browsers instead of a new language that you have to transpile into a 5MB binary chunk you drop in for negligible performance improvements? Mmm... yes please.

masswerk 12y ago

I'm especially concerned about the loss of "var". The web (as in HTML + JS) has always been about backward "interpretability" (meaning, a new feature won't break existing clients). The incompatibility of "var" and "strong mode" seems to be the most important break in this concept since JavaScript 1.1 and the introduction of the Array-constructor. (Some may remember the days, when we had to write two scripts, one for Netscape 2 and newer, and another one for older clients, each defining the same functions and producing comparable results. – Most of this was owed to features related to DOM-interaction. – Alas, the language-attribute ...) Realistically, not everyone will have a fully updated (or even fairly current) browser, and this really shouldn't be an issue which necessarily breaks things. "strong mode" will thus limit access to only those clients with at least some support of ES6 (as in "let"). Please add some basic support of "var"!

masswerk 12y ago
And while we're at it, why not add a backward compatible type declaration, like a string "use type a: int, s: string;" immediately following any declaration or declaration list?
otikik 12y ago
They are not removing var from the language - they are removing it from the "sane mode" only. If you don't write "use sane mode", you can still use var AFAIK.

DustinCalim 12y ago

Dear google, don't you have anything better to do?

Ciantic 12y ago

Conversion to TypeScript has been going inside Google for a year at least. Angular team started to do slides in TypeScript about year ago. What I do find annoying is the constant rebranding the teams in Google tries to do to TypeScript. Angular team called TypeScript + runtime typechecking a "AtScript". Now this document calls something of similar a "SoundScript". Can't the Google just admit it's using TypeScript? Adding a runtime checking doesn't change the fact it's just a TypeScript.

sjrd 12y ago
It is absolutely not TypeScript. SoundScript is supposed to have a sound type system (one that can be the basis for optimizations). TypeScript was designed with an unsound type system.
sangnoir 12y ago
> Can't the Google just admit it's using TypeScript? What makes you think they haven't "admitted" it yet? > AtScript is TypeScript: We’ve been collaborating with the TypeScript team on our proposed productivity [1] They have been collaborating with Microsoft, and it's no secret[2] 1. http://angularjs.blogspot.com/2015/03/announcements-from-ng-conf-were.html http://angularjs.blogspot.com/2015/03/announcements-from-ng-... 2. http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx http://blogs.msdn.com/b/typescript/archive/2015/03/05/angula...
- Ciantic 12y ago
  It's good to know, it just didn't seem like that last year. I know that Hjelsberg went to meet Angular team after this lecture https://www.youtube.com/watch?v=b69vwMIphic&t=3928 https://www.youtube.com/watch?v=b69vwMIphic&t=3928 (QA position 1:05:30) As a little note about your references: 1. was posted 23 hours ago. 2. six days ago. I'm actually not checking their plans daily.

xiaoma 12y ago

Classes are not an improvement. See Crockford: https://www.youtube.com/watch?v=bo36MrBfTk4 https://www.youtube.com/watch?v=bo36MrBfTk4

randomguy7788 12y ago
it used to not be, but with the reversal of the `this` creation and addition and use of `target.new` in constructor functions we are now able to extend Exotic types like array.
- BrendanEich 12y ago
  `new.target` ;-). /be
  - randomguy7788 12y ago
    Thanks for the correction :)
BrendanEich 12y ago
Out of date, as usual :-P.

otikik 12y ago

I like most of what I see in the sane mode. I would even go further and make "" and 0 truthy in that mode. I don't think I would use the type system. Maybe it should have its own proposal instead of being "bundled up" with sane mode. At least it is optional.

BrendanEich 12y ago
Making 0 and "" truthy is just asking for trouble, whatever your opinion of current JS semantics. The hope with sane mode (or whatever less able-ist name it should have) is to have no runtime semantic change if the mode directive is not recognized (as it won't be, if a quoted prologue directive aka useless string-literal expression-statement, in any downrev browser). Doubling the testing load, making hidden time bombs for older browsers to find blowing up in their faces at later dates: Not Good. Elsewhere here, both Alon Zakai I question the wisdom of using an erased "use sanity"; mode directive, given that runtime semantics will diverge for any code not in the new subset. The hope is that people will test fully with checks on, and find all code that doesn't follow the rules. I think TC39 will balk at this hope. Murphy was an optimist. /be
- say2joe 12y ago
  I, for one, sincerely hope the semantics of truthy/falsy operations of which I've grown accustomed to these past 19 years don't change. I tend to appreciate these expressions in JS moreso on actual user input operations.
  - BrendanEich 12y ago
    The likely TC39 debate is between Dart-like Puritanism: no implicit conversion from primitive values or object references to Boolean values; vs. implicit conversion of primitives but not of object refs. I'm in the latter camp. Update: this does not say 0 == "" of course, separate issue. /be
- otikik 12y ago
  Hi there, thanks for taking the time to comment. > The hope with sane mode (or whatever less able-ist name it should have) is to have no runtime semantic change if the mode directive is not recognized From my limited understanding, old browsers can't handle 'let' anyway, which is supposed to be used exclusively on this mode (as there will be no 'var'). But you probably know more about this than me. > making hidden time bombs for older browsers to find blowing up in their faces at later dates: Not Good. Doesn't that happen all the time? What I mean is: If ES6 becomes widely supported in browsers, pages written on it will make old browsers "blow up", too. Unless the people who program those make two versions, which defeats the point of using ES6 in the first place. The same when a new version of CSS comes out - use that, and the old browsers "blow up", too. It seems to me it is the nature of the beast - new features make old browsers blow up.

outside2344 12y ago

Why not just join the TypeScript project instead of subvert it with a fork?

dandare 12y ago

Can someone give me an example of TypeScript declaration that is not "sound"? I thought that "It guarantees that (1) an expression that has a static type T can never evaluate to a value that is not a T, and that (2) evaluation cannot run into unexpected runtime type errors." is already supported in TypeScript.

lmm 12y ago
Generics are bivariant in TypeScript and so unsound: class Base {} class Derived1 extends Base {} class Derived2 extends Base {} class Box<T> { constructor(public value: T) {} }; var a: Derived1 = new Derived1(); var b: Box<Base> = new Box<Base>(a); var c: Box<Derived2> = b; var d: Derived2 = c.value;
- barrkel 12y ago
  TypeScript is structurally typed; there's nothing in your example that suggests that Derived1 and Derived2 have different types, instances of each are the same type.
  - lmm 12y ago
    Point, but add a differently-named field to each and it will still compile.
xxgreg 12y ago
My understanding is that gradually typed code, i.e. using "any", introduces unsoundness. var s : String = "bar"; var a : any = s; var i : int = a; Not sure, but I think Typescript's assignability rules, which use structural typing, also introduce unsoundness. class A { foo() { print('A'); } } class B { foo() { print('B'); } } var a : A = new A(); var b : B = a;

cdnsteve 12y ago

This is starting to sound like what Google is doing to JavaScript as Facebook has done to PHP. Customize to meet their own needs based on performance. This "testbed" could be good or bad, time will tell.