4 ms·

If history is an indication, any part of the JavaScript ecosystem that is not part of a formal standard, no matter how widely used or deeply integrated into the

by hliyan 3y ago

If history is an indication, any part of the JavaScript ecosystem that is not part of a formal standard, no matter how widely used or deeply integrated into the industry, is prone to getting replaced or obsoleted. There was a time when front-end development without jQuery was unthinkable. We now seem to be slowly coming out of any era when front-end development without reactive component based SPAs (React, Angular etc.) was unthinkable. I suspect that in the long run, compile-to-JS type systems will go the same way. Perhaps the alternative is a set of optional run-time validation capabilities built into ECMAScript (syntactic sugar over `typeof`?), whatever that may be.

javier123454321 3y ago
Honestly the TC39 is the best case scenario. https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/ Forget runtime type validation, TS is really for preventing bugs at development time as well as IDE integration.
- josephg 3y ago
  If types were added to javascript it could also dramatically improve the performance of javascript virtual machines (V8 and friends). It seems so silly to me that I write typescript, then the types are erased from my code, sent to the browser, and then the browser tries to infer them as part of its own optimization process. Adding types to javascript proper would be fantastic.
  - bazoom42 3y ago
    > If types were added to javascript it could also dramatically improve the performance of javascript virtual machines Are you sure? In my understanding modern JS engines basically makes type inference on the code anyway, and in the rare case when types are observed to change at runtime, it is special-cased. So static types might simplify this but I dont see how it would dramatically improve performance.
    - IshKebab 3y ago
      This is a good read: https://medium.com/dartlang/dart-and-the-performance-benefits-of-sound-types https://medium.com/dartlang/dart-and-the-performance-benefit... That said I really doubt JS will actually get sound static types ever. Typescript is not sound.
      - auscompgeek 3y ago
        That Medium link 404s for me.
        homarp 3y ago
        https://medium.com/dartlang/dart-and-the-performance-benefits-of-sound-types-6ceedd5b6cdc https://medium.com/dartlang/dart-and-the-performance-benefit... works for me or https://web.archive.org/web/20210310020311/https://medium.com/dartlang/dart-and-the-performance-benefits-of-sound-types-6ceedd5b6cdc https://web.archive.org/web/20210310020311/https://medium.co...
    - olejorgenb 3y ago
      And chances are(?) typescript code are to a larger degree monomorphic than javascript making the JIT more efficient(?). At least typescript discourage writing functions where the parameters can have wildly different types since this is un-ergonomic and/or hard to type.
  - vbezhenar 3y ago
    This proposal is not about adding types to JavaScript. This proposal is about new syntax for comments in JavaScript. Virtual machine will not use this information.
imgyuri 3y ago
indeed, it's almost a certainty that every framework and tool in the JS ecosystem becomes obsolete as time goes by.
Xenoamorphous 3y ago
Disclaimer: I’m not a frontend dev so what I’m about to say might very well be nonsense, but I thought that jquery became popular not due to shortcomings in the JS language, but in the DOM API. So I think TypeScript is a very different case, as it fills a void in the language itself (lack of types). That doesn’t mean that in the future types won’t be added to the lang spec, but if that happens I think it would be very heavily influenced by TypeScript (e.g. like what happened with Hibernate and JPA).
- phatskat 3y ago
  Correct, at least from my experience. In my personal projects I was heavily Vanilla JS, but I also didn’t care if IE didn’t have full functionality (I did try to use graceful degradation when functionality was important, like navigation), but in any professional setting it would be maddening to rely on JS and not use something like jQuery. Coding around how each browser decided to give scroll position or the differences in accessing other DOM properties by hand could be tedious depending on what you wanted to do, and jQuery abstracted that effectively. I think you’re correct that, if the language formally adopted types, it would look similar to TypeScript. How _much_ of TS would be mirrored may be a different story - it’s incredibly extensive in some areas, I’m still learning new things about it as I’ve only recently started getting into it for work, and there’s a lot to it beyond basic type support.
- irrational 3y ago
  Jquery became popular because at the time there were all these browsers and none of them did things the same. They weren’t standards compliant like most browsers are today. So you ended up writing a ton of code and css that basically said, “if browser x - do this - else if browser y - do this”. Then jQuery came along and took care of all of that for you. They made it so you could just write for jquery and it would take care of translating it into what browser the person viewing the site was using. It made things so much easier. jQuery was basically write once, run everywhere, for the browsers of those days.
