Live data from Hacker News

I Was Wrong About TypeScript

triplet.fi

111–120 of 194 posts

Re: I Was Wrong About TypeScript

#111

Earlier quoted context omitted.

> But doesn't Typescript compile to JS, thus there's actually no type-checking at runtime? Sure, but that's what happens in every other language e.g. C's type system will enforce certain properties for you but when you compile to machine code the machine code is not checking those properties at runtime. If you know the compiler is correct you don't have to worry. Nobody is saying you should stop writing tests but a g…

Q: What is a concrete advantage of Typescript? A: C's type system is very useful for data validation. Please read at least one sentence before writing a response next time.

You claimed that the lack of type checking at runtime is somehow detrimental to the notion. He pointed out that, fundamentally, all strongly typed languages run as weakly typed machine code at runtime, giving C as one obvious example. Thus, types in TS are at least as useful as types in C.

The concrete advantage of TS is the same as the concrete advantage of any strongly typed language - types let you do static validation, and unlike tests, they allow for that validation to be provably complete (of course, the domain of constraints that can be so validated depends on the power of the type system in question).

Re: I Was Wrong About TypeScript

#112

Does anyone have a good tutorial on migrating existing JS codebases to TS? Talking specifically Angular 1 if you have one, otherwise a general tutorial is fine. I'm interested in whether it is worth the effort migrating a pretty large frontend codebase.

I did this on my current project. Basically:

- Set up your TypeScript config

- Set up Typings (or some other type def manager)

- Rename all ".js" files to ".ts"

- Replace all "var x = require()" calls to "import x = require()"

- Gradually refactor components (controllers, directives, services) to classes, or at least add type annotations to everything.

Because TypeScript is a superset of JavaScript, you can work on an untyped system and add gradual typing until the codebase starts looking nicer. Any new functionality can be implemented in TypeScript; any existing functionality can be slowly refactored when it is touched by changes.

Re: I Was Wrong About TypeScript

#114
post #110
post #55

Earlier quoted context omitted.

Ha, I'm on the anti-Angular2 bandwagon due to Angular1. I use React and Typescript and love it. Curious if you've tried React. Or Angular1 (TBH Angular1 was pretty great at the time, but after React I look back at those monstrous template files, ng-everything, plugins and workarounds, and only the bad memories surface).

Angular blew a loooooot of my trust in Google, who in the past always put out the highest quality stuff. I built an entire app in the damn thing only to realize as it got bigger that it wouldn't scale. Sure you can use less HTML templates, but that's the whole point so that it's easier for designers to approach / fix. Sure I should have checked it out but the documentation didn't exactly highlight it (at the time any…

o.O i love angular 1. and probably would like 2 as well, havent started any new major projects lately though

Re: I Was Wrong About TypeScript

#115
post #55

Earlier quoted context omitted.

Ha, I'm on the anti-Angular2 bandwagon due to Angular1. I use React and Typescript and love it. Curious if you've tried React. Or Angular1 (TBH Angular1 was pretty great at the time, but after React I look back at those monstrous template files, ng-everything, plugins and workarounds, and only the bad memories surface).

I'm interested to know if you can build a hybrid app using just React? I tried React but I hit a wall of needing synchronisation, routing, notifications, can you do that now?

Yup

Re: I Was Wrong About TypeScript

#116
post #91

It seems like people are trying to use types as a substitute for tests and a way to protect themselves from unintended mutations. But if you write tests already and use immutable data structures, what benefits does TS bring to people whose background isn't in strongly typed languages?

- Documentation. You don't need to have free-text comments saying "@param myArg must be a string", you can just look at the type signature, and immediately know how to use a function. Attempting to pass in a number will fail at the time of writing, not at runtime (of your test). This is a huge benefit when using third party libraries. For a JS lib, you need to read the documentation, and if something is undocumented you need access to the source code and the time to analyse it, to understand exactly how to use the lib. Compare this to making the type interface available.

- It's easier for a machine to read, which means the possibility for better tooling. e.g. linters and checkers, automatic refactoring.

- It's actually faster to write, due to the ease of making changes. If you move a function out to a new module, the compiler will immediately tell you all of the invocation sites that are now broken. (If you rely on tests, you have to make sure you have tests in every invoking module, rather than just the module you are actually changing. [Ignoring mocking issues...])

Re: I Was Wrong About TypeScript

#117

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…

The two things coming in 2.0 that most excite me are - moving types to npm (despite the great work of Blake on typings, managing type definitions is still out of band) - npm install @types/somelib will be great. - AST transforms, which will open up some interesting options for bundling and optimizations, sort of like babel's plugin ecosystem.

Could you give links about moving types to npm? Are there any issues in a tracker or a blog?

Re: I Was Wrong About TypeScript

#118
post #85

Earlier quoted context omitted.

No, I think solomatov is saying you can always use the 'any' type built-in to TypeScript. You can always do: declare var fancyNewLib: any; fancyNewLib('hello'); fancyNewLib.someCoolFeature = 3; You don't get any suggestions or typechecking (obviously), but you're no worse off than just using JS in that sense. And you can easily replace your 'declare' with the actual // tag when you find it or make it, and clean up an…

Ah, yes, that's what I'm doing most of the time. But like you said it's no better than using JS directly, haha.

Actually, it's better. If the core of your application has non trivial business logic, it's a good idea to write it in typed way and write ui and other support stuff with partially typed code.

Re: I Was Wrong About TypeScript

#119
post #110
post #55

Earlier quoted context omitted.

Ha, I'm on the anti-Angular2 bandwagon due to Angular1. I use React and Typescript and love it. Curious if you've tried React. Or Angular1 (TBH Angular1 was pretty great at the time, but after React I look back at those monstrous template files, ng-everything, plugins and workarounds, and only the bad memories surface).

Angular blew a loooooot of my trust in Google, who in the past always put out the highest quality stuff. I built an entire app in the damn thing only to realize as it got bigger that it wouldn't scale. Sure you can use less HTML templates, but that's the whole point so that it's easier for designers to approach / fix. Sure I should have checked it out but the documentation didn't exactly highlight it (at the time any…

That's a little harsh. It was an MVVM framework along the same lines as backbone, ember 1.0, knockout, and pretty much every other framework of the day, plus a lot of extra functionality. It's not really google's fault that MVVM has limitations.

Re: I Was Wrong About TypeScript

#120

Earlier quoted context omitted.

Q: What is a concrete advantage of Typescript? A: C's type system is very useful for data validation. Please read at least one sentence before writing a response next time.

You claimed that the lack of type checking at runtime is somehow detrimental to the notion. He pointed out that, fundamentally, all strongly typed languages run as weakly typed machine code at runtime, giving C as one obvious example. Thus, types in TS are at least as useful as types in C. The concrete advantage of TS is the same as the concrete advantage of any strongly typed language - types let you do static valid…

Yes, but what about mutating objects/primitives in a way that causes all validations to pass but still be passing the wrong data?

It seems like using type checking as a reason to write fewer tests actually just creates nastier bugs in areas where your coverage is based on type validation.

What am I missing about checking type mutation !== mutation being a problem?

What is the advantage of strong types if your data structures are immutable? Is there any? I'm genuinely trying to understand if TS is just for cases where uncontrolled mutation is the norm and test coverage is poor.

Post reply on HN