4 ms·

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 ai

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 an inscrutable ball of spaghetti like the cartel wants me to) I could probably iterate without breaking the types. 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. "But then why have types at all?" Exactly. They're a crutch for people who want their IDE to understand the code instead of them.

CapsAdmin 4y ago
For me the best experience during development is to build ts to js first with something fast like esbuild and check types in parallel without preventing the output in any way from running in the browser. A perfect scenario for me is having all errors in the project caught by vscode. At the moment vscode only checks files that are currently open. I think type checking should only be done when building to some sort of production or realtime in your editor. Templates like "create react app" can report runtime errors but it's somewhat strange that it also report typescript errors. (although understandable given that it wants to be tooling agnostic) One potential major upside with adding optional type hints to javascript is the ability to run typescript files directly in the browser without needing to strip types in a build step. Advanced type checking could be done the same way we use linters like eslint.
- kuramitropolis 4y ago
  >At the moment vscode only checks files that are currently open While TSC checks everything by default - even files that are not even part of the dependency graph. That's how great the "great tooling" is in reality. >I think type checking should only be done when building to some sort of production or realtime in your editor. Agreed, that's the lest awful option. The problem is that they had 10 years to think of it, and didn't. >Templates like "create react app" ...are a big part of the problem. "But I don't want to spend a whole day just setting up a project!" You wouldn't have to, if you didn't drink the React kool-aid in the first place.
josteink 4y ago
> 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 subset of my code without a complete working system, I have unit-tests for that purpose.
- kuramitropolis 4y ago
  >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?"
Merad 4y ago
It's always fascinating how different people approach writing code. I've worked with some very talented devs who preferred dynamic languages because they liked what I call a "smash face on keyboard" style of coding. They wanted to be able to make a change, run the code, make a change, run the code, often repeating that dozens of times before they got it right. I, and I think many people who prefer statically typed languages prefer a more methodical style of programming where we spend more time reasoning about the types and how data flows through the app. I might only run the code every five or ten minutes, but often if it builds it's right the first time. If the types are wrong, the code is wrong, and I've no interest in running code that's wrong. Is one side or the other right or better? I dunno, I'm not qualified to answer.
- wizofaus 4y ago
  TypeScript doesn't entirely prevent you from doing that, even if you have to stick in a few "any" keywords here and there and ignore whatever linter warnings you might get. I'm happy for individual devs to work like that if that's what works best for them to get their code going - but I'm certainly not happy for a shared codebase for a large complex project with dozens of devs on it to operate the same way.

CapsAdmin 4y ago

For me the best experience during development is to build ts to js first with something fast like esbuild and check types in parallel without preventing the output in any way from running in the browser. A perfect scenario for me is having all errors in the project caught by vscode. At the moment vscode only checks files that are currently open. I think type checking should only be done when building to some sort of production or realtime in your editor. Templates like "create react app" can report runtime errors but it's somewhat strange that it also report typescript errors. (although understandable given that it wants to be tooling agnostic) One potential major upside with adding optional type hints to javascript is the ability to run typescript files directly in the browser without needing to strip types in a build step. Advanced type checking could be done the same way we use linters like eslint.

kuramitropolis 4y ago
>At the moment vscode only checks files that are currently open While TSC checks everything by default - even files that are not even part of the dependency graph. That's how great the "great tooling" is in reality. >I think type checking should only be done when building to some sort of production or realtime in your editor. Agreed, that's the lest awful option. The problem is that they had 10 years to think of it, and didn't. >Templates like "create react app" ...are a big part of the problem. "But I don't want to spend a whole day just setting up a project!" You wouldn't have to, if you didn't drink the React kool-aid in the first place.

josteink 4y ago

> 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 subset of my code without a complete working system, I have unit-tests for that purpose.

kuramitropolis 4y ago
>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?"

Merad 4y ago

It's always fascinating how different people approach writing code. I've worked with some very talented devs who preferred dynamic languages because they liked what I call a "smash face on keyboard" style of coding. They wanted to be able to make a change, run the code, make a change, run the code, often repeating that dozens of times before they got it right. I, and I think many people who prefer statically typed languages prefer a more methodical style of programming where we spend more time reasoning about the types and how data flows through the app. I might only run the code every five or ten minutes, but often if it builds it's right the first time. If the types are wrong, the code is wrong, and I've no interest in running code that's wrong. Is one side or the other right or better? I dunno, I'm not qualified to answer.

wizofaus 4y ago
TypeScript doesn't entirely prevent you from doing that, even if you have to stick in a few "any" keywords here and there and ignore whatever linter warnings you might get. I'm happy for individual devs to work like that if that's what works best for them to get their code going - but I'm certainly not happy for a shared codebase for a large complex project with dozens of devs on it to operate the same way.