101–110 of 128 posts
I love the piegonhole arguments that always 'exclude' Dart from these types of discussions. Class-based vs prototype-based, classes will always win. JS is terrible, TypeScript is only very slightly better. Dart's core team is absolutely world class, and the language is already highly capable.
Earlier quoted context omitted.
Sure and Traceur was backed by Google but that didn't stop it from losing the hype train to Babel (which was someone's side project). The JavaScript hype cycle has no escape hatch. All that go up, must come down. Some things just last a little longer than others.
> Backed by Google Exactly the problem. Like all other Google projects, they bailed on it.
Ditto for Closure which is actively developed (and is among the best libraries in ES6 features) but also lost the hype cycle to Uglify.
Earlier quoted context omitted.
fwiw, TypeScript -> Babel is doable, if painful. I have it set up in my repo here: https://github.com/thomasboyt/manygolf I agree that Flow currently the superior type system (and, unlike TypeScript, not a complete nightmare to set up if you're wanting to use Babel/Webpack instead of manually running file builds through your editor like it's 2002), but TypeScript has significantly more momentum behind it making it a…
There's not really a gap between them. I've spoken to people on the TypeScript team a number of times. Jonathan Turner and I talked about sharing ASTs once, and I gave an internal presentation about Babel at Microsoft last year. Also, there's tons of people that use TypeScript for type-checking and stripping types and then use Babel for compiling down ES2015 code since Babel follows the spec closer.
Earlier quoted context omitted.
Pure (vanilla) JavaScript will remain a bit of a rare unicorn in large projects, though, at least until HTTP/2 and maybe even after HTTP/2 for whatever other reasons [1]. Just about every large project has a bundler and/or minifier step and the Typescript transpilation fits right in there, instead of in the browser. [1] People will always still want to shave bandwidth, and the new hotness is Tree Shakers which shave…
Just about every large project has a bundler step for production . Many have for dev as well, but this is unequivocally an undesirable thing. You can't beat Refresh for dev workflows.
Plus, even a bunch of dev workflows are increasingly using tools like gulp-watch in the background of their refresh cycle (for whatever reasons), and Typescript's watch support has gotten very good.
Earlier quoted context omitted.
Top-level types can be permanently shadowed. For instance, if I name a type "Date" within a namespace, then every file within that namespace or a sub-namespace will no longer be able to access the JavaScript native Date type. This also apparently isn't something they're inclined to fix. [0] The tsconfig.json file does not allow for glob-type inclusion of files, or even inclusion of directories. However, you can exclu…
Isn't this kind of inherent to the JS model? I mean I guess you could rewrite the names of types at compilation but that would create other problems
Interesting he omits Flow from his very carefully chosen "Typescript won" arguments.
Earlier quoted context omitted.
Just about every large project has a bundler step for production . Many have for dev as well, but this is unequivocally an undesirable thing. You can't beat Refresh for dev workflows.
In dev workflows you can deal with the extra few milliseconds of transpilation time just like you deal with the extra few milliseconds of overhead from any of your other dev tools. Plus, even a bunch of dev workflows are increasingly using tools like gulp-watch in the background of their refresh cycle (for whatever reasons), and Typescript's watch support has gotten very good.
Earlier quoted context omitted.
> Backed by Google Exactly the problem. Like all other Google projects, they bailed on it.
No they didn't, it's still under active development, last release 4 days ago. Ditto for Closure which is actively developed (and is among the best libraries in ES6 features) but also lost the hype cycle to Uglify.
Does anyone here have bad things to say about TypeScript? I haven't used it for any large projects yet (couple toy ones) but seems pretty legit. Based on my anecdata, people who have used it at scale seems to like it. I can't tell if that's because they're still in the honeymoon phase or if it really is a step forward for the long term.
The type system is not that great and inference is quite limited. Definitions are not always existent or up to date and a single repo like definitelytyped is a terrible way to manage all the definitions. The above sounds negative but TS is still the best bet right now imo. Some people will prefer Elm or Purescript for better type systems but I like staying close to JS.
Earlier quoted context omitted.
Top-level types can be permanently shadowed. For instance, if I name a type "Date" within a namespace, then every file within that namespace or a sub-namespace will no longer be able to access the JavaScript native Date type. This also apparently isn't something they're inclined to fix. [0] The tsconfig.json file does not allow for glob-type inclusion of files, or even inclusion of directories. However, you can exclu…
Isn't this kind of inherent to the JS model? I mean I guess you could rewrite the names of types at compilation but that would create other problems
JS doesn't have namespace scoping, and therefore everything has to be explicitly scoped. So if I create `my.awesome.Date`, just `Date` means JavaScript's `Date`, and I have to put `my.awesome.Date` to get the new type. Typescript adds namespaces and scoping rules, so that anything in the `my.awesome` namespace or any namespace below it will see `Date` as `my.awesome.Date`. And there's no way to explicitly reference the global scope, so within those namespaces the new type completely and irrevocably shadows the original JavaScript type.
Also in JavaScript, unless I overwrite the original `Date` type, I can always explicitly scope it by saying `window.Date`. But TypeScript doesn't define `Date` within the `window` type, so I can't use that out either.