Ask HN: Starting a startup with typed code x none typed code I'm not a really good programmer and I still have problems with types in TypeScript x JavaScript, for example. I'd like to start a business and I would of course move a lot faster by simply writing JavaScript instead of TypeScript. If I chose the JavaScript route, what considerations should I have in mind? |
For (almost) every language that exists, there's at least one startup using it that succeeded.
The argument of speed is not realistic. Time matters, that's true, but not to *that* extent.
Maybe the only factor that matters is how familiar you are with language (so that you can easily build your prototype/MVP) and how popular the language is so that you can easily recruit when the time comes.
In fact you can use TS now, but write JS. It will just work. Then as you begin to feel more comfortable with features of TS, you can begin using them.
If you write JS, you are supposed to write a bunch of tests to catch possible regressions that TS's type system would catch for you at compile time. But tests are always a tradeoff; they take a little longer today to write for being able to move faster and more confidently later (this assumes you're writing good tests. Bad tests are generally worse than no tests).
Caveat, you kinda have to already be thinking about types while writing JS for this to work. Highly dynamic code can be much easier to write in TS from scratch than rewrite from JS.
TypeScript in the long run is better as it will help ensure that the data flowing through your application is consistent, however, there is an upfront cost to learning to work with types that is not trivial. It will initially slow things down as you grapple with the stricter syntax and the tooling around it. For POCs if you are not an experienced programmer, this will likely add a lot of friction. Keep in mind though that when your application reaches a certain level of complexity, the cost of not having TS starts to exceed the cost of using TS. A good rule of thumb I go by is to try to pick up 1 new technology per project/sub-project. Hope this helps!
But, since you asked, I have been programming professionally much longer than most HN users have been alive, and based on that experience, I have concluded that, all else being equal, languages with sophisticated static typing are superior to dynamically typed languages. Note the word "sophisticated": that specifically excludes, e.g., Java, which there's no good reason to start a new project in in 2021 anyway.
Here's a great tool, https://quicktype.io/typescript . You can paste in JSON objects and it will spit out useful type definitions for your objects. The reality is that types exist in JavaScript and any other untyped language, they're just implicit. You have to read the code to know what they are. Then to help yourself or people who work with you, you will start writing examples either in the docs or in tests, and now you've informally specified your types. Or you don't do either then every time you or anyone else goes to edit a piece of code you have to read, understand, manually find all places you used that code and make sure you didn't break anything.
The purpose of a static type system is to find bugs, or issues with your code without even running it. The compiler will let you know if you make a change to the code which breaks the type you set. It can do a lot of the above mentioned work completely automatically.
You end up saving a lot of time not repeating work. One time working in python I had a problem that took me an hour to figure out. I had to look through a bunch of project code, then library code, and then I figured out that I just had put in the wrong shape of data. In a typed language it would have take me 30 seconds. The compiler would have complained and told me how I was wrong and then I would have fixed and moved on. At that moment I said "I'm getting too old for this shit", and then have never looked back from working with typed languages.
Secondly, TypeScript is not Java/C/C++. TypeScript has type inference and expressive type system. This means that you do not need to manually write the type for every single variable. Most you can omit because TypeScript is clever enough to figure it out.
Secondly, Structural typing is exactly how duck typing works in JavaScript and Python. Unlike those older languages you don't need to build huge class based hierarchies to make types that work in many situations. Define a minimal interface that you need for a function. Any object that has those properties will type check and work.
Check out Effective TypeScript, or Programming TypeScript. As a seasoned node developer I assure you that if you ever have teammates, types will help them contribute to a code base faster and with more confidence.