71–80 of 201 posts
What I would like to have in TS is a more expressive type system - the current is somewhat basic(e.g. you can't have a Symbol as a dictionary key - interesting given that it's possible in JS. Also you can't mix dictionary fields with regular ones in one class/interface).
EDIT: typo.
I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious. My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.
Have you spent any real time with Flow? As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go. TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people. I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve…
The main large project you're likely to use that does not really play well with TypeScript yet is create-react-app. There's a TypeScript fork [1] which works reasonably well, but "reasonable" is not really what you'd hope.
That said, the strong community push means that they're at least considering it. [2]
[1] https://github.com/wmonk/create-react-app-typescript [2] https://github.com/facebook/create-react-app/pull/2815
I haven't used it in a while. Does it play nice with plain-JavaScript libraries from npm yet? I quit using it a few years back because it was a _nightmare_ having to write d.ts files for everything or be unable to use noImplictAny for your own files. `AllowJs` wasn't even a thing when I started using it, but even after its addition, this problem continued to be absolutely disastrous for my project. I remember being v…
Bottom line: I never write my own definitions for other projects.
The alternatives to TypeScript seem increasingly compelling to me.
It was good to see Haxe mentioned even in passing; I really enjoy using it and — as others have noted[1] — it feels like a “better” TypeScript.
Haxe has great features both at the language-level (pattern matching, algebraic data types, array comprehensions, and more[2]) and tooling-level (cross-compilation to JavaScript, native code and dynamic languages, a fast compilation server[3], good VS Code support in Haxe 4, and a bunch of cross-platform game frameworks[4]). I wish more people would try it! https://haxe.org/
Reason is also compelling; it will be better still once Bucklescript's Belt library is out of beta and some warts in Reason/OCaml are smoothed out — lack of ad-hoc polymorphism[5] and lack of unicode support without BuckleScript string literals being two examples.
[1]: https://news.ycombinator.com/item?id=10009290
[2]: https://haxe.org/documentation/introduction/language-feature...
[3]: https://haxe.org/blog/nicolas-about-haxe-episode-1/
I always wonder why people think typescript is a fix for bad code. We primarily do JavaScript, and I see no issues with it when you set up governance in how to use it. I don’t think building your own libraries is really a bad thing either, in fact I think you should do so often instead of relying on 3rd party packages of quality you typically judge on how many times they’ve been downloaded if you’re being honest. I t…
I think the problem is that people are abusing JavaScript for large projects when JavaScript's purpose is small-scale DOM manipulation in response to UI events.
In our project I’ve found we make a lot less mistakes than with pure JS and there’s a lot less pointless type check unit tests due to the guarantee’s it gives us. io-ts (https://github.com/gcanti/io-ts) around rest endpoints checking json input as well has been a godsend.
After a few years with both TS and JS my verdict is that TypeScript definitely helps , but mostly with type-related bugs - with proper testing you don't get many of those. What I would like to have in TS is a more expressive type system - the current is somewhat basic(e.g. you can't have a Symbol as a dictionary key - interesting given that it's possible in JS. Also you can't mix dictionary fields with regular ones i…
I think what we need is a subset of JavaScript, not a superset. There are things we should not be able to do in JavaScript in a web browser because to me that's where JavaScript belongs. I think the whole idea of js on the server or in other kind of projects is very silly. But that's besides the point.
But I agree with your example of symbol in dict. I would be surprised if it isn't already on the roadmap. Have you tried reaching out to the typescript people?
Real big fan of TS, like anything though you just have to be disciplined when using it. Type absolutely everything and set the transpiler to the most aggressive checks possible... If you’re being lazy and putting : any everywhere and then complaining about how good it is...you’re doing it wrong In our project I’ve found we make a lot less mistakes than with pure JS and there’s a lot less pointless type check unit tes…
> "compilerOptions": { "strict": true }
But given the huge number of other options I worry that like GCC's '-Wall', that doesn't actually give you the strongest possible type checking. Anyone know about that? My aim with Typescript is to turn JS into OCaml.
Isn't Reason/Ocaml a better direction than Typescript? I believe that TS is a step forward but I'm afraid that we are still in a muddy path .
Google has enough resources for someone to write a transpiler that can take annotated JS and convert most of it to TypeScript. It's certainly much more pleasant than having to type random comments everywhere, which kinda makes syntax highlighting way less useful. Oh, and last I checked there were no editor plugins for linting Closure Compiler annotated code. Another option would be to add TypeScript support to Closur…
It'll probably happen anyway, but the current competition will determine which tool that will be. So far TS looks like it's winning it, but, clearly, not by a large enough margin that the industry coalesces around it - yet.