4 ms·

> And TypeScript of course runs natively on browsers As a backend engineer I was thinking, "Whoah, the frontend is moving so fast that browsers support Typescr

> And TypeScript of course runs natively on browsers As a backend engineer I was thinking, "Whoah, the frontend is moving so fast that browsers support Typescript natively!" But it turns out the author is either uninformed, or, more likely, just being sloppy.

beardyw 1y ago
And >Rust targets system software or places where efficiency is paramount. Well, if that's all you want you could use C! Maybe it's written by AI.
- pjmlp 1y ago
  Actually if efficiency is paramount, Assembly would be the right answer.
  - msla 1y ago
    That only gets you efficiency on one system, as dictated by microarchitecture. You are observing the rules to write efficient code, correct?
    - pjmlp 1y ago
      It gives more than C, as the days of it being a portable high level assembly are long gone. Plus for those that love their pre-processor, proper macro assemblers are quite powerful, unlike those UNIX assemblers that were designed to be used as part of C compilation pipeline with very few amenities.
DanielHB 1y ago
There are some proposals for browsers to do type-stripping, removing/ignoring type-annotations so typescript (and flow) don't need transpilation anymore (except for enums I guess). NodeJS already started doing that in the latest version as well.
- WorldMaker 1y ago
  Direct link to the Stage 1 proposal: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
  - DanielHB 1y ago
    Thanks, interesting that there are a lot more typescript things that wouldn't be covered by the proposal besides enums (class/fields modifiers, function overloading, declare keyword, namespaces). Meaning the proposal would only really be useful for fairly small projects. It would be nice to have bundlers not need to do any transpilation at all while in dev mode, but this will not get us 100% there (even for non-JSX projects).
    - WorldMaker 1y ago
      Typescript has had the "erasableSyntaxOnly" compiler option for a couple versions now. Running it on a medium sized or large code base isn't terrible. With Node now supporting type-stripping, you can run entire large code bases without compilation today after that flag, so there's some benefit to doing it. (If for some reason you need to support an out-of-support Typescript version, eslint has had linter rules that match "erasableSyntaxOnly" for even longer.) > (class/fields modifiers, function overloading, declare keyword, namespaces) Most of the class/field modifiers have standard JS ways to do them today (#field for private, [symbolField] for protected/"internal"). The nicest one to have and hardest to replace is `readonly` used to enforce at compile time that a field is only ever set once at initialization. There are workarounds with properties and property syntax and a workaround to use a JSDoc comment. Function overloading and declare keyword can generally be handled by moving everything to an appropriate .d.ts file. Also a lot of function overloading can be taken care of today in more JS-friendly ways with union types or `unknown` with type guards that better matches the runtime experience of JS. (I realize that there are definitely still edge cases that can be easier to write as function overloads than as `unknown` with type guards, but they seem so much fewer than ever.) I personally have only found one use case for namespaces in a while that isn't solved with module (re-)architecture (including "exports" at the package level architecture) and/or symbol-named things. That use case is silliness involving passing JSX type information. Typescript is a little weird about how it wants to pick up JSX types. It should still work in a .d.ts and that's on my TODO list of things to try soon (I'm working on a rewrite of a JSX-based view engine where one of the motivations for the rewrite is to get possibly really wild with JSX types because moving from one `jsx` function to many, for interesting reasons). I know the "gentle merge" of namespace will be missed by some, but the code it generates is easy to reproduce in pure JS and will be very familiar to anyone who did a lot of jQuery era `window.myObject = window.myObject || {}` dances, which were the style at the time and that to get that to type how you need it to you'll need a lot more `as unknown as MyExtendedObject` type dances. But also that's a somewhat better type representation of what you are doing with those sorts of multiply expanded objects.
tmaly 1y ago
This would actually be amazing if it were true.

beardyw 1y ago

And >Rust targets system software or places where efficiency is paramount. Well, if that's all you want you could use C! Maybe it's written by AI.

pjmlp 1y ago
Actually if efficiency is paramount, Assembly would be the right answer.
- msla 1y ago
  That only gets you efficiency on one system, as dictated by microarchitecture. You are observing the rules to write efficient code, correct?
  - pjmlp 1y ago
    It gives more than C, as the days of it being a portable high level assembly are long gone. Plus for those that love their pre-processor, proper macro assemblers are quite powerful, unlike those UNIX assemblers that were designed to be used as part of C compilation pipeline with very few amenities.

DanielHB 1y ago

There are some proposals for browsers to do type-stripping, removing/ignoring type-annotations so typescript (and flow) don't need transpilation anymore (except for enums I guess). NodeJS already started doing that in the latest version as well.

WorldMaker 1y ago
Direct link to the Stage 1 proposal: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
- DanielHB 1y ago
  Thanks, interesting that there are a lot more typescript things that wouldn't be covered by the proposal besides enums (class/fields modifiers, function overloading, declare keyword, namespaces). Meaning the proposal would only really be useful for fairly small projects. It would be nice to have bundlers not need to do any transpilation at all while in dev mode, but this will not get us 100% there (even for non-JSX projects).
  - WorldMaker 1y ago
    Typescript has had the "erasableSyntaxOnly" compiler option for a couple versions now. Running it on a medium sized or large code base isn't terrible. With Node now supporting type-stripping, you can run entire large code bases without compilation today after that flag, so there's some benefit to doing it. (If for some reason you need to support an out-of-support Typescript version, eslint has had linter rules that match "erasableSyntaxOnly" for even longer.) > (class/fields modifiers, function overloading, declare keyword, namespaces) Most of the class/field modifiers have standard JS ways to do them today (#field for private, [symbolField] for protected/"internal"). The nicest one to have and hardest to replace is `readonly` used to enforce at compile time that a field is only ever set once at initialization. There are workarounds with properties and property syntax and a workaround to use a JSDoc comment. Function overloading and declare keyword can generally be handled by moving everything to an appropriate .d.ts file. Also a lot of function overloading can be taken care of today in more JS-friendly ways with union types or `unknown` with type guards that better matches the runtime experience of JS. (I realize that there are definitely still edge cases that can be easier to write as function overloads than as `unknown` with type guards, but they seem so much fewer than ever.) I personally have only found one use case for namespaces in a while that isn't solved with module (re-)architecture (including "exports" at the package level architecture) and/or symbol-named things. That use case is silliness involving passing JSX type information. Typescript is a little weird about how it wants to pick up JSX types. It should still work in a .d.ts and that's on my TODO list of things to try soon (I'm working on a rewrite of a JSX-based view engine where one of the motivations for the rewrite is to get possibly really wild with JSX types because moving from one `jsx` function to many, for interesting reasons). I know the "gentle merge" of namespace will be missed by some, but the code it generates is easy to reproduce in pure JS and will be very familiar to anyone who did a lot of jQuery era `window.myObject = window.myObject || {}` dances, which were the style at the time and that to get that to type how you need it to you'll need a lot more `as unknown as MyExtendedObject` type dances. But also that's a somewhat better type representation of what you are doing with those sorts of multiply expanded objects.

tmaly 1y ago

This would actually be amazing if it were true.