And building web pages with rust is just another example of this phenomenon, its ironic because somehow its viewed as a positive thing by people who commonly complain about the introduction of new tools into web development ecosystem, but the power of rust hype somehow obscures the fact that this is exactly the same thing such detractors always complain about.
For the record, I love rust and wasm and think this is great, but I have always been opposed to the framing that people creating new web development tools is a bad thing.
It is perfectly logical to believe that this is true, while simultaneously believing that allowing new language ecosystems to target the browser, could result in a new ecosystem that is much more conservative and changes at a slower pace than the JS ecosystem for whatever reason (a language with a larger standard library, a language with a different culture etc...).
A one time change to another ecosystem and then a slower pace of changes.
Who knows if this is will be the case, but it is a logically consistent position to hold, and there's nothing ironic about it.
It's perfectly logical to criticize the JavaScript ecosystem for having too much churn, while calling for a change that will increase Global web development churn, while simultaneously creating another subset of the global ecosystem with a locally lower level of churn--assuming you are only planning on working in that particular ecosystem.
If you're suggesting otherwise, you'd have to explain what exactly is bad about churn in general and why those negative properties somehow dissipate based on the source language. Using your logic if every tool in the existing js landscape compiled down to wasm somehow "churn" would be a non-issue, but if that's the case then "churn" must mean something different than what is regularly complained about on every js technology thread on this forum.
But here goes.
First, I don't care about churn--doesn't bother me. It does bother a lot of people though.
Imagine there's a console called a ChurnBox. ChurnBox only runs code written in Churn. The Churn ecosystem is known for adopting and then abandoning frameworks at a rapid pace. People who run Churn teams have a reputation for for quickly adopting the newest Churn framework of the moment.
Now you are a developer who wants to work on the ChurnBox, but you absolutely despise learning new frameworks.
You could try to find a company that uses Churn with no frameworks, but you're a bit lazy and it's hard to find that kind of thing out just from reading job advertisements, so you stick with your old trust language--Molasses.
Molasses is known for its very expansive standard library and its very slow release cycle. The community is also very conservative, so most Molasses developers stick with the standard library and new frameworks are rarely released.
One day the company that makes ChurnBox announces that they are going to run code written in a low level language called Chasm that is designed to be easy to compile to.
Then some of the Molasses maintainers announce that they are releasing a Molasses to Chasm compiler.
You're excited because you think that maybe in the future you can completely ignore the Churn ecosystem, but still get to write programs for the Churnbox. You think that maybe in the future you'll be able to easily find Molasses Churnbox shops to work with that will adopt the conventions of the existing Molasses ecosystem, and thus rarely adopt new frameworks.
I think you're just too condescending to fathom someone disagreeing with you.
> Imagine there's a console called a ChurnBox. ChurnBox only runs code written in Churn. The Churn ecosystem is known for adopting and then abandoning frameworks at a rapid pace.
Totally irrelevant. Pick a framework and use it, there is nothing preventing you from doing this regardless of the language; that's an indisputable fact. If you feel compelled to make engineering decisions based on superficial fashions rather than as an answer to specific needs, that's your mistake, it has nothing to do with the language or the framework.
> One day the company that makes ChurnBox announces that they are going to run code written in a low level language called Chasm that is designed to be easy to compile to.
Absolutely nothing has changed, that's exactly how all modern JS tooling works today! In fact, almost every language out there has some type of lang-to-js project, the only thing that makes WASM special is the memory and performance capabilities that cannot be achieved with vanilla js, however the "too much churn" crowd are usually quick to point out that low-level performance is almost always complete overkill for a web application.
> Now you are a developer who wants to work on the ChurnBox, but you absolutely despise learning new frameworks.
WASM presents you with the exact same problem because you now have to learn a new framework that models your applications with respect to a browser environment. 99% of JS frameworks from the last two decades continue to work today, so the only reason you would ever upgrade to something different is because you have a specific need that justifies the upgrade or you are the very thing that you're complaining about and rely on the slow pace of Molasses to prevent you from refactoring your production applications every time someone's personal project hits the front-page of HN.
Kick rocks.
>Totally irrelevant. Pick a framework and use it, there is nothing preventing you from doing this regardless of the language; that's an indisputable fact. If you feel compelled to make engineering decisions based on superficial fashions rather than as an answer to specific needs, that's your mistake, it has nothing to do with the language or the framework.
First engineering decisions are often based on superficial fashions because fashion influence executives, investors, engineering leadership, and available talent.
Second I wasn't talking engineering decisions, but career decisions relating to potential work environment.
Third those aren't the decisions I would make, but I can understand how someone would arrive at them logically.
>Absolutely nothing has changed, that's exactly how all modern JS tooling works today! In fact, almost every language out there has some type of lang-to-js project, the only thing that makes WASM special is the memory and performance capabilities that cannot be achieved with vanilla js, however the "too much churn" crowd are usually quick to point out that low-level performance is almost always complete overkill for a web application.
So wasm is no better than JS, and it isn't a better compilation target. Except where it is better. But that's irrelevant because the straw men you're conjuring don't think that part matters. Gotcha.
It doesn't matter if wasm is actually a better compilation target (I think that it is) because it is perceived to be a better target, and is attracting interest in places that compiling to JS didn't (Blazor for one).
>99% of JS frameworks from the last two decades continue to work today, so the only reason you would ever upgrade to something different is because you have a specific need that justifies the upgrade
If you're talking about personal projects, sure. I don't know anyone who is concerned that they might have to switch frameworks for their personal projects. The concern is rapid adoption and abandonment of frameworks within potential employers.
Executives and investors aren't hip to the latest software engineering trends, and even if they are, it's not at all common that non-technical executives are asking engineers to rewrite the business in a new framework, this is pretty much never what they want, even in the rare case when that's actually a good idea.
As far as engineering leadership goes, if they're rewriting the business based on technology fashion they're simply a terrible engineering leader and that is the consensus opinion within the industry.
Finally, the talent pool argument just doesn't square with reality; the JS talent pool is one of the most robust in existence, the idea that businesses are having trouble hiring engineers because their JS frameworks are going out of date is fiction.
> So wasm is no better than JS, and it isn't a better compilation target. Except where it is better. But that's irrelevant because the straw men you're conjuring don't think that part matters. Gotcha.
Wow. That's a very disingenuous twisting of what I wrote. It's not a starwman, it's an extremely common criticism of the js ecosystem, i.e. that it has too much complexity and that all these fancy tools don't contribute much of anything useful except fluff for cowboy programmers to pad their resumes. The use of the word "churn" implies that nothing useful is gained, otherwise it's not "churn" it's "progress" and something to be lauded rather than looked down on.
> The concern is rapid adoption and abandonment of frameworks within potential employers.
Right... so potential employers who want to build front-end web applications have an overflowing arsenal of battle-tested front-end tooling in the JS ecosystem and now WASM comes along and offers an exponential increase of nascent front-end tooling options, yet somehow you can't connect the dots between why the introduction of these tools in the WASM ecosystem produces EXACTLY the same effect as it does when new tools are introduced into the JS ecosystem. How long before we start to see "Why we rebuilt our front-end in Rust/Ruby/Go/Haskell etc" blogs hitting the front-page? It's exactly the same damn thing.
>As far as engineering leadership goes, if they're rewriting the business based on technology fashion they're simply a terrible engineering leader and that is the consensus opinion within the industry.
Yes this is basically always a bad idea. That it's a bad idea and doing it makes you a bad executive/leader/whatever doesn't stop it from happening.
>Finally, the talent pool argument just doesn't square with reality; the JS talent pool is one of the most robust in existence, the idea that businesses are having trouble hiring engineers because their JS frameworks are going out of date is fiction.
You can always find candidates. Whether you can find candidates in your particular locations, for the price your company is willing to pay, that don't require more training or ramp up time learning your framework than your company is willing to privde is another story entirely.
>Wow. That's a very disingenuous twisting of what I wrote. It's not a starwman, it's an extremely common criticism of the js ecosystem, i.e. that it has too much complexity and that all these fancy tools don't contribute much of anything useful except fluff for cowboy programmers to pad their resumes. The use of the word "churn" implies that nothing useful is gained, otherwise it's not "churn" it's "progress" and something to be lauded rather than looked down on.
You aren't the one making the argument, you are picking the version of the argument that fits your argument.
One of the biggest arguments for using vanilla JS is performance, and there are plenty of people arguing against churn and for performance. But you dismissed the performance advantage by saying that people arguing against churn don't care about low level performance.
>"Why we rebuilt our front-end in Rust/Ruby/Go/Haskell etc" blogs hitting the front-page? It's exactly the same damn thing.
I'm sure that will happen.
The difference is that if you decide to work for a C# shop doing Blazor development, they are less likely to switch their company over to Ruby, than a JS shop is to switch to a new framework or introduce new tooling.
If that sounds good to you, then it makes sense to simultaneously dislike the state of the JS ecosystem, yet like the introduction of wasm.
It also provides a boost to other languages, which I think is good, there's no really good reason why JS should continue to be the only browser 'blessed' language.
The primary complaint expressed regarding front-end churn is that the landscape is confusing because there is too much tooling and too many options and that they're unnecessary and that people should just use JS, if you're saying "not having to deal" with js is a positive thing then you're implicitly saying "churn" is not a problem since "not having to deal with js" is the only reason that "churn" exists in the first place.
Either "churn" is bad and something like rust-to-web is another example of unnecessary tools complicating the landscape or tooling that helps to avoid the warts of js is a good thing and "churn" is a non-issue; you can't have it both ways.
Why is that a problem and who is the arbiter of merit with regard to publishing code to the internet? I can't see any other way to parse what you've written other than "people should stop making so much stuff"
> wasm is just a new compilation target for Rust
And the vast majority of the js ecosystem is just compilation targets for js, if anything rust seems even further removed from the web ecosystem since web applications typically don't require low level performance.
But at the same time --
To all the people complaining that modern web browsers are too complicated for small teams to build and maintain, do you think WASM helped with that at all?
To all the people complaining that Javascript's lack of an extensive standard library makes it hard to quickly read/grok other people's code on Github, do you think that situation is going to get any better when people are using entirely separate languages to program the same webapps?
To all the people complaining that there are too many frameworks and tools being released for the web to keep up with, do you think that's going to get any better when suddenly every programmer and their dog can start porting any Open Source UI toolkit/framework to the web with low-cost DOM bindings?
Kind of yes.
For simple browser as a general application platform you need a simple base technology where much can be shipped as library level. It would be fun to see WASM only browser with JS and CSS layouting solutions run as WASM compiled libraries.
So in theory WASM could be used as a first step to more simple browser but in practise it's propably just a fantasy.
Absolutley not. I love rust and would be happy to live in a world where I could write rust in any place where I would typically use typescript or babel or coffeescript back in the day, but none of that is going to be possible without an entire stack of tooling similar to that which already exists for the js-targeted ecosystem, and I have no problem with that, but people who ostensibly dislike "churn" claim to have a problem with new tooling and new solutions for building web pages and this is exactly the promise of wasm.
If anything, wasm represents the biggest shift in "churn" in the history of web development since it opens the door to dozens of new languages and frameworks that were previously impossible to use for web development.
You mean you support the creation of a new JS UI framework every other week? Or is this about something else?
You have no idea what people need when they decide to create whatever is they want to create, if you don't want to use it you don't have to.
Yes and nothing about the Babel or typescript or node was required for the creation of wasm or a wasm compiler.
People complain about churn in the JS ecosystem because of the rate that frameworks and tooling rise and then fall out of favor.
I don't see the irony at all in people complaining about one ecosystem while being excited that they are being given a way to bypass that ecosystem all together.