3 ms·

I'm not sure why nobody is talking about TypeScript? If browsers were to natively support it, that would be a game changer. We could phase out quirky features o

I'm not sure why nobody is talking about TypeScript? If browsers were to natively support it, that would be a game changer. We could phase out quirky features of JS and mark them as obsolete in IDEs. More use of the Map class for example would avoid some quirks of using objects.

toxicFork 4y ago
I guess we would not need to compile it down to js and instead evaluate or jit it directly? Could someone do this on an open source browser perhaps? Or would it require some initial big chunk of work?
indy 4y ago
I'm surprised that Microsoft haven't already done this with their Edge browser. At least offer a 'developer' mode which enables TypeScript support only during development
- deleted 4y ago
  [deleted]
- mlajtos 4y ago
  Don't give them ideas. https://en.wikipedia.org/wiki/JScript https://en.wikipedia.org/wiki/JScript
  - protomolecule 4y ago
    Why not? https://en.wikipedia.org/wiki/XMLHttpRequest#History https://en.wikipedia.org/wiki/XMLHttpRequest#History
neongreen 4y ago
Map is in JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... TypeScript is designed in such a way that type annotations can't influence the runtime behavior. This is unlike e.g. Haskell, where types can drive code generation. Happy to elaborate more if necessary. This means that transpiling TypeScript to JavaScript consists merely of stripping the type annotations + transpiling some of the syntactic features that might not be supported by the target JS version. The "Type Annotations" proposal (https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations), IIRC championed partly by the TS team, will allow type annotations with almost-TS-like-syntax in plain JavaScript, which will make the "stripping type annotations" step unnecessary. You would still use the TS tooling to actually type-check the code, though. Which exact part of TS do you want to be built into browsers?
- indocomsoft 4y ago
  Do you mind elaborating more on Haskell's types driving code generation? Genuinely curious
  - wruza 4y ago
    The regular type-based polymorphism/overloading, afair. Just like in C++. Typescript has a way to simulate it, but the code remains the same as if there were no types/overloads. https://www.typescriptlang.org/docs/handbook/2/functions.html#function-overloads https://www.typescriptlang.org/docs/handbook/2/functions.htm...
- trinovantes 4y ago
  There's still non-const enums generating runtime code I think it would be huge if some future nodejs/web browser can parse native TS so we no longer need to deal with the mess of dev tools like ts-node and babel and wonder why some folder structure or sourcemap is not working
chombier 4y ago
What about ReScript? As far as I understand ReScript has a sound type system which would make it an even better foundation?
kragen 4y ago
We can't phase out features of JS in browsers, quirky or otherwise, because that would prevent us from running existing, fully debugged, standards-compliant web pages. It would mean that programming for the web was like depositing rare books in a library that was already on fire.

toxicFork 4y ago

I guess we would not need to compile it down to js and instead evaluate or jit it directly? Could someone do this on an open source browser perhaps? Or would it require some initial big chunk of work?

indy 4y ago

I'm surprised that Microsoft haven't already done this with their Edge browser. At least offer a 'developer' mode which enables TypeScript support only during development

deleted 4y ago
[deleted]
mlajtos 4y ago
Don't give them ideas. https://en.wikipedia.org/wiki/JScript https://en.wikipedia.org/wiki/JScript
- protomolecule 4y ago
  Why not? https://en.wikipedia.org/wiki/XMLHttpRequest#History https://en.wikipedia.org/wiki/XMLHttpRequest#History

neongreen 4y ago

Map is in JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... TypeScript is designed in such a way that type annotations can't influence the runtime behavior. This is unlike e.g. Haskell, where types can drive code generation. Happy to elaborate more if necessary. This means that transpiling TypeScript to JavaScript consists merely of stripping the type annotations + transpiling some of the syntactic features that might not be supported by the target JS version. The "Type Annotations" proposal (https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations), IIRC championed partly by the TS team, will allow type annotations with almost-TS-like-syntax in plain JavaScript, which will make the "stripping type annotations" step unnecessary. You would still use the TS tooling to actually type-check the code, though. Which exact part of TS do you want to be built into browsers?

indocomsoft 4y ago
Do you mind elaborating more on Haskell's types driving code generation? Genuinely curious
- wruza 4y ago
  The regular type-based polymorphism/overloading, afair. Just like in C++. Typescript has a way to simulate it, but the code remains the same as if there were no types/overloads. https://www.typescriptlang.org/docs/handbook/2/functions.html#function-overloads https://www.typescriptlang.org/docs/handbook/2/functions.htm...
trinovantes 4y ago
There's still non-const enums generating runtime code I think it would be huge if some future nodejs/web browser can parse native TS so we no longer need to deal with the mess of dev tools like ts-node and babel and wonder why some folder structure or sourcemap is not working

chombier 4y ago

What about ReScript? As far as I understand ReScript has a sound type system which would make it an even better foundation?

kragen 4y ago

We can't phase out features of JS in browsers, quirky or otherwise, because that would prevent us from running existing, fully debugged, standards-compliant web pages. It would mean that programming for the web was like depositing rare books in a library that was already on fire.