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

I'm working with a singlepage webapp that consists of ~1.5MLOC serverside(+other) and an additional ~100KLOC of javascript (not including libraries).

Refactoring and maintaining consistency are the two big problems we have with Javascript. It's easy enough to write javascript that works and does what we need it to do. The challenges come in when you start having separate components that need to interoperate.

eshint/jshint etc take you only so far (preventing you from dumping things into the global scope, avoiding typos). AMD etc can take you a bit further with async loading, and give a better [more consistent] pattern for exporting things than saying to devs "just put your stuff in an IIFE". FB Flow looks helpful, but it's trying to solve a difficult problem, and unfortunately doesn't work so well with our code thanks to ONE bad decision made a long time ago to rely on declaration hoisting ("unreachable code" :( ).

Anyways, knowing that your code isn't going to work before you start spinning up the application saves a lot of time.

Knowing that you can rename a method/function and have no undefined errors come out of it is great. Being able to look up usages of a method across the entire codebase is also useful. Eventually if Microsoft decide to spend resources on it, TypeScript might get CodeLens (which is on its own all manner of cool+useful).

Having class syntax means that you don't need to worry about external consumers accessing properties that they shouldn't be (+gets rid of silly conventions like underscore private members/methods).

JS is a great language, and it's powerful, but when you're writing large quantities of stuff, sometimes you need structure. Particularly when it's a large team and there are people of wildly varying experience, ranging from near-zero JS experience to people who have used it for a decade or more.

Unit tests fix the changing methods issue as well as making sure it will run when you run it. Types don't save you from that anymore then JSLint would as both can have logic errors.

Browserify can help with breaking your code down into smaller reusable modules for the client side and node you want to make your modules as small as possible? From the sounds of it you fell into the one big huge application that does everything problem instead of breaking it up. The same issues would have happen if you would have done that in any other language.

Varying experience doesn't mean you can give them TypeScript or CoffeeScript and not mess something up. You should still put code reviews and training in place though I do agree JavaScript lets you shoot yourself in the foot much easier.

You can hide variables through closures and sorry not a fan of getters and setters, I feel they are a anti-pattern (http://www.yegor256.com/2014/09/16/getters-and-setters-are-e...).

The one thing that would be nice would be knowing where your code is called. Though if you are using NPM and Browserify then that can be easier as well. I agree though that the tools are not as nice as Visual Studios find callers and the intellisense isn't that good ether but I am willing to trade them for the flexibility of not having to declare types and the simplicity of not having to work around types with generics, interfaces, and casting.

So I think there is structure in Javascript you just have to learn the best ways of implementing it. Yes Javascript makes it a little easier to shoot yourself in the foot but you can still do it with CoffeeScript, TypeScript, or even in C# and Java, we learn from our mistakes. I fell to be successful in Javascript you really need to keep it small and re-factor often but that really is the same in all languages.

TypeScript is different from CoffeeScript, it's not a new language. It's superset of JS, and it almost is JS, only ES6. So that's the direction where JS is going.

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.

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