131–140 of 226 posts
After trying TS, I basically never want to write JS again. I know that 'OO' and 'typing' is not the solution to everything ... but aside from all the nice things you can do in TS ... the 'enforced architecture' of OO-ish paradigms, combined with typing, and essential obfuscation of the prototype paradigm ... has cut the time to development in half. I can hardly think of a reason to use JS now that TS exists. Of cours…
Earlier quoted context omitted.
TypeScript doesn't split the community any more than Flow does. TypeScript remains very close to ES2016/2017, syntax-wise, with the only major difference being type annotations, but you have those with flow as well. Anybody who can read JavaScript can read TypeScript.
Flow tries to integrate with the existing ecosystem as much as possible. By taking advantage of Babel, ESLint, Atom, etc. With Flow you don't even have to opt-in to a new syntax. You can just use comments: function foo(val /* : boolean */) /* : string */ {} Using really powerful inference you can also write much fewer types. If you have well types libraries [you sometimes don't need types in your code at all]( https:…
So you use a opt-in comment-based syntax instead of a opt-in non-comment based one for type-annotations.
Hardly a big difference.
> Using really powerful inference you can also write much fewer types
I'm just going to assume you didn't know typescript does this too.
Typescript is nice. You should give it a try once. You may end up surprised:)
Can someone comment on the difference in reliability between using typescript and a natively statically typed language like haskell or scala? Is there any? Or is the type safety really as good when you use ts
I was missing this mostly for incoming requests. A good solution for me has been to generate json-schema from typescript interface definitions, using the typescript-json-schema npm package. Then incoming data can be checked vs the generated json schemas. Works fine and I get json schemas for api endpoints from it as well, so no complaints.
Been a Linux developer for ages C# was never my taste, I'm still a bit Microsoft-hatred as of now(Visual Studio Code is the only item I adopted for JS development, the rest languages I still use vi/Geany). How tightly TS is related to C#? That has been the main reason I had not tried TS seriously so far. Don't want to have anything to do with C#. I know...
TS is just JS + new features from future JS specification + optional type system. And optional type system is fundamentally different than the one in C#, and it was designed to fit well with JS patterns and idioms (structural vs nominal type system)
If you look at TS code that looks like C#, it's because JS looks like that (classes syntax, classical inheritance, lambda syntax - it's all ES7 (or ES2016/ES2017, or whatever it's called now)
Earlier quoted context omitted.
> 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. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (w…
If the code isn't typed, then you can't find all references accurately. For example, in the below, you've no idea if the "a" inside the function is the same is as on "foo". ```javascript var foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj) { obj.a = false; // Won't find this "a". } ``` Call site inference can follow this sometimes. However with types it c…
Disclaimer: I'm working on a competing tool
Still 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?
If 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 have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.
Would be so cool if the js engines ignored types like python3. Then I could just write Typescript and run it on node/browser
Earlier quoted context omitted.
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. At this point in time, it's a bit of a false dichotomy. It just amounts to a programming tool based on a form of meta-data. Of course people are going to have different ideas about the cost-benefit of that tooling. Of…
I don't think this is a false dichotomy. There's definitely a spectrum between static and dynamic type systems, and plenty of people who identify with either camp. Calling it "tooling" changes the name of the problem, there are still people who will complain when they think the tooling is going in the wrong direction, and those complaints have merits because so many of us will be forced to write code in a style we do…
The key word is spectrum.
and plenty of people who identify with either camp.
What does it mean when people take something that's actually a spectrum, then divide that into two opposing camps? Does this sort of activity generally get public discourse closer to the truth, or farther away from it? It usually does the latter, in my experience. Hopefully, someone has set that knob to a position that works pretty well, and things work out.
those complaints have merits because so many of us will be forced to write code in a style we don't like.
Just who gets to write code in exactly the style that they like? From what I've seen, people generally make compromises, or they found the "perfect" job, or they are the one running the project, or they are going rogue and doing their own thing and introducing inconsistencies into a project's codebase.