7 ms·

I'm rooting for WASM to win. One of the things that discouraged me from Front-end Web Development is JavaScript weirdness. It just has too many pitfalls and it

I'm rooting for WASM to win. One of the things that discouraged me from Front-end Web Development is JavaScript weirdness. It just has too many pitfalls and it's very hard to debug for a newcomer unless you study a proper JS course that tells you precisely all of these traps before you get burned. I've never found a programming language that didn't behave like I expected it on first touch, except for JS. I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS. I know transpilers avoid many of these pitfalls, but I cannot avoid feeling like I'm building a skyscraper in quicksand. The hard thing about talking about this exact topic it's that I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Let me be clear this is not my intention. I come from the static-typed programming languages world, so I have a preference for my programming to be the most correct. WASM to me provides this solid foundation, if only (big IF) we manage to create a browser where the main execution virtual machine is not a JS one. I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly. For instance, why'd be too hard to think about something like HTML/CSS/Python?[0] JS has been a discourager to me career-wise, and I'm doing great in Back-end Web Dev, but I'm pretty sure I'm not the only one feeling this way about it. The web should be more accessible in this sense. -- [0]: I am aware of the existence of Brython: https://brython.info/ https://brython.info/, but it's not my point, that is still Python-over-JS.

Tade0 3y ago
> I've never found a programming language that didn't behave like I expected it on first touch, except for JS. Can you share some examples?
- ivanmontillam 3y ago
  Happy to! - https://jsisweird.com/ https://jsisweird.com/
  - rantallion 3y ago
    This one gets trotted out every time someone wants to demonstrate how terrible JavaScript is. You can do many of the same stupid things in many other languages too, and most of the examples in that quiz are pretty contrived. Do you have some real-life examples of things you've personally encountered, rather than crazy examples that no-one would actually write?
  - cxr 3y ago
    To be clear: the context of this is a comment that "I've never found a programming language that didn't behave like I expected it on first touch, except for JS", and this quiz includes things like "0.1 + 0.2 === 0.3", which raises a few questions: Since this has nothing to do with JS per se and is a standard example to showcase the counterintuitiveness of IEEE 754 doubles, then does this mean that you have never worked with another language that uses IEEE 754 doubles? (And in what other languages do you find yourself typing "===", i.e. what would motivate you to type it out "on first touch", anyway—rather than "==", that is?) The quiz is filled with other examples like "+!![]". Can you briefly explain what intent/expected behavior is associated with the mindset a decision to type this out in a program and how JS violates those expectations and would therefore would be better if only it could be changed?
  - Tade0 3y ago
    I meant your own examples. I've seen these many times - few people deliberately write such code.
    - satvikpendem 3y ago
      Today I'm wrangling with null versus undefined in TypeScript and making a bunch of changes just to deal with that. I know there is a semantic difference between the two but in practice most people use them interchangeably. It's simply unnecessary to have two ways of representing nothingness when most languages simply have `null`, or even eschew it altogether by making nullability sound, via option types as in Rust, Haskell, or OCaml.
rtpg 3y ago
For me, the huge missing link (that is fortunately being worked on!) is being able to (in a performant way) have a good answer for "host code wants to do some blocking operation, WASM should suspend during the operation". This _should_ be gotten thanks to work on stack switching in WASM. As of the most recent working group meeting on this [0], it seems like V8 has made a good amount of progress on this. They published a thing back in January[1] on this, and hopefully if things go well and this is available across WASM engines then there will be one less "JS-ism" (everything async) that causes issues for transpilation. [0]: https://github.com/WebAssembly/meetings/blob/main/stack/2023/stack-2023-07-31.md https://github.com/WebAssembly/meetings/blob/main/stack/2023... [1]: https://v8.dev/blog/jspi https://v8.dev/blog/jspi
- paulhodge 3y ago
  Another feature (like WASM itself) which will probably be misused to create pages that are less usable and responsive than before. There are very good reasons why the language of the web is non-blocking.
  - rtpg 3y ago
    I think you are misunderstanding things. This makes it easier for WASM-compiled programs to favor non-blocking mechanisms when being compiled. It's just that the source language might express this without an async layer. The fact is right now if the source language has a notion of blocking calls, the when compiled to a non-blocking target like WASM it currently has to do a bunch of tricks that outright makes things slower. WIth these improvements, those "blocking calls" can properly end up non-blocking at the JS layer, matching what we all know computers can do. JS stuff is non-blocking because of the original sin of Javascript (we have to execute all the JS before we can render a page, since there can be some document.body = ... nonsense in there). This is incidental to the programming model, and not some deeper truth about how things should be programmed. Case in point: non-blocking `async` code in Javascript ends up sometimes turning into blocking code for performance reasons in specific cases (when awaiting an already completed promise, notably). Jumping in and out of an event loop isn't exactly efficient either.