weinzierl 3y ago
I suspect that in the long run, compile-to-JS type systems will go away and will be replaced by compile-to-WASM type systems.
- zarzavat 3y ago
  After having used WASM on the client side, I have my doubts. It is too much of a drag on productivity using less featureful developer tools, and JavaScript is already plenty fast enough. WASM is good for things that need to be as fast as possible, but for the vast majority of use cases it simply doesn’t offer any benefits. The advantage of JS is that the browser is aware of your object graph and can provide dev tools around that.
  - runlaszlorun 3y ago
    In my experience and in other benchmarks I’ve seen WASM runs basically the same as JS. Faster in some benchmarks, slower in others. The JIT in V8 and others is pretty solid.
  - antihero 3y ago
    Isn’t the idea that wasn’t means you can expose the web etc APIs to any language? Eventually there will be tooling that will make this a doddle.
    - zarzavat 3y ago
      It doesn’t approach the convenience of JS dev tools. For example, you can’t have a REPL and high-level debugger combo, you just get a very basic low-level debugger. It’s a 90s debugging experience. You can’t even have a modern low-level debugger because you can’t control how the browser executes your WASM, unlike in a native executable where you can run a debugger and then run your code inside it. I guess you could have a WASM based debugger that has a WASM interpreter inside, and then you run your code inside that, but my God if that’s the future then I want no part of it.
  - chii 3y ago
    > WASM is good for things that need to be as fast as possible i would've thought that WASM was really only "good" for reusing existing software written in other languages not intended for the web, by recompiling it into WASM. For example, you want to create a web version of an app written with QT or some other widgeting framework which could get a WASM target.
rapind 3y ago
> I suspect that in the long run, compile-to-JS type systems will go the same way. I think the plan was to compile to WASM. The hype phase seems to be over, but afaict it’s been delivering on at least some of it’s promises no?
mhoad 3y ago
I actually think about this I’m entirely the opposite way. The moment all browser APIs especially the DOM become usable from WASM it’s over for JS and would no longer be the obvious choice as it’s suddenly not the only game in town and the hacks that were required before such as compile to JS for example stop mattering.
- solumunus 3y ago
  “The moment”? You’re living in a fantasy. JavaScript would still be highly relevant and used for decades to come.
TrickyRick 3y ago
jQuery is a bit of a poor example in the context since most of the stuff jQuery provides HAS been integrated into the standard making the lib obsolete. If the ES standard introduces types in a good way that will of course make TS obsolete.

by hliyan 3y ago

javier123454321 3y ago

Honestly the TC39 is the best case scenario. https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/ Forget runtime type validation, TS is really for preventing bugs at development time as well as IDE integration.

josephg 3y ago
If types were added to javascript it could also dramatically improve the performance of javascript virtual machines (V8 and friends). It seems so silly to me that I write typescript, then the types are erased from my code, sent to the browser, and then the browser tries to infer them as part of its own optimization process. Adding types to javascript proper would be fantastic.
- bazoom42 3y ago
  > If types were added to javascript it could also dramatically improve the performance of javascript virtual machines Are you sure? In my understanding modern JS engines basically makes type inference on the code anyway, and in the rare case when types are observed to change at runtime, it is special-cased. So static types might simplify this but I dont see how it would dramatically improve performance.
  - IshKebab 3y ago
    This is a good read: https://medium.com/dartlang/dart-and-the-performance-benefits-of-sound-types https://medium.com/dartlang/dart-and-the-performance-benefit... That said I really doubt JS will actually get sound static types ever. Typescript is not sound.
    - auscompgeek 3y ago
      That Medium link 404s for me.
      - homarp 3y ago
        https://medium.com/dartlang/dart-and-the-performance-benefits-of-sound-types-6ceedd5b6cdc https://medium.com/dartlang/dart-and-the-performance-benefit... works for me or https://web.archive.org/web/20210310020311/https://medium.com/dartlang/dart-and-the-performance-benefits-of-sound-types-6ceedd5b6cdc https://web.archive.org/web/20210310020311/https://medium.co...
  - olejorgenb 3y ago
    And chances are(?) typescript code are to a larger degree monomorphic than javascript making the JIT more efficient(?). At least typescript discourage writing functions where the parameters can have wildly different types since this is un-ergonomic and/or hard to type.
