> Maintaining Software that is written in a dynamically typed language like JavaScript is costly. Maintaining a JavaScript frontend that is build with React, NPM, WebPack and Babel is even more expensive.
Not exactly. In modern browsers JavaScript executes in a VM. If the JavaScript instance is written in a strongly typed way it executes quickly by receiving the full benefits of a compiled language. Aside from arithmetic it executes almost as fast as Java. That is one of the strengths of TypeScript.
I do completely agree about NPM, dependency overkill, and framework insanity.
In short, don’t blame the language for being slow. Blame marketing and bad developers. That being said I have little faith that WASM will be fast once it meets the reality of bad developers and marketing teams.
Again, that goes to the quality of product/people in a given instance. I have done this long enough to fully appreciate that when it comes to fucking up software on the web people will find a way whether it’s for some poorly conceived developer motivation or media/marketing motivation.
i think the original post just mentionned « costly ». It didn’t say it was impossible to mess things up even with rust. Just that it removes the cost of checking types are still matching after a refactoring or a dependency update.
> A single threaded environment does not yield the usual advantages of the Rust borrow checker.
This is quite wrong - reference invalidation and async code that's being scheduled within a single thread are two common examples where it matters a lot.
Lots of boilerplate and error-prone code can also be avoided by implementing `drop` on relevant types, this can yield to pretty interesting APIs in the web space.
This argument is a bit... tired. There are genuine advantages to different technologies and we should explore them. Every article about rewrites (not only Rust) is met with this sort of comment and it is counter productive. If someone is claiming a technology is better in some way and you disagree, explain why they are mistaken.
> There are genuine advantages to different technologies
That is also a tired argument. The compile target is WASM. Rust can be the greatest thing ever, but the performance that matters and the only limitations the user will see are those inherent to WASM. Is WASM multithreaded with the execution speed of a Rust binary? No, so who cares?
The process of generating the WASM is entirely different. C, C++ and Rust all generate x86 assembly but they have very different trade offs. Following this line of reasoning writing raw WASM would also be a fine choice!
It certainly isn't HN. It's everywhere. Reddit was worse by an order of magnitude and poorly moderated. I don't even think WASM executes faster than JavaScript in any meaningful metric.
The strongest motivation, from developers that are not in any way involved in the WASM spec, is a shimmering hope that developers will be off the hook for writing JavaScript. In the context of "replacing JavaScript" type threads this results in the religious fascination that you and others have observed, but in other contexts comments are equally up-voted for their critical examination: https://news.ycombinator.com/item?id=21723071
If the desire to not use JavaScript is widespread, is that a sign that the pool of software developers are all wrong or maybe it's a sign that there is something truly distasteful with JavaScript?
The problem is that a lot of people who "don't like JavaScript" actually don't like dealing with the idiosyncrasies of web technologies.
Instead of developing an understanding of the environment JavaScript was developed in, its limitations and the idiosyncrasies that shaped the language as well as the methodologies that have been developed to work around that; people appear too spend a week learning to write JavaScript (from W3 schools) as if it was C#/Java/Other C style language the developer is already comfortable with.
Then they write code, shitty let's pretend this language is other language code. Since the web stack is designed to fail gracefully, there are no compilation errors, fatal runtime errors rare and the mistakes made attempted to be corrected or gracefully dealt with by the system.
If one is used to writing unforgiving languages like C++, one might conclude that everything is fine. Because hey, it kind of runs in my browser!
Other devs come in. Do the same thing. Code turns to spaghetti. Global variables everywhere, improper scope, implicit type coercions and (of course) insufficient unit testing.
Now the code is in production. Users interact with it using a different browser. Packages and features are added. The code is a mess, weird bugs are starting to appear and the product is a mess. "Oh well, it's because JavaScript is shit but we had no other choice. It's all Brendan Eichs fault."
None of the developers I've met that have strong negative opinions on JavaScript appear to have made an effort to understand it and how to work with it properly. Instead it appears easier to just disregard the language as a piece of crap.
I don't blame rain when bad drivers get in car accident. It really is true that there are bad drivers in the world and that they are numerous.
That is faulty reasoning for a couple of reasons. What size is your sample pool out of total developers? Degree of passion in an opinion is not evidence of it being widespread or how widely spread.
Although a faulty premise the point you make is still valid, but more complex than you are suggesting.
* Perhaps many developers are not properly prepared or educated to that language or in general. Is that language a common language of primary focus in many computer science programs? There isn't any established licensing or certification program to qualify competence in the industry for any language.
* Perhaps there is a common lack of motivation to perform well in this language. Many large organizations set performance targets that are far out of alignment with product quality or code authorship.
* Perhaps there is a common lack of mentoring. It could be reasoned that sometimes new developers are thrown to the wolves at work and the people they are supposed to be reliant upon for guidance are just as insecure.
An example I work on a team at a really ginormous company that is incredibly insecure. I spend most of my time performing copy/paste instead of writing code and the code has all kinds of problems. It would be faulty to blame the language for such poor implementation and such poor internal development.
By far the most common behavior I have observed in the big established corporate world is that most developers enter software development careers from a computer science education. Most of the time the languages of primary focus in education are C++ or Java but not JavaScript. The result then is to make JavaScript behave like something an inexperienced developer is more comfortable with using an architecture in a box and when that doesn't fully work simply add tools until it does work. The fact that JavaScript is multi-paradigm and can behave like Java, somewhat, isn't helpful.
These same frustrations exist for a variety of other popular languages as well. The only one thing that separates JavaScript from other popular languages, in this regard, is that JavaScript is the language of the web. If you are forced to work on that software platform JavaScript is forced upon you to all your emotional anguish and sad loathing.
I think it is a sign of people being asked to do things they don't want to/know how to.
I actually like writing JavaScript, but there are guys on my team who are more backend orientated who are occasionally called upon to do frontend fixes in JavaScript and they hate it and moan and grumble from start to finish every time they have to do anything.
And that is fine.
The trick is don't ask people who are not JavaScript engineers to write JavaScript. Same way that you don't expect the electrician you got in to fix your broken sockets to also unclog your toilet.
I don't think WASM is meant to replace JS, but you the tooling is such that you can use it to replace JS and have the JS glue generated for you. But it does seem that in a couple of years it'll be on-par performance-wise with javascript, without needing any JS glue autogenerated.
--------
WASM vs javascript performance is a multi-faceted beast.
DOM manipulation? Probably not going to be as fast in WASM because you'll need a javascript bridge, though the cost of calling between WASM and javascript has been greatly reduced. Firefox has a nice post about it [0], and IIRC, chrome made similar optimizations since then.
For more computationally intensive things though, WASM can beat javascript. Though that's still a little nuanced because if you really know what you're doing, you can write your javascript such that the optimizer can work really well. The firefox team put out a nice post detailing writing a hot path in WASM and getting almost a 6x speedup in their real-world-ish benchmarks (so, take that with a grain of salt)[1].
> Cool but when it comes to DOM manipulation, which is what matter for most.
Try to say to anyone making 2D/3D games in web browser using Canvas/WebGL that DOM manipulation is the only thing that matter. And look to their reaction, just to laugh a bit.
Not exactly. In modern browsers JavaScript executes in a VM. If the JavaScript instance is written in a strongly typed way it executes quickly by receiving the full benefits of a compiled language. Aside from arithmetic it executes almost as fast as Java. That is one of the strengths of TypeScript.
I do completely agree about NPM, dependency overkill, and framework insanity.
In short, don’t blame the language for being slow. Blame marketing and bad developers. That being said I have little faith that WASM will be fast once it meets the reality of bad developers and marketing teams.