
Strengthening JavaScript - jashkenas
https://developers.google.com/v8/experiments
======
eldude
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.

~~~
BinaryIdiot
> Specifically, "accessing missing properties throws" will undermine how
> developers use the language.

I couldn't agree more; there are many times I access a property that may or
may not exist and I plan on using the undefined that comes with it not
existing. Requiring it to exist is trying to turn JavaScript into a more
strict language without all of the language features to do so very easily.

~~~
nawitus
I wonder if "SoundScript" will support optional properties. TypeScript also
considers accessing missing properties a compile-time error, and I haven't
noticed many problems with that as you can define some properties as optional.

~~~
jahewson
That would work at "compile" time, but how do we know whether or not a
property is missing at runtime without accessing it? Or resorting to an
expensive and minifier-hostile call such as hasOwnProperty? The TypeScript
approach won't work here.

Guaranteeing that optional properties have a default value would be one
solution, another would be to use ES6 default parameters instead of options
objects. But there has to be some sort of value to use at runtime if missing
property access always throws.

------
rmrfrmrf
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.

~~~
dietrichepp
> 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.

~~~
BrendanEich
Before TypeScript (fall 2012), Zef Hemel then at c9.io did static analysis for
JS IDE diagnostics (mid-2012?), Dmitry Vardoulakis then grad-student-interning
at Mozilla Research did DoctorJS (spring 2010, I think). And don't forget the
Closure compiler from Google, but I'm not sure when that really got serious
about static analysis -- perhaps after Google hired Dmitry. So no more than 15
years, not 20. ;-)

What's damning is the stagnation under the IE (convicted in the US) monopoly
from late '90s through 2009 when ES5 was published. It's not as if Python 1.3
or whatever, if frozen in Netscape 2 amber, would have fared better if forked.

~~~
lmm
> It's not as if Python 1.3 or whatever, if frozen in Netscape 2 amber, would
> have fared better if forked.

Disagree. Python 1.3 was at least designed as a general-purpose programming
language, with a variety of use cases, and took the best parts of existing
languages (TCL and Perl) rather than having novel features that sorta-but-not-
quite replace more conventional ones. It had its share of warts but nothing in
Python 1.3 is as awkward as prototypal inheritance or javascript's scoping.

IMO the biggest tragedy is Mozilla's unwillingness to put other languages in
the browser. Dart was developed in public, far more of an open standard than
the original JS, fixed language design problems that ES6 still isn't
addressing, had an adequate approach to running in JS-only browsers, and would
have added much less complexity to browser implementation (the reason given
for rejection) than many standards that Mozilla has been happy to support.

~~~
amyjess
> IMO the biggest tragedy is Mozilla's unwillingness to put other languages in
> the browser. Dart was developed in public, far more of an open standard than
> the original JS, fixed language design problems that ES6 still isn't
> addressing, had an adequate approach to running in JS-only browsers, and
> would have added much less complexity to browser implementation (the reason
> given for rejection) than many standards that Mozilla has been happy to
> support.

It's also Google's failure to exploit their market position. Instead of using
Dartium, they should've just integrated the Dart VM into mainline Chrome and
began paying web developers to use Dart. Mozilla would then have no choice but
to implement Dart or find their users complaining about not being able to
access their favorite websites.

