61–70 of 120 posts
For any JS that is over 100 lines, I will use Typescript without thinking. This is 20% for bugs, and 80% for sanity in long term maintenance. Refactoring is so much better / safer when you have a compilation process and at a minimum, types. I just wish I could use Typescript without npm.
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.
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",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.
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 i…
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.
Before I tried Typescript I thought it was just another JS-precompiler... been there done that. I tried Coffeescript, the Closure Compiler, even LispyScript. In the end it wasn't really that much different to plain old JS, just with some syntactic sugar. But when I actually had to use it in a project, I instantly fell in love with it. Not only does it force me to think about the proper scope and type of a function or…
What about Typescript clicked for you that didn't click with the Closure Compiler?
But I'd say it simply has a different scope: The Closure Compiler takes a subset of Javascript and creates highly optimized code. It optimizes the execution, not the development workflow.
Typescript forces you to think differently about the implementation itself. While the CC also imposes constraints on types and checks them during compilation, in the end I really just wrote Javascript (and sometimes pretty messy one).
In the end, I don't think either technology can be a substitute for code quality. But for me, with Typescript its certainly easier to produce a better coding style.
My experience with TS is totally on the backend. The biggest issue with typescript, and the reason I'll probably never reach for it for another large project despite having used it for a 50k line+ project, is that it's still, at its core, javascript. We've experienced a tremendous amount of pain because of this. - We've needed libraries which don't provide typescript typings. Like a good little typescript user, we ha…
Why did you submit the types directly to them rather than to DefinitelyTyped? It's great when libraries maintain their own typings, but TypeScript handles the case where they don't really well.
>Express is a good example; you might have middleware which parses a bearer token and attaches it to the request. When the request hits the next middleware or request handler, its just a normal request. There's no way to assert at compile time that "this middleware came before, the request is now a new type with this extra field". Express, Apollo, the list goes on.
Yeah, this can be a pain. In situations like this, I've defined types like `type RequestWithAuthField = Request & {auth: AuthField};` and then in handlers that I knew came after the auth middleware, I'd immediately cast the request parameter to that type. It is an escape hatch and I'd prefer to not have to do that though.
>Further, the community around creating Typescript-native libraries is exceedingly small and, as far as I can tell, dying.
Besides that they're sure to avoid TypeScript-unfriendly APIs (unlike Express), I don't think there's much difference between a library with good type definitions and a TypeScript-native library. (Maybe the library could have bugs that it being authored in TypeScript would have avoided.)
I don't fully disagree with your points. There's a lot awkward about TS on the backend, but at the same time there's not much quite like it.
But if you’re in the position of deciding whether or not to use it, you should have a realistic understanding of both the benefits and the costs. Will it have a positive or negative impact? I strongly disagree. You can start using typescript without thinking for a second about what parts of it will be beneficial. Initially you can just run javascript through the typescript compiler and let type inference find some bu…
I don't know where this misconception started, but you can't just run javascript through a typescript compiler. There is a huge amount of valid javascript that is not valid typescript. Try something like `const testVar = {}; testVar.asdf = "asdf";`. Node web frameworks, for example, are based entirely off this ability to monkey-patch the request object.
Going beyond just adding annotations is not what the references study attempted to do.
Would I use Typescript for my own production use? Likely not. My perception is that it is yet another layer of complexity added to front-end development that, ultimately, does not need to be there.
Here's Eric Elliot, doing his Eric Elliot thing. Pages and pages of beautifully worded, perfectly structured arguments about absolutely nothing. And this month he's a Distributed Systems Expert. More power to this guy for building a brand for himself, but what a load of nonsense.
> Pages and pages of beautifully worded, perfectly structured arguments about absolutely nothing. I don't know Eric Elliot, but this sentence captures my perception of most "influencers" perfectly.
I'd rather someone that knows that their shit stinks for X number of reasons than one that thought theirs was a work of art. My favorite question to ask a mid to senior interviewee is what do they hate or what would they change about the framework, language, or technology that we're hiring for and why. If they're unable to answer that, yet they give dozens of reasons why they hate Java over C# or what-have-you then I usually assume they don't have enough experience or have pigeon-holed themselves into some specific task and will flail if you start to steer out of their comfort zone. Eric seems to have dug himself a very successful hole. Good for him, but I wouldn't trust him to work on a business application that's core to the monetary success of a company. I'm sure he makes great homepages though.
For any JS that is over 100 lines, I will use Typescript without thinking. This is 20% for bugs, and 80% for sanity in long term maintenance. Refactoring is so much better / safer when you have a compilation process and at a minimum, types. I just wish I could use Typescript without npm.
If you write 20% more bugs in pure JS you definitely should re-evaluate your skill. I'd never hire someone saying that to me.