19 ms·
I have to say, I think they'd be crazy not to write the new version in TypeScript. Choosing to use JS without TS at this point has become a dogmatic statement
by rattray 4y ago
I have to say, I think they'd be crazy not to write the new version 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.
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.
- h1fra 4y agoit's even weirder to say that and then say that you will add jsdoc, use tsc and publish types = having the exact the same processes without having a .ts at the end ahah
- hajile 4y agoJSdoc comments are 100% JS while TS types are not. This means you will be able to run ESLint without a TS compiler while still having types for people who want them. It's also more future-proof for if/when JS adopts a type system that may or may not be compatible with TS. This sounds like everyone wins except the people who are overly-dogmatic about TS.
- EduardoBautista 4y agoIf ESLint were rewritten in TS, you would still be able to run it without the TS compiler, since it would already be compiled into regular JS when published to NPM.
- hajile 4y agoWhy should you be forced to deliver via NPM? 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".
- arrakeen 4y ago> What about Deno or people using it in web-only contexts? i was under the assumption that deno natively supported typescript, no?
- capableweb 4y agoMeh. Choosing to write something in JavaScript that is wildly supported on every platform via browsers without having to deal with transpilation doesn't seem that foolish to me. TypeScript solves a small sub-section of problems that can be solved in other ways too, like extensive unit tests, but that also comes with tradeoffs, just like using TypeScript comes with tradeoffs. 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.
- bugmen0t 4y agoESLint does not even support the browser. I think your first sentence is (I'm assuming accidentally) creating a straw man argument.
- capableweb 4y agoYeah, you're right, it doesn't quite apply here. But I think the general idea applies. JavaScript is supported, used and known by more developers than TypeScript, no matter if it's in the browser or not.
- pritambaral 4y agoOne of the stated goals of this rewrite is to support running in the browser.
- nerdbeere 4y agoFrom the github issue: > 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. […]
- cageface 4y agoI can't imagine maintaining a large JS codebase without types now. For places where you really need dynamic typing the any type is there for you. I certainly would never take a job in a pure JS shop.
- tobr 4y ago“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” honestly sounds like a dogmatic statement.
- nsonha 4y agoin the same sense that "wear a mask" is dogmatic
- sieabahlpark 4y ago
- nine_k 4y agoWhile I'm in favor of TS, I'm in favor of it for practical reasons. 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.
- madeofpalk 4y ago> Prototyping is often easier and faster with plain JS I disagree, especially in the realm of AST-crawling, that having type hints in the IDE has been extremely beneficial in moving fast.
- nine_k 4y agoI have very often seen prototype code crafted in a REPL, not in an IDE. That's where the fluidity comes in handy. 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).
- jakear 4y agoWhat you want is a prototyping REPL, in your IDE, that gives you type hints, type aware autocomplete, and inline type errors, but knows to back the fuck off when you want to just run the code and perform simple type-stripping rather than erroring out and telling you to fix types or GTFO. 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.handydandy-notebook https://marketplace.visualstudio.com/items?itemName=jakearl.... . And it supports every language your shell does! (I made it)
- wwwigham 4y agoEh, wanting to dogfood the JS tooling you're writing is a fairly valid reason, imo. Would dogfooding on TS cover many JS usecases? Sure. But inevitably some things are different. I'm somewhat sympathetic.
- gregors 4y ago"much better safety" Every bug to to ever hit production has * passed all manual testing * passed all unit tests * passed the type checker
- pohl 4y agoEveryone who has died drank milk.
- Kinrany 4y agoThis is a fully general argument for debugging in production.
- __alexs 4y agoI have written and shipped many Python bugs that did not pass the type checker but it was impossible to run the type checker because it would not be invented until many years later.
- gregors 4y agoIf you had a type checker bug you didn't you manually test that code path at the bare minimum. Type check bugs are the most simplistic bugs to catch. Is it nice sure, but if you can't spot those before you ship I can almost guarantee that you have larger logic bugs that the types won't catch. 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.
- __alexs 4y ago> If you had a type checker bug you didn't you manually test that code path at the bare minimum. 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.
- aew4ytasghe5 4y ago> I have to say, I think they'd be crazy not to write the new version in TypeScript. 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.
- ratorx 4y agoJS vs TS does not impact runtime performance. 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.
- capableweb 4y agoNot directly, but it becomes harder to reason about performance unless you're familiar with the TS compiler and/or it's output. Once you identified a performance issue related to the JS VM(s) you're targeting, it's also harder to resolve the issue. This is true for every "compile to JS" language and TS is no exception.
- pitaj 4y agoRealistically, that simply doesn't apply to TS, because the conversion to JS literally just removes types.
- nine_k 4y agoNot always, because certain operations that look trivial in TS involve more code in JS, e.g. the widespread `?.` operator. The code is usually trivial though. It's Flow that just allows to remove any type annotations; there's no compiler, only typechecker.
- mcluck 4y agoYou're mistaken. Optional chaining is a JavaScript feature[1]. The stated goal of TypeScript is to be valid JavaScript when the types are stripped away. That's why they have functionally removed namespaces and they want to remove enums. They're the only language features that are actually compiled instead of just stripped. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- roebk 4y agoThey are choosing TypeScript, they're opting into type checking with JSDoc and tsc. For a brand new code base, you could argue that it would make sense to jump in and write TypeScript, but JSDoc and tsc will get them most of the benefits. It's almost a non-issue.
- frou_dh 4y agoIt's illustrative of how crazed some TypeScript advocates have become, that any deviance whatsoever causes them to be shocked and appalled, as some have expressed in this comments section. People, if you must be religious about a programming language, at least find a more enthralling god than a JS superset!
- runarberg 4y agoFrom the article: > 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.
- yrgulation 4y agoTypeScript is great for inexperienced devs, so i dont see why they should use it for eslint. Is there any benefit in using a language that transpiles to a different language that then gets interpreted that you had in mind?
- kevinfiol 4y agoYou are wrong, and the statement that it is based on dogmatism is completely baseless. A couple years ago, the Deno team switched from TS to JS for performance reasons because compiling the TS code became painfully slow. This was an entirely practical reason. Similarly, a lot of JS package authors choose to use JS in conjunction with JSDocs, type def files, and tsc (see: Preact).
- e12e 4y ago> A couple years ago, the Deno team switched from TS to JS for performance reasons because compiling the TS code became painfully slow. 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_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/mobilebasic#heading=h.cx5nx247bag https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...
- kevinfiol 4y agoI may be misreading, but from the first two bullets under "Problem": > 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.
- jakear 4y agoThis decision turned me off from Deno in a big way. It's as if they actively refused to look out to the community to see if the problems were solvable before throwing in the towel. It's quite possible to have instant incremental updating of TS projects, when I was a developer on VSCode (a much larger TS/JS project than deno) a change to the source code would be reflected in my dev build in less than 100ms.
- spankalee 4y agoDeno integrating TypeScript at all was a big mistake, but that doesn't mean that TypeScript at build time isn't a god idea, or that transpilation can be extremely fast with tools like esbuild.
- kanonieer 4y agoIt seems that some TypeScript and Rust devs are converging in their holier than thou approach, never missing an opportunity to belittle people for not choosing a tool they would have chosen.
- Aeolun 4y agoIt’s because I have to work with the thing. The current ESLint codebase is almost impenetrable. I enjoy people choosing tools I would have chosen.
- selfmodruntime 4y agoI'd say it's more that people are still using archaic tools because of altruistic purism and that contributing to a gigantic js only project like ESLint is a daunting task.
- joshxyz 4y agopros use jsdoc ts, hehe. for real, it's less the hassle.
- hinkley 4y agoJetbrains still doesn't know how to set breakpoints in third party Typescript code. 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.
- TheRealPomax 4y agoNot seeing a "why" here, though. If you like TS, go use TS, but if you want type checking then JSDoc does that job rather well and forces you to treat documentation as a first class citizen, too. With the obvious bonus of not needing to be compiled: the code you wrote is the code that runs, while having all the features in place to perform type checking. It just goes about it in a different way. 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.
- replygirl 4y agois there a well-maintained and widely-adopted cli type checker for jsdoc other than eslint-plugin-jsdoc though?
- TheRealPomax 4y agoYou had me until "though": it sounds like you're saying that you need more than the one that already works?