8 ms·

Meh. Choosing to write something in JavaScript that is wildly supported on every platform via browsers without having to deal with transpilation doesn't seem th

Meh. 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 ago
ESLint does not even support the browser. I think your first sentence is (I'm assuming accidentally) creating a straw man argument.
- capableweb 4y ago
  Yeah, 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 ago
  One of the stated goals of this rewrite is to support running in the browser.
- nerdbeere 4y ago
  From 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 ago
I 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.
- capableweb 4y ago
  I certainly wouldn't take a job in a place where they default to using TypeScript without thinking about the tradeoffs first. Cargo-culting never ends well, and there are no silver-bullets. I'm more afraid of those two "concepts" being a part of "company culture" than having to use JavaScript without TypeScript.
  - nsonha 4y ago
    I certainly would not hire a dev who thinks about their own convenience (not having to write types), instead of the consumers of their code (to have types as a form of documentation). Programming is too hard?
    - camgunz 4y ago
      Eng velocity is pretty precious isn't it? I would at least say the formula here is defects prevented by using typescript vs features delivered.
      - nsonha 4y ago
        no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.
        camgunz 4y ago
        Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - 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.
Aeolun 4y ago
If you are not writing your new javascript projects in Typescript I think you are just willfully hurting yourself.
spankalee 4y ago
Unit tests and types don't have as much overlap as anti-type people claim. You need both, and you shouldn't write tests for most of what type errors cover. 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.
selfmodruntime 4y ago
> Choosing to write something in JavaScript that is wildly supported on every platform via browsers 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.
- riquito 4y ago
  > First, eslint is a developer tool and not intended to run in the browser. from the linked article: "Yes, that means an officially supported browser version!"
  - freshbakedbread 4y ago
    The point still stands that an officially supported browser version can still be typescript transpiled to JavaScript.

bugmen0t 4y ago

ESLint does not even support the browser. I think your first sentence is (I'm assuming accidentally) creating a straw man argument.

capableweb 4y ago
Yeah, 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 ago
One of the stated goals of this rewrite is to support running in the browser.
nerdbeere 4y ago
From 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 ago

I 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.

capableweb 4y ago
I certainly wouldn't take a job in a place where they default to using TypeScript without thinking about the tradeoffs first. Cargo-culting never ends well, and there are no silver-bullets. I'm more afraid of those two "concepts" being a part of "company culture" than having to use JavaScript without TypeScript.
- nsonha 4y ago
  I certainly would not hire a dev who thinks about their own convenience (not having to write types), instead of the consumers of their code (to have types as a form of documentation). Programming is too hard?
  - camgunz 4y ago
    Eng velocity is pretty precious isn't it? I would at least say the formula here is defects prevented by using typescript vs features delivered.
    - nsonha 4y ago
      no one can count defects "prevented", even if it's possible that has not been done at a meaningful scale. Which renders your formula meaningless.
      - camgunz 4y ago
        Sure but, that's (one of my) point(s). I think type systems prevent some bugs, but I more view them as this analogy: - 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.

Aeolun 4y ago

If you are not writing your new javascript projects in Typescript I think you are just willfully hurting yourself.

spankalee 4y ago

Unit tests and types don't have as much overlap as anti-type people claim. You need both, and you shouldn't write tests for most of what type errors cover. 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.

selfmodruntime 4y ago

> Choosing to write something in JavaScript that is wildly supported on every platform via browsers 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.

riquito 4y ago
> First, eslint is a developer tool and not intended to run in the browser. from the linked article: "Yes, that means an officially supported browser version!"
- freshbakedbread 4y ago
  The point still stands that an officially supported browser version can still be typescript transpiled to JavaScript.