Proposal: Optional Static Typing (Part 3)

Isiah Meadows isiahmeadows at
Sat Jan 13 08:20:06 UTC 2018

Inline. Also, in summary, types just get in your way at times, but in
others, it's the best thing you could ever have.


Isiah Meadows
me at

Looking for web consulting? Or a new website?
Send me an email and we can get started.

On Sat, Jan 13, 2018 at 1:59 AM, kai zhu <kaizhu256 at> wrote:
> rant warning
>> The demand for types as a different approach to code has been so strong in the past few years that separate languages have been created to deal with the perceived shortcomings.
> where is this demand coming from? newcomers from c# / java
> who don't know anything about how javascript is used to ship
> end-user-features and web-products? or those who do and accept the
> reality that there's always lots of ugly corner-cutting involved with
> javascript to push a product out the door?

Generally, the latter. C#/Java people tend to want static types, then
they wind up [writing unidiomatic TypeScript][1], wondering why it
won't work even there. But most users who are actually active in
wanting types tend to come from the JS community (there's a reason TS
and Flow are both incredibly expressive - they have to be to address
the average JS developer's needs).


> static-typing, like classes, makes frontend developers' lives harder;
> it introduce non-essential, rigid structures, making it difficult to
> cut the necessary corners (and the inevitable ugly-hacks needed)
> during integration to ship a web-product.

Yeah, if your project happens to be less than about 30K lines of code.
I've got a personal pet project that's just above that, and I'm
already feeling the pains of the lack of type checking (I'm doing type
and value assertions all over the place). However, a 10K line of code
project with reasonable consistency within would fare better, since
it's much easier to keep in your head.

Also, cutting corners and dropping ugly hacks is possible in both
TypeScript and Flow, as they both have an `any` type which effectively
disables type checking. It's useful for unsafe casts that you know are
correct. Oh, and TS is technically a superset of JS, so `any` is the
default, absent any other type declarations.

As for classes, I'll agree they're overused, but there are times when
they're useful - they make for great DSLs and easier-to-use APIs, and
there are rare occasions where you actually need inheritance (they
make certain forms of extensibility easier, and they take less memory
than copying).

> its usually easier for javascript-programmers to ship products if the
> code and async-logic they have to rewrite during integration and qa
> were mostly throwaway static-functions (with the assumption they WILL
> be rewritten during integration). versus classes with static-typing
> (that are more difficult to rewrite at the late-stage in
> web-development when it matters the most and have a higher tech-debt
> penalty).

Actually, it's the other way around: static typing has a higher
up-front cost, because it's much more rigid to start. It's harder to
write the initial prototype when you're [simultaneously verifying
it][2], but it's easier to make late-stage changes without introducing
new bugs\*. Trust me: I have first-hand experience with both

\* Unless, of course, you have a very annoying
client/customer/manager/etc. who decided to ask for you to change half
of the project entirely for whatever reason, in which it's a people
problem, not a technical problem.


> maybe its different @ the large companies / orgs tc39 represents who
> can hire better-than-average programmers that can magically ship
> products with correct javascript code right-off-the-bat. but not so
> for most of the web-industry that can only afford mediocre
> javascript-programmers whose code-designs and architectures rarely
> survive integration / productization intact.

Note that in no place did *anyone* request that static types be
mandatory, and most of us had responded to suggest *reducing* the
scope of the proposal, not broaden it. Also, your premise of "can
magically ship ... with correct JS code right off the bat" is a straw
man based on the opposite of what static types are for. The whole
point of static types (and type checking in general) is founded on the
assumption you can't trust people to not make mistakes. If you can use
a program to help check those mistakes for you and alert you of them,
you're more likely to correct those mistakes before sending them to

