Live data from Hacker News

TypeScript is now officially 10 years old

coderoasis.com

151–160 of 207 posts

Re: TypeScript is now officially 10 years old

#151
post #141

Earlier quoted context omitted.

But at what cost? We shouldn’t assume it’s free

The cost is the compile time. My personal application is about 50k loc so the compile time is about 9 seconds with TSC or 1.5 seconds with SWC.

There are other costs. One study I’ve seen found that writing libraries with typed generic code too longer to write, but we’re slightly faster to use. I’ve found that changing peoples badly typed code is worse than changing similar dynamic code.

In short, there is very little empirical data on this, and it’s almost entirely anecdotal. My gut feeling is that if typing were a huge benefit it wouldn’t be so hard to prove.

Re: TypeScript is now officially 10 years old

#152
post #144

Earlier quoted context omitted.

I find it catches a lot of design mistakes for me which I would put in the non-trivial bugs category. Many bugs that result from design mistakes are less immediate, like hard to spot edge cases (a better design makes them impossible) or code that lends itself to becoming messier and more bug prone in the future as it's changed/extended (a better design makes this less likely).

I’ve had the opposite experience with complex type systems. They make it harder to evolve out of bad designs. This is particularly true when a lot of inheritance is used.

Interesting. What I've found is that when I come up with some pattern that is hard to type, or I have two parts of a system that need to work together but the interface can't be typed simply or doesn't quite 'fit', it is almost always the case that changing things around until the types do work straightforwardly uncovers a better design.

This is definitely sometimes not easy, and of course it'll get more difficult generally the more code there is or the more complex (usually meaning bad!) the design is, but I'd almost put it the other way round to your perspective - the types are like the signposts in this design evolution and discovery process. They don't make it easier to do the work of refactoring a design, but they do make it much easier to understand when I'm going in a good/bad direction and also when I have succeeded.

Re: TypeScript is now officially 10 years old

#153
post #151

Earlier quoted context omitted.

The cost is the compile time. My personal application is about 50k loc so the compile time is about 9 seconds with TSC or 1.5 seconds with SWC.

There are other costs. One study I’ve seen found that writing libraries with typed generic code too longer to write, but we’re slightly faster to use. I’ve found that changing peoples badly typed code is worse than changing similar dynamic code. In short, there is very little empirical data on this, and it’s almost entirely anecdotal. My gut feeling is that if typing were a huge benefit it wouldn’t be so hard to prov…

Avoid things like generics. Keep your types as primitive as possible. Strong typing will covert an excellent developer into an amazing developer but won’t do anything for extremely bad developers. Data types are not a solution to people problems.

Re: TypeScript is now officially 10 years old

#154
post #144

Earlier quoted context omitted.

I’ve had the opposite experience with complex type systems. They make it harder to evolve out of bad designs. This is particularly true when a lot of inheritance is used.

Interesting. What I've found is that when I come up with some pattern that is hard to type, or I have two parts of a system that need to work together but the interface can't be typed simply or doesn't quite 'fit', it is almost always the case that changing things around until the types do work straightforwardly uncovers a better design. This is definitely sometimes not easy, and of course it'll get more difficult ge…

You are describing writing code alone. I’m thinking about other peoples code I’ve had to deal with where I didn’t create the types. Not saying I’m great at it, but that you can’t always control the quality of the code you have to work on.

Re: TypeScript is now officially 10 years old

#155
post #151

Earlier quoted context omitted.

There are other costs. One study I’ve seen found that writing libraries with typed generic code too longer to write, but we’re slightly faster to use. I’ve found that changing peoples badly typed code is worse than changing similar dynamic code. In short, there is very little empirical data on this, and it’s almost entirely anecdotal. My gut feeling is that if typing were a huge benefit it wouldn’t be so hard to prov…

Avoid things like generics. Keep your types as primitive as possible. Strong typing will covert an excellent developer into an amazing developer but won’t do anything for extremely bad developers. Data types are not a solution to people problems.

Agree, but the question for me is whether it is clear that it’s better at organizational scale over decades. I think it is, but not hugely so.

Edit: I should add that I think there are a ton of things that are far more important for a high performing dev team than types.

Re: TypeScript is now officially 10 years old

#156

Earlier quoted context omitted.

