A recent trend has shaken up the JavaScript-TypeScript community: the anti-build-step movement. For over a decade now, a build step1 has been widel...
For further actions, you may consider blocking this person and/or reporting abuse
Your assessment, while very interesting and appealing is ultimately incorrect because you are taking the route of the "weaker part", making your entire conclusion invalid. "Weaker part" is following the weaker of your observations. "Weaker" means "some", when there is an "all" part you can follow instead. Quickly putting an example:
All women are human.
Some humans are doctors.
Conclusion: All women are doctors.
Because I followed the weaker premise, my conclusion is incorrect. This is what happened in your case: Only some consumer code depend on libraries. Not all of it.
Let's also remember that TypeScript has another great feature: Providing new syntax not yet implemented in browsers and JS runtimes. You can take advantage of upcoming JS features when writing TypeScript because TypeScript then transpiles those features according to the target language of your choice. Therefore, your other error is minimizing TypeScript to a mere typing mechanism.
I fail to see what you mean by this. Would you mind further clarifying how my line of argumentation fits the form that you observed?
But to clarify my position, I argued that "JavaScript is more appropriate for application code" where type inference is sufficient. Otherwise, in cases where type annotations, type aliases, and interfaces are necessary, I delegate and isolate the TypeScript-specific code to libraries (that are imported into the solely-inference-reliant JavaScript code). I thus concluded that "TypeScript is best suited for library code while JavaScript is more appropriate for application code".
Ah, I admit that I was not clear with the context I am working with here. For clarity, I assumed a project setup that uses a bundler (e.g., Vite) such that
.jsfiles get transpiled to targeted editions anyway. I thus "minimize TypeScript to a mere typing mechanism" under the assumption that the work of downgrading syntax and polyfilling is delegated to another plugin in the bundling pipeline (e.g., Babel).But if we assume that TypeScript the compiler is indeed the primary means of transpilation, then I must concede to your point. TypeScript the compiler would be necessary for that particular situation. Everywhere else, I believe I am fully justified in "minimizing TypeScript [the language] to a mere typing mechanism". Please do let me know if I miss out on other use cases, though.
I am a back-end developer, so the world of Babel and company is not my forte. Based on your claim, I asked Bing's AI to clarify this for me. I asked "Bing, can Babel, Vite, esbuild or any other tool do what TypeScript does? Can they polyfill and re-write code of not-yet-released JavaScript language features?". The response:
It seems that not even Babel can replace TypeScript fully when it comes to not-yet-released JS syntax/features. Is the AI correct?
Your train of thought derailed because you are incorrectly assuming that all code that is TS-dependent can or will be encapsulated in a library. This, while theoretically possible, is never done in practice. You could attempt to advocate for this practice, but I don't see anyone calling code that doesn't follow it a bad practice or anti-pattern.
For example, a typical business app that connects to an API needs to type the API responses. Will people create an NPM package to declare the application models? Unlikely. So we will write TS in-app. Furthermore, there will be some business-related code that we will be writing directly in the UI app, most importantly for security. This will be very specific to the app and most likely it will declare functions and services that need typing. Will devs be encapsulating this in an NPM package? No. It's only useful to this one app. It's a waste of time.
Now, to be fair: Since I suppose it is strictly possible to follow the encapsulation pattern you propose, I'll just say this is logical, but not practical.
Perhaps this is true for the extra bleeding edge features such as the
usingkeyword. Nevertheless, the official TypeScript Handbook notes thattscis typically meant for type-checking. That is to say, transpilation is an incidental feature rather than a first-class use case. More advanced transpilation and polyfilling still falls on the hands of build tools.To that end, I'd say the AI is correct with emphasis on the caveat that only the extra bleeding edge features are unavailable (which is a fair limitation to be honest).
Ah, I see where we have a misunderstanding now. When I say "library code", I mean this in the monorepo sense of the word. Taking Rust's package manager Cargo for example, we have first-class monorepo support, which enables us to treat a project as multiple sub-projects. The entry point project is the "application code" which imports the "library code" from the other sub-projects.
Now, this distinction is important because I believe we misunderstood each other when I say "library code". In this article, "library code" can be some locally linked sub-project in a monorepo/workspace or some other file that we import from the same project. The point being: "library code" is not necessarily a published NPM package.
I hope this clears up the confusion.
I guess it clears the confusion up, but I still think it is not practical.
I would make a
servicesfolder to accommodate data services, and I need to type those. Just because they are typed I won't create a newpackage.jsonto make it a sub-project. It is very impractical.What I mean to say is: The application will have application-specific code that is only useful in said application. Monorepos are overkill, in my opinion, for the gains. Speaking of which: What are the gains? Using
.jsfiles? Is that it? Transpilation time? What are the gains, exactly?If you are promiting "developer experience" here, what is that experience, exactly? To write code in a
.jsfile instead of a.tsfile? Code that would look identical in either? I think I am not understanding the gains, or maybe indeed the gains are minuscule. Do tell me.I totally agree. That is why I give some leeway in my definition of "library code" in that it can literally be any code you import from the "application code".
Of course! And for that reason, I reiterate that I give leeway to my definition of "library code" so that it also includes files of the same project. As long as they are imported somehow into the "application code", we may as well consider them to be "library code".
The main thesis of the article is that I have begun to treat the
.jsextension as a deliberate communication of the developer's decision to limit the application code to solely rely on type inference for type safety. In cases where type inference is insufficient, I upgrade the.jsfile into a.tsfile but as a last resort considering the most minimal surface possible.The "developer experience" that this scheme provides (at least in my experience) is that I can tell from the file extension alone which files in the project are "[dumb] application code" (for lack of a better word) and which files are the more interesting and meaty "library code".
Consider the application entry point for example. Seeing a
main.jsfile certainly jumps out more than amain.tsfile in a sea of.tslibrary code, right? Here, I find that the.jsextension now takes on a new meaning: "I am consumer code!"It seems that people cant get through their thick skull that Typescript does a lot of type inference and that nobody ever said that you should be ridiculously verbose:
Typescript !== Java.
I agree! Type inference is so powerful that in many cases,
.jsis surprisingly sufficient for type safety.There is no type safety in JavaScript. JsDoc comments and
.d.tsfiles are still typescript.Well, yes. But what I mean is that leveraging TypeScript-powered imports in plain old
.jsfiles can be sufficient for type safety (because of TypeScript's type inference). I didn't mean to say that JavaScript alone is type-safe.Ok, then I agree, although I still don't see a downside to using .ts as file extension 😜
A week ago I stumbles over this article called Turbo 8 is dropping TypeScript
I don't know Turbo 8, it's the reasoning of the writer that caught my attention. This section made me chuckle:
Reliable. We all experimented with TypeScript at some point. "Maybe it makes sense?" And then, after 3 hours, you realize you could have done it in 5 minutes with ES6.
For big projects and teams, it makes sense. For smaller projects/teams, it's an overkill IMHO.
Thanks for the article though. Respect and good luck!
I personally hated typescript, as how I needed to waste more time on fixing types which ultimately don't benefit me. The only thing that seems useful is when a package provides autocomplete and intellisense thanks to types provided too. Hopefully typescript is removed soon! I have been working on reejs (ree.js.org) which helps me to only get warnings on ide without slowing down the time required to compile it & fixing types which would stop me from proceeding to add new features to my app. I transpile ts to js code on the fly, and the process time is barely noticeable on a 12yr old pc.
So, I definitely see the points about not having to transpile the app.
I've also found that typescript can be extremely limiting at times.
I would say the biggest issue I've had with typescript over the years is that it has not really, IMHO, accomplished fixing the problem it set out to fix. At least not as I understand the problem.
I've been developing with JavaScript for decades. Over that time, I've learned that you have to be really disciplined with JavaScript in order to write code that won't bring down your entire team and project over time. In essence, tech debt in JavaScript accrues at a higher percentage rate than many other languages.
In comes Typescript to solve this issue. Unfortunately, in my experience, it hasn't worked. When I've worked in teams with undisciplined developers in Typescript that have been allowed to get away with letting tech debt into the code, I've had even more pain points with Typescript than JavaScript. I guess the main difference would be that I see those problems faster than I do with JavaScript and perhaps that's the good part, since I can address much earlier that the project is going south. In essence, my experience with Typescript is that the interest rate on tech debt in Typescript has been even higher and compounded more frequently than with JavaScript.
It's fine for disciplined developers, but so is JavaScript.
Without that, the peer review process is really the most important thing in a team.
I would highly encourage everyone to listen to this episode of JS Party with Rich Harris (creator of Svelte). They do a really good dive into the “war” between TS people and non-TS people, as well as the recent activity going on with TS and take very fair points for both sides. Extremely valuable information and stuff worth considering for all of us! 😀
Rich also touches on when TS is the “right” tool, and when it’s not.
I could be wrong but saying that you only need TypeScript partially in a project or the saying of using TypeScript led to poor developet experience, basically sounds like a red flag to me that those are the kind of people who don't understand the value and benefit of TypeScript and they have been forcing themselves to use it for no good reasons. You should only use it when you think it does what you need. It's either you go big or go home. You always have the choice to use whatever tools you need.
I'd like to clarify my position that I'm not advocating for the removal of TypeScript in a project. I very much rely on its type safety guarantees to enforce compile-time correctness for my applications (to some extend).
What I have presented in this article, however, is the usage of the
.jsextension in cases where full reliance on type inference is sufficient—in which case TypeScript-exclusive syntax is unnecessary. Now this.jsphenomenon is typically the case for application code, which imports the heavily typed library code written in TypeScript (i.e.,.ts). In my experience, the explicit separation of the.jsand.tsfiles thus offers clearer semantics between application/consumer code and library code, which ultimately makes it easier to navigate a codebase.My perspective on this, that either you use JSDoc or ts files its fine if it works for a specific project, both do type checking with typescript anyway.
But going back to just working with javascript for web applications is long term not sustainable, its a pain coming to a codebase that has plain JS (at least for me after I've worked with projects with typescript).
Regarding this, I'd like to reiterate one of my comments from another thread here.
I would argue the other direction, use typescript in your application vs. a library. I reason that if your library could be used by a js file then you need to build all the type checking into your library since it won't be validated at build time otherwise.
Using it in the app allows for quicker refactoring across the app, which is one of the best things and (I feel) is the main selling point of ts.
The main question I ask when someone wants to use ts vs js is 'What problem are you solving?' - then 'How much does this problem cost you?' - and lastly 'How much do you think going to ts is going to cost you?'
After those three you should be able to decide if you want ts. The problem is most of the time I see teams go to ts, because, well 'types' and I like types :)
Interesting direction you went with here. I have never considered that perspective. Personally, I'd still prefer TypeScript for library code just to avoid the performance hit from frequent runtime type validation.
Instead, I would use something like Zod at a centralized utility module to validate schemas during deserialization time. Then, I would use TypeScript for the rest of the library code under the assumption that the types are valid even in runtime (since I would be enforcing that all deserialization logic passes through the validation layer anyway).
I think the biggest contributor to build step being bad is Babel, not TypeScript.
It's always great to read your thoughts, @somedood . 😊
The preference for types is determined by the developer's inclination, not by whether it is an application or a library.
A comparison is needed between IDE support and the inconvenience of type writing.
I think that in applications, types will be preferred because they only need to use the types already written in libraries.
Libraries should write types to satisfy these users.
Which means this is backwards:
SvelteKit switched to JavaScript to gain ultimate control over the runtime code…
… but kept TS JSDoc in order to deliver consistent user types.
Meanwhile library consumers get the convenience of existing types in TypeScript while not having to write many types themselves.
If you have to produce extremely minimal, terse code for file size, avoiding compilation is very reasonable. Most JS projects do not have this requirement.
For the same reason it is better to use native CSS over using CSS-in-JS or SCSS if you have to make sure not one letter gets repeated.
In most cases more can be gained reducing the number of dependencies and choosing only lean dependencies.
Though in some cases it's simply about the desire to have runnable code without having to pass it through at best a transpiler or at worse
tsc.When an app becomes sufficiently complex, type checking becomes extremely helpful. If you write just a standalone page, perhaps it is less useful. But I would trade safety of types and not getting unexpected data for minor convenience any time.
I must reiterate one of my comments from another thread.
Again, I do not argue to remove type safety. I am arguing for the use of a
.jsfile where TypeScript-powered type inference is sufficient.I don't understand why should one be thinking over it instead of just using one thing everywhere.. I can see the purist point of view. For me though it's a negligible concern that would be a nuisance in the long run whenever a ts feature would need to be added to the file. Also inexperienced devs will surely apply it incorrectly - the distinction between app and lib code that you propose.
I suppose so, but in my experience, I have found it easier to navigate the codebase when the distinction between entry points, consumer code, and library code is clear from the file extension alone. Bonus points for those using code editors that have fancy file icons.
Maybe if you have created your own convention it works for you. I doubt it can work with random and especially inexperienced devs. Sounds to me though that you may achieve the same or better by a good project structure.
I'd like to note that the convention I am proposing seeks to augment an already existing project structure (regardless of whether you may consider it "good"). The discussion on a "good project structure" is irrelevant here (and also beyond the scope of my article) as I only intend to add new semantics on file extensions, not impose a specific project structure (aside from the separation of library code from application code which is arguably a best practice anyway).
New devs can pick up on the existing project structure. The extra file extension semantics are ideally just a cherry on top (that may or may not guide the further refactoring of library code).
Javascript first: absolutely agree, when you learn the language. After that TypeScript unless you need to write code that has to run in a console or a throwaway node.js one time script.
The way you must think of TypeScript is this is a productivity tool for your IDE. You write TS, because you want to know where and how things are going to be used. Try renaming a function in a JS codebase over a TS codebase.
For TypeScript to work super effectively you have to always look at the code you write from the perspective of the user of the code and the IDE: it provides clarity to each and relative safety.
When I do data transformation I rely extremely heavily on TS telling me what is my input and what is going to be the output. I can refactor my code while I have those in place. I cannot tell you how frustrating is to work with JS code and not knowing the exact shape of an object. How I need to double-triple check and infer what the gosh darn duck that silly object has or has not. I don't want to work with large JS code bases, because they halve my productivity. Time wasted on checks that can be done by machines.
Lastly there are two evil operators for which
anyholy warrior must resist temptation:asandany. Usually people cover their lack of understanding with those keywords and make TypeScript lie. And then they blame TypeScript being bad.I want to be clear here that I'm not advocating for the outright removal of TypeScript (and types) from the codebase. My preference for the
.jsfile is motivated by the fact that much of the application code that I deal with on a daily basis is often the subset of TypeScript that is literally just plain old JavaScript. The.jsfile extension is therefore syntactically sufficient for most application code. In this case, type safety solely hinges ontsserver's type inference.I came from mobile and my journey to web was the need to develop APIs without depending on third-party solutions. I tried python first and later node. I hated javascript because it made me get stuck for hours trying to figure out the problem with my code. When I discovered Typescript, everything became easier and I never had the problem of spending hours debugging the code again. The fact that I came from a typed language like C, Java and Kotlin made the learning experience easier and I decided to migrate to the web.
If you write any functions, adding types to the parameters makes the code way safer. If you're not writing any functions (doubtful) then you can get by with type inference of imports. Is a function in main.js considered "library code"?
Perhaps it could be. If type inference is sufficient (i.e., zero input parameters) or if one settles on JSDoc instead, then that function need not be removed from
main.js. But if the typing of the function becomes a little bit too complex, then perhaps it is time to consider upgrading it to a.tsfile as "library code".nice
Let’s limit the use of JS to scripting only to start with. To fix one problem created thousands other.