> On Jan 12, 2018 12:19, "Brandon Andrews" <warcraftthreeft at> wrote:
>> > I'm still yet to read the entire proposal, but with a quick skim, it seems to me like this is essentially what Typescript or Flow offers you: i.e. an opt-in type system?
>> This is in the core of ECMAScript, so the types would be real. The implementers would be encouraged to use native hardware types. But yes, outside of that it is an opt-in type system. Language built on top of it would then benefit from this. I often wonder if languages built on top of ES6 haven't limited themselves because types don't exist. That is they'd do more, but didn't because the complexity of transpiling. Stuff like this: Imagine if ECMAScript already had all those types and support function overloading. TypeScript could move on and implement more experimental ideas.
>> > I'm wondering if you have any good reasons to want there to be a standardised static type annotation syntax within ECMAScript instead of a "Bring Your Own Type Checker" system. If you do have some thoughts on this, you might also want to include that as a preface on your Github's README.You have a "Rationale" bit that seems to ignore the existence of these existing systems.
>> Did you read the rationale? It specifically says:
>> > The demand for types as a different approach to code has been so strong in the past few years that separate languages have been created to deal with the perceived shortcomings.
>> More of the rationale was below the types proposed. I've moved it up into the rationale since it fits better there. If there's more you think should be added I'll include it. I'm trying to keep things concise since it's a long proposal. I could go into an explanation that TypeScript and other languages are generally just a superset of Javascript and benefit from bringing their features closer to the base language and possibly the hardware? It seems too obvious to me to write something like that.
>> > From a quick read, I'm more in favor of something that's a little more restricted to start, something like what Python has. Python has optional static type annotations, but the Python interpreter just ignores them. They are present purely for the purposes of tooling, and are silently ignored at runtime.
>> The goal with this proposal is to get essentially native hardware types where applicable. All the proposed types have special operator rules, value ranges (overflow behavior), and in the case of SIMD very real performance impact behind them. While documentation hints are a side-effect, I'm more focused instead for pushing ECMAScript toward being a more powerful language. Python is a classic example of where data type shortcomings lead to unintuitiveness or weird design like: I'm trying to avoid such things.
>> > One of the reasons why I'd prefer a simpler approach to start is that TypeScript and Flow, the two main implementations that add syntax, have a *very* similar syntax, but have several nuances that would make a heavier proposal much harder to accomplish:
>> > - Flow has `?Foo` for optional types, TypeScript just uses unions.
>> I have a section on unions with a small explanation on why I left it out. I kept it simple by only adding nullable types. Right now someone would overload or use 'any'.
>> > - TypeScript has mapped/index types, where Flow uses special named types.
>> I didn't include these.
>> > - Flow allows omitted parameter names in function types, TypeScript only allows named parameters with implicit `any` types.
>> I created an issue to be more explicit about optional and default typed parameters and the behavior.
>> > - Flow has exact types, TypeScript doesn't.
>> I hadn't even considered something like this. It sounds interesting for configuration options. They introduce new tokens. Something I'm very much avoiding for this initial proposal.
>> > - Flow has `opaque type`, TypeScript only has `type`.
>> Something to be decided later. Doesn't create breaking changes to add later.
>> > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.
>> There's a section on generics and why it isn't included already. I'm with you that it's far too complex to add in with initial types. There's no breaking changes introduced by adding it later. (Mostly because it introduces new tokens which would be a huge deal).
>> > - Flow has existential types, TypeScript doesn't.
>> I definitely haven't included this. Flow is a few steps ahead of this proposal.
>> It seems like a lot of these features already aren't included in the proposal. I definitely hold your view that the proposal has to be minimal, but I think my minimal is functionally minimal. Something that when implemented allows developers to experiment and then discussion can progress from there to how more features can be added. I'm trying to be thourough though as to not harm a future proposal so if any of my decisions block something I'm open to changes.
>> Most of my thoughts and focus have been on what I think of as the basics. How types interact with declarations, functions, classes, destructuring, allocation, and control structures. The future consideration sections are mostly a catalogue of ensuring that these basic initial features and designs will work as the language incorporates other proposals.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

More information about the es-discuss mailing list