Why are we still talking about this.
Ask HN: Is TypeScript worth it?
441–450 of 469 posts
Re: Ask HN: Is TypeScript worth it?
#442Earlier quoted context omitted.
Idk if I’m just an idiot but my company’s codebase for the last year has had pretty slow tsc compile times and nobody on my team has been able to make it better. Probably since we have a decent amount of generated code that pushes the amount of source code up considerably, but still no good answers to make that better.
If you are autogenerating code you can generate it in JS and skip compilation altogether.
The point of the generation is to build type safe API clients, not for the runtime behavior, so that doesn’t really fly unfortunately.
Re: Ask HN: Is TypeScript worth it?
#443Another point is that Typescript is most powerful when you use it everywhere and share types.
E.g: Between frontend and backend API.
It’s hard to keep track of where something is used when you change it.
Typescript can do it for you.
Re: Ask HN: Is TypeScript worth it?
#444Earlier quoted context omitted.
Typescript doesn’t just statically type. That’s easy. It does program flow analysis to 1) infer type and 2) ensure the inferred types actually work. I think in most statically type environments, the type analysis engine relies a lot of on the developer to define the correct types in the correct places, but the types in TS are always _logically_ correct. As in absolutely correct (unless of course you eject from the ty…
> but the types in TS are always _logically_ correct. As in absolutely correct Erm... type Test = Array ; const xs: Test = []; const x = xs[0]; What's the type of x, according to typescript's default behavior? It's number [0]. What's the logically correct type? Some sort of a Maybe , which typescript doesn't have; so a number|undefined instead. Most people don't use typescript at that level of soundness, both because…
I’ve never found it to be overly painful. If you’re accessing values this way (on an index vs defined fields), you’re already treading into iffy territory, structure-wise, and its good to undermine your assumptions about what’s at the index. An extra check might seem very hand-holdy, but I’ve been doing JS long enough now to have seen a large number of errors originate in this class of index access.
Re: Ask HN: Is TypeScript worth it?
#445I've been working with JavaScript for 20 years. And 5 years with TypeScript. And, well. I still am not convinced. 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 th…
I've also been working in JavaScript for 20 years and TypeScript for 5. You will have to claw TypeScript out of my cold, dead hands. You shouldn't need to type obvious things in most cases, TS should be able to infer it. In my experience TypeScript has prevented many bugs, makes coding more enjoyable, clear and faster, and best of all, refactoring becomes like a super power. I've yet to do a large refactor in a good TS codebase that caused a single regression. The word "good" here is a pretty strong caveat though. TS is only as good as you make it, and overlaying types onto a dynamically typed language (especially manually) can cause issues for sure.
Re: Ask HN: Is TypeScript worth it?
#446Earlier quoted context omitted.
Just to add to #4, I've worked on some large codebases where transpilation starts taking a very long time, and I begin to think "wow, this is really straining TSC"... so far, every time it's happened, it's been because some sort of data files weren't being excluded from the build.
Idk if I’m just an idiot but my company’s codebase for the last year has had pretty slow tsc compile times and nobody on my team has been able to make it better. Probably since we have a decent amount of generated code that pushes the amount of source code up considerably, but still no good answers to make that better.
I don't do anything with generated code. But is it necessary to generate that code every time TSC does a build? Could it be independent? I usually use two different ts export indexes, and create two dist JS files for each app. Most of the boilerplate that rarely gets touched (user management, login and signup screens, common UI elements, utility code) is essentially in an outer JS file that loads the inner JS with the business logic and meat of the app, but has no imports from the inner JS whatsoever. They're basically two separate projects. Not that I've noticed much difference with tsc, but it makes webpack or r.js faster if you can create separate webs of dependencies and only need to repack one of them without touching the other...
Re: Ask HN: Is TypeScript worth it?
#447Earlier quoted context omitted.
Let's think about what happens on a team: If a single person goes and reads the source code to learn how the public API works instead of simply using the exported types, that's a wasted thirty minutes instead of two - okay, fine, whatever. If all of my engineers have to do this, suddenly each of them is spending that amount individually; and just like that, we've wasted an entire man-day, for nothing. As you declared…
I am a strong believer that every developer on a team should know how the code works. Emphasis on HOW. You only know that if you go to the source of truth. That is how people become proficient with a skill — by doing and re-doing and re-doing things. I disagree that it's wasted time. The time spent investigating how a piece of code works is time extremely well spent. If the code is too difficult to understand — of co…
If the codebase is small and owned by a few people then it might be true. But when the codebase gets large enough and worked on by multiple teams - it is unreasonable to expect that everyone will understand the workings of the whole application.
Re: Ask HN: Is TypeScript worth it?
#448Earlier quoted context omitted.
> 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. It's really difficult to construct a comprehensive SPA without a nice framework such as Vue or React; and as it relates to your prior paragraph about WASM, I'd love to take this advice, but reactive UI frameworks suitable for browser are you…
I think its good to bring up SPAs in this context: fundamentally, they shouldn't exist, and you're using the browser wrong. They are the poster child of design smell when it comes to "web apps". Do you need SEO to work, even though Google Search torpedoed effective SEO a long time ago? Search engines disfavor websites that are extremely opaque and are made of a single page or few pages. Do you need to be able to open…
This is all outdated thinking now that we have PESPA frameworks
Re: Ask HN: Is TypeScript worth it?
#449TypeScript itself is good but typescript errors are bad and annoying
Re: Ask HN: Is TypeScript worth it?
#450I write types everywhere. Without types, I'm in the blind. So yeah, don't look at motifs why some library maintainer has TS errors in their declaration files. I'm a full-stack TS developer, and I can count on my one hand fingers the times when some library had type problems. And if they had, I would fix them with my own declarations. But how do you code without types? It brings so much clarity to everything. Judging…
I've been continuously frustrated by it - but the projects I'm working with are large, or leverage some more complicated dependencies. For example both ProtobufJS and Apollo can be very tricky.
I also do a lot of refactoring and improvement on these codebases, often updating packages, so perhaps I run into more issues more frequently than many. I accept that a lot of the time it can be smooth sailing, but anything tricky and it's a real time sink.