On a similar note, it's kind of a shame that IE's support for VBScript never
took off. Not because VBScript was a good language, but because it would've
laid down a precedent for the web being a multi-language environment. Browser
vendors would have developed pluggable scripting architectures to compete.
Imagine if, say, every browser on Windows could have allow scripts written in,
for example, everything offered by Windows Script Host (and I'm sure some
equivalent architecture would have been developed for Mac and Linux -- maybe
even something as simple as "any script that can be interpreted via a shebang
line").

~~~
BrendanEich
See my reply just above. You ignore high costs of multiple engines, both
intrinsic and inter-engine -- including, notably, a memory cycle collector of
some sort, with its attendant write barrier costs. See Fil Pizlo on webkit-dev
the other year:

[https://lists.webkit.org/pipermail/webkit-
dev/2011-December/...](https://lists.webkit.org/pipermail/webkit-
dev/2011-December/018811.html)

As for your lamenting the lack of Machiavellian market power abuse by Google,
it really is not clear that even Google can force Dart down others' throats,
or its own throat. Rewriting JS code in Dart is a net lose, as far as I can
tell. No Google property yet uses Dart, even with dart2js (I welcome
correction).

Ignoring the morality of such market-power shenanigans (hey, I was at
Netscape, but I've paid my dues, and someone had to be "first" :-P), it is
also not clear "Mozilla would then have no choice". Money AKA energy is not
free; Mozilla can least afford follies; there is always an option to reject a
neo-standard.

Microsoft could not make VBScript stick in the '90s. I say this is signal, yet
again. Multiple and mandatory HTML scripting languages exact high direct and
indirect costs. Lack of such an outcome is not a conspiracy or tragedy. It's
economics and evolution in action.

Update: WSH, shebangs, wow. You forgot about security!

~~~
BrendanEich
An example of a power-play and widely deployed de-facto standard that we
resisted at Mozilla, wisely: ActiveX plugins. Independent companies emulated
some of the ActiveX COM APIs, plus basic MS COM, on Unixen, in the '90s and
into the noughties. Lack of spec and open source were not a barrier, and MS
documented well.

Was MS abusing market power? The US v. Microsoft case said they were. They
definitely caused plugin vendors to support ActiveX _en masse_. And they then
dropped the old Netscape Plugin API, which led many such vendors to drop NPAPI
too, leaving those plugins IE-only.

Yet we at Mozilla resisted ActiveX, successfully. We did not just hold the
line, we restarted NPAPI incremental evolution via the plugin-
futures@mozilla.org list I created, and meetings jst@mozilla.org and I
convened with Apple, Opera, Real Networks, Dolby, and Macromedia.

Even a convicted monopolist couldn't ram ActiveX down other browser vendors'
throats, when it could and did do so to plugin vendors and some web
developers. Google with Chrome is not yet near MS IE's monopoly share. So
again, I think you should be more skeptical of your own assertions and
assumptions about "no choice".

~~~
bootload
_" An example of a power-play and widely deployed de-facto standard that we
resisted at Mozilla, wisely: ActiveX plugins. Independent companies emulated
some of the ActiveX COM APIs, plus basic MS COM, on Unixen, in the '90s"_

Thanks for doing this Brendan.

I was at a young startup at the time and an MS dev team gave us access to the
IE Trident preview with ActiveX [0] and you could tell it was a pile of
_horse_ , without even implementing it.

    
    
       '*you what?* create a plug-in, only works on IE, 
        then everyone has to download it?'
    

Totally against the grain of how the web worked and still works.

[0] IE4 layout engine:
[https://duckduckgo.com/l/?kh=-1&uddg=https%3A%2F%2Fen.wikipe...](https://duckduckgo.com/l/?kh=-1&uddg=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTrident_\(layout_engine\))

------
sandstrom
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.

------
azakai
> 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
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
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-u...](http://www.nczonline.net/blog/2012/03/13/its-time-to-start-using-
javascript-strict-mode/)

~~~
azakai
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
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.

------
hajile
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
Not really. It's a way to enable increased performance by disallowing certain
hard-to-optimise constructs.

~~~
ryanisinallofus
Which ones specifically?

~~~
runeks
> [...] accessing missing properties throws, arrays cannot have holes, all
> scoping errors are static, classes are immutable.

------
Ciantic
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.

~~~
sangnoir
> 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-...](http://angularjs.blogspot.com/2015/03/announcements-from-ng-conf-
were.html)

2\.
[http://blogs.msdn.com/b/typescript/archive/2015/03/05/angula...](http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-
on-typescript.aspx)

~~~
Ciantic
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.

------
swang
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.

~~~
shurcooL
Differences between IE and Chrome:

\- IE has fixed versions, IE 6, 7, 8, 9, 10, 11; Chrome autoupdates so there's
only Chrome stable, Chrome beta, Chrome dev and Chrome canary.

No need to hardcode IE6-specific hacks.

\- IE is closed source; Chrome is more open source.

~~~
cozuya
IE autoupdates since IE10, which is frankly a huge event for our industry that
very rarely gets recognized.

~~~
grumblestumble
Except for the fact that it still moves at a glacial pace compared to the
competition. Incremental IE10 updates do not include new CSS or Javascript
functionality, that's limited to version releases - which is measured in
years. Compare that to Chrome or Firefox, where new functionality lands every
couple of weeks in stable.

~~~
cozuya
IE10, if left alone, will auto update to IE11 silently.

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

~~~
joshstrange
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
The breakage argument is valid for Coffeescript, but Typescript has always
made it clear that it supports ES6. Am I missing something?

~~~
aikah
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.

~~~
findjashua
the website says it supports modules. Quasi literals also seem to be
supported.

~~~
aikah
That's untrue read the spec. Typescript doesn't support ES6 modules , nor
quasi literals. Typescript has its own module system which is incompatible
with ES6 modules.

~~~
findjashua
Fair enough. I haven't read the spec, just went to their website, and one of
the first things they mention is modules and classes. Also, when I googled
'typescript template string' the first hit was
[https://github.com/Microsoft/TypeScript/issues/13](https://github.com/Microsoft/TypeScript/issues/13),
so I assumed they were supported.

------
rurban
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.

------
cpeterso
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).

~~~
mythz
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
> 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.

------
donbronson
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
If having more options "leads to a confusing mess", I fail to see how having
an additional option gets "ahead of this problem."

~~~
mtrpcic
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
Ehem, Dart.

------
ianbicking
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.

------
pugio
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.

------
masswerk
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
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?

------
crimsonalucard
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
They already do. The standardised assembly language is called "javascript".

~~~
crimsonalucard
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
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

------
scotty79
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?

~~~
stupidcar
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.

~~~
scotty79
You can compile to asm.js if you care about performance that much.

------
shadowmint
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.

------
xiaoma
Classes are not an improvement. See Crockford:
[https://www.youtube.com/watch?v=bo36MrBfTk4](https://www.youtube.com/watch?v=bo36MrBfTk4)

~~~
randomguy7788
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
`new.target` ;-).

/be

~~~
randomguy7788
Thanks for the correction :)

