

A Strong Mode for JavaScript - ingve
https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp49nDQMZ1y7fwf5YjaI4/view

======
dustin1114
I think I like most of what this document proposes _except_ for the following:

    
    
      In strong code, accessing objects (strong or not) throws on missing properties.
      New object properties have to be defined explicitly and cannot be removed
      from strong objects.
    

To me, this seems to break a fundamental aspect of the language. I've found it
very acceptable to be able to define an object literal property "on the fly."
However, with strong mode trying to make the language friendlier to eventually
being more statically typed, I see the necessity. It just boggles my
dynamically typed mind :-)

~~~
comex
That's funny; I think that's the _only_ part of what the document proposes I
like. -- Well, okay, that's not really true; there are a lot of bits that just
make sense, either because they hurt performance for little benefit (holes in
arrays) or they're just dumb (arguments.caller). But I don't like gratuitously
locking things down in a way that makes highly dynamically-typed code harder
to write, where it doesn't seem to solve a real unavoidable performance
problem: for example, the ban on constructors leaking 'this', and the oddly
specific recursion limitations. In general, the document seems to express the
sentiment that only statically typed code matters, which I think is short-
sighted. I also dislike, among other performance-unrelated changes, the "let's
fix C" syntax bits, such as banning fallthrough, which is just likely to annoy
programmers familiar with C (who are used to writing code that relies on it on
occasion).

However, making nonexistent property accesses silently return undefined is
just an amazing way to ensure typos in property names never get caught. I
don't think `foo.bar || baz` is much to sacrifice - Python, for example, has
getattr(foo, 'bar', baz), which works fine, and has the benefit of returning
foo.bar if it exists at all, not just if it's a truthy value.

~~~
stormbrew
My experience is that the python way results in long and obfuscating chains of
access checks. It's a fine idea to not make it the default behaviour, but
there should be a way to do a chained check a-la coffeescript's '?.' to ease
deep accesses, especially since in js objects are commonly used for data
structures.

------
leichtgewicht
First: this document should be on github. How do I do a PR on a google doc?

My biggest problem with this proposal is that it will force a full-blown code-
style on you. Many, perhaps most, of the features will be part of the common
consent how to write good apps but I am sure lots of people have a problem
with feature x or y. I wonder if a "selecting a subset" would be practicable.

~~~
acjohnson55
_My biggest problem with this proposal is that it will force a full-blown
code-style on you._

Yes, just like _" use strict"_ did, and thank goodness! The fact of the matter
is that Javascript wasn't a carefully designed language from top to bottom and
we're still working to fix some of its pitfalls. It's not that some of the
ill-posed features don't have valid uses; they do. But we know a lot about the
best practices, and with ES6, there are objectively safer alternatives to old
patterns.

This isn't just for today's experienced JS dev. Javascript is here to stay,
and there's _no reason_ the person learning it today should have to know all
the language quirks I had to work around. _" use strong"_ will lead to more
performant and more resilient JS coding practices, period. Let's stop
fetishizing the missteps of the original language.

------
sidekick
As someone who is saddened to see the relatively low acceptance of Dart, I
hope to more efforts like Strong mode take off.

More and more mission critical software is being written in javascript,
affecting the livelihood of ordinary people. I think there is a significant
audience that can benefit from a less dynamic, more static javascript.

------
noiv
I don't get this approach, it's backwards. Why can't the JIT assume everything
is perfect and spit out information like: Warning: Can't optimize function foo
in bar.js because of foobar? Instead devs have to tell the JIT what to assume
and wait for errors.

What I'm missing here?

~~~
colinramsay
This would make more sense to me, if not only because it seems like a great
way to avoid the most complained-about parts of JavaScript, like weird type
coercion.

------
thomasfoster96

        It is a SyntaxError to use the identifier ‘eval’.
    

SyntaxError? "use strong"; should probably do something like: let eval = void
0; rather than making eval a SyntaxError.

~~~
pavpanchekha
Making it a syntax error means code will not fail quietly. This should help
transition code to Strong mode.

~~~
thomasfoster96
Wouldn't a `ReferenceError` make more sense?

------
msoad
> It is a SyntaxError to use the keyword 'var'

What if I want a variable?!

~~~
jongleberry
use `let ` or `const `. there's no need to use `var` in ES6+, ever.

~~~
bluesnowmonkey
But we're going to keep it around, aren't we? Because we can always add
features but we can't really remove them. It feels like JS is getting
cruftier. Would it be better if var already worked like let? Sure. Will JS be
better with two slightly different ways of scoping a variable, one of which
you really shouldn't use? Doesn't seem like it. One more thing to explain to
newcomers.

~~~
reissbaker
So, you're right that nothing can be removed. But you can add new things, and
via mode switches (e.g. "use strict", which enables strict mode currently, or
"use strong", which is planned to enable strong mode) _essentially_ remove old
ones by disallowing them in the latest "mode." Old code will continue to run,
but as long as you opt-in to the new way of doing things for your new code you
can enforce not using the legacy constructs in the new code.

It's important to note that the modes are on a per-function basis, so opting
into the new mode doesn't break existing libraries, etc even if you call those
libraries from a newer mode.

It's also worth mentioning that _strong mode doesn 't introduce anything new._
All that strong mode does is remove features. `let` and `var` both already
exist; in strong mode, only `let` does.

------
Corporate_Shill
Still trying to sell Javascript? I guess it's getting harder to find cheap
engineers willing to put up with it.

~~~
CmonDev
Yes, I see so many JS-only front-end job posts these days - nobody wants to
touch that crap even with a stick: "let's hire a guy who will only do JS,
close him in a separate room, and forget about this scripty language like the
horror dream it is".

