Hacker News Reader

Comment by geist | Hacker News Reader

Articles like this will certainly bring out the pro-Typescript people, so this got me thinking. I'd like to hear from people who tried Typescript and found they didn't like it for any number of reasons.

Note I'm not pro or anti myself, I've only just begun playing with it, but would like to hear from all kinds of people.

View on HN

The article is correct in that it's important to understand that typing your code has a cost - it's not just all magical benefits. Personally (personally - not for everybody) the cost is that it inhibits my initial experimentation. I don't KNOW what types things should be while I'm faffing around researching and experimenting in a new domain.

I'm a huge fan of strongly-typed code, but I like to add the types much later, once all of the pieces are in place and are not in constant change, and mostly as a way to not have to write unit tests. If I type from the start I find I lock in to sub-optimal data structures and get "attached" to them. I already typed them, I don't want to break things!

Also, I live by the "What Would Rich Hickey Do?" school of thought... so when he mandates types in Clojure, I'll switch to TypeScript by default ;)

type IJustWantToExperiment = any

You could use the allowJs typescript flag and mostly use JS files at first; perhaps only typing a few models.

Typescript projects definitely give me the most pain. You regularly end up to the point you have to resort to 'any' after hours of looking for a stupid type definition. IMAO it's just one big waste of time, just landed a job with a good old JS codebase, what a relief. TS might help for junior and medior developers so they make less mistakes. But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something. Imagine you give a painter a brush that doesn't allow to be used freely, that's what TS does to a good JS developer.

But TS is at this moment really eating JS jobs, and that kinda hurts. I just don't understand the proponents, besides the job opportunity, give me one single reason to write in TS? If you want to go for a strictly typed language TS is definitely the worse choice. TS simply doesn't fit in the JS ecosystem. Look at (a part of) the dependency part of this package.json, from the beginning of a large project. Don't you agree something is going very wrong in the JS world?

    "ts-jest": "^23.1.3",
    "ts-loader": "^4.5.0",
    "ts-node": "^7.0.1",
    "tsconfig-paths-webpack-plugin": "^3.2.0",
    "tslint": "^5.11.0",
    "tslint-config-prettier": "^1.14.0",
    "tslint-react": "^3.6.0",
    "typescript": "^3.0.1",
    "typings-for-css-modules-loader": "^1.7.0",
    "@sentry/browser": "^4.0.0-beta.12",
    "@sentry/node": "4.0.0-beta.12",
    "@sentry/types": "^4.0.0-beta.12",
    "@types/autoprefixer": "^6.7.3",
    "@types/classnames": "^2.2.6",
    "@types/clean-webpack-plugin": "^0.1.2",
    "@types/compression": "0.0.36",
    "@types/cookie-parser": "^1.4.1",
    "@types/cors": "^2.8.4",
    "@types/cucumber": "^4.0.4",
    "@types/enzyme": "^3.1.13",
    "@types/enzyme-adapter-react-16": "^1.0.3",
    "@types/enzyme-to-json": "^1.5.2",
    "@types/express": "^4.16.0",
    "@types/helmet": "0.0.38",
    "@types/html-webpack-plugin": "^3.2.0",
    "@types/jest": "^23.3.1",
    "@types/js-cookie": "^2.1.0",
    "@types/memwatch-next": "^0.3.1",
    "@types/node": "^10.5.7",
    "@types/node-sass": "^3.10.32",
    "@types/optimize-css-assets-webpack-plugin": "^1.3.3",
    "@types/react": "^16.4.11",
    "@types/react-dom": "^16.0.7",
    "@types/react-helmet": "^5.0.7",
    "@types/react-intl": "^2.3.10",
    "@types/react-loadable": "^5.4.1",
    "@types/react-redux": "^6.0.6",
    "@types/react-router-dom": "^4.3.0",
    "@types/redux-mock-store": "^1.0.0",
    "@types/serve-favicon": "^2.2.30",
    "@types/webdriverio": "^4.10.3",
    "@types/webpack-merge": "^4.1.3",
    "@types/webpack-node-externals": "^1.6.3",
    "webpack": "4.19.0",
    "webpack-assets-manifest": "^3.0.2",
    "webpack-cli": "3.1.0",
    "webpack-dev-middleware": "^3.1.3",
    "webpack-dev-server": "^3.1.5",
    "webpack-hot-middleware": "^2.22.3",
    "webpack-merge": "^4.1.4",
    "webpack-node-externals": "^1.7.2",
    "stylelint": "^9.5.0",
    "stylelint-config-prettier": "^4.0.0",
    "stylelint-config-recess-order": "^2.0.0",
    "stylelint-config-recommended-scss": "^3.2.0",
    "stylelint-scss": "^3.3.0",

I just don't like having to look things up, or remember them, or tell someone else about them, or make sure the things I told them or that they told me are still true six months later, or check manually that I haven't typo'd a variable name, and so on and so on, when a machine can do those things for me.

The absolute worst case with TS is that I'm as bad off as I would be in JS (use "any", or "as", or provide a dummy anything-goes d.ts for a lib, or whatever). I haven't found that I actually need to do those things very often, even being fairly lazy and having a very low tolerance for time lost to managing my tools.

When dealing with binary packages I have to do stuff like iterating over an object to see what it exposes. I guess typings (if one exist) help a lot there. But for open source code you can just look in the source. Looking at other peoples source code is the best way to learn, so don't let TypeScript take that away for you. The projects with non-existing documentation is often the ones most easy to use. Maybe because the source code is so easy to understand that no documentation is needed :P

> But I'm pretty sure if you can code Javascript well Typescript only stands in your way when you want to create something.

You and the author are both overly concerned about writing code and completely ignoring maintainability. If you write your code once and never touch it again, sure, use plain JS. If you're going to come back in six months month and refactor it or hand it off to a co-worker and expect him to write some code TypeScript is a godsend.

There's more to maintainability then just adding types. Maintainability is a process not a language.

Yes, and TypeScript is an incredibly powerful tool to make that process easier.

It's like using a bandage to prevent an injury. Yes it's good to have, but it doesn't prevent anyone from writing unmanageable code. Contrary it can make it even easier to write unmaintainable code.

You can say that about literally any technology. Nobody's claiming TypeScript will fix all your problems and discover all the secrets of the universe: it's just a useful tool that well outweighs the overhead it adds.

you mean Python and Ruby like languages are unmaintainable and therefore deprecated? I rarely have a problem with maintainability in JS because of types, but I do have problems with poor constructs, poor readability, dependency issues and so on. It's a typical illusion of TS proponents that code becomes magically maintainable.

JS developers moving to TS should at least do a few weeks of Assembly and C programming to first understand the origin of types. I've spoken too many front-end devs who don't have a clue what a type actually is and at the same time promote TS. It's a godsend we don't need them in scripting languages. Use tooling to catch issues, that's the future, TS is just a whim.

Most developers coming new to JS are Java and C# developers. They want to keep their old tools, and methods. And Microsoft want to keep selling it to them. Which is my main concern, once you're in you are locked in.

Reply on news.ycombinator.com