Would be especially inconvenient in places where you have daylight from 9AM till 4PM and where people rely on electric heating.

1. You can define enum like `const enum A {...}` and they will not have runtime representation.

Correct, but that does not solve the other issues I pointed.

Additionally, const enums DO NOT have an associated type. That is a problem in libraries, since users cannot reuse the type definition around (it back ports to a string or a number)

const enum doesn't work when in transpileOnly mode (e.g. webpack, Parcel), and Babel treats "const enum" the same as "enum". I'd really love a non-broken const enum in TypeScript, though.

I'd love to see them out of the language. I do not have evidence/document supporting this, but I think it was ultimately a failed attempt of copying the C# feature ignoring the fact that JavaScript works differently.

I'm not sure comparison is correct. If you want routing in jQuery app - you will have some similar concept to routers. Using packers is also not required. And if you want some good automating module splitting in jQuery app - you'll probably pick up some packer as well. So it's more like HTML5/jQuery can be compared to just React without additions.

Most of these things that bring cognitive load have some purpose. It looks from time to time that developers start making tools in the sake of tools, but most of the time there's some sane reasoning behind.

Agree with this one. Reading article i though "Why don't you just drop ImmutableJS in favor of pure js collections with lodash/fp?". I felt the same when were using ImmutableJS. Two collection libraries across the app is very inconvenient. One could build entire infrastructure with ImmutableJS and restrict native collections to only system boundaries, but in js you usually befriend a lot of libs which makes it complex.

I suppose Vue.js is not very TypeScript friendly?

It is very friendly. I've successfully migrated my gwt + vue-0.10 stack to typescript 2.0 + vue 2.0

Shameless plug: https://github.com/vuets/vuets

It is a micro-lib less than 100 LOC.

Vue even has official typescript typings https://vuejs.org/guide/comparison.html#TypeScript

Don't you use router with vue.js? And what's so messy about JSX?

Probably when you accidentally scanned a document to PDF. Or when you received a document in PDF from some nasty man.

Once I tried to make a union of a sorted set and an unsorted one. Result set inherits behaviour of a bigger input set so when i first got my sometimes-sorted set i thought like loosing my mind.

Oh, that's really annoying too.

Avoiding madness like this is why I have come to really prefer statically typed languages.

The issue doesn't have much to do with dynamic typing, any subtyping support can trigger it. Take Java, if Set had a `Set union(Collection)` method a SortedSet could return a new SortedSet (cast as a set, but still with the actual behaviour of a sorted set).

But you would not be able to pass it to a method that takes a SortedSet, which means you can't rely on the sorted behavior. Incorrectly using behavior that your implementation doesn't support is where the confusion comes from, it doesn't come from your implantation having extra behavior that you can't use.

In Java, you can have:

    class Set<A> { public Set<A> union(Collection<A> c) { ... } }

    class SortedSet<A> extends Set<A> {
      @Override public SortedSet<A> union(Collection<A> c) { ... }
    }

In other words, the more specific type overrides the operations of the more general type into more specialised operations.

defnly agree that you can get these problems in languages with static types, but i think you have to go out of your way vs dynamic languages, where these types of shenanigans are easier and (in my experience) prevalent.

e.g., in your example, because your returned type is Set, you presumably would not be relying on the result to be a sorted set! -- so there would be no problem. if you WERE relying on it being a sorted set, you would have to explicitly downcast -- i.e. would pointing a gun and at your foot and pulling the trigger. maybe you know it's unloaded, but the danger is clear from the type system. ;)

It could also benefit from constant propagation (iirc the term) where you could write obj.get(Item.name) and both get type check and stay refactoring friendly (though with cost of some more typing).