Assuming everyone should use TypeScript just because you happen to like it over JavaScript seems crazy. But I guess that makes me seem crazy to you, so here we are in a circle...
TypeScript seems to have entered the same hype cycle as Rust (if it didn't do it before Rust) where people seem to think that everything written in X should actually be written in Y instead (C/C++ => Rust and JavaScript/Any compile to JS => TypeScript). Doesn't mean every project have to follow that though.
> Runtime agnostic. ESLint should be able to run in any runtime, whether Node.js, Deno, the browser, or other. Runtime agnostic. ESLint should be able to run in any runtime, whether Node.js, Deno, the browser, or other. […]
I certainly would never take a job in a pure JS shop.
Could you please provide a list of these tradeoffs?
But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer.
As a second tradeoff, choosing JavaScript over TypeScript tend to make codebases less complect and more modular, at least in the teams I've been in who maintained codebases with both languages.
My experience with js-land is that choosing a typescript and make use of the @types packages is _the_ modern way of doing js dev. What you describe is basically do the same people did 15 years ago.
That is not a trade-off, but a refusal to re-evaluate the situation under changing conditions.
You've yet to provide even a single example.
As an aside, at least to me you're coming off as really combative in this thread. You might get more constructive responses to your posts if you adopted a more curious, open tone.
> type errors may be such a small proportion of your errors that a using a type checker isn't justifiable
This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is.
> As an aside, at least to me your posts are coming off as really combative in this thread
You are correct in this. Sorry. I will fix my comments to come off as less abrasive.
Oh super interesting! I wonder if the solution is like, tsc becomes a reference compiler. I'm pretty sure people would absolutely love a Rust implementation that was fast but a little behind. A lot easier to daydream about than to do though, haha.
> This is a bit biased. The major advantage I see in using typescript is that you can be certain an interface is exactly what it says it is.
Yeah and I do miss this in dynamic languages. Interfaces (and typed data structures) have great descriptive power just on their own. There are run time packages for this (prop-types, etc) but... run time is worse haha.
[citation needed]... My experience is the exact opposite. Javascript code bases I've worked with had crazy mega functions that would accept any arbitrary input and try to return something. Typescript code bases (in my experience) tend to be more modular because the interfaces between things are clearly defined. If you want to use code written by someone else, it's immediately obvious what structure your data needs to have to work with their code.
> But if I'd want something that is optimized for ease of install, ease of contributing to and minimal build tooling, choosing JavaScript over TypeScript is a no-brainer.
I mean, they are talking about having parts written in rust:
> Rust-based replacements. Once we have a more well-defined API, we may be able to swap out pieces into Rust-based alternatives for performance. This could look like creating NAPI modules written in Rust for Node.js, writing in Rust and compiling to WebAssembly, creating a standalone ESLint executable written in Rust that calls into the JavaScript portions, or other approaches.
That looks like an _extremely_ complex build system setup compared to using the Typescript. They are also planning to document the types anyway:
> ESM with type checking. I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS, but I do think rewriting from scratch allows us to write in ESM and also use tsc with JSDoc comments to type check the project. This includes publishing type definitions in the packages.
The only possible trade-off I can think of is that type checking with tsc + JSDoc results in a faster build than using typescript directly. Personally, I find it a bit odd to use tsc + JSDoc instead of TS, but hey, they can do what they want.
Like, you are theoretically correct, but practically the extra complexity of using Typescript over Javascript is running ‘npm install typescript’ after installing node. You certainly have less build tooling without tsc, but the benefit there is tiny.
There’s some mild reasons to go for pure JS, and a lot of absolutely gigantic reasons to go for Typescript (in my opinion).
Even Rust, which has a much stronger type system than TS, does not prevent all runtime errors. Types can prevent a certain class of bugs/errors, and that’s great, but zero runtime errors is overstating it by a wide margin.
Of course, everything is just tool. Its up to us to decide if we want to use it or not. What I don't understand is why wouldn't you use it. I totally understand if its fun to cobble together some webserver using only bash scripts. But if you're writing something as big, complex, and widely used as ESLint, I am very surprised if you don't choose something that is more performant and maintainable. It is almost irresponsible. I have plenty of fun side projects that should never ever be used in production because I know its really bad.
I never claimed that using Rust will magically make all your sort implementation correct. Of course this is an insane claim. But like I said, if you take any snippet of JavaScript, you actually cannot reason about it without looking at all the calls to that function, plus all the functions that calls to that. Given any variable S, what is its value? Who knows. I guess you just have to run this massive test suite that we wrote. There's WAY more possible incorrect JavaScript code than there are Rust.
I have written webservers in TypeScript and Rust. The moment I get something out of serde in Rust, I know for a fact this is a string. If the key doesn't exist, its None. In TypeScript, I don't have the same confidence. Did they wrote the correct validator? Wait did they add a default value? Does this interface match what we have? Oh its a string...but its actually Date. Wait...why does this bool keep returning false...(https://stackoverflow.com/questions/59046629/boolean-paramet...)
I could have written 1000s of unit tests...Or just use type and fail the "test" at compile time.
>there's anything wrong with working in language without static typing
Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.
> Yes there are. If Linux starts going backward (as in they are starting an effort to handwrite new drivers in assembly) and move in that direction, everyone else should rightly be really worried.
Frankly, I have a lot more confidence in something written in Python/Ruby/JS to not fail in a really dangerous way than I do something written in C. It's silly to pretend like all languages with types are equivalent, or that types are uniformly better for all use-cases.
Sure, the type systems in C/C++ will verify that you don't have type errors, but they can't verify that you don't have use-after-free errors, or out-of-bounds errors, or null pointer dereference errors, and so on. Even Java, which has an extensive and relatively modern type system, can't protect you from null pointer dereferences.
I never said "there's nothing wrong with working in a language without static typing for ANY PROJECT IN THE WORLD." Some projects need it, and some projects frankly don't. Linux, given its constraints, could not have been written in anything other than C. That's fine.
Very large projects in dynamic languages seem to eventually want type annotations, e.g. Dropbox (Python), Stripe (Ruby IIRC), and Facebook (PHP). But at the same time there are plenty of large, successful projects written in dynamic languages: GitLab (Ruby), Wordpress (PHP), much of emacs (Lisp), this very website (Lisp), Datomic (Clojure), CircleCI (Clojure). Sure, you can say that all of those projects should have been written in some statically typed language, but they have found success regardless, which is really the only metric that matters.
Besides, I’d imagine the deployed code would be minimized anyway regardless of whether TypeScript is used.
Which renders your formula meaningless.
- code formatter :: style
- type system :: tests
...which is to say that mainstream type systems tend to just unify what people in dynamic languages are doing ad-hoc in their test suites. As a result, I think their contribution to safety is overstated.
All of which is to say that posts in this thread coming out swinging for all of Typescript's safety improvements, while also arguing that it has no trade offs seem pretty off base to me. We can't even tell it's working most of the time.
> - type system :: tests
This is an oversimplification. To me types are also documents, and not a "here is the public/high level API, you don't need the details" kind of thing, it's document on public and private API.
Types are also tools that help you think about your system. I assume having a tool to think make you think more effectively, but I can't prove that.
Sure, empirical knowledge isn't the only knowledge there is, but this is what your proposal sounds like:
"Hi $TECHLEAD, I think we should use TypeScript because it's good documentation, and because it helps me think about the system."
My response would be: "that sounds like changing our whole development toolchain, which would be a lot of work and carries a lot of risk; what if we wrote some documentation instead?"
In A Philosophy of Software Design, John Ousterhout writes that (paraphrasing) because code is always an imperfect representation of a model, comments are required in order to fill in the gap. This rings true to me, and I'm skeptical that any type system--much less a mainstream one--could overcome what seems like a fundamental limitation of information. I'm more receptive to documentation: comments, code docs, arch docs, etc.
---
> so suggesting data driven decision making such as benchmarking because you don't trust Big-O
The reason people benchmark is because Big-O notation is incomplete: it doesn't describe n. You can't describe the performance of a system with Big-O alone. Maybe I'm digging into a poor example here, but I don't think it really fits in our discussion.
> quantifying typescript's benefits instead of actually thinking about them is a cop out
This is a little dismissive; I'm actually a person who likes types and misses them when I don't have them. I often move between languages (or the same language typed and untyped like Python or JS/TS). Consequently I have some experience across lots of different verification/validation/constraint/testing systems. My general take is that what your type system doesn't provide your tests can compensate for, and since you (should) have tests anyway, a type system's benefits are diminished. Further, tests can check things type systems can't, and can be traced to requirements. For example:
int add(int a, int b) {
return a - b;
}
Dynamic language communities have known about stuff like this for a long time. Indeed a lot of people are fans of TDD precisely for the reason you mention: tests are tools that help you think and reason about a code base. Types are not a silver bullet, there are always trade offs, software engineering is the agony of never really being sure but having to ship anyway.
Speaking of which, tests are often too verbose it hurt readability aka the ability to reason about your system
My point is that if you have tests, you probably don't need types, and since you really oughta have tests, the benefits of mainstream type systems are overstated. A lot of arguments in this thread are essentially "types have benefits you can't get anywhere else", but you can get them with tests. When it comes to verifying program correctness, tests are a super set of types' functionality.
> You can have less tests when you have more types.
Can you? In my dynamic language work the tests aren't doing type checks, usually there's some kind of validation library doing that. Generally the tests are doing work that types can't.
> There are type systems that requires an overhaul of the whole toolchain, but what we’re talking about typescript isn’t that.
I guess we can disagree about "overhaul", but IMO adding a compiler, new dependencies (types) and entirely new syntax to your toolchain qualifies. If that doesn't, what does?
> You can literally run plain js with jsdoc through tcs and make your comment provably accurate documentation
A few things foil this:
- using `any`
- using untyped libraries
- taking advantage of gradual typing
- unhelpful type soup
"Type soup" really bears expanding:
subscribeToMore(
options: {
document: DocumentNode,
variables?: TVariables,
updateQuery?: Function,
onError?: Function
}
) => () => void
Further, these types don't verify any behavior. They can't prove to you that `onError` is called when an error occurs. They can't prove to you that you will continue to receive data when it's updated. They can't prove to you that you subscribed to the specified document. On and on. There's a reason that high-reliability environments use tests, even though they're using strongly typed languages like Ada and Eiffel, and that's because type systems cannot fully specify a program's behavior.
[0]: https://www.apollographql.com/docs/react/api/react/hooks/#su...
TypeScript transpilation is easy and fast. You can emit JS even when there are type errors, and use tsc as just a type-checker while using esbuild to strip types from JS. Performance is not an issue in practice and the benefits are pretty far reaching.
This statement makes no sense in two ways and shows you're not as accustomed to the problems at hand as you'd perhaps like to be. First, eslint is a developer tool and not intended to run in the browser. Second, you generally do not distribute typescript code but compiled js to target platforms.
> TypeScript seems to have entered the same hype cycle as Rust (if it didn't do it before Rust) where people seem to think that everything written in X should actually be written in Y instead (C/C++ => Rust and JavaScript/Any compile to JS => TypeScript). Doesn't mean every project have to follow that though.
No, TypeScript is a superset of JavaScript that can be enabled with little cost for the gigantic benefit of bringing type safety to a language which people have mocked for its unsafety for decades.
I really wish people on HN would hold back a little with their contrarian purism at all cost.
from the linked article: "Yes, that means an officially supported browser version!"
This sounds like everyone wins except the people who are overly-dogmatic about TS.
What about Deno or people using it in web-only contexts?
If they use ES-compliant modules, a build step isn't even required.
Once again, it's not that they don't have types, but the TS fanboys are now complaining that it's "not the right types".
i was under the assumption that deno natively supported typescript, no?
Since the new ESLint is going to be highly modular, TS would shine in defining these modules' interfaces in a robust way. Whether to use TS deeper down, or whether to enforce the use of TS across the codebase, is another question. Prototyping is often easier and faster with plain JS, while typing well-defined parts later may be helpful for maintenance purposes.
I disagree, especially in the realm of AST-crawling, that having type hints in the IDE has been extremely beneficial in moving fast.
Type-level refactoring tools don't seem to be very powerful at the moment, too; without them, you can end up with some legwork when you change a design decision (a frequent thing while prototyping), even if you carefully aliased every type (which is legwork in its own right, because trivial cases like 2-tuples are plentiful).
Fortunately, TS allows you to gradually type your code, and rely on inference in many cases (not as much as Haskell, but still).
Bonus points if it comes in notebook form so you get a nice convenient run button, a solid multiline text editor, and markdown-powered persistence format.
Thankfully, this already exists: https://marketplace.visualstudio.com/items?itemName=jakearl.... . And it supports every language your shell does!
(I made it)
https://www.typescriptlang.org/docs/handbook/jsdoc-supported...
Every bug to to ever hit production has
* passed all manual testing
* passed all unit tests
* passed the type checker
Or been ignored. It happens.
> passed all unit tests
If they have been written at all. And every bugfix should come with a regression test.
> passed the type checker
If it hasn't been disabled. And I would expect that a bug that could be fixed with better typing would include making types more restrictive when necessary.
Unfortunately, tools like testing and types are seen in two conflicting ways. Some people embrace them and see that they can use them to write better code with less bugs. Others see them as obstacles that have been placed in their way due to the additional learning curve.
What isn't helpful is the the notion that types replace testing. Either manual testing or unit/functional/generative testing. It isn't "safer" at all, it does speed up development by catching the simple bugs so the run edit compile loop is less. If you're saying "my code compiles then it's works", I don't buy it.
I'm glad that you agree type checkers help avoid error prone and expensive manual testing work.
> What isn't helpful is the the notion that types replace testing.
Types are a type of testing. They are another tool in the toolbox for writing correct programs.
But what bugs did you not see hit production because these eliminated it?
I disagree. The lesson learned from a decade of js tooling is performance issues.
That is why you see more and more js tooling rewritten in rust or other fast languages.
This is GOOD for js development, in the sense you end up with better faster more powerful tooling.
Now whether you use JS at all is a completely different point, but I think the parent was making a point about TS > JS, than TS > other languages.
It's Flow that just allows to remove any type annotations; there's no compiler, only typechecker.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This gets a bit more complicated in some setups because the typescript compiler can also transpile modern JS/TS code to older versions, doing a similar job to Babel, but this doesn't have to be the case, and in practice this tends to be fairly orthogonal to the question of Typescript: you can compile to older versions regardless of whether you use Typescript, and you can use Typescript regardless of whether you compile to older versions.
So in practice, there will be no difference between a Typescript program and an equivalent idiomatic Javascript version, because Typescript is just Javascript with syntax for type hints.
The main exceptions are enums, and decorators, both of which perform straightforward transformations. My understanding is that adding new such features are forbidden as the TypeScript team considers them to be historical mistakes. If new syntax is added in the future is should be such that it can be mechanically stripped, leaving the obvious underlying JS behind.
There also exist some historical features like namespaces or const enums that have long been considered essentially deprecated by the team (not marked as such in the documentation, as there are no plans to actually delete support for them, but they won't work correctly in isolatedModules mode for example). In practice those features are not used in new codebases since project templates will be configured with isolatedModules enabled.
The advocacy for Typescript is for type safety. Using Rust hits that same benefit.
> ESM with type checking. I don't want to rewrite in TypeScript, because I believe the core of ESLint should be vanilla JS, but I do think rewriting from scratch allows us to write in ESM and also use tsc with JSDoc comments to type check the project. This includes publishing type definitions in the packages.
This is such a heated debate, and so many posts here are just simply wrong about the capabilities of using TypeScript as a type checkers.
A statically typed code base is a primary goal of the author, they simply pick to do it using JavaScript and annotating the types in JSDoc comments, using TypeScript only as the static type checker, which is an available—and well supported—option in TypeScript.
> Choosing to use JS without TS at this point has become a dogmatic statement of purism that, while beautiful in a sense, is so unpragmatic as to appear a little foolish.
You’re parent is simply just wrong here, and it is quite frustrating how many posts here simply take up this talking point and repeat it.
It doesn't seem that performance was the driving factor, but the ability to keep code idiomatic?
https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...
> Incremental compile time when changing files in cli/js takes minutes. This is crushingly slow and painful to modify.
> The typescript organization/structure that we're using in cli/js is creating runtime performance problems.
Either way, my point is that there are very practical non-dogmatic reasons to use JS over TS.
But if you're building developer tools or libraries and want the output to be optimized for the end-user, introducing a middleman like tsc or esbuild can have tradeoffs. This is likely what the ESLint team considered.
opentelemetry.js is already an architectural nightmare (clearly built by people who use J2EE), but the fact that it's Typescript makes it ten times worse because I can't set breakpoints. I have to step all the way in every single time. Through layer after layer of delegation. So much delegation they had to pull out a thesaurus to name things.
JSDoc can do a lot of the things that Typescript does. Use it.
The goal is type safe code, and there are multiple paths that get you to that goal. Pretending that TS is the only, golden path and everyone else is hopelessly wrong -requiring hyperbole to mock even- suggests having lost sight of the actual goal itself.
Choosing to use JS without TS at this point has become a dogmatic statement of purism that, while beautiful in a sense, is so unpragmatic as to appear a little foolish.
It's like insisting on using the pre-electronics version of a powerful, dangerous machine even though the new version gives you just as much control, greater precision, and much better safety, because of a romantic notion of purity in the way things should be done. Admirable and not at the same time.