Would be so cool if the js engines ignored types like python3. Then I could just write Typescript and run it on node/browser
That would work except for enums. That's the one simple thing the engine actually has to do.
Announcing TypeScript 2.1
51–60 of 226 posts
Re: Announcing TypeScript 2.1
#52If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.
I've tried it and it's awful. If you don't like the language, go code in Ruby. If your company makes you code in Javascript, you are in the wrong job, let someone who knows and loves JS do it.
Re: Announcing TypeScript 2.1
#53I like the functionality of let merged = { ...foo, ...bar, ...baz }; But I've come to understand ... as variadic parameters in C++, Java and Go. Wish they'd used another token.
It depends on the context. In JS variadic parameters are also supported. This is like complaining they confusingly use curly braces around function bodies while you got used to them surrounding object declarations :)
Re: Announcing TypeScript 2.1
#54another anecdote - ive been using TS2.1 for the last month on three interconnected projects - a rest api, an express app and also for client side code in that express app - it has been a great experience. async/await is a godsend and @types/ makes what used to be a terrible process much more streamlined and easy. If you have to write JS, typescript is the best way ive ever found.
Re: Announcing TypeScript 2.1
#55Still no VS 2013 support? We're stuck on 1.8 for a while. It would be great if they supported VS 2013 at least until they release 2017.
So this is totally a hack, but have you tried changing the manifest in the VSIX (it's just a zip file) and seeing if it installs?
Re: Announcing TypeScript 2.1
#56The easier imports solves my biggest issue with migrating an existing project over. I'd say TypeScript is "ready" now. The last feature I'd want is an easy way to map nested json into classes rather than interfaces. Anyone know how?
An approach I've seen is to have each class extend from some abstract base class (I know, OO blech) that looks like this:
abstract class AbstractClassObject {
constructor(json?: any){
if (json){
this.updateFromJSON(json)
}
}
public updateFromJSON = (json: any): this => {
Object.assign(this, json);
return this;
}
}
Re: Announcing TypeScript 2.1
#57Feels like Typescript is building (or has built up?) more momentum than Flow.
Its true and unfortunate. Typescript is the new Coffeescript. It splits the ecosystem. Flow is a progressive enhancement and improves the ecosystem. Typescript has had more push in the mindshare marketing from Microsoft.
Re: Announcing TypeScript 2.1
#58I like the functionality of let merged = { ...foo, ...bar, ...baz }; But I've come to understand ... as variadic parameters in C++, Java and Go. Wish they'd used another token.
Spread (for arrays) was added with ES6. This just adds that kind of thing for objects (ES2017).
let a = [1, 2, 3];
Math.max(...a); // 3
function sum(...numbers) {
return numbers.reduce((a, b) => a + b, 0);
}
sum(1, 2, 3, 4, 5); // 15Re: Announcing TypeScript 2.1
#59One thing I never understood with Babel is which features are shimmed in the output JS and which features are re-implemented? What I means is: I didn't know how to tell Babel which browsers I was targeting, and I'm pretty sure that some of their feature implementations do not feature test the platform before activating, since they were so compiled in. Is that the case? Also, do you have to tell TypeScript your target…
You might be interested in https://github.com/babel/babel-preset-env :D.
(I'm working on it so let me know if you have questions)
Re: Announcing TypeScript 2.1
#60It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.
Maybe it is me, but I feel like mapped types and keyof are terrible features, and using them would be a sign of a bad design/architecture. In general, I don't think using a string that represents a static symbol (such as the name of a var, an attribute or a class) is a good idea. I try to keep a simple stack (Typescript + NPM at the moment), and I prefer to wait for Typescript to have the feature I want, than to inst…
I think there are two main kinds of developers who use TypeScript. Some developers come from traditional statically-typed languages, like C#/Java/C++/etc, and expect the language to conform to their idea of "good design". For these developers, "mapped types" are "not good design". Other developers come from JavaScript, Python, Ruby, or other duck-typed languages and think, "I know that this object is just a dictionary underneath it all, and I want a type system that lets me write code with that foundation." These developers want additional safety but they see traditional type systems as handcuffs.
These are two very different styles of programming, and TypeScript does a fairly good job of serving both groups--it would have to, in order to be as successful as it is. There are a ton of useful JavaScript libraries out there which couldn't easily be rewritten to conform to some Java-style type system, and there are a ton of skilled Java/C#/C++ engineers out there who don't want their name on a bunch of cowboy code.
I don't think this cultural division is going to go away any time soon, so it's in our best interest to believe that people in the "other camp" (whichever camp that is) are skilled and conscientious developers. I'm sure you've heard the arguments by dynamic language lovers who talk about how restrictive/slow/painful it is to write in a static type system, and I'm sure you're as tired of that argument as I am.