4 ms·

I remember when MicroSoft tried to make it's own superscript of JS and people said "Hey this is a bad idea. Standards are a thing for a reason and we should all

by ebbv 11y ago

I remember when MicroSoft tried to make it's own superscript of JS and people said "Hey this is a bad idea. Standards are a thing for a reason and we should all stick to them." That argument was correct then and it's correct now, IMHO. Where is the objection in 2015? Is it just people are so desensitized by other companies attempts to make JS replacements (that for now compile to JS) that another one just doesn't bug anyone? I realize the temptation for big companies like Microsoft with thousands of devs to roll their own, but when every big company abandons standards to focus on their own little alcove we all suffer. And yeah, I realize you can frame it as they haven't abandoned the standard because TypeScript compiles to JS and yada, yada. But I disagree. If instead of focusing on TypeScript which you can only take advantage of by working in TypeScript, they focused on libraries for JS that we could all use, I think we'd all be better off. And that goes for all large corporations that decide to roll their own solutions instead of sticking to standards. Which is not to say JS can never be replaced, I'd say it's long overdue for replacement. But that's never going to happen by every big company rolling their own thing. Everybody has to come together.

trimbo 11y ago
> But that's never going to happen by every big company rolling their own thing. Everybody has to come together. Google has ditched their own and rolled their efforts into Typescript. http://techcrunch.com/2015/03/05/microsoft-and-google-collaborate-on-typescript-hell-has-not-frozen-over-yet/ http://techcrunch.com/2015/03/05/microsoft-and-google-collab...
dangoor 11y ago
There are quite a few differences from the old "JScript" days. First of all: TypeScript is liberally licensed open source. JScript was totally proprietary. Another aspect is that TypeScript is seeking to be a strict superset of JavaScript that evolves as JavaScript does (something that wasn't really happening in the JScript days) and is focused on specifically providing static types and tooling for types in JS. It's not a general "embrace, extend, extinguish" kind of thing at all, but rather a very targeted tool. TypeScript is really one of the most JavaScript-y languages that compile to JS. Most of the compile-to-JS languages are more radical divergences from JS. JS is not going to be replaced (though WebAssembly[1] will likely become an additional compile target), but compile-to-JS is going to continue to grow in popularity. Already, many people are compiling future-JS to present-day-JS. The browser vendors have found that the standards evolve best when people can actually write code against the standards before the standards are hardened. Compile-to-JS tools help with that. If optional static types and type inference become very popular via TypeScript and Flow, JS itself may evolve to support those features and then we'll have that standard. Microsoft is a better player on the web today than they have ever been before. [1]: https://github.com/WebAssembly/design https://github.com/WebAssembly/design
- spion 11y ago
  > TypeScript is really one of the most JavaScript-y languages that compile to JS. Most of the compile-to-JS languages are more radical divergences from JS. This is what I've been trying to get across for a while, thanks for the wording. Even CoffeeScript is a much bigger divergence than TypeScript (not only in syntax but in semantics, e.g. scope)
wtetzner 11y ago
Can't you use TypeScript libraries from plain JS?
- mynameisvlad 11y ago
  Of course, since TS compiles down to JS.
  - thomasz 11y ago
    More than that, it compiles to readable JS
Sophistifunk 11y ago
Having seen pervasive API arity changes that would take 2 hours in Java take a week in Javascript, I couldn't disagree more strongly. Sure, you can write 10x more unit tests to replicate a compile-time type checker, but you basically have to hold a gun to the head of every developer to enforce it. And unless you're the boss, you don't get to hold a gun to your teammates. The compiler does.
- netheril96 11y ago
  I am all for static typing and type inference. But are you sure `tsc` could hold the gun to your teammates? They could just write regular js, which is also valid typescript. They could also throw up their hands and annotate most types with `any`.
castell 11y ago
I upvoted you, because you are right. We would be better off, adding optional typing to JavaScript 6/7. They already added "class" syntactic sugar thanks to them. Dart and TypeScript just divide the devs and open code base. It's like finding a great project on Github only to figure out it coded in language XY.

by ebbv 11y ago

trimbo 11y ago

> But that's never going to happen by every big company rolling their own thing. Everybody has to come together. Google has ditched their own and rolled their efforts into Typescript. http://techcrunch.com/2015/03/05/microsoft-and-google-collaborate-on-typescript-hell-has-not-frozen-over-yet/ http://techcrunch.com/2015/03/05/microsoft-and-google-collab...

dangoor 11y ago

There are quite a few differences from the old "JScript" days. First of all: TypeScript is liberally licensed open source. JScript was totally proprietary. Another aspect is that TypeScript is seeking to be a strict superset of JavaScript that evolves as JavaScript does (something that wasn't really happening in the JScript days) and is focused on specifically providing static types and tooling for types in JS. It's not a general "embrace, extend, extinguish" kind of thing at all, but rather a very targeted tool. TypeScript is really one of the most JavaScript-y languages that compile to JS. Most of the compile-to-JS languages are more radical divergences from JS. JS is not going to be replaced (though WebAssembly[1] will likely become an additional compile target), but compile-to-JS is going to continue to grow in popularity. Already, many people are compiling future-JS to present-day-JS. The browser vendors have found that the standards evolve best when people can actually write code against the standards before the standards are hardened. Compile-to-JS tools help with that. If optional static types and type inference become very popular via TypeScript and Flow, JS itself may evolve to support those features and then we'll have that standard. Microsoft is a better player on the web today than they have ever been before. [1]: https://github.com/WebAssembly/design https://github.com/WebAssembly/design

spion 11y ago
> TypeScript is really one of the most JavaScript-y languages that compile to JS. Most of the compile-to-JS languages are more radical divergences from JS. This is what I've been trying to get across for a while, thanks for the wording. Even CoffeeScript is a much bigger divergence than TypeScript (not only in syntax but in semantics, e.g. scope)

wtetzner 11y ago

Can't you use TypeScript libraries from plain JS?

mynameisvlad 11y ago
Of course, since TS compiles down to JS.
- thomasz 11y ago
  More than that, it compiles to readable JS

Sophistifunk 11y ago

Having seen pervasive API arity changes that would take 2 hours in Java take a week in Javascript, I couldn't disagree more strongly. Sure, you can write 10x more unit tests to replicate a compile-time type checker, but you basically have to hold a gun to the head of every developer to enforce it. And unless you're the boss, you don't get to hold a gun to your teammates. The compiler does.

netheril96 11y ago
I am all for static typing and type inference. But are you sure `tsc` could hold the gun to your teammates? They could just write regular js, which is also valid typescript. They could also throw up their hands and annotate most types with `any`.

castell 11y ago

I upvoted you, because you are right. We would be better off, adding optional typing to JavaScript 6/7. They already added "class" syntactic sugar thanks to them. Dart and TypeScript just divide the devs and open code base. It's like finding a great project on Github only to figure out it coded in language XY.