3 ms·

This nicely show why Rust/WASM speed up things. All that detective work? Is UNDOING what javascript do, idiomatically! Can be argued that JS is "fast" after a

by mamcx 5y ago

This nicely show why Rust/WASM speed up things. All that detective work? Is UNDOING what javascript do, idiomatically! Can be argued that JS is "fast" after all that, but instead, that show Rust give it for free, because is idiomatic there. The problem with JS and other mis-designed languages is that do easy things are easy, but add complexity is easier. And the language NOT HELP if you wanna reduce it. In contrast, in Rust (more thanks to ML-like type system), the code YELL the more complex it becomes. And Rust help to simplify things. That is IMHO the major advantage of a static type system, enriched on the ML family: The types are not there, per-se, as performance trick, but for guide how model the app, then you can model performance! P.D: In other words? If JS were alike rust (ala: ML, plus more use of vectors!) it will be far easier to a) not get on a bad performance spot in first place b) easy to simplify things with type modeling!

derefr 5y ago
I wouldn’t call JS mis-designed. Most use of JS in the world is still for simple things, e.g. validating form inputs to put an X or checkmark beside each field. It’s important for those cases that in JS “easy things are easy”, even at the expense of developer productivity for complex apps. JavaScript (the syntax+semantics) was never intended for complex apps. It would be better if we had JS and another language that were both usable in browsers to interact with the DOM, where this other language was more low-level. And this was the original plan — the “other language” was originally going to be Java. (Java applets were originally capable of manipulating the DOM, through the same API surface as JavaScript!) Then people stopped liking Java applets, so it moved to thinking about “pluggable” language runtimes, loadable through either NPAPI (Netscape/Firefox) or ActiveX (IE), enabling <script type=“foo”> for arbitrary values of foo. This effort died too, both because those plugin systems are security nightmares (PPAPI came too late), and because browsers just didn’t seem willing to standardize on a plugin ecosystem in a way that would allow websites to declare a plugin once that enables the same functionality on all past, present, and future browsers, the way JS does. Eventually, we acknowledged that all browsers had already implemented JavaScript engines (incl. legacy browsers on feature-phones) and so it would be basically impossible to achieve the same reach with a latecomer. So we switched to the strategy of making browsers’ JavaScript engines work well when you use in-band signalling to (effectively) program them in another language; and we called the result WASM. This isn’t the cleanest strategy. What’s great about it, though, is that (the text format of) WASM will load and run in any browser that supports JavaScript itself.
- mamcx 5y ago
  > And this was the original plan — the “other language” was ... In short? mis-designed. JS was fora use case, and have become more and more for other uses case (even backend!). This is also the problem with html, css, dom. Plus, some WATs are part of rushing it, and others for mismatch in the uses cases.
  - handrous 5y ago
    I think the fact that it features, very prominently, an OO model (prototypal) that's pretty firmly in "please, never actually use any of the notable features that differentiate this model from others" territory is enough to fairly label it mis-designed, however far it's come. It's no accident that prototypal-heavy JS is damn near at the bottom of paradigms for approaching JS programming, beneath a bunch of others, OO or otherwise, that brush right past it, pretending it's not there. I'd point to not making async calls synchronous-to-the-caller by default as another pretty bad design mistake. The way so many JS files start nearly every line (correctly! This isn't even counting mis-use of the feature, which is also widespread!) with `await` is evidence of this, and so's all the earlier thrashing before we had `await` to deal semi-sanely with this bad design decision. The original scoping system was just bad. We have better tools to make it suck less now, but it was designed wrong originally.
    - catlifeonmars 5y ago
      I’ve thought about what JS would look like if instead of await, the language would await by default and expressions would be explicitly deferable via some other keyword (like “defer”).

by mamcx 5y ago

derefr 5y ago

I wouldn’t call JS mis-designed. Most use of JS in the world is still for simple things, e.g. validating form inputs to put an X or checkmark beside each field. It’s important for those cases that in JS “easy things are easy”, even at the expense of developer productivity for complex apps. JavaScript (the syntax+semantics) was never intended for complex apps. It would be better if we had JS and another language that were both usable in browsers to interact with the DOM, where this other language was more low-level. And this was the original plan — the “other language” was originally going to be Java. (Java applets were originally capable of manipulating the DOM, through the same API surface as JavaScript!) Then people stopped liking Java applets, so it moved to thinking about “pluggable” language runtimes, loadable through either NPAPI (Netscape/Firefox) or ActiveX (IE), enabling <script type=“foo”> for arbitrary values of foo. This effort died too, both because those plugin systems are security nightmares (PPAPI came too late), and because browsers just didn’t seem willing to standardize on a plugin ecosystem in a way that would allow websites to declare a plugin once that enables the same functionality on all past, present, and future browsers, the way JS does. Eventually, we acknowledged that all browsers had already implemented JavaScript engines (incl. legacy browsers on feature-phones) and so it would be basically impossible to achieve the same reach with a latecomer. So we switched to the strategy of making browsers’ JavaScript engines work well when you use in-band signalling to (effectively) program them in another language; and we called the result WASM. This isn’t the cleanest strategy. What’s great about it, though, is that (the text format of) WASM will load and run in any browser that supports JavaScript itself.

mamcx 5y ago
> And this was the original plan — the “other language” was ... In short? mis-designed. JS was fora use case, and have become more and more for other uses case (even backend!). This is also the problem with html, css, dom. Plus, some WATs are part of rushing it, and others for mismatch in the uses cases.
- handrous 5y ago
  I think the fact that it features, very prominently, an OO model (prototypal) that's pretty firmly in "please, never actually use any of the notable features that differentiate this model from others" territory is enough to fairly label it mis-designed, however far it's come. It's no accident that prototypal-heavy JS is damn near at the bottom of paradigms for approaching JS programming, beneath a bunch of others, OO or otherwise, that brush right past it, pretending it's not there. I'd point to not making async calls synchronous-to-the-caller by default as another pretty bad design mistake. The way so many JS files start nearly every line (correctly! This isn't even counting mis-use of the feature, which is also widespread!) with `await` is evidence of this, and so's all the earlier thrashing before we had `await` to deal semi-sanely with this bad design decision. The original scoping system was just bad. We have better tools to make it suck less now, but it was designed wrong originally.
  - catlifeonmars 5y ago
    I’ve thought about what JS would look like if instead of await, the language would await by default and expressions would be explicitly deferable via some other keyword (like “defer”).