4 ms·
Ask HN / TypeScripters: How Choose JavaScript?
I see a lot of fierce feedback from the TypeScript community when someone decides to use JavaScript and not TypeScript on a project. I'm developing Nue JS frontend library and I'be been a target for several accusations due to my rationale on using JS here: https://nuejs.org/faq/#ts
So here's the question: can you help me with a list of the right/valid reasons to choose JavaScript so that the TypeScript community is pleased? This would help me a lot going forward.
Thank you!
- metaloha 3y agoTS helps remove a whole class of bugs (type-related) by preventing you from building (or in this case, transpiling) code with known and potentially unintended type casting (eg. `let myName = "Joe"; myName = null;` This makes it impossible to push production code with these types of potential bugs. But, you do add a transpilation step you might not have needed (unless you're writing ES6 code and are already using Babel or something to target ES5 browsers). But, TypeScript is better for adding strong or static typing than anything else, IMHO, so if you need that feature, don't use anything else. But, it can be harder to write good TS code because JS devs have long been taking advantage of the weak typing inherent to the language. It can be a challenge to change that mode of thinking and resist the temptation to use the `any` type in TS. As to the list at the link, point 1 is a non-issue; if you're using advanced JS features that aren't supported by the browser, you already have a transpilation step. Point 2 is not a feature of JS, it's a side-effect. Static typing is awesome and (I would argue) necessary for advanced development. Strong typing is a bit of a double-edged sword, but I'd still rather have it than not. Point 3 is related to point 1 - if you already have a transpilation step for some reason and you want strong/static types, no reason not to jump to TS; it transpiles to JS same as CoffeeScript or Flow or JSX.
- metaloha 3y agoOh yeah, I'll mention JSDoc @type tags - hard pass, if you can. Comments should have NO EFFECT AT ALL WHATSOEVER on code. They're comments. Everything should be identical with and without them, they are 100% disposable. Moving any type of functionality into comments makes them brittle and now they can't be stripped out. The suggestion to add a `.d.ts` file is good - it allows people who do use TS to be able to use strong/static typing while using your library, without you needing to add any kind of type support within your library. Just make sure it stays updated ;)
- eyelidlessness 3y agoJSDoc types don’t have any effect on how the code runs. They just document the types they’re commenting on. They’re conceptually exactly the same as a .d.ts companion file, and both are just different ways to achieve roughly the same thing as having TypeScript types directly in the source.
- bavarianbob 3y agoWhy do you feel the need to justify yourself on that decision? That brainpower could be better spent going to new features or a more robust codebase. The audience that is pedantic about what the technology is written in is not an audience worth spending time satisfying.
- tipiirai 3y agoGood point! My goal exactly. But sadly I'm not immune to hate speech.
- bavarianbob 3y agoNo one is. You signed up to potentially receive that as soon as you decided to build something. Filter the noise and move on my friend.
- pestatije 3y agotry throwing some ts at a browser and see what comes out of it
- tipiirai 3y agoI thoght this would be a good one, but it was disregarded as "wholly immaterial" point
- pestatije 3y agothats your call not theirs...im not entirely getting this exercise, why are you discussing this point with anybody?...you are the developer, you give your reasonable reasons, and thats it...you can perfectly reasonably say you don't want an additional transpilation step in your project, whats the deal?
- halfmatthalfcat 3y agoPoints 1 and 2 are not exclusive to either JS or TS.
- wryoak 3y agoThey can fork it if it bothers them so much