------
1st1
Overall the proposal looks good.

BUT: please provide a way to construct _classes_ dynamically (or allow
functions to have [[construct]]).

~~~
yoklov
They seem to mention this at the end of the slides.

------
dandare
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
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
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
Point, but add a differently-named field to each and it will still compile.

------
otikik
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
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

~~~
otikik
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.

~~~
BrendanEich
It turns out `let` is usable in most browsers today, and in some older ones.
The point is there's no extra opt in and no forked runtime semantics.

> Doesn't that happen all the time?

You're talking about new syntax bombing old browsers. That's not the issue.
The issue is same syntax in old and new, works (for whatever value of "works")
in old and new, but differs in meaning due to a "use sanity"; directive.

~~~
otikik
Fair enough. You have probably heard arguments similar to mine hundreds of
times, thanks again for answering.

For what is worth, I never depend on the truthyness of falsyness of 0 and "",
and always test for them explicitly, so it will not affect my code if in a
distant future javascript starts treating them as truthy. Just, you know, in
case you change your mind in the future.

Good night!

------
cdnsteve
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.

------
mavdi
This presentation makes me want to punch the next person I see
[https://drive.google.com/file/d/0B1v38H64XQBNT1p2XzFGWWhCR1k...](https://drive.google.com/file/d/0B1v38H64XQBNT1p2XzFGWWhCR1k/view)

"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
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
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
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
Yep and it's awesome to have that but I personally hardly ever use for loops.

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

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

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