- vbezhenar 3y ago
  This proposal is not about adding types to JavaScript. This proposal is about new syntax for comments in JavaScript. Virtual machine will not use this information.

imgyuri 3y ago

indeed, it's almost a certainty that every framework and tool in the JS ecosystem becomes obsolete as time goes by.

Xenoamorphous 3y ago

Disclaimer: I’m not a frontend dev so what I’m about to say might very well be nonsense, but I thought that jquery became popular not due to shortcomings in the JS language, but in the DOM API. So I think TypeScript is a very different case, as it fills a void in the language itself (lack of types). That doesn’t mean that in the future types won’t be added to the lang spec, but if that happens I think it would be very heavily influenced by TypeScript (e.g. like what happened with Hibernate and JPA).

phatskat 3y ago
Correct, at least from my experience. In my personal projects I was heavily Vanilla JS, but I also didn’t care if IE didn’t have full functionality (I did try to use graceful degradation when functionality was important, like navigation), but in any professional setting it would be maddening to rely on JS and not use something like jQuery. Coding around how each browser decided to give scroll position or the differences in accessing other DOM properties by hand could be tedious depending on what you wanted to do, and jQuery abstracted that effectively. I think you’re correct that, if the language formally adopted types, it would look similar to TypeScript. How _much_ of TS would be mirrored may be a different story - it’s incredibly extensive in some areas, I’m still learning new things about it as I’ve only recently started getting into it for work, and there’s a lot to it beyond basic type support.
irrational 3y ago
Jquery became popular because at the time there were all these browsers and none of them did things the same. They weren’t standards compliant like most browsers are today. So you ended up writing a ton of code and css that basically said, “if browser x - do this - else if browser y - do this”. Then jQuery came along and took care of all of that for you. They made it so you could just write for jquery and it would take care of translating it into what browser the person viewing the site was using. It made things so much easier. jQuery was basically write once, run everywhere, for the browsers of those days.

weinzierl 3y ago

I suspect that in the long run, compile-to-JS type systems will go away and will be replaced by compile-to-WASM type systems.

zarzavat 3y ago
After having used WASM on the client side, I have my doubts. It is too much of a drag on productivity using less featureful developer tools, and JavaScript is already plenty fast enough. WASM is good for things that need to be as fast as possible, but for the vast majority of use cases it simply doesn’t offer any benefits. The advantage of JS is that the browser is aware of your object graph and can provide dev tools around that.
- runlaszlorun 3y ago
  In my experience and in other benchmarks I’ve seen WASM runs basically the same as JS. Faster in some benchmarks, slower in others. The JIT in V8 and others is pretty solid.
- antihero 3y ago
  Isn’t the idea that wasn’t means you can expose the web etc APIs to any language? Eventually there will be tooling that will make this a doddle.
  - zarzavat 3y ago
    It doesn’t approach the convenience of JS dev tools. For example, you can’t have a REPL and high-level debugger combo, you just get a very basic low-level debugger. It’s a 90s debugging experience. You can’t even have a modern low-level debugger because you can’t control how the browser executes your WASM, unlike in a native executable where you can run a debugger and then run your code inside it. I guess you could have a WASM based debugger that has a WASM interpreter inside, and then you run your code inside that, but my God if that’s the future then I want no part of it.
- chii 3y ago
  > WASM is good for things that need to be as fast as possible i would've thought that WASM was really only "good" for reusing existing software written in other languages not intended for the web, by recompiling it into WASM. For example, you want to create a web version of an app written with QT or some other widgeting framework which could get a WASM target.

rapind 3y ago

> I suspect that in the long run, compile-to-JS type systems will go the same way. I think the plan was to compile to WASM. The hype phase seems to be over, but afaict it’s been delivering on at least some of it’s promises no?

mhoad 3y ago

I actually think about this I’m entirely the opposite way. The moment all browser APIs especially the DOM become usable from WASM it’s over for JS and would no longer be the obvious choice as it’s suddenly not the only game in town and the hacks that were required before such as compile to JS for example stop mattering.

solumunus 3y ago
“The moment”? You’re living in a fantasy. JavaScript would still be highly relevant and used for decades to come.

TrickyRick 3y ago

jQuery is a bit of a poor example in the context since most of the stuff jQuery provides HAS been integrated into the standard making the lib obsolete. If the ES standard introduces types in a good way that will of course make TS obsolete.