4 ms·

This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly b

by xvilka 3y ago

This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.

mbork_pl 3y ago
You mean, like C and its derivatives became obsolete once successors to PDP machines were built? ;-)
flohofwoe 3y ago
Any non-toy WASM application running in browsers will almost certainly end up as a hybrid WASM/JS application, just because you can't call directly from WASM into browser APIs, and even if the JS shim is "hidden from view", sometimes it's either more convenient or even more performant to write more than just a thin API shim in Javascript, especially for asynchronous code or to avoid redundant copying of large data blobs in and out of the WASM heap.
- LudwigNagasena 3y ago
  > just because you can't call directly from WASM into browser APIs Surely that will change someday.
  - flohofwoe 3y ago
    You are still limited by the fact that browser APIs are mainly designed for usage with Javascript, and those Javascript APIs usually don't map all that well to languages used with WASM (which typically use the "C ABI" for FFI). There is zero chance that each web API will get a second API which is compatible with "C calling conventions". There is a (now inactive) "interface-types" proposal, which has dissolved into "component-types", but this scope-creep definitely is already quite concerning: https://github.com/WebAssembly/interface-types https://github.com/WebAssembly/interface-types
andsoitis 3y ago
> This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web. JavaScript and TypeScript are not "proper" languages? Different languages are powerful in different use case dimensions (tradeoffs), and the typical client-side web programming has a very very strong UI angle, which many "more powerful" languages that I am going to guess you have in mind are less adept at.
- airstrike 3y ago
  JavaScript's redeeming quality is that it is ubiquitous due to being used by browsers. I don't think anybody credibly claims it to be a language we would want to use if we were to redesign web programming from scratch today
  - andsoitis 3y ago
    What follows is meant to be descriptive rather arguing "my camp is right". > JavaScript's redeeming quality is that it is ubiquitous due to being used by browsers. JavaScript has other properties that make it very adept at a wide range of web app usecases. Languages exist not in isolation, but have a dynamic environment w.r.t. domains they excel in, tooling, mindshare, programming in the small and the large, comlexity, etc. > I don't think anybody credibly claims it to be a language we would want to use if we were to redesign web programming from scratch today Dart has tried. Many languages transpile to JavaScript (and have for a long time). Yet, JavaScript and TypeScript are some of the most popular languages on the planet. If the web is still around in 20 years, it will be interesting to see whether another language has taken center stage. I'm not quite holding my breath, if only because even with transpilation being around for many many years, no other language has overtaken. I have a hard time seeing WASM changing that outcome in a meaningful way.
  - shepherdjerred 3y ago
    TypeScript is a pleasure to use. I have no desire to replace it with another language.
  - 3y ago
thrashh 3y ago
What language would that be? I've programmed in Java, Python, C, C#, TypeScript, VHDL, and some other languages and they all fucking suck in some way. If it was up to me, I would pick the best parts of the languages/ecosystems and make a Frankenstein language. And anyway in the end, it's never the language. It's the ecosystem. Just because you can run Java on .NET doesn't mean you should -- because almost no one else does it your way and it's not worth the trouble maintaining some weird approach very few people use. You're never going to get help from library authors when it doesn't work on your weird setup.

by xvilka 3y ago

This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web.

mbork_pl 3y ago

You mean, like C and its derivatives became obsolete once successors to PDP machines were built? ;-)

flohofwoe 3y ago

Any non-toy WASM application running in browsers will almost certainly end up as a hybrid WASM/JS application, just because you can't call directly from WASM into browser APIs, and even if the JS shim is "hidden from view", sometimes it's either more convenient or even more performant to write more than just a thin API shim in Javascript, especially for asynchronous code or to avoid redundant copying of large data blobs in and out of the WASM heap.

LudwigNagasena 3y ago
> just because you can't call directly from WASM into browser APIs Surely that will change someday.
- flohofwoe 3y ago
  You are still limited by the fact that browser APIs are mainly designed for usage with Javascript, and those Javascript APIs usually don't map all that well to languages used with WASM (which typically use the "C ABI" for FFI). There is zero chance that each web API will get a second API which is compatible with "C calling conventions". There is a (now inactive) "interface-types" proposal, which has dissolved into "component-types", but this scope-creep definitely is already quite concerning: https://github.com/WebAssembly/interface-types https://github.com/WebAssembly/interface-types

andsoitis 3y ago

> This is why once WebAssembly more polished and more common, languages like JS and TS could become obsolete since proper, more powerful languages will suddenly become a valid choice for Web. JavaScript and TypeScript are not "proper" languages? Different languages are powerful in different use case dimensions (tradeoffs), and the typical client-side web programming has a very very strong UI angle, which many "more powerful" languages that I am going to guess you have in mind are less adept at.

airstrike 3y ago
JavaScript's redeeming quality is that it is ubiquitous due to being used by browsers. I don't think anybody credibly claims it to be a language we would want to use if we were to redesign web programming from scratch today
- andsoitis 3y ago
  What follows is meant to be descriptive rather arguing "my camp is right". > JavaScript's redeeming quality is that it is ubiquitous due to being used by browsers. JavaScript has other properties that make it very adept at a wide range of web app usecases. Languages exist not in isolation, but have a dynamic environment w.r.t. domains they excel in, tooling, mindshare, programming in the small and the large, comlexity, etc. > I don't think anybody credibly claims it to be a language we would want to use if we were to redesign web programming from scratch today Dart has tried. Many languages transpile to JavaScript (and have for a long time). Yet, JavaScript and TypeScript are some of the most popular languages on the planet. If the web is still around in 20 years, it will be interesting to see whether another language has taken center stage. I'm not quite holding my breath, if only because even with transpilation being around for many many years, no other language has overtaken. I have a hard time seeing WASM changing that outcome in a meaningful way.
- shepherdjerred 3y ago
  TypeScript is a pleasure to use. I have no desire to replace it with another language.
- 3y ago

thrashh 3y ago

What language would that be? I've programmed in Java, Python, C, C#, TypeScript, VHDL, and some other languages and they all fucking suck in some way. If it was up to me, I would pick the best parts of the languages/ecosystems and make a Frankenstein language. And anyway in the end, it's never the language. It's the ecosystem. Just because you can run Java on .NET doesn't mean you should -- because almost no one else does it your way and it's not worth the trouble maintaining some weird approach very few people use. You're never going to get help from library authors when it doesn't work on your weird setup.