Dudester230602 3y ago
> ...because talking about JS like this it's going to feel like I've insulted a cult... There is now a generation of developers equating front-end with web. > ...but I'm pretty sure I'm not the only one feeling this way about it... There are dozens of us!
- ivanmontillam 3y ago
  > There is now a generation of developers equating front-end with web. I'd go further than that. There is now a generation of developers equating all of Software Development with Web. The irony? They don't think their web browser, code editors, IDEs, operating systems, etc. are also software that someone developed. For them, it's like firmware that just magically appeared.
  - fidotron 3y ago
    The way to spot these developers is everything is a request and a response. Anything involving a stream or pushing becomes radically difficult and will be smushed into the request/response framework.
layer8 3y ago
While JavaScript is a terrible language, WASM will lead to web apps being less transparent, less “discoverable”, because the executable format is binaries instead of source code.
- ciex 3y ago
  If you don't care about transparency your web app will not be transparent today. It takes effort. Same can be said for Wasm-based projects.
  - layer8 3y ago
    Yes, but with WASM it will be non-transparent by default.
    - brabel 3y ago
      I don't understand why people always feel this is bad. The times when people "hacked" the JS of the websites they visited are long gone, and for nearly all web applications (which is what WASM is useful for, as opposed to simple websites) the code is already completely unreadable (even if it were not minified, I mean, you would probably need to spend weeks understanding what it's doing for non-trivial stuff)... it's even illegal today to alter websites you visit to use "hidden" features, depending on your jurisdiction. Besides, WASM is not going to displace JS, it will just give people an option to achieve things they couldn't with JS alone.
      - cxr 3y ago
        > The times when people "hacked" the JS of the websites they visited are long gone, and for nearly all web applications (which is what WASM is useful for, as opposed to simple websites) the code is already completely unreadable This is an overly narrow and ungenerous interpretation of the criticism here. Frequently JS can be close to unreadable after minification (and even then, that's still only "frequently", "can", and "close"), but the anatomy of the page is as manipulable as it's ever been through standardized interfaces (DOM). Browser extensions and other features baked into browsers that depend on this ability to fiddle with or read e.g. form controls are ubiquitous. Flutter (or Flash) rendering a blob of pixels to a canvas destroys this. We'd never have gotten tabbed browsing or popout picture-in-picture videos with native playback controls or password managers or AdBlock Plus and uBlock Origin if executing opaque SWFs and Silverlight bundles were gating users' access to Web apps. (Worth pointing out that there's nothing really "Web" about them at that point, either—only through a dubious transitive argument involving the fact that the thing they're executing in has traditionally been called a Web browser).
tyingq 3y ago
Python running well in WASM requires WASM to be more like a virtual machine (as in JVM, not KVM) and less like ASM. WASM is headed that way, with things like GC. But then you also need direct DOM integration. And even if you have both of those working well, Python's runtime and stdlib are pretty large, and if everyone picks a different version of Python they want to run, there's no economy of scale. Couple that with browsers all killing off the advantage of shared libraries in a CDN via cache partitions. It feels like the road to all of that working reasonably well in all situations is pretty long.
- rthz 3y ago
  It's done currently in Pyodide: Python with DOM integration running with WASM. Minimal application with stdlib is around 5.5MB after compression now. Not small but still manageable depending on the use case. Still I agree with your other comments, and in particular not being able to share caches in the browser is very unfortunate (but understandable).
  - tyingq 3y ago
    Yes, it works...but it puts python at a big disadvantage in terms of size and performance. The DOM integration, for example, works, but isn't what it could be if WASM had more direct support for it.
baz00 3y ago
I completely agree with all of this in every way having written a hell of a lot of front end code over the last 25 years. Apart from the WASM bit. As a somewhat extremist on this front, I'd rather "the web" was still Gopher that shifted nice PDFs generated in LaTeX and 80 column formatted text files. And email was plain text only. And leave the rest to native apps on whatever platform you happen to like. WASM is basically Flash but less shit.
bazoom42 3y ago
> I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Just FYI this line of argument is called “poisoning the well”. Definition from Wikipedia: > a type of informal fallacy where adverse information about a target is preemptively presented to an audience, with the intention of discrediting or ridiculing something that the target person is about to say. It is not conductive to a reasoned discourse about a technical topic.
- fluoridation 3y ago
  That's not poisoning the well. That would be something like "if you disagree with this it's because you've drunk the kool-aid of the web development cult, so your opinion is biased and therefore invalid". Something along those lines. Although it was poorly phrased, what GP meant to say is that they weren't trying to intentionally offend anyone's sensibilities, they were just expressing their sincere opinion on a subject.
  - dleary 3y ago
    “Triggered” implies an emotional or irrational overreaction to some stimulus. Describing your opponents as a “cult” also implies that they are non rational. The GP described opposition to his argument, before it was presented, as coming from triggered members of a cult. If this is not poisoning the well, what changes to his argument need to be present for it to cross over the line? How much more clear does it need to be?
    - lelanthran 3y ago
      > The GP described opposition to his argument, before it was presented, as coming from triggered members of a cult. And to rub salt into the wound, he then went on to describe his preference as "the most correct". I wonder what he primarily programs in.
      - ivanmontillam 3y ago
jeroenhd 3y ago
I would advocate for making browsers run Typescript, but WASM is just another compiler, just like Typescript. Whatever you're afraid of by using transpilers is much worse to debug and resolve once you've compiled it to a blob of binary code. If you can trust the Python interpreter, you can trust the Typescript transpiler. Things become a little complicated to debug when you're stuck dealing with crap like IE11 or various older Safari versions, but we're not living in 2010 anymore. Javascript is terribly inconvenient and has tons of weird edge cases ("semicolons are optional except for these three edge cases", scope switching through using, the unpredictable type conversions) but the rules aren't that hard to write a transpiler for. Transpiling another language into JS will probably leave some optimisations on the table (by reimplementating methods in a way another language expects rather than calling the native Javascript API) but at least it has the normal API to rely on. WASM is like Docker; it works on my machine, I can't get it to work on your machine, so we'll ship half of my machine and call it even. You're shipping standard libraries and JSON parsers to a browser as if you're pushing code to a bare metal server. Javascript isn't a hard language to learn and neither are HTML or CSS. What I see many WASM people want to do is write browser code without ever needing to learn how the browser works. That's a terrible idea that will only end in either bloat or broken abstractions. "Let's make backend devs do frontend" is how we ended up with Java applets everywhere, which barely worked inside the context of a desktop browser, let alone on touch screens and phones. There's a reason "native" desktop development has become "run an outdated copy of Chrome with some OS glue", and it's that web development is easy compared to native frontend development, especially if you target multiple platforms. WASM isn't going to turn backend developers into frontend developers overnight, you'll be stuck learning new frameworks and barely usable tooling regardless. Just use JS, it's inconvenient but much a much better option than the proposed alternatives.
samsari 3y ago
>I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult What a completely unnecessary thing to say in the middle of an otherwise reasonable post.
- doublerabbit 3y ago
  Not really. I agree with the statement. It's applies for many programming groups. Those like to live in their realm, one where that their language is the greatest and thou can't be spoken negative about. Just try mentioning C++ to a bunch of Go programmers or Python to a bunch of Rust programmers. Not to say there isn't crossover but it's all ironic really, as most languages were crafted from C.
  - pjmlp 3y ago
    20 years of programming languages predate C.
mattlondon 3y ago
Citation needed for not behaving like you expect on first touch. I very very much doubt that most people's first touch of writing javascript included writing contrived syntacical-gotchyas like `+!!NaN * "" - - [,]` (example 25 on jsiswierd.com)... unless of course they are perl coders :) Yes there are a few weird things around true/false evaluations and other syntax "gotchyas", but they take at most 5 minutes to grok the ones that actually come up in normal day-to-day coding, and many of the other things that people like to flag up (like scope in blocks/functions) are often the same in statically typed compiled languages too - there was a blog post from golang just recently about a "common mistake" around scoping of variables in loops etc for example (sorry cant find link). Don't even get me started on Python's weirdness. What I am saying is there are many ways to shoot yourself in the foot in any language - you'll "get burned" in anything that you don't really understand. First-touch of rust without really knowing the language that well? First-touch of c++ without really knowing the language that well? Have fun not getting burned with those until you have studied a proper rust/c++ course that tells you precisely all of the traps. It turns out that you need to know about a programming language to use it effectively. And for what it is worth, modern ECMAScript does not need a transpiler - it executes directly in the browser without any molestation. Typescript requires transpilation to javascript before execution, but you can get a long way without typescript if you want to without sacrificing too much besides types (and tooling these days for standard ECMAScript is excellent) I think that maybe perhaps you are confusing javascript with browser-based frameworks like React? React and NPM are a total dumpster fire of awfulness, but they are not javascript. I'd encourage you to give modern, native ECMAScript another go.
EMM_386 3y ago
> I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS. I fully understand the reluctance or just sheer annoyance of having to set up a toolchain just to end up with JavaScript. I've written an absurd amount of JavaScript since 1995. And yes, it is quirky, and awkward, and at times seemed downright ridiculous. ES6 at least was somewhat of a paradigm shift towards normalcy. Granted, JavaScript was created "in 10 days" and then simply became the de facto language of the web. But after I started working with TypeScript, and enforcing linting rules through ESLint, and working in a proper IDE for it like VSCode, there is simply no going back. And it's not just the development that is so much better. With tools like webpack you also easily get tree-shaking, bundling, and minification, which are all good things for the users. For very small sites with a single developer, sure you can just write JavaScript and call it a day. But anything even slightly beyond that and I would take the small amount of time to setup a build environment. It's not that difficult, and once it's set up properly it should stay out of your way and help tremendously. I'm full stack lead on an enterprise Angular project that happens to require all of this stuff, but I would use it going forward for many less complex, non-SPA projects as well. After 20+ years I don't necessarily loathe working on the front-end anymore. That's not to say I didn't have to be pulled kicking and screaming into this world at first, while yelling "get off my lawn!". That may have been the case.
zaphirplane 3y ago
I Dont get what you mean. Why is it better to use rust or go or whatever to write react like code templating, reactive or htmlx than it is to use typescript for the same. Typescript is ok overall and the various frameworks / libraries used to generate a browser elements are really to my simple take not so much a language workaround than the best some very smart people have envisioned to build/update browser elements Well maybe in another language react hooks wouldn’t be so quirky
cesarb 3y ago
> I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly. These existed. You could have used VBScript instead of JavaScript (Internet Explorer). Or, perhaps, you might have wanted to go all the way in the other direction, and use JavaScript syntax for your stylesheets, instead of CSS (Netscape Navigator, JavaScript Style Sheets aka JSSS). As for HTML, it might be possible to use pure XML styled directly with CSS or something like XML-FO, without having a XSLT which transforms it into HTML, but I don't know which browsers support or have supported that.
phil_kahrl 3y ago
I think WASM will win. I've been using JavaScript for 25+ years, and I just wrote a SPA using Rust/WASM using the Leptos framework: https://github.com/leptos-rs/leptos https://github.com/leptos-rs/leptos, and now I don't want to go back to JavaScript. Cargo is a superior package manager, with Cargo I might actually be able to let me my project sit for a year or two and go back and build to a working runtime without having to do a lot of dependency updates (good luck doing that with NPM). Rust has a solid type system, and with the borrow checker along with pattern exhaustive matching I can write something that I know is solid and will be difficult to break. There is no need to have multiple stages build pipeline running through Babel and Webpack which need to be properly configured; simply compile Rust to the WASM target and that is it. The WASM bundle is also likely to be smaller than a corresponding JavaScript bundle. Additionally, with Rust it is easier to do low-level stuff in the client efficiently such as feature extraction from image binaries. Also, the application I wrote with WASM is faster than a similar app I wrote in React, although I attribute that mostly to the fact that Leptos does not use a virtual DOM as React does.
geysersam 3y ago
I don't think the question "will WASM win?" is about JS vs other languages. In my mind it's about the web as a platform versus "apps". WASM will be used in cases when performance and correctness is worth the extra effort. Libraries, components, etc. Js will glue it all together, like the Python of the web.
FractalHQ 3y ago
Typescript is miles ahead of Python… especially when talking about correctness. That suggestion seems to contradict your whole argument.

Tade0 3y ago

> I've never found a programming language that didn't behave like I expected it on first touch, except for JS. Can you share some examples?

ivanmontillam 3y ago
Happy to! - https://jsisweird.com/ https://jsisweird.com/
- rantallion 3y ago
  This one gets trotted out every time someone wants to demonstrate how terrible JavaScript is. You can do many of the same stupid things in many other languages too, and most of the examples in that quiz are pretty contrived. Do you have some real-life examples of things you've personally encountered, rather than crazy examples that no-one would actually write?
- cxr 3y ago
  To be clear: the context of this is a comment that "I've never found a programming language that didn't behave like I expected it on first touch, except for JS", and this quiz includes things like "0.1 + 0.2 === 0.3", which raises a few questions: Since this has nothing to do with JS per se and is a standard example to showcase the counterintuitiveness of IEEE 754 doubles, then does this mean that you have never worked with another language that uses IEEE 754 doubles? (And in what other languages do you find yourself typing "===", i.e. what would motivate you to type it out "on first touch", anyway—rather than "==", that is?) The quiz is filled with other examples like "+!![]". Can you briefly explain what intent/expected behavior is associated with the mindset a decision to type this out in a program and how JS violates those expectations and would therefore would be better if only it could be changed?
- Tade0 3y ago
  I meant your own examples. I've seen these many times - few people deliberately write such code.
  - satvikpendem 3y ago
    Today I'm wrangling with null versus undefined in TypeScript and making a bunch of changes just to deal with that. I know there is a semantic difference between the two but in practice most people use them interchangeably. It's simply unnecessary to have two ways of representing nothingness when most languages simply have `null`, or even eschew it altogether by making nullability sound, via option types as in Rust, Haskell, or OCaml.

rtpg 3y ago

For me, the huge missing link (that is fortunately being worked on!) is being able to (in a performant way) have a good answer for "host code wants to do some blocking operation, WASM should suspend during the operation". This _should_ be gotten thanks to work on stack switching in WASM. As of the most recent working group meeting on this [0], it seems like V8 has made a good amount of progress on this. They published a thing back in January[1] on this, and hopefully if things go well and this is available across WASM engines then there will be one less "JS-ism" (everything async) that causes issues for transpilation. [0]: https://github.com/WebAssembly/meetings/blob/main/stack/2023/stack-2023-07-31.md https://github.com/WebAssembly/meetings/blob/main/stack/2023... [1]: https://v8.dev/blog/jspi https://v8.dev/blog/jspi

paulhodge 3y ago
Another feature (like WASM itself) which will probably be misused to create pages that are less usable and responsive than before. There are very good reasons why the language of the web is non-blocking.
- rtpg 3y ago
  I think you are misunderstanding things. This makes it easier for WASM-compiled programs to favor non-blocking mechanisms when being compiled. It's just that the source language might express this without an async layer. The fact is right now if the source language has a notion of blocking calls, the when compiled to a non-blocking target like WASM it currently has to do a bunch of tricks that outright makes things slower. WIth these improvements, those "blocking calls" can properly end up non-blocking at the JS layer, matching what we all know computers can do. JS stuff is non-blocking because of the original sin of Javascript (we have to execute all the JS before we can render a page, since there can be some document.body = ... nonsense in there). This is incidental to the programming model, and not some deeper truth about how things should be programmed. Case in point: non-blocking `async` code in Javascript ends up sometimes turning into blocking code for performance reasons in specific cases (when awaiting an already completed promise, notably). Jumping in and out of an event loop isn't exactly efficient either.

Dudester230602 3y ago

> ...because talking about JS like this it's going to feel like I've insulted a cult... There is now a generation of developers equating front-end with web. > ...but I'm pretty sure I'm not the only one feeling this way about it... There are dozens of us!

ivanmontillam 3y ago
> There is now a generation of developers equating front-end with web. I'd go further than that. There is now a generation of developers equating all of Software Development with Web. The irony? They don't think their web browser, code editors, IDEs, operating systems, etc. are also software that someone developed. For them, it's like firmware that just magically appeared.
- fidotron 3y ago
  The way to spot these developers is everything is a request and a response. Anything involving a stream or pushing becomes radically difficult and will be smushed into the request/response framework.

layer8 3y ago

While JavaScript is a terrible language, WASM will lead to web apps being less transparent, less “discoverable”, because the executable format is binaries instead of source code.

ciex 3y ago
If you don't care about transparency your web app will not be transparent today. It takes effort. Same can be said for Wasm-based projects.
- layer8 3y ago
  Yes, but with WASM it will be non-transparent by default.
  - brabel 3y ago
    I don't understand why people always feel this is bad. The times when people "hacked" the JS of the websites they visited are long gone, and for nearly all web applications (which is what WASM is useful for, as opposed to simple websites) the code is already completely unreadable (even if it were not minified, I mean, you would probably need to spend weeks understanding what it's doing for non-trivial stuff)... it's even illegal today to alter websites you visit to use "hidden" features, depending on your jurisdiction. Besides, WASM is not going to displace JS, it will just give people an option to achieve things they couldn't with JS alone.
    - cxr 3y ago
      > The times when people "hacked" the JS of the websites they visited are long gone, and for nearly all web applications (which is what WASM is useful for, as opposed to simple websites) the code is already completely unreadable This is an overly narrow and ungenerous interpretation of the criticism here. Frequently JS can be close to unreadable after minification (and even then, that's still only "frequently", "can", and "close"), but the anatomy of the page is as manipulable as it's ever been through standardized interfaces (DOM). Browser extensions and other features baked into browsers that depend on this ability to fiddle with or read e.g. form controls are ubiquitous. Flutter (or Flash) rendering a blob of pixels to a canvas destroys this. We'd never have gotten tabbed browsing or popout picture-in-picture videos with native playback controls or password managers or AdBlock Plus and uBlock Origin if executing opaque SWFs and Silverlight bundles were gating users' access to Web apps. (Worth pointing out that there's nothing really "Web" about them at that point, either—only through a dubious transitive argument involving the fact that the thing they're executing in has traditionally been called a Web browser).

tyingq 3y ago

Python running well in WASM requires WASM to be more like a virtual machine (as in JVM, not KVM) and less like ASM. WASM is headed that way, with things like GC. But then you also need direct DOM integration. And even if you have both of those working well, Python's runtime and stdlib are pretty large, and if everyone picks a different version of Python they want to run, there's no economy of scale. Couple that with browsers all killing off the advantage of shared libraries in a CDN via cache partitions. It feels like the road to all of that working reasonably well in all situations is pretty long.

rthz 3y ago
It's done currently in Pyodide: Python with DOM integration running with WASM. Minimal application with stdlib is around 5.5MB after compression now. Not small but still manageable depending on the use case. Still I agree with your other comments, and in particular not being able to share caches in the browser is very unfortunate (but understandable).
- tyingq 3y ago
  Yes, it works...but it puts python at a big disadvantage in terms of size and performance. The DOM integration, for example, works, but isn't what it could be if WASM had more direct support for it.

baz00 3y ago

I completely agree with all of this in every way having written a hell of a lot of front end code over the last 25 years. Apart from the WASM bit. As a somewhat extremist on this front, I'd rather "the web" was still Gopher that shifted nice PDFs generated in LaTeX and 80 column formatted text files. And email was plain text only. And leave the rest to native apps on whatever platform you happen to like. WASM is basically Flash but less shit.

bazoom42 3y ago

> I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Just FYI this line of argument is called “poisoning the well”. Definition from Wikipedia: > a type of informal fallacy where adverse information about a target is preemptively presented to an audience, with the intention of discrediting or ridiculing something that the target person is about to say. It is not conductive to a reasoned discourse about a technical topic.

fluoridation 3y ago
That's not poisoning the well. That would be something like "if you disagree with this it's because you've drunk the kool-aid of the web development cult, so your opinion is biased and therefore invalid". Something along those lines. Although it was poorly phrased, what GP meant to say is that they weren't trying to intentionally offend anyone's sensibilities, they were just expressing their sincere opinion on a subject.
- dleary 3y ago
  “Triggered” implies an emotional or irrational overreaction to some stimulus. Describing your opponents as a “cult” also implies that they are non rational. The GP described opposition to his argument, before it was presented, as coming from triggered members of a cult. If this is not poisoning the well, what changes to his argument need to be present for it to cross over the line? How much more clear does it need to be?
  - lelanthran 3y ago
    > The GP described opposition to his argument, before it was presented, as coming from triggered members of a cult. And to rub salt into the wound, he then went on to describe his preference as "the most correct". I wonder what he primarily programs in.
    - ivanmontillam 3y ago

jeroenhd 3y ago

I would advocate for making browsers run Typescript, but WASM is just another compiler, just like Typescript. Whatever you're afraid of by using transpilers is much worse to debug and resolve once you've compiled it to a blob of binary code. If you can trust the Python interpreter, you can trust the Typescript transpiler. Things become a little complicated to debug when you're stuck dealing with crap like IE11 or various older Safari versions, but we're not living in 2010 anymore. Javascript is terribly inconvenient and has tons of weird edge cases ("semicolons are optional except for these three edge cases", scope switching through using, the unpredictable type conversions) but the rules aren't that hard to write a transpiler for. Transpiling another language into JS will probably leave some optimisations on the table (by reimplementating methods in a way another language expects rather than calling the native Javascript API) but at least it has the normal API to rely on. WASM is like Docker; it works on my machine, I can't get it to work on your machine, so we'll ship half of my machine and call it even. You're shipping standard libraries and JSON parsers to a browser as if you're pushing code to a bare metal server. Javascript isn't a hard language to learn and neither are HTML or CSS. What I see many WASM people want to do is write browser code without ever needing to learn how the browser works. That's a terrible idea that will only end in either bloat or broken abstractions. "Let's make backend devs do frontend" is how we ended up with Java applets everywhere, which barely worked inside the context of a desktop browser, let alone on touch screens and phones. There's a reason "native" desktop development has become "run an outdated copy of Chrome with some OS glue", and it's that web development is easy compared to native frontend development, especially if you target multiple platforms. WASM isn't going to turn backend developers into frontend developers overnight, you'll be stuck learning new frameworks and barely usable tooling regardless. Just use JS, it's inconvenient but much a much better option than the proposed alternatives.

samsari 3y ago

>I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult What a completely unnecessary thing to say in the middle of an otherwise reasonable post.

doublerabbit 3y ago
Not really. I agree with the statement. It's applies for many programming groups. Those like to live in their realm, one where that their language is the greatest and thou can't be spoken negative about. Just try mentioning C++ to a bunch of Go programmers or Python to a bunch of Rust programmers. Not to say there isn't crossover but it's all ironic really, as most languages were crafted from C.
- pjmlp 3y ago
  20 years of programming languages predate C.

mattlondon 3y ago

Citation needed for not behaving like you expect on first touch. I very very much doubt that most people's first touch of writing javascript included writing contrived syntacical-gotchyas like `+!!NaN * "" - - [,]` (example 25 on jsiswierd.com)... unless of course they are perl coders :) Yes there are a few weird things around true/false evaluations and other syntax "gotchyas", but they take at most 5 minutes to grok the ones that actually come up in normal day-to-day coding, and many of the other things that people like to flag up (like scope in blocks/functions) are often the same in statically typed compiled languages too - there was a blog post from golang just recently about a "common mistake" around scoping of variables in loops etc for example (sorry cant find link). Don't even get me started on Python's weirdness. What I am saying is there are many ways to shoot yourself in the foot in any language - you'll "get burned" in anything that you don't really understand. First-touch of rust without really knowing the language that well? First-touch of c++ without really knowing the language that well? Have fun not getting burned with those until you have studied a proper rust/c++ course that tells you precisely all of the traps. It turns out that you need to know about a programming language to use it effectively. And for what it is worth, modern ECMAScript does not need a transpiler - it executes directly in the browser without any molestation. Typescript requires transpilation to javascript before execution, but you can get a long way without typescript if you want to without sacrificing too much besides types (and tooling these days for standard ECMAScript is excellent) I think that maybe perhaps you are confusing javascript with browser-based frameworks like React? React and NPM are a total dumpster fire of awfulness, but they are not javascript. I'd encourage you to give modern, native ECMAScript another go.

EMM_386 3y ago

> I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS. I fully understand the reluctance or just sheer annoyance of having to set up a toolchain just to end up with JavaScript. I've written an absurd amount of JavaScript since 1995. And yes, it is quirky, and awkward, and at times seemed downright ridiculous. ES6 at least was somewhat of a paradigm shift towards normalcy. Granted, JavaScript was created "in 10 days" and then simply became the de facto language of the web. But after I started working with TypeScript, and enforcing linting rules through ESLint, and working in a proper IDE for it like VSCode, there is simply no going back. And it's not just the development that is so much better. With tools like webpack you also easily get tree-shaking, bundling, and minification, which are all good things for the users. For very small sites with a single developer, sure you can just write JavaScript and call it a day. But anything even slightly beyond that and I would take the small amount of time to setup a build environment. It's not that difficult, and once it's set up properly it should stay out of your way and help tremendously. I'm full stack lead on an enterprise Angular project that happens to require all of this stuff, but I would use it going forward for many less complex, non-SPA projects as well. After 20+ years I don't necessarily loathe working on the front-end anymore. That's not to say I didn't have to be pulled kicking and screaming into this world at first, while yelling "get off my lawn!". That may have been the case.

zaphirplane 3y ago

I Dont get what you mean. Why is it better to use rust or go or whatever to write react like code templating, reactive or htmlx than it is to use typescript for the same. Typescript is ok overall and the various frameworks / libraries used to generate a browser elements are really to my simple take not so much a language workaround than the best some very smart people have envisioned to build/update browser elements Well maybe in another language react hooks wouldn’t be so quirky

cesarb 3y ago

> I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly. These existed. You could have used VBScript instead of JavaScript (Internet Explorer). Or, perhaps, you might have wanted to go all the way in the other direction, and use JavaScript syntax for your stylesheets, instead of CSS (Netscape Navigator, JavaScript Style Sheets aka JSSS). As for HTML, it might be possible to use pure XML styled directly with CSS or something like XML-FO, without having a XSLT which transforms it into HTML, but I don't know which browsers support or have supported that.

phil_kahrl 3y ago

I think WASM will win. I've been using JavaScript for 25+ years, and I just wrote a SPA using Rust/WASM using the Leptos framework: https://github.com/leptos-rs/leptos https://github.com/leptos-rs/leptos, and now I don't want to go back to JavaScript. Cargo is a superior package manager, with Cargo I might actually be able to let me my project sit for a year or two and go back and build to a working runtime without having to do a lot of dependency updates (good luck doing that with NPM). Rust has a solid type system, and with the borrow checker along with pattern exhaustive matching I can write something that I know is solid and will be difficult to break. There is no need to have multiple stages build pipeline running through Babel and Webpack which need to be properly configured; simply compile Rust to the WASM target and that is it. The WASM bundle is also likely to be smaller than a corresponding JavaScript bundle. Additionally, with Rust it is easier to do low-level stuff in the client efficiently such as feature extraction from image binaries. Also, the application I wrote with WASM is faster than a similar app I wrote in React, although I attribute that mostly to the fact that Leptos does not use a virtual DOM as React does.

geysersam 3y ago

I don't think the question "will WASM win?" is about JS vs other languages. In my mind it's about the web as a platform versus "apps". WASM will be used in cases when performance and correctness is worth the extra effort. Libraries, components, etc. Js will glue it all together, like the Python of the web.

FractalHQ 3y ago

Typescript is miles ahead of Python… especially when talking about correctness. That suggestion seems to contradict your whole argument.