If it were me, I'd prefer rails to django any day of the week, that's a personal preference, but if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views, which you need a js backend to do.
But if I have it right, I have no idea why a JS backend would be required to do SSR; this is exactly the same domain of work php, rails, django have always done, without node.js needing to enter. For an SPA (which I believe is just a bunch of js fetching data from JSON apis and rendering client-side), you'd need JS to handle client-side rendering, but if you can replace that with WASM (when it has DOM support)... I don't see why you'd need JS anywhere
FYI I'm defining everything because I'm pretty sure there's a mistake somewhere in my understanding of the problem
Traditionally, it means rendering your HTML on the server. Exactly what you're saying.
It also refers to a specific technique that's used to implement rendering your HTML on the server by effectively running your client side app server side, then shipping its output. This requires some work to get right, and so it's presented as a feature of client-side libraries/frameworks.
The actual client code is being executed.
Wait thats just weird -- if you're effectively removing the work from the client to the server anyways, such that its only executing on the server... I don't see what you've achieved beyond the original writing of standard language-agnostic SSR -- that you can design everything client-side, and conveniently migrate the heavier work serverside without interruption/rewrite?
Finally, it lets you also render them to React Native using a lot of shared code. And you can share code between your backend APIs, etc.
To be honest, I’ll take Typescript over anything, even if it wasn’t the default for the web. It strikes the perfect balance of flexibility, concision, safety, debugging ux, and has a huge ecosystem to boot. I think client side JS these days if anything is underrated and the WASM hype won’t change much - if you want a lightweight, accessible app then doing a SPA in JS (with SSR) is actually not even a compromise, it’s truly superior to any alternative. Now, with a big caveat: you need to invest to get it all set up properly. No one has really “railsed” it yet, as far as I can tell.
It's not, it can run on both. You render on the server for the initial page load, and then on the client for every page after.
Or not! The point is, now that you've unlocked both, you can use either one, in the way that works best for your application, in whatever ratio makes sense.
https://developers.google.com/web/updates/2019/02/rendering-... is a great resource on the subject.
You can be fully Server-side (regular php), you can do full JS client-side rendering, and you can have hybrids that mix both.
This is totally not what the parent is getting into. It seems like your comment reads much more like "my personal preferences are good" than the parent
I have not used React with Rails and maybe I'm misunderstanding your comment, but the react-rails readme includes a section about SSR via ExecJS and integrated with Rails:
https://github.com/reactjs/react-rails#server-side-rendering
This is not typically how the term "backend" is used in this context. Most mature apps will use a variety of tools and services built in a variety of languages, but this is not referred to as "importing a second backend." In fact, your comment is apparently the first use of the phrase "import a second backend" on the entire internet: https://www.google.com/search?q=%22import+a+second+backend%2...
Is not worse, is fine. Mostly depends on the requirements, why go the extra complexity of SSR if you don't need it?
None of that eas necessary for WebAssembly to be developed. Unless you mean that the annoyance of the constantly changing JS ecosystem motivated people to push for it.
Not to mention that at this point the complexity of web development isn't exclusively held within your framework choice. Thinking about global state, eventing, and architecting your project are where the real hard problems are.
[1] https://2019.stateofjs.com/front-end-frameworks/#front_end_f...
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.
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.
However:
> Nobody wants to hand-write wasm (...)
As a side note I want to point out that it is actually quite feasible to hand-write WASM in the text representation WAT.
It has some high level control constructs, type checking, some unique safety guarantees and a simple memory model.
Writing some (simple) programs in WAT and possibly a small language compiler for WASM is quite educational, fun and can be inspiring.
It can also build a more grounded intuition for the performance characteristics of WASM.
Theres no churn in WebAssembly tooling and frameworks yet, because WebAssembly has yet to make a big impact on many front end devs. We will see the jQuery-but-WebAssembly for making binding easier, Bootstrap-but-WebAssembly for making UIs and React-but-WebAssembly for managing components (not actually those libraries, but equivalents) come along and they will get adopted to make applications that serve large bundles of WebAssembly code that could be done better in simpler tools. That is inevitable.
WebAssembly will be used badly. Everything is, especially in web dev. Hopefully it will also be used well though.
I'm not sure I've seen a more elegant approach to frontend web development in 2020 than Vanilla JS.
Maybe with some lit-html on top.
Active State had ActiveX plugins for using Perl and Python instead of JavaScript.
http://www.software-lab.org/publications/usenixSec2020-WebAs...
Google did a much better version of this, without these problems; they called it PNaCl. People still didn't like it, because LLVM IR is still not technically a formal standard, only a de-facto one.
I'm not sure if this is still the case, but last time I looked into it LLVM IR also changed between releases in ways that were not backward compatible.
I don't see this as a fundamental limitation.
Perhaps I should have said QEMU instead of VirtualBox.
The thing about the web, and web standards, is that web clients (browsers) are expected to be able to work with web apps, on a common "web platform." Users expect to be able to take an up-to-date web browser and point it at any arbitrary old website, and have it work. And web platform engineers agree that this is how things should be, and make sure that browsers do everything they need to do to make this possible.
But having the possibility of a web app delivering one of N different binaries for each of a bevy of random ISAs—and no requirement to support all ISAs, only whichever ones the site's author felt like deploying—means that the browser authors of 20-years-from-now, to support users' expectations of arbitrary old web apps "just working", would need to ship N virtual-machine interpreters, one for each ISA that people ever compiled web binaries for.
Basically, it'd be a not-quite-combinatorial explosion in VM/runtime implementation work, which would decrease the quality that any one VM/runtime could have (which is really bad when those very implementations are one of the main sources of security vulnerabilities for attacking computers today.)
And, even then, there'd still always be sites broken because they shipped native code only for a platform nobody ever bothered to build support into browsers for; or used an instruction only available on some extension of an ISA that only appears in some particular proprietary chipset.
The web-standards people all agreed that, if you were going to have "object code for the web", it was much better to constrain the web to one "abstract machine" ISA. All the browser authors could then put all their effort behind implementing just one high-quality runtime/VM serving that abstract machine.
The only dispute, after that, was what form the ISA would take. Google suggested LLVM IR, and was shot down. WASM came up with their own proposal, and it got accepted, probably mostly because it was a proposal for a standalone formal standard, rather than a de-facto part of something else.
Probably, any ISA that was standalone in a similar way could have been used instead of WASM. But that is a surprisingly rare quality in an ISA. (For example, neither JVM nor CLR bytecode is a standard independent of the platform/runtime it's a part of. You can't become a member of the "JVM ISA steering committee", only a member of the Java working group.)
Rust is a special case here, light weight, and loved by JS devs.
I'd still "flame" anyone who wants to drop a C# or Java VM on their users.
Is it? That's interesting, because to me the two languages seem to be polar opposites.
"loved by JS devs" is maybe a bit strong, as there are a LOT of JS devs, but we do enjoy a lot of JavaScript folks getting involved with and/or using Rust, and I and others have given a bunch of talks about Rust (with and without wasm) at JavaScript conferences that were well received.
Static checking etc. is nice but what's wrong with things like typescript? Do we really want web libraries fragmented into a million languages?
> randomly from the norm for no apparent reason other than to be different
This has been written about in a number of places, and I don't have time to get into it, but a lot of languages are trending in this direction with syntax because it is more regular in a language that contains pervasive type inference. It's not random.
> Static checking etc. is nice but what's wrong with things like typescript?
Typescript still has node (or deno, still V8) as a runtime, so you're still dealing with its runtime, and all the cons (and pros) there. Additionally, the guarantees you get out of TS and Rust are different, as they have pretty different type systems, even if they're both statically typed, and TS is closer to Rust than it is to JS.
- leaning on (some) pragmatic FP concepts
- modern tooling and dependency management
- very _approachable_ and solid documentation, books etc. (see MDN, Rust by Example, Rust Book, Eloquent Javascript...)
- both can target the browser (well)
- Mozilla has a very good name in the Web dev community. I think at least; this is definitely relevant to me.
I just remember having to do a lot of my college classes in C++, where some of our basic programs needed variables to be constantly cast into another type just to do something with it. I remember, man, I cannot wait to have to deal with this when I parse json data from an api request, bring it on.
I am JS developer, and apparently I love Rust.
In what world is Rust a lower level language compared to JavaScript at this point?
That seems like a much bigger minefield, but I’d be happy to be educated on this. I’d ask that part of that education include why I’d ever introduce this class of problems into web development.
Rust is the first mainstream language that looks at this code and says "Hold on, are you the only one modifying `a.name`?" And the intimidating part is not the question. The question is not for you. The intimidating part is that the Rust compiler asks itself the question, and it always knows the correct answer.
What the Rust compiler is looking at is the same thing the senior programmers are looking at during code reviews at your company. The people who know who should own which data. In C, once you `malloc` a struct someone has to know to `free` it. That's the rule. You acquire a resource? You're in charge of releasing it. Or at least passing the responsibility of freeing it over to someone else.
Rustc is the ultimate code reviewer. Yes, it's super pedantic, but also, hey, it can take any amount of insults you can throw at it and still thrive. If you run out of things to call it and the code still doesn't compile, guess what, the problem is probably on your side.
I repeat, Rustc is the perfect code reviewer you could ask for. And it's available 24/7. Compilation speeds are not very fast? Ok. Compare them to code review times from your peers when using a lesser language. 10 seconds for an incremental compile doesn't seem so bad when the alternative is to get instant feedback and a comment 16 hours later that you missed an edge case.
Sorry for the big post. Thanks if you read the whole thing; kudos if you scrolled straight down. Be kind, work hard, and good things will happen.
The embedded one. Can't write bootloaders or kernels in JS. I mean, maybe you could but... why would you?
(On mobile here, bear with me if no newlines came through)
There is no axis on which JavaScript (with or without Typescript) is a higher-level language than Rust in 2020. Rust offers a richer standard library, much MUCH more powerful facilities for modeling data, state-of-the-art (de)serialization that's one crate import and a one-liner annotation away.
I don't know who came up with asm.js, but that person definitely knew. JavaScript's destiny is to be a building block. Yes, it feels nice to write plain JS without importing any libraries. It's nice knowing the difference between `Array#slice` and `Array#splice` without looking it up on MDN. But it felt just as nice for ASM coders in the 80s to bypass a C compiler, and look where we are now.
You’ll get all that (and more), and it’ll be higher level.
Additionally, these languages are designed to target the web, so they have a lot of libraries and bindings for JS libraries already written.
Redex's library selection is anemic compared to Crates.io, and so is Pursuit's. There are a couple of gems in both, but for any given use case it's just as likely you will have to write your own code than find a workable solution in the package manager.
More importantly, Rust has orders of magnitude higher bus factor than Purescript and ReasonML combined. Phil Freeman has long since left his project, and so will eventually Hongbo Zhang, at which point Reason will follow PS's slow downward spiral into open source limbo.
Believe it or not, I actually put a bit of thought into this. And I do firmly believe that Rust is by far the best ML-like language for the web available to the public right now. Perhaps I should finally write that blog post I keep putting off.
So you are missing a basic feature that a bazillion other languages can give you. I am still amazed how people think that the ML features in Rust somehow new inventions.
The onus is on you guys to tell me why I’d add cognitive overhead for simple webapps, and if it’s coming from the Rust community, I’m expecting to hear ‘performance’, in which case I’m game.
I have the same opinion on overheard in the JS churn cycle, it’s up to you to make the case why the overhead makes sense for the cruddiest of apps.
We shouldn’t coronate things willy nilly. If Rust is the one true blood prince of the C era, I expect him to reign in similar domains, but please don’t flex that power in domains where you are a sub standard solution.
All hail Rust, but jesus, slow down. That’s a simple js app.
Some people like Rust. Some people like web apps. Some people want to use Rust to write web apps. If you don't, there are tons of other technologies you can (and should!) use to do that, and someone saying "hey if you're interested, here's how with a small example" isn't a threat to any of that.
I no longer treat these posts as banal.
And considering TypeScript is so favored as a way to "herd the cats" of JavaScript typing, it seems not everybody shares your opinion.
People go to Rust not necessarily because it's "fast" or "low-level", but possibly because it has a expressive type system that lets you be precise and correct without having to be verbose.
Sure, the fact that it can be used at the low-level and for performance-intensive applications can be a very good thing, but it is far from Rust's only merit.
I realize this is an unpopular opinion, but JS/TS is WAY more human readable than Rust is. It's almost the equivalent of programming in C for the browser. Plus, literally anything you could ever want to use in already in the JS ecosystem and doesn't have to be reinvented in Rust.
Also, explicitly borrowing in method signatures is a BIG plus for me as its a lot easier to understand an API when its clear whether it mutates or not an argument, as opposed to JS where number arguments just cannot be mutated and pointer arguments (such as arrays) always can be mutated. I find understanding random github projects a lot easier in rust than js or python.
I'm not saying you should use rust, but many like rust specifically because of its readability and even find they're more productive in the long term because of its "high level" features and explicitness (although LEARNING it is a lot harder).
...so but how's the quality of npm ecoshitstem? last time I heard you guys had some trouble in paradise, plus everything noteworthy is owned by either facebook or google, both having huge antitrust issues lately
Rust certainly has an advantage here, as it was design to not require a runtime system.
Tiny Go, D and AssemblyScript all manage small enough download sizes.
Then just like with native apps, one doesn't necessarily need to download everything at once.
Is there any data on that?
I don't think that has ever been an unreasonable reaction. Nor is it all that unique: if you want to do iOS development in something other than Objective C or Swift then the iOS dev community is going to tell you that you're making a mistake. And they're often right.
I've used Rust. I like Rust a lot. But one thing I don't see mentioned in this article at all: "debugger". Or "inspector". The web development stack has some incredible tools to aid in development, debug code, memory usage, etc. etc. Can you still use them with this single page app? If not, what strength is Rust bringing here that you can't achieve with the standard web dev stack?
2. You can write your backend and front end in the same language which can be appealing to increase the ability for more people in the org to contribute code (eg you don’t need to hire a traditional web developer).
3. Tooling in rust is different. I’m sure the state of debugging and inspecting WASM will get better (I don’t actually know the state) but you’re now not limited to the tooling just in the browser and you can run all of that offline in a server
4. Performance
5. Tooling isn't there yet but it's an area of active development. Debugging in Chrome: https://developers.google.com/web/updates/2019/12/webassembl...
When it comes to DOM interaction (a key part of this article) you absolutely can’t.
I see the logic in compiling a native library to Rust and using it via WASM. It’s the part where you bring the whole DOM WASM-side that I’m sceptical about. As you say, tooling isn’t there yet. Is performance even there yet? Last I heard WASM<->DOM interaction incurs a performance penalty. Right now it all feels like a “because I can” capability. I’m not saying that will always be the case, but for right here and now I’m sceptical.
I was working on some prototype code that would eventually run on an embedded device, so C++ was the obvious choice for that work. Getting it all running in a linux app using SDL was a good starting point, but then I needed to collaborate with some very non technical people. At that point using Emscripten to compile the code to run in the browser ended up being useful work. I can upload the resulting html, js, wasm file to a webserver and anyone with a link can take a look.
Most of the debugging I do outside of the browser. But I was able to do some debugging using the web inspector.
But you’re right. I’m not sure that the tooling is quite there yet for a more generic single page app. My code tends to destroy the browser if left open, and it’s hard to tell why (most likely something memory related that doesn’t translate well).
I’m tempted to do more experimenting with cross compiling to wasm, but I’m not sure if my goal was production code on a browser I’d target anything but HTML5 CSS and JS+framework.
That said, there’s something to be said to being able produce a webapp while having no direct need for HTML & CSS. In the article author was still using HTML and CSS, so mostly the Rust was to avoid JS. My use case allowed me to not have to know HTML to produce a page. There’s also lots of precedent with game devs using Unity or Haxe tool chains to cross compile to the browser.
I don't know why anybody would choose Javascript for a server except for the fact that it's also Javascript, so you can largely share your stack between front-end and back-end. But I'm not convinced Javascript is all that great of a choice compared to most other languages out there for backend development, albeit it being very popular.
If I'm building a blog, then maybe it makes sense, but for high profile web apps/infra I just don't understand the appeal beyond using similar tooling and having the learning curve be the same (e.g. at least on the surface your UI and backend engineers can theoretically be the same).
I guess it generally depends on what you are building, but I tend to prefer something a bit beefier. I also love Go, so I may have a bias there, though the performance bits are data-driven, not subjective.
JavaScript might suck, but it’s got all the normal basic shit other languages have. Loops and shit, variables and stuff. You guys aren’t complaining about a little old language, you’re complaining about UI development and how tedious it can actually be if you want a professional level of polish.
But maybe more importantly: WASM frees Javascript from the future burden of being both a human-friendly programming language, and a machine-friendly compilation target.
I think the human friendliness transition happened already when most JS programmers started compiling their JS-version-du-jour to legacy-JS.
[0] https://www.developerfusion.com/code/2184/dm-web-server/
Also see "IT runs on Java 8" https://veekaybee.github.io/2019/05/10/java8/
I'd like to thank this thread for reminding me why that's probably not a good idea.
Are there any good resources to read up on for making sure accessibility is good in <canvas>? I assume you'd have to implement it yourself.
whatwg.org[1] is less than helpful when it comes to to describing how to make sure canvas elements are accessible; MDN[2] is a little more helpful. tl;dr: it's a lot of hard work.
I have found some relatively useful posts in various places (eg: [3]) for people (like me) who don't like being told not to do something. These articles generally date from around the mid 2010s but, given that there has been little development in the <canvas> world since then, their advice is still good today.
[1] whatwg - https://html.spec.whatwg.org/multipage/canvas.html
[2] MDN - https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/...
[3] - https://developer.paciellogroup.com/blog/2015/02/html5-canva... - including this link because post was updated in 2020
edit: OK, maybe not compared to Rust... but here it wins by ease of learning.