My project is small but TS takes 4-5 seconds to compile it from scratch on each run. The main speed impact is in developer productivity though. If something ain't working right, now I first gotta fix the types before I can see if I've fixed the actual logic. I imagine if my codebase was more "OOP-y" (i.e. if I replaced every layer of my domain model with 3 layers of dependency injection, turning the whole thing into…

> But for any sane developer having made the mistake to touch TypeScript, the capability to strip the types and run the code with broken types, is essential. You’re free to hold that opinion, but I think you see (based on downvoting) that your definition of a “sane” developer is not as universal as you may have thought. Personally I almost never see any value in running known broken code. If I need to run/test a subs…

>your definition of a “sane” developer is not as universal as you may have thought

Where I'm from, sanity has historically been the minority opinion, so we don't really have a word for this, but I think the English one is... "gaslighting"? "TS is a superset of JS", "there are 4/5 lights", "this line is longer/shorter", etc. (Look those up if you haven't, Microsoft marketers surely have.)

What I'm saying is, I am well aware that I represent a minority, and guess what, getting downvoted (not nearly as much as expected) still beats keeping silent about the things that have been fucking with my head for the past, what, year and a half? Considering I've been writing Node for barely 6, the fact that every year the number of software developers doubles [cit needed] probably has a lot to do with it.

No matter if we're talking about a very simple or a very complex system: if there are a lot of subtle inconsistencies in it, and you have to gradually learn your way around them, your ability to keep a consistent mental model of it in your head, and reason about what you're doing, will be impaired: -1 sanity.

Ironically this is the same as people's gripes about the original JS type system. IMHO `==` and `===` should've been the other way around, and 1000 ships wouldn't've been launched. This unwieldy choice of notation (implicit type coercion on `==`) made it just enough subtly different for people expecting C-like strict equality, to create a feeling of confusion and distress.

But since the underlying design principle was not clarified (in browsers all input comes from text boxes, as strings, anyway; and the original "source of truth" was only the HTML file, where element attributes are also strings; so in some limited sense it makes sense to have convert-from-string by default), we get all these (generations of) people with the impression that JS is a "low sanity" language... and that it needs, of all possible features, even more of a type system.

>Personally I almost never see any value in running known broken code.

That's completely subjective. Personally, I don't know how to fix a piece of code without being able to see with my own eyes how/where/why it breaks, but surely that's just my deficiency and everyone else is just telepathic. Boo, shame on me! (I'm also the guy with the months-long pull request because guess what, TypeScript did not make it easier for me to see what I'm doing wrong, just looped me into a waves of type refactors, sometimes causing me to break working code to get dat "spellcheck" out of everyone's faces. I do semver, but most libs on NPM don't ...)

So, in my experience, TypeScript prevents me from running known good code way more often than it prevents me from running known/unknown broken code. As for what value you see in either, sure - that's a matter of style.

Rust was mentioned elsewhere in the thread. It's great to work in a language where "compiles"="works". But TS is not a static language, where types actually matter; it's a restrictive "sanity checker" overlay on top of a dynamic language. And not one that's good enough for me to sacrifice the expressivity that JavaScript allows.

Maybe it's good enough for many other people who never came to rely on JavaScript's flexibility that much in the first place. Thoughts and prayers to 'em. Each one has to make the choice which is the right tool for a job - and when there's an incipient monoculture trying to make that choice for me, I'm bound to make a ruckus.

> If I need to run/test a subset of my code without a complete working system, I have unit-tests for that purpose.

Amen to that! Thing is... you see how elsewhere in the thread, it's mentioned that people use TS annotations as an excuse not to write documentation? Well, in my purely anecdotal personal experience, they also use it for an excuse not to write unit tests! And considering what unit testing in JS looks like... well, no surprise there, either. "Ubiquitous JS" is supposed to be accessible. Instead, we have a number of onramps to it covered with rusty razor blades,

TypeScript is not without its good parts, but overall my journey with it has been one of frustration and, as I'm sure you can see from miles a way, a whoooooole lot of mismatched expectations. Like, ESM working...

Hence the exaggerations, and generally the lots of writing. I like JS/Node, I consider them simple I've been round the block just enough to see it evolve a bit, I gotta adapt to what others are doing (TS) because otherwise good luck getting help, right? So this is my honest perspective about that and I'm here to represent it because it's gotta amount to at least as much as the usual "nah bruh everything ok... u ok?"

Re: TypeScript is now officially 10 years old

#157
post #113

Earlier quoted context omitted.

No, cringing at some "helpful" popup appearing right over the previous line of code. If anything, they could've made it appear under the current line; code's still written top to bottom so it's less likely for "suggested relevant info" to obscure the actual relevant info.

You can press f8 to view the problem in a "peek view" under the problem line, or view on the problems panel.

> 10542667 Aug 9 20:40 node_modules/typescript/lib/typescript.js

aint fitting ten megs in a peek view... :(

Re: TypeScript is now officially 10 years old

#158
post #119

Earlier quoted context omitted.

Quoted post unavailable.

You can directly import any valid JS module using TypeScript if you have “allowJS”: true in the compiler options of your tsconfig.json file. The comparison to FFI doesn’t make any sense. FFI requires compiling a special library that explicitly exports the C types. This is different than TS. Using TS, you can import any valid JS module without any special preparation. Also, you can’t import all compiled languages into…

>There is no way to export a Go struct for consumption via FFI, for instance.

I hope not.

>Using TS, you can import any valid JS module without any special preparation

Why does the DTS ecosystem exist then (https://www.npmjs.com/package/@types/node etc)

Re: TypeScript is now officially 10 years old

#159

I feel like I am the only one in the world not liking typescript. It is not that I don't like types, it is what those types do to the readability of the codebase in terms of verbosity. My original programming language was Java but I switched to Node.js because I liked the simplicity of the code written in it. Nowadays every Javascript project seems worse than a Java project in terms of verbosity. My main gripe with p…

I'm also in the not-liking typescript camp. I was an early adopter (I think my first version was 1.7 or 1.8) and it put me off forever. What increased my productivity the most was not languages, linters, build tools, compilers, transpilers, etc... it was a good IDE. Now I just write plain Javascript with JSdoc and I don't need to update my toolchain every week.

I maintain several JS+JSDoc projects for work, and several TS personal projects. You can certainly get a very similar IDE experience with plain JSDoc, but the tradeoffs are pretty severe. Certain aspects of the type system have no JSDoc equivalent (assigning a type to a class definition), or worse have conflicting equivalents (eg enum, which I know everyone hates in TS but the JSDoc version is worse), or require cramming TypeScript syntax onto a single line in (eg conditional types).

Most plain JS projects use some build tooling even without compiling TS, my work projects are no exception. When I started the job, the build tools (Rollup and Terser) worked just fine and had been in place for years. A short while later I made the case to switch to ESBuild to improve iteration speed, which took a couple hours maybe? It’s been almost totally untouched since. And if I had more time, I’d be able to gradually convert the code to TS without any additional tooling effort.

I get that tooling pain in the JS/TS ecosystem is basically a running joke at this point, but no one is forcing you or anyone else to update anything. Plain old tsc still works if you want to keep it simple (and it’s what I recommend to anyone who wants to try out TS and feels confused or intimidated by the whole Tooling Thing).

To each their own of course, but living on both sides of the fence… the JSDoc-types side isn’t nearly so green as it can sometimes sound.

Here’s hoping the types-as-comments proposal keeps gaining traction. I’ll still use a build tool to strip types out for prod, but I think the no-tooling/JSDoc-types crowd would benefit a lot from a syntax much closer to TypeScript too.

Re: TypeScript is now officially 10 years old

#160

Earlier quoted context omitted.

well I can, I wrote a year-long js project that I abandoned as refactorings gradually turned into eternal bug-fests. I started from scratch in typescript, and the project is now 3x the dead project, with none of the bugs. and refactorings have become painless, with the compiler tools and editor telling me what I must fix up. There may be a special breed of programmers who need no such help, but I have yet to meet the…

You still have bugs, you just haven't found them yet. When strict typing is not available you adjust and use other tooling and tests. Of course with a big, venerable project the balance changes drastically. But an experienced single-person project should be doable with javascript for a long while and may even get to MVP faster by focusing on things that are essential.

I’ve been coding professionally for 39 years. ts seemed very strange to me at first. Only even started using it because I had to do some customization in NetSuite and some third party type and build support in ts made comprehensible the typically-stilted and insane NetSuite js required by SuiteScript.

Now I’m addicted to it. Specifically the lightweight and easy to use _interface_ directive feeds my practice of self-documenting code with good doc and reusable data structures.

Post reply on HN