Hacker News new | comments | show | ask | jobs | submit login

Each of your points is valid.

We have unit tests (fewer on the client than server though), CI that runs integration tests, automated UI tests and other stuff - but that's all much slower than "VS tells me that my code's broken so I should fix it before starting to debug". We'll catch bugs with TS or JS, it's just how long it takes to catch them that's the issue.

Modules aren't so much an issue for us (we don't have a big ball of mud IMO), it's how these modules talk to one another. This is not a problem that we experience in our serverside code because we have powerful tools (in terms of the IDE) that largely stop us from doing dumb things. We refactor a lot, and historically doing this in js has been a massive pain (ie there are no GOOD automated tools for refactoring that I'm aware of). If you use C# and move a method, you expect everything to keep working, but you don't have that same expectation when refactoring javascript. If your app is structured correctly, you do get that with TypeScript.

Same with reviews and training - we have both, but our team isn't big enough to have people dedicated to each area. We mostly hire C# devs, for better or worse, and want them to be as productive per hour as possible. Having it harder to shoot yourself in the foot means fewer feet shot over time, regardless of the team and their skillset.

Getters/setters was an unclear use of term "properties" on my behalf (which actually referred mostly exclusively to methods). Regardless of my personal opinions on getter/setter methods/closures etc, we have established patterns that will take a while to change. The problem is there, and so tooling that helps reduce what breaks when we make changes is a big plus. We don't have a robust message bus in the application, so there's a lot of crosstalk (that's a refactoring area).

And, overall, TS is a superset of javascript so you can always just write JS if that's what you've gotta do.

I guess that my overall point is that javascript is a great language (well, it's ok), but that tools like TypeScript just make things "better" for the average developer working on a large-scale system. JS is an organically grown language, and it shows in a number of places. You can do some super-cool things with it, sure, but for a lot of uses it's a worthwhile tradeoff to write something in a slightly-more-strongly-typed way.

We're about 10% new code, 90% refactoring and updating (though that's a guess, I haven't looked at the stats lately). For us, JS is more painful to maintain than C#. From what we've seen, TypeScript will give us significant benefits on that 90%.




All awesome points, I'll have to take a second look at TypeScript. Thanks for the points back.




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: