Hacker News Reader

Comment by greenspot | Hacker News Reader

I like very much the last slide and the author's recommendation. Helpful and better than the admonitory 'yes you should use typed JS':

- if your project does not live for long: no

- if your project is really simple: no

- if there is a chance you will need to refactor the thing: yes

- if your system is very important or even crucial for the success of your company: yes

- if people enter or leave your team frequently: yes

View on HN

Right, that check-list is actually useful in any dynamically-VS-statically typed decision scenario.

IMO, that list is specific to JS because JS now gives you the ability to optionally add types. Otherwise, there are good arguments to be made for dynamically typed languages and statically typed languages. That is, I have seen a proportionally similar number of maintainable Python projects as Java.

Python added type hints in version 3.5. It's a good checklist for dynamically typed languages with optional static typing I'd say.

If you bring up Java when you talk about statically typed languages, let me be sneaky as well and mention PHP as a dynamically typed language. (What I mean: both are shit and are not worth mentioning.)

> - if people enter or leave your team frequently: yes

Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one

But you’ll end with more self-documenting code and more clear internal APIs. It’s a fair tradeoff IMHO.

The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project.

I wish I had something similar for all the Ruby code I write.

It's not exactly what you want, but if you want a statically typed ruby-like you should check out crystal (http://crystal-lang.org/)

Crystal looks interesting but I can't really migrate to a new language. Something that compiles down to plain Ruby would be great though.

You might want to check out rubocop[1]. It does static checking, and we're pretty happy with it.

1: https://github.com/bbatsov/rubocop

Does it actually do static type checking? Because I don't see anything about types in the documentation. It looks like just a more sophisticated linter, which is very different from what TypeScript and Flow bring to the table.

Ah, you're right. It's "just" a linter... but a pretty good one.

I started using rubocop earlier this year and I've become a huge fan. It's done a lot to improve the quality of my code and the consistency of code on projects with multiple developers.

Not sure if this will do, but there's Contracts for Ruby: https://github.com/egonSchiele/contracts.ruby

Learning time of the actual type system is nothing compared to learning/getting in to the code base if it's anything non-trivial.

At the very least type annotations are compiler verified documentation which is a huge time saver, along with better tooling that lets you navigate trough the code more efficiently.

> since introducing TS to you project means longer time train new employees.

From my experience, even developers who have never used statically typed languages are able top pick up the Flow / TypeScript in a matter of hours. Not everything, but enough to barely have an impact on productivity. The main hurdles in the learning process as far as I can tell have been nullable types (smaller hurdle) and declaring types for external modules (big hurdle, many of them still don't fully grasp it).

I've found Flow to have a much, much lower barrier to entry than TypeScript, and I believe it's because it's quite strict / sound as the author very well pointed out (slide 12 for example).

> since introducing TS to you project means longer time train new employees

Does it though? I mean, we're talking about intelligent beings who can drive cars and program computers, how hard can it be for them to spend an hour reading the typescript docs?

I suppose it depends on ones definition of a long time.

Learning TS itself takes minutes. Probably -seconds- if you're familiar with Java/C#.

The real learning curve is in the edge cases, of which there are plenty. Fighting with a 3rd party lib with incorrect type defs, dealing with cases common to JS that are hard to properly type (such as certain functional constructs), dealing with things missing from the TS compiler that are present in ES6/babel, etc.

Those things are quickly going away and may eventually be a non-ssue, but as of today, they're very real. That's in contract with languages that have the type system baked in from the get go, where it wouldn't be an issue.

IMHO the type system of flow and typescript are pretty different from Java/C#. Structural typing to name one and maybe the most important.

they're very different if you take them in a vacuum, but they're nearly clones when compared to ML/Haskell/Scala-style type systems.

Don't forget C# has some structural typing for some features (such as delegates)

Training is not a problem. Anyone who knows the basic of OOP can learn TypeScript in a day.

On the other hand, giving them constraints (because of the type system) ensures their work is not breaking stuff along the way as they learn the ropes of the code base.

From my perspective, setting up a build flow (dependencies, etc) is the biggest problem with TypeScript projects. If you assume that's already done in a given project, then the negative impact is gone and TypeScript only makes it easier.

These are the sort of things you could argue in favor of using GWT.

GWT compiles Java to JavaScript. The issue with it is that the semantics of Java and JavaScript are fairly different. Makes debugging and integrating native JavaScript libs harder.

Reply on news.ycombinator.com