41–50 of 194 posts
I just wish TS was based on CoffeeScript.
I just can't justify writing my team's code base in typescript. I don't want to make that move, setting us down a very specific path. I don't want to add another layer of training to develop on our codebase, but mainly, I just don't have the confidence that it's a right or wrong choice, and its a big choice. But I get a sense that it would be great to try for smaller, disposable projects as that's limited risk. Does…
So in theory you could give it a go, and if you decide you don't like it after a while, you could continue development on your .js files and ditch the .ts files.
Chances are that you'll love TypeScript though.
I just wish TS was based on CoffeeScript.
I recently started learning TS after reading a previous HN post on it ( https://medium.com/@basarat/typescript-won-a4e0dfde4b08 ) and listening to the JS Jabber episode with Anders Hejlsberg himself explaining the benefits ( https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-... ). These two (plus knowing that Angular 2.0 is going to be much easier with TX) totally sold me on learning it. I'm in the middle o…
About the text editor: I think all editors use the same TypeScript compiler APIs. That would mean that you would get pretty much same suggestions, error lists, etc. Correct me if I am wrong. VS Code could have some other API calls or project file support. JS Jabber episode was great! Full of great insights.
Emacs is capable of all of these things (because Emacs is capable of anything) but it doesn't work that way out of the box nor is there an already-written package around that makes that easy. To rename you type M-x tide-rename-symbol and it's inconvenient enough that I forget to use it.
With the arrival of TS 2.0 this month (hopefully) we'll have some cool features: a union types [1] b type guards to work with them [1] c nonullable types [2] [1] https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript/pull/7140 As a Scala developer I like Typescript a lot. Which is a first for me in browser development. But I'm not so fond of webpack et al. So I cre…
I see a lot of Angular comments, has anyone had good/bad experiences with TypeScript and React?
I find it very helpful to have properties defined, so when I use the component, I immediately know what are the props I can provide.
There are some 3rd party React components that won't have type definitions yet, but the popular ones are well covered. I have written most of the components I have used, so I haven't had many problems.
I've been using Typescript exclusively as my transpiled language for about a little over a year now. The benefits of intellisense/code-completion and refactoring because of static types can't be underestimated, especially in large apps.
That said, I actually like the opt-in nature of Typescript. There's some parts of code I don't feel like I need to define an interface for. It's just not worth it.
Typescript is turning out to be quite a powerful little language...maybe approaching the point of quite a bit of complexity, but all in-all it's pretty much been a win for my development efforts.
I just wish TS was based on CoffeeScript.
I've often thought about a CoffeeScript variant with optional typing that transpiled to TS. The types would be ascribed via a backslash, e.g. `(hello\string) -> hello + ' world'`. But considering the huge benefit of TS is the tooling such as intellisence, I doubt it's worth the effort to start a whole separate ecosystem.
Though even better would be if the TS team could figure out a way to factor out the type inference logic so that it could be applied just as simply to CoffeeScript as to Javascript, and even allow definitelytyped defs and perhaps intellisense logic to be reused everywhere.
Roslyn does this somewhat for C# and VB, so it might not be too big of a jump.
I just can't justify writing my team's code base in typescript. I don't want to make that move, setting us down a very specific path. I don't want to add another layer of training to develop on our codebase, but mainly, I just don't have the confidence that it's a right or wrong choice, and its a big choice. But I get a sense that it would be great to try for smaller, disposable projects as that's limited risk. Does…
I've found the biggest headache is getting all the *.d.ts files setup right and setting up your own types can sometimes be a pain, but as I mentioned it's pretty opt-in.