by roberttod on 1/12/23, 8:03 PM with 443 comments
I want to skip over the static typing benefits argument, because I think it is well understood that static typing is a good thing and if we could bless JavaScript with a built-in and robust typing system then I don't think many people would be against that. My issue is with the amount of extra work it places on developers, much of it the "dumb" kind of work which can eat up hours and doesn't deliver all that much value.
i) Like a framework, you are at the whim of TS devs as it gets updated (edited)
For example, a new package you install can require a new TypesScript version. Once installed, you then may need to update your source code. This can place quite a high tax on the developer, where perhaps a 10 minute change becomes hours long.
ii) Libraries are badly documented
Most libraries do not document their types, or have no examples using TypeScript. Some worst offenders: Apollo, Protobufjs. The type definitions exported by these libraries can be large and complex, and the error messages emitted by TypeScript are so long and cryptic the result is often a drawn out process of trial and error along with trawling through source files.
iii) Error messages are hard to follow
Errors are long and don't provide enough detail. They will explain a type mismatch referencing many types you may not have ever seen, and are not documented anywhere. Except for simple errors, many of them are very hard to follow to a remedy.
iv) It requires yet more transpilation
Transpilation takes time, and always adds a burden to developers. I didn't mind so much with ES6 etc because eventually many functions were included in a broad set of browsers. There doesn't seem to be much progress including TypeScript in a browser, and feels like these complicated transpilation steps could be with us for a long time.
I could probably add more to this list, but my point is that I just can't see that TypeScript is worth all this time investment and making progress so slow sometimes. Are there others that come to this conclusion? I mainly see positive posts about TypeScript.
edit: I referred to TypeScript as a framework which it isn't. However it feels similar to me in that you are at the whim of TypeScript developers and how they decide to progress with the language.
by DanRosenwasser on 1/12/23, 10:11 PM
i. Dependency management is indeed frustrating. TypeScript doesn't create a new major version for every more-advanced check. In cases where inference might improve or new analyses are added, we run the risk of affecting existing builds. My best advice on this front is to lock to a specific minor version of TS.
ii. My anecdotal experience is that library documentation could indeed be better; however, that's been the case with JavaScript libraries regardless of types.
iii. Our error messages need to get better - I'm in full agreement with you. Often a concrete repro is a good way to get us thinking. Our error reporting system can often take shortcuts to provide a good error message when we recognize a pattern.
iv. Compilation can be a burden from tooling overhead. For the front-end, it is usually less of a pain since tools like esbuild and swc are making these so much faster and seamless (assuming you're bundling anyway - which is likely if you use npm). For a platform like Node.js, it is admittedly still a bit annoying. You can still use those tools, or you can even use TypeScript for type-checking `.js` files with JSDoc. Long-term, we've been investigating ways to bring type annotations to JavaScript itself and checked by TypeScript - but that might be years away.
I know that these points might not give you back the time you spent working on these issues - but maybe they'll help avoid the same frustrations in the future.
If you have any other thoughts or want to dig into specifics, feel free to reach out at Daniel <dot> MyLastName at Microsoft <dot-com>.
by CSMastermind on 1/13/23, 3:32 AM
Personally I've found that JavaScript lends better to a functional style of coding but there are no protections in the language to enforce this and both codebases I saw had a weird mismatched set of object oriented and functional style principals. Defined classes, prototypical inheritance, modifying the prototype chain directly, a factory pattern here, a weird "constructor" there, just figuring out the shape of the data was difficult to do.
The lack of guardrails in JavaScript also empowered people writing "clever" code which technically works but was insanely hard to parse and understand, especially when you're 20 function calls down a stack trying to understand what's happening.
I agree the TypeScript compiler's error messages are confusing but you should have see the types of stack traces JavaScript produces.
by satvikpendem on 1/12/23, 8:32 PM
If I take your question prima facie, then yes it's still worth it, since you seem to be dismissing the main reasons people use TypeScript, the static type benefits, and the bulk of your arguments seem to actually be about how TS can improve, not why one should throw out TS wholesale, which I personally would never do.
In other words, you're focusing on the 20% BS out of the 80% benefits. Can the 20% be improved? Of course, but I'll take 80% benefits over 0% with JS any day.
by bestest on 1/13/23, 8:18 AM
Too much overhead for me. I really dislike typing obvious things and boilerplate. Probably my fluency with JS is to blame. I don't need to see types and autocompletion. If I really need to — I just go to the source and inspect the source code, that is how I familiarise myself with the interface. I also think this makes one a better developer.
by chucklenorris on 1/12/23, 10:08 PM
by nforgerit on 1/13/23, 12:52 PM
1) Look up "this months current way of doing things"
2) have a couple of horrible hours wrestling with tooling and the module system
3) add a new feature, install 1 lib with 30 deps
4) figure out that one dep does not work with TS/the chosen module system/whatever versioning related thing
5) go for a walk. scream into the void. come back to the desk.
6) browse through dozens of Github issues to figure out what is going on
7) decide to fork the according dep knowing that I'll hate myself in 3 months
8) ...
Yeah, so I'm kind of missing the good old YOLO JS times w/o semi-colons and stuff. But I need to say that I'm usually not opting for NodeJS for deep "OOP-alike" Domains. I think NodeJS' sweet spot is infrastructural things, MQ Consumers, glue code or little http fetching/posting orchestration scripts. I never had too many issues without static typing because I intentionally kept things simple, had tests and rolled out updates consciously watching the ongoings.
by DiabloD3 on 1/13/23, 12:55 AM
Are you writing a brand-new codebase that needs to work on multiple platforms, and not exclusively in a browser? Don't use Typescript, use a language with native WASM support. This includes avoiding solutions that involve Electron, Deno, and CEF, as they are browsers, too.
Are you writing a brand-new codebase that only works in the browser? Learn how to use HTML and CSS correctly, avoid as much Javascript and Typescript as possible: Less is more.
Are you maintaining an existing codebase with extensive Javascript, and you are not willing to rewrite entirely Typescript? Try using Typescript, but you're better off jumping ship, nothing can save it now.
Any codebase that has untyped code in it, that cannot be compile-time analyzed for safety, that requires a significant client-side investment (ie, a giant blob sent to the browser), is kinda doomed to failure, and you will not realize the magnitude of your mistake until it is too late.
I realize my opinion is unpopular, as the programmers on HN seem to be a lot of front-end devs and a lot of "fullstack" devs, where the "full" is JS+TS in NodeJS, using some predefined popular NodeJS framework. I just want systems that are designed to minimize the BS, I've chased enough BS in my lifetime, TS can never deliver a no-BS system to me.
by genezeta on 1/12/23, 8:35 PM
But even so, I will say a couple of things about your arguments.
Regarding i), no, it's not a framework. But then again, I don't think that's what your argument expresses anyway. You seem to be saying "it's yet another dependency you need to keep up with". This would be correct and a valid argument. But it's unrelated with "being a framework" (which, again, it is not).
As for ii)... I'm afraid this argument could be valid for any large group you want to pick in software. Are you arguing JS libraries at large are better documented? Sounds highly dubious. From a different angle, is this a problem with the language itself or is it a problem with the libraries?
Finally, regarding iv), there is no "progress including TypeScript in a browser" and you should never have expected it. Not saying it will never happen because some person somewhere might do it, but you shouldn't expect it.
by dunno7456 on 1/13/23, 9:57 AM
The technology itself had few issues like compilation time and inability to run the application locally because of reasons.
The new systems were so complicated that everything ended in neverending bike shedding.
The people pushing for "everything to be written in typescript including other teams tooling (aka pulumi)" were very unflexible crowd.
The previous system had few issues that could be solved with database indices.
It's soul crushing to work on these type of places where technology is used for the sake of technology instead of bringing some business value.
by larsrc on 1/13/23, 7:56 AM
I have used plain JS, GWT, and TypeScript. TS is an incredible improvement over the two others. The TS type system is excellent, very expressive and helpful. An important advantage you get from static typing is that your IDE has more information to work with and so becomes more powerful. If you code in a text editor, you won't reap the full benefits, and you'll have to do more of the grunt work yourself.
by kitsunesoba on 1/12/23, 9:43 PM
by pontilanda on 1/13/23, 6:11 AM
If I change a signature, tests fail. If I pass junk data, tests fail. It's like invisible live tests and people forget this.
As in the other recent discussion, yeah, you can live without tests and you can live in JS-land. Whether it's worth it it depends on you. TS and traditional testing lets me ship updates without even opening node or the browser.
by eitland on 1/13/23, 10:55 AM
It is worth it if you want me on the team. I refuse to work with anyone who throws out TS for JS in 2023.
Slightly longer answer:
I have said a number of times
"Javascript is a simple version of Java in the same way as a bike with one wheel is a simpler version of an ordinary bike."
If anybody suggest to use Javascript today I won't take them seriously.
i) I have used Typeescript since 2017. For some reason I don't have these problems and never had.
ii) Yes, some libraries are poorly documented, that is for me a reason to prove why I am a software engineer by either figuring it out, complain until they fix it or even better use my gut feeling and use some libraries that aren't stuck 10 years ago.
iii) Error messages can be hard, but compared to debugging the mess that happens without typing it isn't hard at all.
iv) Have someone look at your project setup.
And before someone says I don't know Javascript: I wrote my first javascript application (OK ECMAScript since it was in Adobes SVG plugin), which was a working map, dynamically updated based on GPS position, back in the spring of 2005, that is half a year or so before Google Maps and years before most people took Javascript seriously so I should be qualified to have opinings. Yes, it wasn't production quality, but I built the logic more or less alone in 5 months in between other school work.
by faefox on 1/13/23, 6:03 AM
FWIW I can't recall the last time I reached for a 3rd-party library and found that it was lacking types. The DefinitelyTyped project has really done a remarkable job expanding type coverage. And even in that rare case where you might need to add type definitions yourself it's simple enough to do so.
There's a ton of room for improvement around error messages, no argument there. The TS team is very much aware of this and they're working on it but it'll take time.
by andrewstuart on 1/13/23, 5:08 AM
Too much time is spend fighting TypeScript as opposed to writing application code.
I have a question for the language experts out there .... why is TypeScript getting so complex? Are other strongly typed languages this complex? Or does the complexity arise from trying to overlay typing on JavaScript which is an incredibly dynamic language?
And if it is the case that TypeScript's complexity keeps going up because essentially "strongly typed JavaScript" is a hack, then should we all be moving to a much simpler strongly typed language that compiles to WASM, and yet still richly interfaces with the DOM and browser APIs?
Does TypeScript just have to keep getting ever and ever more complex and detailed - is that the unavoidable future?
by llanowarelves on 1/12/23, 9:36 PM
Most of your (pretty good actually) critique are points to make the least-bad way of doing JavaScript even better, and I'd agree could be improved.
Others have taken notice.
"Native support" of TypeScript is done by Deno. And tight TypeScript (and other adjacent tooling) integrations with VS Code and WebStorm.
And transpilation is being worked on by various builders. Stripping types and running through esbuild or swc is fast. For typechecking part, was a proposal to have TypeScript be rewritten in Rust for performance.
We can lament that JavaScript went from being a web document enhancer to being shoehorned into a full application compilation toolchain, but the old Jquery thru Expressjs era of doing things has significant drawbacks for full sized applications/APIs/etc.
by 8n4vidtmkvmk on 1/13/23, 7:16 AM
I just try to type things 90% of the way, until it's good enough, and slap an `as` in there if I get too annoyed or it takes too long to fix. Don't even care. It doesn't put me in a worse spot than JS would have.
Getting completions on all my giant objects is wonderful.
by apatheticonion on 1/13/23, 10:23 AM
In my opinion, TypeScript is not only essential in the context of any professional project, but it features one of the most ergonomic type systems I have ever worked with.
There are certainly pain points with certain TypeScript features (e.g. enums) but any project that takes me longer than 5 minutes to write, I need type checking. If I can't be bothered with setting up tsc - and setup difficulty is a valid criticism - I just use jsdoc.
I have seen TypeScript take the heat when applied to JavaScript projects that implement multiple trendy programming paradigms. Often times the projects themselves are so complex that adding a type system requires type-kungfu. It's not the type system at fault - but a needlessly complex architecture.
Love TypeScript. Wish there was anything like it that compiled down to static binaries.
by tmpfile on 1/13/23, 5:07 AM
Typescript, as the name implies, adds types to your script. If you don’t see the benefits of types then typescript may not be for you.
> My issue is with the amount of extra work it places on developers… and doesn't deliver all that much value.
If you think adding types doesn't add much value then typescript may not be for you. In my experience, types are defined once then provide a lifetime of value.
> you are at the whim of TypeScript developers and how they decide to progress with the language.
This is true of any library, programming language, operating system, hardware, etc. But adding types isn’t somewhere I’d worry about backward compatibility being broken. All the newer versions of typescript are backward compatible. If you have a library that requires a newer version of ts then upgrading ts won’t break anything dependent on earlier versions.
by mejutoco on 1/13/23, 8:17 AM
This is one of the eternal complains about type safety, somehow mitigated by type inference. I believe it is totally worth it in the case of Typescript.
> i) Like a framework, you are at the whim of TS devs as it gets updated (edited)
As a language, it has proven quite stable. Even if development stopped tomorrow you could keep the current version forever.
> ii) Libraries are badly documented
It is inconvenient but, since they are js libraries, they are compatible. You do not need specific ts examples, although it is extra nice.
> iii) Error messages are hard to follow
Did not run into this issue myself but fair enough.
> iv) It requires yet more transpilation
tsc compiles ts into js. Depending on what you use, you could get rid of webpack etc. and just use tsc.
In summary, for me Typescript is totally worth it. All this lost time you mention is different from the lost time adapting to x framework or y packer update, since it reduces errors down the line. It might feel like it is slowing you down, but you can always use any for certain modules and type things at the interface. It is still your decision what to type, the language gives you the tools to do so.
by LASR on 1/12/23, 9:40 PM
Even within the same project, there are times when I don't want typechecking - when I am prototyping something out and want to move fast.
And there are other times, when I want typechecking - when I am finalizing a feature implementation or doing integration with existing logic etc.
It's not a framework. It definitely is a language in its own right.
But from personal experience, the group productivity goes way up with larger codebases with many ICs working on it. Unit tests become type checks. It opens up a lot of extra bandwidth for more sophisticated functionality or better tests.
Solo IC, working on a small project, with no intention of ever writing tests - you might see TS be an overhead.
To sum up, your requirements decide whether it's worth it.
by confidantlake on 1/13/23, 1:43 AM
by fergie on 1/13/23, 10:48 AM
There is a good argument for using types (and also a good argument for not doing so). If the argument for wins out, then types will be included in the native js spec and the need for TypeScript will disappear. If the argument against wins, then TypeScript will also disappear.
If TypeScript really floats your boat then by all means use it, but treat it for what it is- a hairy dependency that only a minority of developers love or need.
by fedeb95 on 1/13/23, 7:48 AM
by tobyhinloopen on 1/13/23, 8:39 AM
Lately I've been using Typescript's JSDoc comments just so I don't have to deal with transpiling code but still get most of the advantages like editor autocomplete and warnings.
by ozten on 1/12/23, 8:58 PM
by brundolf on 1/12/23, 8:54 PM
by vlod on 1/13/23, 8:31 PM
I've used static langs like Java and GoLang and prefer them over TS. Heck I even like ruby-rails more. Since I'm fullstack (TS on FE/BE), it's hard to move 100% away from TS (becz a use React) and it irks me how everything has changed the last 10 years of so.
I am a seasoned developer and can code (in JS) extremely fast, clean and performant. With sufficient test coverage you can go a long way. Of course if you use TS and change something important, the compiler will tell you all the places you have to refactor. This is super useful.
However in my experience with a fair amount of TS codebases, there has been a tendency for devs to use as many clever TS features of possible (e.g. utility classes and generating crazy generic types from multiple types). I detest this style of programming, becz when you have to can't get something to work, it's a pain to try and understand the errors. This also extends to TS enabled libraries which can be challenging when you try and do something non-standard.
I burn time trying to understand the errors and getting TS out of my way, so I can get on with the task at hand. I find cases that if you look at the logic I've written, there's not a chance that something can be undefined and yet I have to wrap code in "if's" just to satisfy the compiler.
Even though I have a ton of experience, I deliberately code for that junior devs can understand/debug/work-with or the support engineer who just got woke up and trying to fix prod, which in my experience, isn't a common approach anymore. This is part of the problem IMHO.
Most devs I talk to are using TS as their first language and have mostly never experienced the joy (and lack of safety, I grant you) of dynamic/non-typed languages (e.g. ruby/lisp). Get a lisp-er to do TS and start hearing the flood of swear words. lol.
Of course, I understand the benefits of TS, but for me at least there's no joy in it and that's one of the reasons I got in this game in the first place.
by d357r0y3r on 1/13/23, 4:05 AM
Hard pass.
by azangru on 1/12/23, 9:55 PM
Me, I love typescript. It's an extra reassurance that my code will probably work correctly — and even though it isn't as trustworthy as Elm, Haskell, or Purescript, it's better than nothing. It is a good pair programmer who has many times saved me from stupid mistakes I made while writing code. And it holds my hand while I am refactoring — I would be scared to do that in a javascript codebase. Tests would help with refactoring, of course; but they aren't as exhaustive as a static type checker is.
by datasert on 1/13/23, 4:48 AM
Typescript has bunch of "clever" things but you don't have to use it. We probably use 30-40% of TS features and that is more than sufficient for us. With that said, here is what I think about your questions.
1. Agree, and it is not any better without TS either. In case, a library is not compiling with your TS version, we ignore the error, put a FIXME there and remove the "ignore" sometime later
2. Yes but that is not TS problem. Without TS it is even worse.
3. Agree sometimes, we get so complicated errors. We search around and see if any smart people have figured what that means. If not, ignore and move on with a FIXME
4. Since many years, we are not writing any JS which doesn't need transpiling. If not TS, you would be using babbel or some other tool most of the time anyways so we haven't this to be an issue.
by paxys on 1/13/23, 3:22 AM
#2 – If libraries haven't published types, just use them as pure JavaScript (which is what you would have done anyways). Lack of documentation again applies to both JS and TS equally.
#3 – I assume you are talking about compiler errors? I have personally found them to be simple to understand, especially when the exact location is highlighted in your IDE. At runtime there will be no difference since it is all the same JS code under the hood.
#4 – Yes transpilation takes non-zero time. TypeScript has a lot of tooling around incremental compile/watching for changes, so I don't think it should really be that much of a burden during development. I have worked on massive TS projects and don't even notice the compile task running in the background.
I find this post weird because TypeScript does have some real drawbacks – overly complex type system, makes the codebase more verbose, false sense of security (no runtime type mismatch errors), mix of typed and untyped code in codebase etc., but your reasons for disliking it all seem superficial and easy to overcome.
In my personal opinion everyone should be starting new JS projects in strict-mode TypeScript by default unless there is a reason not to.
by logicalmonster on 1/12/23, 8:14 PM
Personally speaking, I'd say that adding another layer of abstraction onto your stack shouldn't be a dogmatic thing that you just reflexively do without considering the actual needs of a particular project. TypeScript offers some benefits for certain types of complex projects, but also some costs and problems that might not be worth dealing with for certain projects.
It's a little bit like GraphQL in a sense. That's a phenomenal idea...for a product like Facebook...but probably not actually needed for every single project.
by hussainbilal on 1/13/23, 1:48 PM
- WebAssembley (which other, controversially better or at least more adopted languages also target)
- Javascript's spec. is not time invariant (https://github.com/tc39/proposals#readme)
- Typescript isn't the best solution (There are better less adopted solutions providing types, like Elm, Rescript, or Purescript)
For Javascript, the real solution is hygienic macros and contracts, but because `eval()` can't get no love or safety on the browser side, everyone on the server-side has to suffer.
Ironically, introducing a fake compilation step where Javascript transpiles to Javascript (not like babel.js which targets older JS, but literally just the same lang spec) is the way to side step the `eval()` problem, lol! (expanding those `eval()` in a fake compile step)
by bborud on 1/13/23, 12:53 PM
JS is a garbage language. You need only look at identity or all the stupid asymmetries in the language to realize it isn't a well designed language. TS tries to fix that, and good job for doing that, but you can't escape the fact that it is desperately trying to fix a pig with lipstick, botox and hold-in pantyhose.
by jacquesm on 1/13/23, 11:02 AM
It also means there is no 'development environment' as such, it's just a repo on gitlab that anybody can read, fork and contribute to from within gitlab if they want.
I have also tried to keep the number of dependencies to an absolute minimum, which also helped to make something that doesn't feel like a moving target.
by vagrantJin on 1/13/23, 1:30 PM
Js is a shovel. Simple. Does its thing. Digs dirt in our quest for gold.
TS is like adding a two stroke petrol engine so the shovel vibrates up and down. Loud, jerky, difficult to handle.
A sane person looking in would wonder why not just buy a jackhammer(java/c#)? Or use an excavator(Rust/C++)?
Why is it neccesary to attach an engine to a shovel?
by jillesvangurp on 1/13/23, 8:44 AM
Regarding your points:
I) this is indeed endemic in the javascript world. I would not blame typescript for this. I work with Java and Kotlin a lot. Things are more stable there. Five years is short for compatibility. In the js world, six months is long.
II) The typescript annotations are documentation too. They help your IDE figure out what is what and enable things like autocomplete. The original js code probably isn't a whole lot better. Also, lots of libraries are developed in typescript these days.
III) That's what happens in weakly typed and highly asynchronous environments. Pure javascript just moves that burden to runtime. Better to deal with it before you deploy your code.
IV) Most modern javascript is transpiled. It's a compilation target at this point. So you might as well make full use of the fact that there is a compilation step. The packaging and minification is actually just as bad.
by bborud on 1/13/23, 12:44 PM
- chaotic and baroque layers of tooling that need to be figured out and made to keep working
- a software tradition where poorly thought out ideas are implemented with vigor resulting in design by accident
- ...which then results in frequent rewrites
- a universe of low quality libraries and frameworks resulting in frequent discovery of serious bugs
- every project having lots and lots of dependencies
And that's before we even consider the language or the congenital defects inherited from JavaScript.
by thadt on 1/12/23, 9:59 PM
Sure, dealing with TypeScript can be a hassle, but it is less hassle than dealing with broken software.
by pipeline_peak on 1/13/23, 4:47 AM
I haven’t used JS professionally so maybe I don’t know any better, but I think dynamic typing should be embraced. There are A LOT of applications where you really don’t need to worry about types. And from my experience working with app/cloud code bases in C#, I’ve seen a lot of ugly classes that I can’t touch simply because they were written 10 years ago and I don’t trust them. My guess is the web world is plagued with all sorts of old code you don’t want to touch, I don’t think TypeScript solves that with static OOP.
I think the prototype based OOP approach in JS is better because you don’t have to concern yourself with all these hierarchies. You can have multiple car object definitions with dynamic typing, it doesn’t matter because it’s all about what’s being used in the moment. In static typing we expect a single concrete definition to be extended, composited, and reused in an intricate way. That way never works because what is defined today as “just the bare minimum” mutates into something larger and now everything inherited “needs” it too. But they don’t always truly need it, they just have to satisfy some argument. And of course that “single” definition gets duplicated across the code bases anyway. Initially we think of these approaches as elegant, but it almost always rots in its own hierarchal casket.
Dynamic typing allows cleaner OOP and its approach is more honest. “I need a representation of this abstract type right now”, not that type and a whole bunch of other crap that it’s fundamentally forced into bringing along for the ride.
by bern4444 on 1/12/23, 9:23 PM
ii) Lots of libraries are extremely well documented and typed. This is the same in any language not just for types but also for docs, capability, perf etc. This argument applies to all software everywhere so it doesn't make sense to single out TS
iii) Error messages can sometimes be hard to follow. But you get better at parsing them very quickly when they get gnarly.
iv) Transpilation is nearly always a required step anyway. Adding TS support is minimal. There are plenty of tools that do TS to JS on an order of magnitude of MS.
All decisions are tradeoffs.
What benefits does it bring (ignoring the biggest one of them all)?
TS makes it easier to maintain software across large teams by providing a mechanism to express relationships in a codebase.
They are self documenting and replace a lot of JSDoc needs (letting you focus docs on more useful info like intent, design choices, example usage, etc).
Types can also replace the majority of unit tests validating code is correct saving time on running fewer unit tests and letting devs focus on integration tests.
Lastly, I've never seen or experienced something breaking from upgrading the Typescript version in a project. Even when a TS upgrade has 'breaking changes' they never actually break anything in practice that I've seen.
by edwincoronado on 1/12/23, 9:46 PM
by typescriptfan on 1/12/23, 8:36 PM
> For example, a new package you install can require a new TypesScript version. Once installed, you then may need to update your source code. This can place quite a high tax on the developer, where perhaps a 10 minute change becomes hours long.
No. It's a language compiler. You can upgrade it safely without changing a single line in your codebase. If there is a breaking change (sometimes, regarding the strictness) there's also a configuration option that lets you keep the previous behavior.
> ii) Libraries are badly documented
And so you're going to lose any and all typing as your solution? I don't understand. Undocumented but typed >>> undocumented and untyped.
> iii) Error messages are hard to follow
I disagree completely, TypeScript has helped me many times to understand what's happening and why - I mean errors that I wasn't aware of in my previously untyped JS codebase.
> iv) It requires yet more transpilation
> Transpilation takes time, and always adds a burden to developers.
Doesn't matter. Use SWC or esbuild for sub-100ms compilation times. Your CI is a long running job due to tests and lint anyways. Nobody is writing pure uncompiled JS these days - you can't use NPM libraries that way, so there's always some (Web)pack step. I haven't seen a single developer who liked having to care about browser versions and wants to go back to that - but if you add a compilation step you get that for free and can write the latest and greatest.
by danielEM on 1/13/23, 8:54 AM
1. It is worth it, but not as much for benefit of types safety straight forward as for ... "intellisense" that discharge you from remembering stuff and misspelling it
2. It is annoying - they (MS/TS team) have very "conservative" approach which leads to:
- no operators overloading,
- no option to extend primitive types,
- no option to get info about your types at transpile time,
- no built in options to improve performance at transplantation time,
- no built in options for transformation plugins
- no other than JS transpilation targets
- need of tons of other tools to make your actual target,
- ... etc.
Sorry for being a bit grumpy, but sometimes it feels like wasting a life working with TS. ;-) (especially when I read again what I just wrote ;-) )
Seriously, let me know MS/TS team if you need someone to drive to TS some real fresh new value ;-)
by alixanderwang on 1/12/23, 9:58 PM
by xigoi on 1/13/23, 12:56 PM
by jpgvm on 1/12/23, 9:34 PM
The best choice however is to simply use a better ecosystem entirely.
IMO JVM+Kotlin is great general purpose combo, Rust is good if you don't write the sort of code that needs GC'd structures, etc. Between those two I rarely need to consider anything else.
by topherPedersen on 1/12/23, 9:35 PM
by rattray on 1/13/23, 5:28 AM
There are a lot of cases where it's totally reasonable/rational and honestly fairly safe to just throw in a well-scoped "any" cast, a `// @ts-expect-error` comment, etc.
If you know what you're trying to do, and TS isn't understanding, sometimes it's just a lot more expedient to tell it to shut up and listen to you.
Of course, sometimes you're wrong, and you don't want unsafety to leak, so it does require a fair amount of experience and judgement to do responsibly.
by sinenomine on 1/12/23, 8:58 PM
Late-binding dynamically typed languages are underrated, if you can hold the mental picture of types in tour working memory, that is.
by mauro_c8 on 1/13/23, 3:54 AM
by zekenie on 1/12/23, 9:35 PM
Typescript is a wonderful tool for many situations. Typescript may not be needed for all situations. There's upfront cost to configuration and tooling. But you get type safety and automatic documentation.
In all my new non-trivial projects, I default to typescript. It has caught so many issues and saved me a lot of time. Not having it feels like driving without a rear-view mirror. But, if I'm just writing a little script, I might omit it.
by _gabe_ on 1/13/23, 4:43 AM
iii) You should see C++ template errors if you think the TS errors are bad. The TS errors do suck sometimes, but when I see which line of code it's complaining about, it's usually enough to clue me in to what the problem is. And once again, ts-ignore exists for a reason ;)
iv) The majority of the frameworks I use allow you to skip transpilation while developing. So you can supply the TS files directly, and then transpile when you're done.
TS has some problems sure, but these all seem like very surface level complaints that you have to deal with in any other language. Which language has dependency management solved? Or clear and concise error messages all the time? Or super fast compile times? I don't see any alternatives that don't host some or most of all of these warts.
Additionally, when I code using Javascript I feel like I'm blindly groping my way through the magical forest of dynamic code. Typescript gives me a clear and concise road map and helps me avoid a lot of traps laying around that are obscured by that dynamic magic.
Is typescript worth it? 100% yes.
by syspec on 1/13/23, 4:13 PM
It requires so much mental effort to understand what's going on
by brailsafe on 1/13/23, 12:51 AM
by fennecfoxy on 1/16/23, 4:05 PM
There are a few quibbles with TS devs over not implementing certain ideas because it breaks out of the JS superset paradigm, which really makes me wish we had a TS++ or TS# that broke this on purpose but hey.
It does have a lot of problems, but it usually comes down to pre-existing ones. i: yup but like, isn't that true of every framework/language/library? But less so for TS given that it's open source
ii: this is the JS ecosystem in a nutshell, but I think you'll find with any similarly sized ecosystem, built from the thankless efforts of a bunch of amazing individuals in the community that this is true. If you want Oracle level support/docu you gotta pay big $$$ for it
iii: this is very true and my advice to other devs I work with is usually to read more towards the bottom of the error. TS currently gives you a lot of context for the error, much of which may be but isn't always useful.
iv: realistically we have been waiting for a very long time for node.js/browsers to be able to run TS natively. I would be a huge fan of this. Transpilation on large projects can take a good amount of time, but I'd say the larger the project the _better_ the advantage you will have using TS; sure you'll have to deal with trans times but TS can really save your butt when making a breaking change in a large project.
I've used Node.JS pretty much my whole career, whilst I've done a lot of stuff in C# and C/embedded as well my mainstay has been Node & JS and as soon as I could use it, TS.
I remember callback hell, I remember adding console logs every few lines to figure out what the fuck is going on, I remember sitting in the debugger trying to make sense of why various vaguely connected chunks of code weren't working properly. I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain.
by steve_adams_86 on 1/13/23, 4:32 AM
On the backend it can be nice if you’ve got a monorepo including the front ends it supports. Maybe you’ve got graphql happening and you can share types. That seems great sometimes, and there are cases where it’s super handy and efficient.
I don’t know for sure, but it doesn’t seem worth it after a certain point. I’d much rather keep typescript to the front end where I find it really shines. I’ve worked on a lot of projects where it was full stack typescript and there were always these common, nagging, very typescript-and-JavaScript-specific problems.
Fundamentally the build and development tool chains in general tend to be awful. I can accept it on the front end out of necessity, but on the back end it gets egregious quickly unless you’re using micro services and builds stay quick by default.
Any time I work on something statically typed with nice tooling I realize how much better life can be. It feels like the minor gains I get from fullstack TS are quickly negated by the plethora of advantages to using something like Go or Rust where I can purpose-build applications with absolutely crazy performance, reliability, and portability.
So, TS in the browser is awesome. I think you’d be crazy not to. On the backend on the other hand — unless you’ve got like a perfect fit for using something like Next.js or a static site generator where the backend can be dead simple, I’m pretty tired of dealing with its deficiencies.
And even then it’s not the language so much as the cruft built up in tooling over the years. It’s slow and awkward. NPM is plain old awful. Basics like linting are painfully slow. Testing libraries feel like a house of cards. And so on.
by nack_jickolson on 1/13/23, 11:35 AM
In my company we built a lot of web apps in very small teams (mostly just 2 people). We use mostly c# as a backend and typescript + mostly angular, sometimes react as a frontend. When typescript came out I built a conversion utility that allows me to generate typescript definitions and metadata from my c# type definitions. In angular I built my own type safe reactive forms, access control and API framework. Often we use ef core as a database layer on the backend, so we have a single source of truth (the c# types) for database and frontend types for the API. I use mapped types in typescript a lot to reuse the generated API types in my frontend code. If a field in a class is renamed ef core takes care of the database migration. On the frontend I get notified of every error because of the rename. Is there a table column for the field, I get an error. Is there a form that maps to the field I get an error. Do I check for write permissions of the field with the old name somewhere, I get an error. I use exhaustive matching to ensure that all cases of enums or union types in general are handled. Everything is type safe and the types come from a single source of truth.
It's so insanely productive it feels like magic!
Edit: also wanted to add I mostly do not use libraries outside of framework libs for angular or react in my frontend. Generally most library code I need (with few exceptions) is built by myself rather fast and easily. I avoid libraries because of the npm ecosystem mess but it also has the upside that I don't have problems with outdated type declarations or typescript incompatibilities.
by adminu on 1/13/23, 9:19 AM
Anecdotal evidence from my Haskell experience: If my Haskell programs compiled, they usually worked. Which is amazing. Powerful types for the win.
by heresjohnny on 1/12/23, 10:04 PM
I no longer have to worry about things unknowingly becoming undefined or falsey.
When chaining map, filter, and reduce, I know at every step of the way what kind of object I’m working with.
And when I use a dependency, I don’t have to trust possibly outdated documentation but can rely on types.
Just these three things make it 100% worth it for me.
by jmull on 1/13/23, 1:13 PM
You started by skipping over the benefit of static type checking, but that's the direct trade-off: is that benefit worth the extra complexity and time spent satisfying the compiler. For me it's probably usually yes for smaller projects where I know the devs can handle it and definitely yes for larger projects where the communication burden is high (it just partially helps people stay on the rails, organized, and on the same page -- not sufficient by any means, but it eases the strain).
by Sevii on 1/13/23, 2:53 PM
I've been using typescript for a year now and I just want to go back to Java at this point. Biggest obstacle to that is management believe it or not.
by throwaway0asd on 1/13/23, 8:09 AM
I have been using TypeScript for almost 6 years and not experienced this problem. Like everything else keep things simple, don’t chase trends, and so long as do right by your product everything will be smooth. I also don’t waste time with large SPA frameworks.
> ii) Libraries are badly documented
I don’t use many dependencies. The DOM and Node type definitions are extremely well documented and inspired me to write better documentation.
> iii) Error messages are hard to follow
For me this depends on the complexity of a given object or type definition. When things are primitive the error messages are more clear. My only suggestion is to keep your interfaces primitive.
> iv) It requires yet more transpilation
I use SWC as a TypeScript stripper. My nearly 50kloc project takes about 2seconds to covert to JS, which pushes out my total build time to about 2.5seconds.
by Tade0 on 1/12/23, 10:43 PM
People who've always programmed in traditional statically typed languages like Java scratch their heads on why would anyone not want to have static typing, but the reason for that is simple: in a dynamically typed language you can (and often do) produce code that's hard or impossible to type in said statically typed languages.
TypeScript's designers recognized this, so not only there are escape hatches here and there, but also the type system over time evolved to adapt to the real-life use cases instead of imposing some abstract, complex type system which might not even be very useful when used against all the creative ways JS programmers write their code.
And it works.
by jokethrowaway on 1/13/23, 7:40 AM
I still use TS on frontend (as frontend framework in rust are not quite there yet when compared to something like solid start - perseus is getting there though) but I definitely use any freely when I'm in a hurry.
That's exactly what I don't like about TS: it enables developer to bypass safety making the whole thing not very safe. You can't trust your dependencies as you normally do with Rust (unless your dependencies specifically opt out with unsafe - there is still deps vetting needed, but it really hasn't been a problem).
Is it worth it? Before swc I would say no, with swc (typescript compiler written in Rust) the perf hit and DX is not too bad and I'd say yes.
by xiphias2 on 1/12/23, 9:37 PM
by nl on 1/13/23, 2:49 AM
To me, install a new package and it requires "target=ESNext" and modules="ES2022" and suddenly I feel like I'm back in the Python 2 to Python 3 transition debacle.
Except this happens every couple of weeks!
by tluyben2 on 1/13/23, 5:19 AM
We definitely are happy with the move. I will never be a fan, but the alternatives I cannot sell to the team.
by cesaref on 1/13/23, 8:34 AM
The question should really be, are the development pains you have more or less than the (most likely) production pains you'd see if you weren't using it?
I personally believe that more problems in development for reduced production outages is the right answer for the vast majority of software development.
If would be interesting to know of cases where projects have stepped away from it. I'm sure there are some examples and it would be interesting to understand their reasoning.
by MaxArt2501 on 1/16/23, 11:09 AM
Let's see the others.
ii) It's true that many libraries don't have type definitions, but the most used ones have an externally-maintained corresponding @types/### package that solves the problem. And even if they don't, how is it the fault of TS? The alternative is no type documentation at all - is that better for you?
iii) Yes, error messages are something that can be improved, but then again, the alternative is no static error and eventually an even more laconic runtime error. Would that be better? At least, TS catches that there's a problem before you run the code.
iv) Compilation adds a burden to the CPU, not the developer. But anyway, it's a one-time process, and unless it takes 30 minutes it shouldn't be a problem. There are new, much faster compilers nowadays, like esbuild and SWC, plus other tooling tricks like module caching, that makes your local development almost feel like there's no compilation at all.
I won't discuss the merits of the adoption of TypeScript. Since I started using it - except for very simple projects - I always felt like I'd be way less productive without it. And I actually had the confirm recently, when I had to work on a Loopback@3 BE that somehow is in JavaScript (even though Loopback 3 does support TS).
It's been a mess. Trying to understand the models, the signature and the sense of all the entities has been a nightmare. The documentation for LB v3 is badly maintained and sometimes broken, and this adds even more difficulty. Some dev tried to add some JSDoc info here and there, but it's not nearly sufficient to understand what's going on without investing hours of study of the existing code.
This is part of the cause that prevented the team to upgrade to LB@4, so much that I even suggested to redo the BE altogether in Nest (save for the core business logic parts), rather than trying to make a sense of it.
So yeah, I'll stick to TS for the foreseeable future, and strongly suggest all the teams I'm going to work with to do the same.
by shagymoe on 1/13/23, 5:25 PM
by forty on 1/13/23, 8:08 AM
Update TS regularly to avoid making updates hard and lagging behind to much. Unlike a runtime framework, updates are unlikely to break things at runtime, so there are no reason not to update very often. If some external types are wrong or annoying, don't forget _any_ exists and simply brings you back to the crappy situation you'd have without TS (well admittedly it adds transpilation costs, but it's still type checking everything else, which is well worth it).
I think TS is nearly the best language that could be done given the constraints of being fully compatible with JS.
by sebastianconcpt on 1/13/23, 11:25 AM
I feel that using it optionally where it's easier to maintain and feel its value is the best of both worlds.
by majestic5762 on 1/13/23, 12:04 PM
by 8note on 1/13/23, 12:10 AM
Understanding the type mismatch is ofter difficult, but it does solve a real problem.
I also like that it gives escape hatches, for when I know what the type should look like, or I don't care what it looks like
I haven't found the typescript updates to be difficult, nor situations where packages I'm depend on require incompatible typescript versions
My pains are on that it's hard to get the setup right where you aren't depending on a giant set of types packages, giving you size bloat for things you mostly don't care about.
by commitpizza on 1/13/23, 9:13 AM
If you have a larger team, yes it is worth it. If it is your side project or if you are like 2 people working on a project then I would say it's probably not worth it.
Typescripts biggest strength is that it's easier to work several people on the same thing. When someone else makes a change, it's easier to figure out what their code does.
The bigger the team and project, the bigger benefits you will get from typescript. At least, that is my opinion.
by abalashov on 1/13/23, 12:23 PM
It's also way too complicated for what it is. To the extent static typing is beneficial, most developers and projects only need the bottom 30% or so, but the expansive - and expanding - feature set encourages byzantine solutions, especially for showy types for whom tight little chunks of terse syntactic cleverness are an aesthetic (I've been there, I get it). And as if JS build tooling wasn't unnecessarily overcomplicated already, let's pile on a bunch of transpilation infrastructure?
Now, I still use TS, having sensed that it's where the centre of gravity was moving as far as JS developer fashions. Plus, of course it's not bad to have types in the language in a rudimentary sense. Sure, why not? Moreover, I try to pick technologies that I could hire someone else to work on or collaborate with me on in the future, and TS is definitely "in". There were subtle nudges from other areas; I'm a very heavy Vue user, and Vue 3.x certainly doesn't mandate TypeScript, but let's be real; they want you to use TypeScript.
I make a point of using as few "clever features" as possible; 90% of my uses are banally simple interfaces. I think I did foray once into `Map<Partial<keyof RTCSessionEventMap>, RTCSessionEventMap[keyof RTCSessionEventMap]>`, and it's not at all clear that this got me anything. But it looks cool, doesn't it? I guess that's what leads TS-heavy developers to churn out impenetrable gobbledygook. I'm quite capable of not typoing my own key names. Why are we so fixated on abstruse manipulations of arbitrary contrivances that get transpiled away anyway? I suppose you could ask the same question about any high-level programming language insofar as it ends up machine code in the end, but TypeScript's complexity doesn't reflect an appropriate humility for its place high up the meta-hierarchy. You need to be an actual programming language to ride this ride; as a fancy templating system, it's too entitled with its massive cognitive demands.
I'm not going to say there's nothing good about TS. I do appreciate the ability to inspect type definitions to learn more about how a library works, especially if they have crappy documentation--which is often. Naturally, I also pocket the benefits that type definitions afford to IDE autocomplete. But on the whole, it's a drag on my productivity, and I spend an awful lot of time either struggling to decipher someone else's TypeScript or paying some sort of tribute to the exacting and mercurial TS compiler gods. I'm not writing better or error-free code because of it. Good end-to-end testing is a check on my code quality; the ever-so-occasional squiggle in the IDE is not.
Related thought: "type safety" has become some sort of metaphysical fixture, an unfalsifiable theory of quality and robustness. "I'm so glad I have type safety!" is a liturgical or ritualistic statement, the kind that nobody in their right mind would question, or attempt to unpack or otherwise anatomise. It's a self-evident, ipso facto good. Types in JavaScript seem to have become a religious totem object. This oft-posited but seldom materialised correlation between "types" and "quality" remains to be illuminated for me. My background is entirely in statically typed languages (C above all else), so I understand the argument and need no convincing that types are good, and even elegant. However, I can assure you I wrote plenty of buggy code in C, C++, Go, Java...
It reminds me a bit of the apex of the TDD hypermania about "refactoring with confidence", or specifically, the naive and childlike optimism of "now that I have unit tests, I can refactor with confidence!" Can you? That depends on many things, doesn't it? Truly, how could it not? And either way, an overabundance of confidence owing to some platitudinal methodology is generally not a great vantage point to bring to engineering. Humbleness about breaking things keeps satellites in the sky, not euphoric, LSD-fuelled campfire paeans to TDD, and certainly not the mere presence of types. </rant>
by Shish2k on 1/13/23, 1:05 PM
What’s the alternative? If you make a type error in TS you get a cryptic error[0], but if you make a type error in JS you get a bug which you learn about after it crashes prod…
[0] Personally I rarely get cryptic errors, because I go out of my way to design libraries in a way that the type definitions are kept simple, which also has the benefit of keeping the mental model of how the library works simple ;)
by the42thdoctor on 1/13/23, 11:13 AM
by ioulian on 1/13/23, 8:57 AM
Since then, I can't image working without TS. As for Third Party libraries, I have a different experience from other devs here, it works very well for most (if not all) big libraries/frameworks, and the autocomplete saves me so much time in digging in the docs.
by sureglymop on 1/13/23, 8:52 AM
- You want to use a third party library but it is completely untyped - You need an object but you're just prototyping it. You don't yet know which keys will be optional - You type a key of one of your objects. Now you load or fetch data from an API and want to assign that to it. But typescript complains because the promise can also return undefined. - and many more
Just be aware that it will annoy you at times.
by difosfor on 1/12/23, 10:11 PM
by franky47 on 1/13/23, 12:00 PM
ii) You could argue that types themselves can be documentation, if named correctly. A JS library without types but great documentation is vulnerable to implementation changes that are not reflected in the documentation. TypeScript at least binds the internal assumptions on function arguments and object types to how they should be used, with a tool to check that there is a match at the call site. Throw in some runtime parsers (eg: Zod) to enforce correct input data at runtime, and from which types are inferred, and you are golden.
iii) Agreed, 100%. Some people are making tools around that, see Matt Pocock's Total Typescript error explainer extension in VSCode: mattpocock.ts-error-translator
iv) Agreed again. Transpilation itself can be fast with modern tooling such as SWC or esbuild (or derivatives). Type checking is still the main bottleneck, though people like Donny (@kdy1dev) are working on a Rust-based alternative.
https://www.totaltypescript.com/rewriting-typescript-in-rust
by amalgamated_inc on 1/12/23, 8:49 PM
by jetsnoc on 1/13/23, 6:47 AM
by no_wizard on 1/12/23, 9:45 PM
I have not found, even in really large projects with thousands of files, that its been an impediment to anything.
My general disposition is the whole "anti build tools" moment is a bit overblown in practice, and I'm always searching for valid counter evidence of persistent issues that can't be easily overcome.
by asdajksah2123 on 1/12/23, 9:16 PM
by antifa on 1/13/23, 8:15 PM
In my experience, any npm library I try to use either already has community created types provided, is too simple to really need types/extra docs, or the docs will still be pre-es6 (pre important, pre async/await, etc.) so it's not like it was going to be convenient to learn anyways.
by nathias on 1/13/23, 7:50 AM
vi) You trade a few type bugs that are easily debuggable and avoidable for type composition and hierarchy bugs which are hard to find.
I have seen good examples of TS that make sense and made to play with functional paradigm, but in practice it was always a bloated mess of OOP JS introducing heirarchy where none is required producing components that are too-tightly coupled and resistant to change and slowed down developing for at least x10.
by rudnevr on 1/13/23, 10:35 PM
True JS programmers are still living without TS, and TS programmers haven't evolved into some culture which could compete with them. That makes TS-based solutions inherently worse.
by auggierose on 1/13/23, 5:23 AM
I am not using many third-party libraries at the moment, and mainly develop my own, so I am not really running into any of your pain points. For my own libraries, developing them in JavaScript rather than in TypeScript would be just plain stupid.
by andrewfong on 1/12/23, 9:52 PM
It's on you to make sure you're not misusing stuff at the boundary, but less hassle to get set up and always something you can clean up later.
by phplovesong on 1/13/23, 11:38 AM
by yieldcrv on 1/13/23, 8:29 AM
its like, just there. I hate how its existence dilutes the javascript community’s example code for some libraries.
I find it cleaner than just JS but its pretty easy for me to keep up with value inferred type in just JS
I would write my new projects and tests in Typescript
by zx14 on 1/13/23, 11:02 AM
I try avoid 3rd party libraries very aggressively and I don't have half the issues people talk about in front end dev. My normal set up is angular and go.
by nc on 1/13/23, 11:44 AM
Once we started keeping our type definitions small and simple we've found it's hugely beneficial.
by yakshaving_jgt on 1/13/23, 11:31 AM
If I’m going to write a bit of JavaScript, I’ll write JavaScript with the minimal feature set possible. It’s not a good thing that the language has continued to accrete features.
If I’m going to write something non-trivial, I’ll go straight to Elm — an actual sane language.
by thomasfromcdnjs on 1/12/23, 9:43 PM
I will be using vanilla Javascript in my own projects for the foreseeable future.
by k__ on 1/13/23, 11:28 AM
The main thing that makes it shine is refactoring.
Besides that, the reast isn't that mind blowing.
I still get crazy bugs just like I did in JS, TS just removed the countless small and easy to fix bugs. Which is good, because they can really slow you down. But when you get something ugly, tests and experience are the only thing that saves you.
by motoxpro on 1/13/23, 11:00 AM
by sarimarton on 1/13/23, 8:13 PM
It goes both ways, a counter example which saved me from some frustration: plotly.js has a horribly bad online documentation, but their type def makes it super convenient to explore all the layout config stuff, when you're buildling a custom visualization.
by sircastor on 1/13/23, 2:58 AM
For all the struggle, it makes me feel very confident about the code, and its reliability. That’s worth a lot.
by florianherrengt on 1/14/23, 1:48 PM
by brap on 1/13/23, 11:05 AM
My only issue with TS is that there are no runtime type guarantees. That, and a few odd syntax choices that I mostly don't have to deal with.
by Aperocky on 1/13/23, 6:49 AM
If you're talking about general backend languages, then there are a lot of options. Since you're talking about large scale applications, that likely means you can use something like java or kotlin.
by huma on 1/13/23, 9:42 AM
by epolanski on 1/13/23, 7:57 AM
Going back to JavaScript just feels...wrong.
TypeScript isn't a perfect language, but I also feel like most of its shortcomings are related to the aim of being a JS superset.
by hsn915 on 1/13/23, 4:22 AM
ii) Yes, but this can't be used to favor JS instead. If a library is badly documented, you're going to have a hard time whether using TS or JS.
iii) This is true, but it depends on what you are doing. One advice is to avoid defining complex types. Another good measure is to sometimes suppress type checking on a few lines that you know are correct but are near impossible for the compiler to verify.
iv) I use esbuild to compile, and have a tsc -watch window open all the time.
by robot on 1/13/23, 5:25 AM
that sounds terrible.
by rlt on 1/13/23, 6:36 AM
I would simply refuse to work on a JavaScript project at this point.
by claytongulick on 1/12/23, 10:33 PM
I have some fundamental guiding principles I apply to engineering, and I find that TypeScript violates these:
1) Reduce complexity
2) Don't be clever
3) Achievement over activity
4) Longevity
---------------------
#1 Reduce complexity
---------------------
Cross compilation introduces additional complexity with debugging and production support. Sourcemaps work fairly well, but often fail on edge cases - normally where you want to be debugging. I've found that JSDoc with good tooling gets 70%+ of the benefit of TypeScript without the additional complexity of cross compilation.
In the browser Javascript ecosystem, I aim to have what executes in the browser be as close as possible to what I've authored. Typescript works against this goal. This is even more important to me on the server side, where introducing a build step diminishes a lot of the value of having a flexible, dynamic environment like Node. If types are desired on the server side due to needed formalism (several problem domains are like this - banking, etc...) there are other languages/execution environments that may be a better choice.
------------------
#2 Don't be clever
------------------
Clever code is frequently a maintenance nightmare. Code should be clear, readable, and approachable. It should tell a story that's easy for anyone (even semi-technical folks) to read.
Typescript lends itself to "clever" and arcane types & structures that increase cognitive load and decrease maintainability, especially as the rules change.
----------------------------
#3 Achievement over activity
----------------------------
I guide my teams to focus on delivering business results and shipping software. I've seen code bases where up to 40% or more of the total LOC are nothing but types and structures to satisfy the compiler, not to provide features. In some cases, that's a good thing - where the business constraint is correctness over TTM, for example. If not though, it can be a company killer. You can end up shackled by your domain models, and small updates have massive cascading consequences.
I've seen developer's entire sprints consumed by tasks that are abstraction related, and don't provide business value. I've personally known several developers that have told me directly that they don't like shipping software, they just prefer to play with frameworks and development theories. While those are extreme cases, I know many more developers that fall somewhere around there. I'm not sure why, but I think Typescript encourages this soft of thing. I get a sense that the whole ecosystem is more about the software process than delivering valuable features to the users. Though those things aren't mutually exclusive, when taken to excess I've seen software process and tooling devolve into a weird sort of navel gazing that's a barrier to delivery.
------------
#4 Longevity
------------
I prefer to stick to standards. I also tend to avoid frameworks, I use Web Components as a component solution, and keep everything as vanilla as possible. I don't mind using stable libraries, like date-fns or lit-html, but I've been burned too many times by multimillion dollar boondoggles that result from framework churn.
I encourage my team to pick technologies and development methodologies that have a five year lifespan as a minimum goal. I have code I've developed in javascript that's been running in production for 15 years without needing a major overhaul, and with stable dependencies.
On the other hand, I've had TypeScript codebases that completely broke based on rule changes that came from a TS update, and required significant revamping within six months of being authored.
While I do think that TS can be beneficial for some projects and teams - specifically ones that require a high degree of formalism - most of the time I don't see it providing concrete business value. I see it consuming dev cycles for limited benefit.
I am looking forward to the optional typing that's currently a stage 1 proposal. I miss AS3, which I thought struck the perfect balance between static and dynamic typing. Static by default, but it was easy to opt out when being dynamic made more sense.
by Waterluvian on 1/13/23, 3:11 AM
by ironmagma on 1/13/23, 9:36 AM
by incompletude on 1/12/23, 10:44 PM
I would recommend to every software developer to learn the type ecosystem inside their language to make sure they have a good/high-paying job in the near future.
In 5 to 10 years, almost every serious engineering job will be working with an ecosystem that contains types.
by mcphage on 1/12/23, 9:45 PM
by it on 1/13/23, 4:54 AM
by throwaway09432 on 1/13/23, 1:54 AM
by bayesian_horse on 1/13/23, 8:08 AM
by ly3xqhl8g9 on 1/13/23, 7:22 AM
type IsParameter<Part> = Part extends `[${infer ParamName}]` ? ParamName : never;
type FilteredParts<Path> = Path extends `${infer PartA}/${infer PartB}`
? IsParameter<PartA> | FilteredParts<PartB>
: IsParameter<Path>;
type ParamValue<Key> = Key extends `...${infer Anything}` ? string[] : number;
type RemovePrefixDots<Key> = Key extends `...${infer Name}` ? Name : Key;
type Params<Path> = {
[Key in FilteredParts<Path> as RemovePrefixDots<Key>]: ParamValue<Key>;
};
type CallbackFn<Path> = (req: { params: Params<Path> }) => void;
function get<Path extends string>(path: Path, callback: CallbackFn<Path>) {
// TODO: implement
}
get(
'/purchase/[shopid]/[itemid]/args/[...args]',
({ params }) => {
params.shopid // number
params.itemid // number
params.args // string[]
},
);
then you probably don't need TypeScript, or types in general. And that is fine.
As to the points:
(i) 99.99% of everything is being developed by someone else in our current stack, but here comes the benefits of open source: don't like how a project is going? fork it and maintain it yourself;
(ii) If you don't use a NPM package with the last release older than 2014 (and why would you given your (i)st fear), chances are pretty high (95%+) the library is written directly in TypeScript or there is a DefinitelyTyped package with the types;
(iii) Type errors, those that come directly from TypeScript, are pretty straightforward (was expecting X, you passed Y);
(iv) Yes, TypeScript should have never been written in an interpreted language, but what were the options in 2012: C? C++? Maybe some day in the unspecified future, we will have a Rust/compiled language implementation with microsecond transpilation time.
by quanticle on 1/12/23, 9:39 PM
I want to skip over the static typing benefits argument, because I think it
is well understood that static typing is a good thing and if we could bless
JavaScript with a built-in and robust typing system then I don't think many
people would be against that.
EDIT (some more thoughts):
For example, a new package you install can require a new TypesScript
version. Once installed, you then may need to update your source code. This
can place quite a high tax on the developer, where perhaps a 10 minute
change becomes hours long.
Most libraries do not document their types, or have no examples using
TypeScript.
Errors are long and don't provide enough detail. They will explain a type
mismatch referencing many types you may not have ever seen, and are not
documented anywhere. Except for simple errors, many of them are very hard to
follow to a remedy.
I referred to TypeScript as a framework which it isn't. However it feels
similar to me in that you are at the whim of TypeScript developers and how
they decide to progress with the language.
by nikanj on 1/13/23, 8:32 AM
Not sure whose domain this falls in, but the situation is a coal mine canary that tells me the whole ecosystem is not up to the level I want from my production tools
by darepublic on 1/12/23, 11:01 PM
by sngz on 1/13/23, 8:24 AM
by paulcarroty on 1/13/23, 5:56 AM
by mauro_c8 on 1/13/23, 3:51 AM
by cassepipe on 1/13/23, 9:35 AM
by dmak on 1/13/23, 3:36 PM
Has anyone tried building in flow for a large project? This was facebook's static type checking approach: https://flow.org/
by gardenhedge on 1/14/23, 11:57 PM
by phazeedae on 1/13/23, 1:17 PM
by AzzieElbab on 1/13/23, 12:54 AM
by jeroenhd on 1/13/23, 9:35 AM
i) You can wait years to update TypeScript itself. I've never run into incompatibilities before.
ii) That's the libraries' fault. Without types, you can pass in total garbage and it doesn't work. With types you can only pass in some garbage and it doesn't work. All the Javascript examples work in TypeScript except now you will be warned that your code won't work before you try to find edge cases to test.
I've had the pleasure to use Frida a while back. It allows you to instrument running native applications using hooks written in various languages, though the live debugger usually uses Javascript. The documentation of many functions is scarce, to say it nicely. Without the TypeScript bindings, I would've never gotten most of these functions to work. You can find example code online but half the time that example code will be buggy and not do what it appears to do exactly because there is no type check on the plain JS API.
iii) I disagree, they're verbose but not that difficult to read. "You specified this but the type doesn't exist" or "you didn't specify this thing the type needs" is almost always the problem, it's just a little over eager to tell you where you're missing something.
iv) Okay this is definitely a downside. If you're not using Babel or another transpiler/minifier/obfuscator already, you'll add an extra build step. A minor one, in my opinion, but a build step nonetheless.
In my experience, TypeScript isn't making progress slow. It's making you fix your bugs and broken promises before the customer calls that your code doesn't work anymore. If you're passing strings instead of numbers you're going to break your code eventually, only now you'll have to get your code to working order beforehand.
Working on a codebase that's a few years old and added typescript retroactively, my experience is that renaming JS files to TS will instantly show you three to five bugs in every single JS file you come across. Import errors all throughout the code base, because it turns out components got reused wrong and what seemed like an optional label that didn't have any contents was actually broken for five years.
TypeScript gets even better with a nice and strict set of linter rules. Not just the builtin ones, also extra stuff like "don't use any everywhere to avoid typing things" and "specify what you're returning when you're returning something". With the stricter guarantees the language can deliver because of types, the code quality analysis can be a lot better as well!
by kyranjamie on 1/14/23, 10:49 AM
by johlits on 1/13/23, 8:28 AM
by fithisux on 1/13/23, 1:22 PM
by lloydatkinson on 1/13/23, 4:06 PM
by garfieldnate on 1/13/23, 3:40 PM
Generally speaking, I have to be extremely careful with working on a JS/TS project. I use the strictest modes possible and enable as much linting as possible. I also use the type-coverage module and fail the build if the `any` type gets applied anywhere.
As another general complaint, NPM doesn't do enough to incentivize its users to release quality software. JS/TS has always been very trend-based and social, and even just running a few simple lints and prominently displaying a score on NPM would probably really help the community improve its standards.
Take pub.dev (Dart), for example. Here's a module page: https://pub.dev/packages/firebase_core. The score is displayed prominently, and if you click on it you get a full breakdown of how it was calculated: static analysis, up-to-date dependencies, and documentation (although the coverage is not 100% for this module, so I think it's wrong to assign full points). When you upload to pub.dev, you want a score of 100! It doesn't guarantee that the module is fantastic software, but at least the basics have been taken care of.
In my opinion, the most important piece missing from the score on pub.dev is test coverage. Take for example a page from Metacpan (Perl packages). Here's a module I've released: https://metacpan.org/pod/Algorithm::AM. On the left you see displayed the automated test results, including the test coverage, which has been submitted by volunteers who downloaded and tested the code on a variety of platforms and Perl versions. There's also link to a "kwalitee" page, which is similar to the pub.dev score (though this could be much improved by having an actual score and displaying it prominently on the main module page).
Now an NPM module: https://www.npmjs.com/package/react. What info do we have about the quality of the package? Essentially just the activity from the community (open PR's and issues, downloads). We have no idea how well it's tested, what kind of static checks have been performed, whether your editor will be able to display documentation or typing when you mouse over a method from the library, etc. (TypeScript is mainstream enough now that it should be fine for NPM to provide a bit of special handling for it.) Most 3rd party libraries are from individual authors and probably have very little activity. When deciding whether or not to use them, right now you need to dive through the code to check if the basics are taken care of. Having some of this automated would save a lot of time.
by eyelidlessness on 1/13/23, 4:37 AM
I can add ~95% of the same safeguards without it, but I’ll spend a lot more time doing so and it’s a lot harder to get buy in to make them stricter than my own editor.
> For example, a new package you install can require a new TypesScript version. Once installed, you then may need to update your source code. This can place quite a high tax on the developer, where perhaps a 10 minute change becomes hours long.
If your project is already strict and if you generally have a good sense of the areas TS doesn’t cover, you probably wouldn’t need to update anything for the last couple years. If your project isn’t strict, you’re probably benefitting from updates more closely matching the semantics you wanted in the first place.
> Most libraries do not document their types, or have no examples using TypeScript. Some worst offenders: Apollo, Protobufjs. The type definitions exported by these libraries can be large and complex, and the error messages emitted by TypeScript are so long and cryptic the result is often a drawn out process of trial and error along with trawling through source files.
It’s fairly trivial to add local type defs if you’re at all interested in the type safety it brings. They’re almost universally easy to transfer to PRs for DefinitelyTyped (which admittedly I should do more often, and I should open a few after I land this work in my project).
> Errors are long and don't provide enough detail. They will explain a type mismatch referencing many types you may not have ever seen, and are not documented anywhere. Except for simple errors, many of them are very hard to follow to a remedy.
This is true. You’re right. If you want a little helpful pointer:
type Debug<T> = [AnyType<T>] extends [never]
? 'My understanding of AnyType failing'
: AnyType<T>
It’s not great but it’s basically a very slow way to walk up the type resolution stack until you find what doesn’t behave the way you expect.
> Transpilation takes time, and always adds a burden to developers. I didn't mind so much with ES6 etc because eventually many functions were included in a broad set of browsers. There doesn't seem to be much progress including TypeScript in a browser, and feels like these complicated transpilation steps could be with us for a long time.
ESBuild, Vite, SWC and such have basically made the build step instantaneous. They’re not without config woes, but they’re worlds better than what came before. So much so I will volunteer to help you set up a project’s build if you do the very easy legwork to find any number of ways to contact me.
by armatav on 1/13/23, 4:21 AM
by canacrypto on 1/13/23, 4:46 AM
by ajkjk on 1/13/23, 2:55 AM
I know it's not an interesting answer and a lot of other people say the same thing; guess I'm just casting my vote.
by FractalHQ on 1/13/23, 1:53 AM
The biggest things I wouldn’t be able to live without:
- the self-documenting nature of Typescript code (I instantly know what a function accepts and returns by hovering over it).
- the comprehensive auto complete my ide gets (saves hundreds of trips to the docs / source code per day).
- the incredible productivity gains when refactoring (change one thing, instantly get notified of all 30 places in the codebase that change introduced errors and clean them up in minutes).
by fckgnad on 1/13/23, 4:06 AM
Are types worth it? Yes. Is typescript worth it? Maybe.
by sph on 1/12/23, 8:58 PM
The solution to better web development is staying as far away from JavaScript as possible, not polishing what is frankly a turd.
I think it's masochism to have a Javascript project that big that benefits from strict typing.
by spaceheater on 1/12/23, 9:38 PM
Use your head, if you don't like TS, don't use it.
by typesornotlol on 1/13/23, 4:26 AM
There is so much more to software development than the how quickly one can vomit code into their editor of choice. If typescript is slowing you down, your code is *bad*. End of story.
Continually pretending that types don’t matter is laughable. The thousands of dynamic language projects with littered with type-hints, type-assertions, and type-verifying unit tests proves otherwise.