It's interesting to see Rust get up to speed in this realm, however I can't help but feel that so far, it's largely what I would call academically interesting. If I want to start a web project, I can hire a team of developers who know Javascript and its frameworks today. If some of them leave, I can rotate in other people with ease. Of course, this is a chicken and an egg problem, but for the time being it feels like a hard sell.
Greg Johnston, author of the Leptos framework, did a pretty good video about this a few weeks ago[0]. The TLDR is (of course): it depends.
WASM has no native access to the DOM, so all DOM manipulations from wasm-land have to go through JS bindings with all the (de)serialisation costs that go with crossing the language boundary. That eats up a lot of whatever performance gains you'd see from rust-on-wasm for pure compute.
Every so often a language comes out that allows frontend developers to put something other than "JavaScript developer" on their CV.
First CoffeeScript, then Flow and TypeScript, then ReasonML, and now Rust with WASM & web macros.
Of these only TypeScript has been successful, partly because it's backed by Microsoft, but mostly because the code you end up writing is very close to JavaScript.
This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024.
My company did an initial evaluation of Rust web development just to see what the options were. Put out some feelers to our web developers to see if they had any opinions about it. It was almost universally negative. Not because the ecosystem or technology is immature, but because our JavaScript/Typescript devs simply could not grok Rust at all. It was too different, or too difficult, or whatever. So we didn't really pursue it any further. At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.
> at expense of browsers complexity rivaling operating systems.
That's a feature, not a bug, as open source browsers have loosened the importance of the operating system (freed us from the MS monopoly) and enabled an multi trillion dollar web app industry to flourish.
If Google ever discontinued Chrome support it would be picked up by the community in a flash. That's the beauty of open source.
> If Google ever discontinued Chrome support it would be picked up by the community in a flash.
Of course it wouldn't. The number of people capable of managing and developing a full-blown browser is minuscule. Even Microsoft gave up and went with Chrome in the end.
Case in point: how many people picked up Servo? Hell, even Firefox?
What does it have to do with the number of people forking and developing their own browser? Agent string sibstitution/emulation has been a thing since time immemorial.
You make your own browsers and issue correct UA (User Agent) only for GMail to stop working. But works fine when issuing Chrome UA. I guess Google is staffed by Howler monkeys, or malicious.
Pushing for whatever feature they fashion, pushing against stuff that they didn't create, doing things differently for no reason, making sure their software works badly on competitor platforms...
What Google is doing isn't much different from the MS from the 90's, except that they didn't stop improving their browser. At least yet.
Yes, they do. And your point? That they are "a community that will pick up Chrome dveelopment in a flash"? That's not how it works.
Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
> And your point? That they are "a community that will pick up Chrome dveelopment in a flash"? That's not how it works.
Yes it really is how it works. You see, Chromium is used by numerous teams and products already. Developers from these projects already contribute support and patches to Chromium on the regular. That's exactly how open source development works.
> Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
Microsoft (especially Ballmer era MS) sucks at a number of things. That internet explorer was a bloated piece of trash beyond all repair is hardly an indication that browser development is beyond the capabilities of an open source community. It wasn't that it was "too expensive" for Microsoft to maintain IE. It's just that IE could not possibly compete with Chromium, because they were saddled with too much technical debt from years of bad decisions.
Entire operating systems and databases are maintained by open source foundations. Have you ever heard of Linux? MS cannot compete with Linux at the server game. They waved the white flag on that battle a long time ago as well.
Besides, when you fork a project, you don't have to instantly rebuild everything from scratch. A foundation would kick things off by prioritizing bug patches, security fixes, etc. The RFC process for deciding new web features is already handled by a consortium: https://www.w3.org/
Browsers are now so essential, that there is little incentive for Google to drop out and very much incentive for everyone else to continue or increase their involvement.
With Firefox there is even a viable alternative that isn't controlled by Google in any form. I'd agree on many projects that would be the case. For Chrome, no.
Servo never had significant market share of any kind, but it has recently been picked back up by a foundation. Firefox has been outcompeted by Chrome and Mozilla has made a number of strategic blunders over the years. But by and large people stopped using Firefox because Chrome/Chromium was better on most metrics users care about. Even developers tend to use Chrome/Chromium because of the superior native debugging tools.
But last I checked Firefox is still very much maintained by Mozilla.
What other open source browsers have been left without maintainence? Ones with no market share? As mentioned, Servo was never really finished and yet it has recently been scooped up by the Servo Foundation. Mozilla still very much maintains Firefox.
We have plenty of examples of open source databases, operating systems, libraries and languages leaving the major companies they were created at and being scooped up by a foundation or consortium to maintain.
WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
But there's plenty of other examples in the open source world. Chromium is far too important, and there's already thousands of eyeballs on that code base. There would be a Chromium Foundation established very quickly if Google abandoned.
> We have plenty of examples of open source databases, operating systems, libraries and languages leaving the major companies they were created at and being scooped up by a foundation or consortium to maintain.
We have just as many left to die. We just don't know or don't talk about them anymore.
> WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
Ah. So the mythical "community" that will scoop in and continue developing is a compani with a 60-billion yearly revenue. Got it.
> Chromium is far too important, and there's already thousands of eyeballs on that code base.
Eyeballs rarely, if ever, translate into understanding the codebase, or being able to do anything about it.
> There would be a Chromium Foundation established very quickly if Google abandoned.
Can I interest you in Apache Foundation where great amazing projects no longer supported by their original company go to slowly slide into oblivion?
> We have just as many left to die. We just don't know or don't talk about them anymore.
Yes, irrelevant products that no one uses eventually die. At present, Chromium is not one of those, and is installed on billions of devices and used every single day on mobile and on desktop. Entire businesses and derivative ecosystems have been built on top of Chromium (Edge, Brave, Node.js and all of its dependencies, Electron, etc.). If there's an economic incentive to keep an open source product going, it will keep going. Anyway, here's the repo if you're interested in contributing: https://github.com/chromium/chromium
Javascript hot reloading requires a "recompile", you just don't notice it. Import a plain js file without any node tooling and see what you get for free.
> I get F5 to refresh the page when source code changes.
Really? That's surprising but so overkill. How does it know what files to poll and which not to, I assume file:// and localhost but more specific? Does it do it for a webpack/vite app which has its own hot reloading setup?
F5 refreshes the browser page. This has been the way to develop pages since the first browsers.
And the original question was "Import a plain js file without any node tooling and see what you get for free." You don't get hot reloading but you get all I wrote in my original comment and much more for free.
Yes, I know I was just surprised it even checks for changes without being prompted, but I guess that's where all the resources go. The point I was trying to make was a response to your claim that hot reloading magically happens without "compiling", it doesn't (I know I know, it's transpiling in js).
It usually goes something like this: some tool watches the file system for changes > trigger build > another tool in the chain injects changes into session > picked up by client to reflect changes, if done well without resetting state.
These are many tools in a toolchain working well together. This DOES exist in other languages, incremental builds exists. You can save and restore a binary at a certain state, and it's less hassle than it is in js.
One thing the systems development world has that I haven't seen in browser tools is radare/ghidra to follow code paths but it probably exists as a browser extension. The web is just reinventing and repackaging tools that have existed for decades.
> you get all I wrote in my original comment and much more for free
Yes, but `apt install gdb` is just as "free" as `apt install chrome` no? Everything you mentioned exists in systems development, you just haven't used it.
It's not a "recompile". JS doesn't get compiled, it may get transpiled or minified. Node.js is only used for sending data over a local websocket from the file system to the browser. You can totally also achieve this effect on a local offline webpage that wasn't even being served if you added an input on the page (ie the React docs: https://react.dev/learn).
Yes. But the difference in this context is nitpicking. The browser needs to know what file was changed, and what to do with those changes right? And preserve state. That doesn't magically happen it's the tooling that supports it.
I could probably set up a simple environment to watch for changes, run make, reload the binary at $current_state in gdb with a one-liner. But it doesn't really fit the work flow, and GDB already gets all changes after I run make.
Most backend frameworks can just route new requests to the updated code - so a refresh is all you need (though there are tools that simply make that refresh automatic, which is pretty much how js frameworks work as well. Intellij can also make the whole recompile-replace code function happen on window defocus, so by the time you switch to your browser, it is already refreshed. And nowadays the compile of something like Java can well be faster than whatever that npm monstrosity does)
> Many languages have all of that tooling and more. For example C# and Java.
Instant hot reloading? Runtime introspection into apps, and into strucutre of the apps, direct view into what the app sends over the network etc.? Open up development tools in your favorite browser, you'll be surprised :)
Well, java in debug mode can hot swap class methods, for what it worth.
But the web is definitely the most used “GUI framework” ever, so there is no competition with that on tooling ground, even if there is nothing inherently that would block it, as a dom inspection is pretty easy to implement - just print out the tree of ui nodes.
Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB and Wireshark alone, in any language that GDB supports.
Don't get me wrong the web pays my bills and I like it but there's no point exaggerating.
> Except for the hot reloading (which you mention twice btw) the tooling for the popular languages has everything in the list, and most can be achieved with GDB and Wireshark alone, in any language that GDB supports.
"Can be achieved" with some additional tools. I doubt you can easily expect the structure of the app, how it repaints, see all the relevant network requests, and also introspect and query the running app, emulate various hardware, inspect and debug animations etc. in most languages.
Yes, there are collections of tools that may give you all that in aggregate, but frankly, it's not close to an "out-of-the-box" experience.
Have you used GDB? And network requests is what Wireshark was created for.
Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. It seems you don't have much experience in the tools you're comparing against. In GDB you would connect to a running application on actual hardware or in a VM, if that's what you're testing. Screen sizes and network can be done locally.
As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser so it's still an "aggregate" as you like to call it.
For me it's the unixy way of doing things and just the way I like it. Do one thing and do it well.
I've used debuggers in general (IDEA, Resharper, Visual Studio), and even dabbled with disassemblers like IDA in my youth.
> Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference.
So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).
> As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser
Wat. The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". So yes, hot loading is a part of tooling. I've yet to see anything outside the web manage hot reloading with any degree of confidence and speed.
You don't like the hot loading, and let's focus on non-moved non-goal non-posts. I hope you noticed the ellipsis at the end of my list?
What's that immediately available tool for GDB and Wireshark whatever that:
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
- examine and debug animations?
- analyze paint/re-paint performance?
- view and debug delayed background actions?
- record and replay user flows?
...
^ Note the ellipsis again.
The build tools for Web are undoubtedly atrocious. However, there are very few, if any, tools that come even close to the versatility and ease of use of the tools that exist for the web ecosystem.
> So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).
The linux kernel has KVM, doesn't get more out of the box than that. Do what you want with it. Emulate ARM? Sure why not.
> The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling".
Not my comment, I'm addressing your claim of "tooling most languages can't even dream of". The ellipsis doesn't really matter I'm not here to guess what you're meaning.
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
Most debuggers including GDB can print and set state.
> - examine and debug animations?
> - analyze paint/re-paint performance?
I don't do GUI development but you'll have to use a tool specific to the environment you're working with (just like how the DOM is a specific environment). What tool do you use to debug webview? Not your main browser. Systems development is the same.
> - view and debug delayed background actions?
You can get the time spent on anything down to individual assembly instructions if you wish.
> - record and replay user flows?
rr (which is GDB compliant hence integrates well with termdebug in vim).
I don't disagree that there are many tools for web dev. But they're not always better or easier to use. The built-in nodejs debugger is shit compared to GDB for example. My point is that everything you can do in browsers that aren't browser specific exists for other languages as well. Many times very specialized with better features that the devtools version.
Again, I love web development, but I also live in the terminal and love those tools even more. I wish they existed for the web.
If we find that at some point we're missing out on something great with Rust/WASM then we'll hire Rust engineers and not just assume that our javascript developers can do it. That was the point.
Rust on wasm is the same story as .net on wasm (aka blazor): it is nice if you have a single language developer workforce. But once you maintain a portal team, the benefit is gone.
IMHO, the more interesting niche is desktop/mobile apps using html as a toolkit. Because here you can combine raw computing/resource access with being more cross platform.
Most web devs are familiar with javascript and typescript and are currently easily able to create products and solve problems for companies. They are much easier to find and hire compared to rust developers.
So why should a company hinder its own productivity by trying to find rust developers because rust is technically safer in some ways? Or risk ruining the culture of its currently functional developers by forcing them to use rust?
This should be present tense, at least in the ClojureScript case.
Recent cool developments on that side include Electric Clojure - generating transparently state passing front and backend code from a single DSL: https://github.com/hyperfiddle/electric
The problem is not "bad code", but experience from teams and community. Browsing HN might make we think that Rust is everywhere and everyone knows it, but most of the frontend developers in the world are not prepared to inherit a project in such a foreign language.
My theory is that, you probably can see when a language its being picked by some community by looking into courses available, either free or on paid platforms
Most modern C++ code bases also completely lack explicit frees/deletes, but not many would argue that C++ is a managed language.
Though a more objective distinction is hard to give on what is a managed language, I found the garbage collection handbooks’ quote on the topic the most illuminating (linking to my older comment): https://news.ycombinator.com/item?id=35332600
In Rust and in C++ memory layout is part of your public APIs and has to be refactored when it changes. This is not the case with managed languages.
It's not really that; it's really just WASM. There's going to be a flood of this sort of thing from all sorts of languages, even multiple per language. It's early days yet and the ground is still being felt out, but eventually the Javascript qua Javascript foundation in the browser is going to be breached and a day will come when it is a minority language (still many years from now), for exactly the same reason that never in the whole history of computing has one general purpose programming language "won". Per https://www.destroyallsoftware.com/talks/the-birth-and-death... , Javascript is going to "win", but it's going to be Javascript in its incarnation as WASM, not the Javascript we know today.
"random bits of Rust in 2024."
And that's "the ground being felt out", not a fundamental problem. I expect to see WASM frameworks develop that are shipped out to the world as WASM and bind to any language. Decent odds they'll be developed in Rust for several reasons (performance not least of all), but you won't need to know that to use it in your Python WASM front-end app or some new WASM-primary language that is nothing more than a gleam in its creator's eye right now. If you don't want the chaos, hey, great. Even people who live on the cutting edge can't be cutting edge in every dimension. By all means sit back and watch from a distance. But these problems will certainly be fixed.
The enemy of this entire thesis is the layers of additional complexity required by such “innovation”. Each layer has its own API and update mechanisms, all of which slow down developer productivity (especially when inheriting a project you did not build).
In some cases that complexity is worth it — Figma, for example, squeezes a lot of value from WASM. I myself have used WASM to create a browser-based testing environment for a Rust-based static analysis tool I’ve built, so my colleagues can quickly repro issues. But for most web development, it’s not worth it.
In the long term, I expect WASM to start blowing away layers of the browser, precisely because of this problem. It may be another 20 years, but it's going to happen.
To put it another way, no, you're not wrong, and yes, the resistance to large-scale changes to the web stack is huge, arguably the largest resistance of all time. Nevertheless, the amount of metaphorical amperage flowing through is even larger and is large enough that it is already "short circuiting" and blasting a new circuit through. It's going to take a while, and the backwards compatibility will be with us for a while, but we're already seeing flashes of websites where you don't need to know the old CSS and HTML and such because they're actually WebGL and WASM. As more capabilities are exposed to WASM and they become more efficient, more and more stuff will be moved into it.
That will cause its own explosion problem, but it'll be handled. It's not like every website is going to write its own bespoke text renderer every single time. And in the end there are some technologies that will fade out and become legacy, then irrelevant. I may yet outlive the HTML/CSS/JS stack.
but once you blow away the layers you are left with a virtual machine with a number of low level APIs. Most people won't want to use them.
Yes, I can see the advantage of rewriting those layers in terms of the lower level APIs, for example if the DOM API were to implemented in WASM, you could keep it out of the browser, and download only when/where needed (with a number of caveats, of course)...
The main issue is that even if you do that, I don't expect an API designed with JS in mind to be a good fit for Rust, and vice versa. The risk is that you end up programming not against the "Web Platform", but "WebJS platform", "WebRust Platform" etc."
Neither one is a different language. Both merely add type annotations to an otherwise pristine ECMAScript code base.
Typescript has some very few and minor and no longer needed things, like enums or namespaces, that need to be transpiled and are not part of ECMAScript. But again, those are minor and you no longer need them (since ES 2015 one can use modules instead of namespaces, and marked "as const" object literals instead of enums).
I know some people want to argue definitions, "different language" etc., but it's really just a completely optional tooling layer that you can just strip. It's also evaluated purely during development time, for type checks, the actual code that gets executed remains the ECMAScript part.
Whenever there are changes in a new Typescript version it's either purely within the type system, or they add type support for new ECMAScript features, those proposals that reached stage 3.
You could just imagine the type annotations in a different layer than the actual code, like in Photoshop. A layer used only by the IDE and code checking tools.
Microsoft added greatly to the confusion by putting the type checker, like eslint usable standalone or continuously queried through the IDE, and the type annotation files (.d.ts) generation and the completely optional .js file transformation AND .js file transpilation - backwards compatible JS code for earlier runtimes - into one tool. But all of those are different things. If your traget is "esnext" or you don't use JS features that your target runtime does not yet support transpilation is just removal of type annotations (except, enums, namespaces, which are no longer necessary and only exist for historical pre ES2015 reasons).
You completely ignored everything I wrote and merely responded with an assertion, ignoring all evidence. What a terrible way to have a discussion. Would you kindly not ignore the facts?
As a recovered Haskell enthusiast, a can say that typescript is downright luxurious to work with for web development in a way that I think is hard to compete with in rust, because of how it types objects (like composable / decomposable sets), and the generic language to work with types really complements JavaScript instead of forcing you to do things differently.
Personally, I expected dynamic languages to ever match or at least get close to the performance of static languages. That seems that it will never happen, and there's a point where I can't afford that much hardware just to run a website. Think of Twitter abandoning RoR, etc.
Both Python and Javascript are eating Rust's lunch in terms of popularity. And Typescript is just a typechecker, it's still a very dynamically typed language/runtime underneath.
Especially with Rust you have to think way more about banalities of the data model you normally really don't care about in web development.
You are not missing anything. I think people are going crazy for strict static typing because they want to feel like they're on the front edge of progress. But I don't think it's _better_; I think it's just _different_. I got bogged down in with Java and Angular awhile back. The amount of boilerplate required to keep the front end and back end compilers in sync was treacherous. Also, I had to make exceptions for corner cases that wouldn't match up. So it was no benefit to me. Maybe if your application is large enough that it involves big teams on each side, you would need static typing to keep everyone straight. And I think this is a large part of the back-and-forth on this forum. We discuss things that vary based on problem context without realizing (or admitting) that the implementation is situational.
I disagree that you aren't missing "anything", there's no such thing as a free lunch. But I agree that _some_ of the uptick is because people are excited about being a "safe" and "rigorous" developer, but they get a nice package manager with Cargo that feels a lot like pip or npm.
I get a question over and over from front end devs when I teach or mentor about being a "real" computer scientist and picking up c, Cpp, or rust, which is silly. Who do you think invented the dynamically typed languages, English majors?
Yeah. The bill was paid when the language devs bothered to write a compiler, so that your runtime bugs become compiletime bugs and so you can understand what's happening when your program is bigger than a tiny script.
I code alone and need performance for my project. I had choice beween C++ which I know a bit of; Go or Rust which I had to learn. Considering that I screw my mallocs and threads in C++ more often than not, I decided to check Rust. I am not disappointed: the safety helps a lot in getting my codebase free of many bugs (rust won't let me be lazy, I have to solve many bugs upfront). Sure the BC is madenning at times, but the support of the compiler allows me to not think too much about what I do and spend time on my business.
Now, on my old PC, the compiler is super slow so I end up prototyping tricky stuff (like maths) in python and then I port it to rust when I feel it's ready.
(my stuff is emulator: no DB, not much GUI but lots of performance, threading, etc.)
If we for some weird reason were to put go as a modern language, than Java is some Haskell :D
But jokes aside, Java’s type system can’t express HKTs, but up to that point it really is surprisingly strong — there is vavr, but I have also personally followed my former “define Haskell basic data types yourself in Haskell” class quite far in it, including Lists, Eq trait, Maybe type, etc.
It makes more sense coming from the Rust side. For example, I can write a lightweight desktop app using the egui rust framework. But I can also compile that for the web, and run it in the browser. Basically for free, I just have to target wasm.
This also means that if you architect your app right, you have have the front-end and back-end self contained in the same app, or split them over a network boundary.
So let's say you are writing a 3d modeling app or something. You write the engine and the gui in rust, and you ship that binary to your users. You can then also, again basically for free, put a network between the gui and the rendering engine, then you can serve the gui to client browser, and handle the rendering on a server.
The point is this is easy for the rust dev, so they don't need to be a JavaScript dev as well.
I believe that many people from Ruby on Rails and Django communities moved on to Clojure, Elixir, and Kotlin.
Others chose between Rust and Go, if performance was the most important thing.
The thing about dynamically typed languages and their expressiveness, is that you are sacrificing the ease of long-term maintenance for the ease of short-term prototyping.
Personally, I am a big fan of Clojure as a tool for designing software, but I would prefer having to maintain a code base written in Rust.
Even the maintainability argument is suspect I think: Static type systems as commonly used are not very powerful compared with schema validation style approaches used in the dynamic languages world (eg malli or spec in Clojure world). Static types lose in expressiveness, flexibility of when & where they are enforced, and ability to pass around the data shape specifications as data.
edit: and tangentially, the building and iterating lifecycle phase is of course usually the make-or-break bottleneck - maintenance phase sw engineering is comparatively a "happy problem".
That's true, and Clojure (when used with metosin/malli) is probably the only reasonable alternative to statically typed programming languages in terms of long-term maintainability.
Essentially, it's like two completely different reasoning models: inside-the-box (ALGOL / SQL), and outside-the-box (LISP / Datalog).
The first model (ALGOL / SQL) is about designing for machines to better understand, and the second model (LISP / Datalog) is about designing for humans to better understand.
I think that the main issue with dynamically typed programming languages is the lack of robust enforcement.
Java literally has a synchronized keyword and it literally runs on your SIM/bank card, was originally created for DVD players, and runs on every major OS. Plus it used to have 20 years ago as well, but has right now also ways to produce a single native binary.
Rust is a low-level language, quite similar in the target niches to C++, while Go is a managed language with a barely-optimizing compiler for fast compile times, and a GC that prioritizes latency over throughput. They are nothing alike.
Rust and Go are very much alike, when Java is not an option because of the JVM startup time and memory requirements (GraalVM Native Image solves this, but at the expense of highly reduced performance).
I see Rust and Go as the best high-performance high-concurrency programming languages today, and choose between Rust and Go depending on the bottleneck (Rust – CPU / RAM, Go – I/O).
"Compiled language" doesn't have to mean "much harder to read" though. I guess that's why many web devs like Go - it's a compiled language that feels more like a dynamic language because it tries to get the types out of the way as much as possible. Of course it doesn't have all the bells and whistles of Rust (now that generics were added, the next major complaint is nullability), but that's exactly what makes it easier to grok.
IMO Rust is more expressive than most languages including languages like Python. Traits and enums are just... a joy to work with. It is also more constrictive in some ways, and a rust-like high-level language could do probably do better still (Swift/Kotlin/Elixir are close).
There's also a tradeoff between expressivity and performance and correctness. The way I see Rust is you get maybe 75% of the expressivity, along with much better performance and correctness guarantees.
I'd agree it's not a good fit for frontend, but IMO it's an excellent fit for backend.
That depends on what do you mean by expressive. I would call languages with more advanced type systems, like rust here, more expressive, as in allowing programmer to express his intention to both computer and other programmers clearer.
Rust is a great language until you want to hire someone to improve your code. Most developers aren’t familiar with it unfortunately and it would take some time to bring a new person up to speed.
When you want to hire them, you'll have to compete (especially in salary) with employers who need them for something Rust is actually very well suited for.
Ah, not wrong, things are like that currently indeed.
But IMO the Rust dev salaries are a bubble that's about to pop. Personally I'm ready to work with Rust at less than the crazy salaries that are offered (though I'd still expect more than the average JS dev salary).
The biggest bottleneck in web applications was, is, and ever shall be, roundtrip time to the database, especially now that nobody bothers to install MySQL on the same box anymore, so every query has to go over the network. Of course, that's in a sane web application. Trendier approaches also try to shovel 10 MB of JavaScript over the wire first, so you can then call your API (which is slow for other reasons), and then render the result (which is also slow because you've shoveled 10 MB of JavaScript into the user's browser).
The language you choose matters relatively little.
I disagree, those 10MB of JS easily become 40MB of WASM. Picking a language that's compiled to Javascript for frontend code is the only good choice IMO.
WASM is not unlike the JARs and SWFs we got shoved down our throat ten years ago when HTML and JS were lacking any useful web capabilities. Huge files with separate runtime that implement their own renderer and operating environment. Google Docs already does this, using a canvas element to render to rather than using HTML and CSS to lay out text.
I think the right approach would be to work with WASM in the same way that we work with GPGPU programming: write most of the code with JS/TS and write only the computation intensive tasks with Rust/WASM.
Engineering is a matter of tradeoffs. With JavaScript, you get simplicity but lose strict typing (can be compensated with TypeScript), performance etc. Rust gives you much better performance but is more complicated to write. However, for a lot of the websites out there, especially those that are not e-commerce or provide creative tools (e.g. Figma) and do not care that much about page performance, the potential performance gain from rewriting JavaScript code in Rust is not visible enough to end users. Of course there are bad websites out there that are slow, but it is often more about CDN/backend servers/the UI code itself rather than the JavaScript language. In other words, many websites are "fast enough", and most CTOs, product managers and developers would rather use JavaScript/TypeScript and release more features rather than write Rust, in the real world.
Same thing for a Rust replacement for VSCode -- I am sure it is an interesting project, but VSCode performance is generally good enough (I don't ever complain about slowness while developing). A lot of the performance bottleneck comes from the language services anyway. If you improve the loading speed from 2s to .2s that is definitely great, but if at the cost of losing most of the existing extensions, I'm not going to consider it at all.
Yes you can technically maybe get off the ground more quickly up front with JavaScript, but as soon as you hit a certain code base size threshold (not sure what it is personally, it is probably different case by case), you would've been better off with TypeScript or Rust as JavaScript starts to "crumble" under its own lack of types, etc.
> However, for a lot of the websites out there, especially those that are not e-commerce or provide creative tools (e.g. Figma) and do not care that much about page performance, the potential performance gain from rewriting JavaScript code in Rust is not visible enough to end user
Agreed. I would hate to see a CRUD spa written in Rust just because it was the fancy new thing. But sites like Figma, Miro, and Frame.io would make sense to look into a Rust WASM solution.
> but VSCode performance is generally good enough (I don't ever complain about slowness while developing).
The one thing I would say it can't handle is large files, like a large JSON file, I'm talking really large. It's something Sublime could handle and I used to keep it around just for that. This is not something I deal with often enough to really annoy me.
This is probably true for the actual business application itself. It would be cool if we can get an ecosystem of performant WASM libraries that your JavaScript/TypeScript can use and be none the wiser.
Javascript has pretty solid performance, assuming the code is half decent.
Honestly, a major benefit of strict/enforced type systems is that it substantially improves maintainability of the codebase. Large Python or JavaScript projects with no typing can be a huge nightmare.
Okay, if we only care about render performance, rust/webasm is kind of comparable to native js frameworks.
Now:
What is compile times for real-world medium to large projects? Do these even exist? Rust is infamous for its compile times, and frontend dev often requires live reload on every change.
What does debugging look like? Can I set a breakpoint in rust code in my IDE? What do I see in browser devtools? Can I change values in my paused code at runtime, then resume execution?
I don't know how much the Rust dev tools have advanced for browser debuggers specifically, but source code maps allow just about any language to be debugged through the standard browser debugger. You're limited by the browser debugger of course (no time traveling debugger like in real Visual Studio) but it works well enough that it felt like debugging Javascript.
Rust build times are huge at first, especially if you haven't downloaded any dependencies before, (comparable to running npm install) but incremental compilation makes small code changes very quick and easy.
Having worked on a Javascript code base that's grown over a few years, I don't believe Javascript is any faster than Rust when it comes to compilation/transcription/packaging, especially when you need to add a layer like TypeScript between your tools and yourself if you don't want to go insane with JS' lack of typing.
I wouldn't use Rust for a browser frontend, but I don't think the lack of tooling is a very good reason not to. The massive size of WASM binaries, the overhead, the lack of transparency, and all the other problems are, though. I'd stick with Rust on the backend instead.
"If your newest tool is a hammer, every problem looks like a nail."
There is hardly any language that doesn't have some kind of meta language that compiles to JS. And without exception they all are bad, except maybe if you have a backend which only needs some very basic front end which you prefer to write in the same language.
But with any decent sized front end project, JS or TS are the better choices. JS, obviously, because it runs natively in the browser. So all browser tooling works out of the box, debugging is easy because what you see is what actually runs.
TS, although it doesn't run natively, at least was designed to be compiled to JS and is widely supported so tooling is good as well.
But any JS substitute that was added to a backend language as an afterthought will suffer:
- inferior tooling
- more troublesome debugging
- and last but not least, because it was added as an afterthought, 95% of the language will work fine but the other 5% can give you as a developer serious head aches.
I really, really can't wait for the extension to WASM to allow it direct access to the DOM and finally be able to remove the need for JS for 99% of its usage.
I do a lot of frontend development and I just cannot fathom how badly design JS as a language is and how awful the developer experience is. Every time I talk about JS shortcoming with other frontend dev, they point out that JS can do X or Y which other language cannot, but usually it is just a hack that are just not needed in other language because they actually do things properly (like having an actual sane type system and not having three ways to express that a variable is null). And TS is just a crutch that can barely help JS shortcoming.
Finally being able to compile from any language to a, reasonably sane, bytecode that can run in-place of JS is just a miracle and I don't understand why it took so damn long. JS should have been deprecated long ago. Even ActionScript was better.
JS can do some things very well that others can't. Prototype based reflection is very powerful!
Its problem is that the things Javascript excels at aren't all that useful, and the things it's bad at are often sold as features instead ("duck typing means I can iterate faster!").
Hum... Direct calling the DOM API is there already. You may be thinking about FFI marshaling, that there is something on the pipeline for helping (I don't even remember exactly what). But that's only a small improvement on speed, and that almost never is a dealbreaker.
For a while I thought the garbage collection helper was a dealbreaker (for anything except Rust), but GC languages are starting to compile into WASM too, with just a small performance hit. (I haven't looked exactly how.)
This year and the next are looking like some serious promising period for non-JS programing on the browser.
In my view, JS is preferable because you are forced to ship source to the client.
This provides a beneficial atmosphere for learning and sharing solutions.
Compiling to WASM, and front-end builds in general, take this critical and unique quality away from the web platform.
Rust-to-WASM is another attempt to abstract away the pain of JavaScript, attempts which began soon after the world discovered XHR. In fact Google released GWT specifically to appeal to Java devs who took one look at JS and said "no thanks".
This is not so say that there aren't legit uses for this technology - its a great way to port other software, like sqlite or linux into the browser.
But as a way to make applications designed to run on the web?
I suggest that any dev that thinks this is necessary to have a good dev experience take the time to attempt to write a web app with just raw html, css, and js targeted at a modern browser.
There's a lot of space there left to explore, I think, before labeling it as an unwieldy thing that must be wrapped in a safer abstraction to even think of touching.
This is the weirdest gotcha. Nobody said it wasn't source anymore, they implied that it wouldn't be readable or conducive to sharing because it's unreadable.
>Pretty much everything is bundled, minimized, and obfuscated now.
Yes, but there is a strain of software minimalism that eschews the front-end build entirely. This is relatively recently possible because of excellent implementations of relatively good standards starting with HTML5, CSS3, ES6, and SVG2.
Sure, if you want to go backwards. JavaScript was created and persisted because it solved a problem that C++, Java, and to some extent PHP, had of being overly verbose. While the idea is novel, it is not business practical.
JavaScript was created in a rush because a web browser in the 90s needed to do some basic form handling and user interaction.
It's Java but with silly names, stupid scoping, a unique prototype system nobody seems to get down, a strong influence from the worst years of Microsoft, and a legacy that forces it to make some pretty stupid choices moving forward.
It's incredible what browsers have been able to make Javascript do, but it's not exactly a well-designed language.
As for being business practical, WASM is already widely employed by web apps. The front end ecosystem is in its early stages so it's quite messy, but it's developing faster than I expected. It may end up being a real competitor for frameworks like Blazor and ASP.NET if it the tooling continues to improve like this.
I want to be interested in Rust, but then I see a line of code like this in the post:
let decrement = move |_| set_value.update(|value| *value -= 1);
Maybe I've lost that interest I once had in learning language syntax.. I just don't really understand this intuitively and the barrier to understanding this line feels unnecessary. When I compare Rust with JS/TS, Python, or even Swift I feel like those other languages are created in a way that's easy to pick up and transfer knowledge from other languages, then the deeper parts of the language are easily accessible once you're introduced to the basics.
Ok fine, "Rust doesn't have a garbage collector and has reference value semantics and ownership semantics."
My point is that the syntax isn't a problem, it's that Rust has very different semantics from the GC'd languages in the original comment and it all has to do with memory management.
let decrement = _=>set_value.update(value => value -= 1)
I don't understand your complaint about syntax. The real difference here is the concept of a move and a dereference. JS lacks these concepts and naturally has no syntax for them.
API Gateway + Lambda/OpenFaaS/Knative with rust handlers (low RAM/fast start), and typescript/react served via CDN.
with serverless platforms, it honestly matters not what language. Rust is just a convenience for compiling to arm for gravitron and low memory footprint. Languages that carry runtime bloat are less desired though for cloud functions.
If there was a superset of Rust where everything was transparently reference counted, every data structure could hold mixed types easily, and closures were dead simple, then maybe.
These are things that are, IMO, just too engrained as being possible in JS/TS for people to give up easily, especially in terms of UI programming.
I've used both quite a bit - I am pulling for Rust to become more ergonomic for this use case where it makes sense because it has lots of other advantages.
But when the rubber hits the road and you start writing, I think Rust gets in the way too much for UI programming. For a small project it may be OK, but in most orgs you have sweeping design changes occurring (probably too) often. Rust is best when things have stopped churning and stabilize.
UI code often churns like a relentless beast, so something extremely approachable/flexible but strongly typed is best I think. This is why TypeScript is winning in this arena.
I'm optimistic headway will be made, but Rust currently feels a lot better to write for back-end and systems. It's not a surprise since that's what it was designed for.
Besides all this, I'm totally unsure where the size of the distributable comes in. In JS things can be chunked per page easily which keeps load times small. With WASM you get the whole thing by default, correct? That could be problematic.
175 comments
[ 2.7 ms ] story [ 104 ms ] threadIt has a server side rendering mode, which for most projects will be all you need.
So then if you follow the Islands Architecture https://www.patterns.dev/posts/islands-architecture means you can sprinkle some typescript when you need more dynamic functionality.
I'd love to use Rust for front end enhancement in this way, but the problem is you have to completely open up your content security policy https://github.com/WebAssembly/content-security-policy/blob/...
Which is going to get picked up in any security review.
I've written up how I develop web apps with rust here https://rust-on-nails.com/
I wrote it up here https://rust-on-nails.com/docs/continuous-integration/integr...
WASM has no native access to the DOM, so all DOM manipulations from wasm-land have to go through JS bindings with all the (de)serialisation costs that go with crossing the language boundary. That eats up a lot of whatever performance gains you'd see from rust-on-wasm for pure compute.
0. https://www.youtube.com/watch?v=4KtotxNAwME
First CoffeeScript, then Flow and TypeScript, then ReasonML, and now Rust with WASM & web macros.
Of these only TypeScript has been successful, partly because it's backed by Microsoft, but mostly because the code you end up writing is very close to JavaScript.
This is not a dig at Rust (which I love) but God help any developer inheriting a frontend codebase with random bits of Rust in 2024.
- Instant hot reload of application
- Inspect app/page structure in runtime
- Runtime debugging
- Monitor all network requests
- Tools to monitor time spent in functions, painting, redrawing...
- Runtime changes instantly applied
...
And now there is essentially one browser who can afford such complexity. Until Google discontinues it.
That's a feature, not a bug, as open source browsers have loosened the importance of the operating system (freed us from the MS monopoly) and enabled an multi trillion dollar web app industry to flourish.
If Google ever discontinued Chrome support it would be picked up by the community in a flash. That's the beauty of open source.
Of course it wouldn't. The number of people capable of managing and developing a full-blown browser is minuscule. Even Microsoft gave up and went with Chrome in the end.
Case in point: how many people picked up Servo? Hell, even Firefox?
Source: https://archive.is/tgIH9
What Google is doing isn't much different from the MS from the 90's, except that they didn't stop improving their browser. At least yet.
Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
Yes it really is how it works. You see, Chromium is used by numerous teams and products already. Developers from these projects already contribute support and patches to Chromium on the regular. That's exactly how open source development works.
> Browser development is prohibitively expensive. Even Microsoft, a trillion-dollar company, gave up on developing their browser. What makes you think that some magical community will just pick up the development of Chrome?
Microsoft (especially Ballmer era MS) sucks at a number of things. That internet explorer was a bloated piece of trash beyond all repair is hardly an indication that browser development is beyond the capabilities of an open source community. It wasn't that it was "too expensive" for Microsoft to maintain IE. It's just that IE could not possibly compete with Chromium, because they were saddled with too much technical debt from years of bad decisions.
Entire operating systems and databases are maintained by open source foundations. Have you ever heard of Linux? MS cannot compete with Linux at the server game. They waved the white flag on that battle a long time ago as well.
Besides, when you fork a project, you don't have to instantly rebuild everything from scratch. A foundation would kick things off by prioritizing bug patches, security fixes, etc. The RFC process for deciding new web features is already handled by a consortium: https://www.w3.org/
With Firefox there is even a viable alternative that isn't controlled by Google in any form. I'd agree on many projects that would be the case. For Chrome, no.
But last I checked Firefox is still very much maintained by Mozilla.
Why doesn't community pick other browsers in a flash?
We have plenty of examples of open source databases, operating systems, libraries and languages leaving the major companies they were created at and being scooped up by a foundation or consortium to maintain.
WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
But there's plenty of other examples in the open source world. Chromium is far too important, and there's already thousands of eyeballs on that code base. There would be a Chromium Foundation established very quickly if Google abandoned.
We have just as many left to die. We just don't know or don't talk about them anymore.
> WebOS is a great example. Created by Palm as a mobile OS before they sold it to HP, who open sourced it. Now the primary contributor is LG, who uses it in smart tvs.
Ah. So the mythical "community" that will scoop in and continue developing is a compani with a 60-billion yearly revenue. Got it.
> Chromium is far too important, and there's already thousands of eyeballs on that code base.
Eyeballs rarely, if ever, translate into understanding the codebase, or being able to do anything about it.
> There would be a Chromium Foundation established very quickly if Google abandoned.
Can I interest you in Apache Foundation where great amazing projects no longer supported by their original company go to slowly slide into oblivion?
Yes, irrelevant products that no one uses eventually die. At present, Chromium is not one of those, and is installed on billions of devices and used every single day on mobile and on desktop. Entire businesses and derivative ecosystems have been built on top of Chromium (Edge, Brave, Node.js and all of its dependencies, Electron, etc.). If there's an economic incentive to keep an open source product going, it will keep going. Anyway, here's the repo if you're interested in contributing: https://github.com/chromium/chromium
Browsers cost a bunch to develop. Just CI for Servo was 10k per year.
While there are some admirable efforts (Ladybird), browsers complexity means your only specification is Chrome source code.
Flame charts in Visual Studio 2003? Sorry, try again.
I get F5 to refresh the page when source code changes. All the other tooling remains the same: https://developer.chrome.com/docs/devtools/
I mean, Chrome even has an animations debugger
Really? That's surprising but so overkill. How does it know what files to poll and which not to, I assume file:// and localhost but more specific? Does it do it for a webpack/vite app which has its own hot reloading setup?
F5 refreshes the browser page. This has been the way to develop pages since the first browsers.
And the original question was "Import a plain js file without any node tooling and see what you get for free." You don't get hot reloading but you get all I wrote in my original comment and much more for free.
It usually goes something like this: some tool watches the file system for changes > trigger build > another tool in the chain injects changes into session > picked up by client to reflect changes, if done well without resetting state.
These are many tools in a toolchain working well together. This DOES exist in other languages, incremental builds exists. You can save and restore a binary at a certain state, and it's less hassle than it is in js.
One thing the systems development world has that I haven't seen in browser tools is radare/ghidra to follow code paths but it probably exists as a browser extension. The web is just reinventing and repackaging tools that have existed for decades.
> you get all I wrote in my original comment and much more for free
Yes, but `apt install gdb` is just as "free" as `apt install chrome` no? Everything you mentioned exists in systems development, you just haven't used it.
I could probably set up a simple environment to watch for changes, run make, reload the binary at $current_state in gdb with a one-liner. But it doesn't really fit the work flow, and GDB already gets all changes after I run make.
I think Rust has all of that except the hot reload and runtime changes.
Instant hot reloading? Runtime introspection into apps, and into strucutre of the apps, direct view into what the app sends over the network etc.? Open up development tools in your favorite browser, you'll be surprised :)
But the web is definitely the most used “GUI framework” ever, so there is no competition with that on tooling ground, even if there is nothing inherently that would block it, as a dom inspection is pretty easy to implement - just print out the tree of ui nodes.
Don't get me wrong the web pays my bills and I like it but there's no point exaggerating.
"Can be achieved" with some additional tools. I doubt you can easily expect the structure of the app, how it repaints, see all the relevant network requests, and also introspect and query the running app, emulate various hardware, inspect and debug animations etc. in most languages.
Yes, there are collections of tools that may give you all that in aggregate, but frankly, it's not close to an "out-of-the-box" experience.
> there's no point exaggerating.
It's not really exaggeration.
Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference. It seems you don't have much experience in the tools you're comparing against. In GDB you would connect to a running application on actual hardware or in a VM, if that's what you're testing. Screen sizes and network can be done locally.
As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser so it's still an "aggregate" as you like to call it.
For me it's the unixy way of doing things and just the way I like it. Do one thing and do it well.
I've used debuggers in general (IDEA, Resharper, Visual Studio), and even dabbled with disassemblers like IDA in my youth.
> Browser developer tools don't "emulate hardware" they change the viewport and throttle network, there's a huge difference.
So, out-of-thebox int their primary tool frontend developers get: viewport simulation, cpu throttling, network throttling, sensor simulation (geolocation and orientation).
And can emulate performance with different number of processor cores. Not bad https://developer.chrome.com/docs/devtools/performance/refer...
> As far as all-in-one solutions go that's a new goal post, your first comment mentioned "tooling", and hot reloading is not a part of the browser
Wat. The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling". So yes, hot loading is a part of tooling. I've yet to see anything outside the web manage hot reloading with any degree of confidence and speed.
You don't like the hot loading, and let's focus on non-moved non-goal non-posts. I hope you noticed the ellipsis at the end of my list?
What's that immediately available tool for GDB and Wireshark whatever that:
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
- examine and debug animations?
- analyze paint/re-paint performance?
- view and debug delayed background actions?
- record and replay user flows?
...
^ Note the ellipsis again.
The build tools for Web are undoubtedly atrocious. However, there are very few, if any, tools that come even close to the versatility and ease of use of the tools that exist for the web ecosystem.
The linux kernel has KVM, doesn't get more out of the box than that. Do what you want with it. Emulate ARM? Sure why not.
> The original comment claimed this: "Maybe the web ecosystem will finally get some sane tooling".
Not my comment, I'm addressing your claim of "tooling most languages can't even dream of". The ellipsis doesn't really matter I'm not here to guess what you're meaning.
- can let me examine and change the UI of the app on the fly? Including handful tools like layout overlays, layers etc.
Most debuggers including GDB can print and set state.
> - examine and debug animations?
> - analyze paint/re-paint performance?
I don't do GUI development but you'll have to use a tool specific to the environment you're working with (just like how the DOM is a specific environment). What tool do you use to debug webview? Not your main browser. Systems development is the same.
> - view and debug delayed background actions?
You can get the time spent on anything down to individual assembly instructions if you wish.
> - record and replay user flows?
rr (which is GDB compliant hence integrates well with termdebug in vim).
I don't disagree that there are many tools for web dev. But they're not always better or easier to use. The built-in nodejs debugger is shit compared to GDB for example. My point is that everything you can do in browsers that aren't browser specific exists for other languages as well. Many times very specialized with better features that the devtools version.
Again, I love web development, but I also live in the terminal and love those tools even more. I wish they existed for the web.
> It was just an exploration to see if there was anything we were missing out on.
Doesn't square with this:
> At some point though we'll probably just have to hire Rust engineers instead of trying to convert JS devs.
Reads like rust exceptionalism.
IMHO, the more interesting niche is desktop/mobile apps using html as a toolkit. Because here you can combine raw computing/resource access with being more cross platform.
So why should a company hinder its own productivity by trying to find rust developers because rust is technically safer in some ways? Or risk ruining the culture of its currently functional developers by forcing them to use rust?
No one is even close.
Anders Hejlsberg, lead architect of C# and creator of Delphi and Turbo Pascal, has worked on the development of TypeScript.
Recent cool developments on that side include Electric Clojure - generating transparently state passing front and backend code from a single DSL: https://github.com/hyperfiddle/electric
Why? Rust has a bunch of features built in to promote "good code", no?
My theory is that, you probably can see when a language its being picked by some community by looking into courses available, either free or on paid platforms
Not quite sure what you mean. I've written some pretty cool stuff in Rust and never had to do any free() / drop()?
Though a more objective distinction is hard to give on what is a managed language, I found the garbage collection handbooks’ quote on the topic the most illuminating (linking to my older comment): https://news.ycombinator.com/item?id=35332600
In Rust and in C++ memory layout is part of your public APIs and has to be refactored when it changes. This is not the case with managed languages.
It's not really that; it's really just WASM. There's going to be a flood of this sort of thing from all sorts of languages, even multiple per language. It's early days yet and the ground is still being felt out, but eventually the Javascript qua Javascript foundation in the browser is going to be breached and a day will come when it is a minority language (still many years from now), for exactly the same reason that never in the whole history of computing has one general purpose programming language "won". Per https://www.destroyallsoftware.com/talks/the-birth-and-death... , Javascript is going to "win", but it's going to be Javascript in its incarnation as WASM, not the Javascript we know today.
"random bits of Rust in 2024."
And that's "the ground being felt out", not a fundamental problem. I expect to see WASM frameworks develop that are shipped out to the world as WASM and bind to any language. Decent odds they'll be developed in Rust for several reasons (performance not least of all), but you won't need to know that to use it in your Python WASM front-end app or some new WASM-primary language that is nothing more than a gleam in its creator's eye right now. If you don't want the chaos, hey, great. Even people who live on the cutting edge can't be cutting edge in every dimension. By all means sit back and watch from a distance. But these problems will certainly be fixed.
In some cases that complexity is worth it — Figma, for example, squeezes a lot of value from WASM. I myself have used WASM to create a browser-based testing environment for a Rust-based static analysis tool I’ve built, so my colleagues can quickly repro issues. But for most web development, it’s not worth it.
To put it another way, no, you're not wrong, and yes, the resistance to large-scale changes to the web stack is huge, arguably the largest resistance of all time. Nevertheless, the amount of metaphorical amperage flowing through is even larger and is large enough that it is already "short circuiting" and blasting a new circuit through. It's going to take a while, and the backwards compatibility will be with us for a while, but we're already seeing flashes of websites where you don't need to know the old CSS and HTML and such because they're actually WebGL and WASM. As more capabilities are exposed to WASM and they become more efficient, more and more stuff will be moved into it.
That will cause its own explosion problem, but it'll be handled. It's not like every website is going to write its own bespoke text renderer every single time. And in the end there are some technologies that will fade out and become legacy, then irrelevant. I may yet outlive the HTML/CSS/JS stack.
Yes, I can see the advantage of rewriting those layers in terms of the lower level APIs, for example if the DOM API were to implemented in WASM, you could keep it out of the browser, and download only when/where needed (with a number of caveats, of course)...
The main issue is that even if you do that, I don't expect an API designed with JS in mind to be a good fit for Rust, and vice versa. The risk is that you end up programming not against the "Web Platform", but "WebJS platform", "WebRust Platform" etc."
Neither one is a different language. Both merely add type annotations to an otherwise pristine ECMAScript code base.
Typescript has some very few and minor and no longer needed things, like enums or namespaces, that need to be transpiled and are not part of ECMAScript. But again, those are minor and you no longer need them (since ES 2015 one can use modules instead of namespaces, and marked "as const" object literals instead of enums).
I know some people want to argue definitions, "different language" etc., but it's really just a completely optional tooling layer that you can just strip. It's also evaluated purely during development time, for type checks, the actual code that gets executed remains the ECMAScript part.
Whenever there are changes in a new Typescript version it's either purely within the type system, or they add type support for new ECMAScript features, those proposals that reached stage 3.
You could just imagine the type annotations in a different layer than the actual code, like in Photoshop. A layer used only by the IDE and code checking tools.
Microsoft added greatly to the confusion by putting the type checker, like eslint usable standalone or continuously queried through the IDE, and the type annotation files (.d.ts) generation and the completely optional .js file transformation AND .js file transpilation - backwards compatible JS code for earlier runtimes - into one tool. But all of those are different things. If your traget is "esnext" or you don't use JS features that your target runtime does not yet support transpilation is just removal of type annotations (except, enums, namespaces, which are no longer necessary and only exist for historical pre ES2015 reasons).
This isn’t really a matter of debate — Microsoft describes TypeScript as a programming language distinct from JavaScript on its homepage.
It’s a programming language with a trivial transpiration step to another language, but a separate language all the same.
Oh and here is what it ACTUALLY says on the Typescript page (https://www.typescriptlang.org/):
> TypeScript is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.
None of that contradicts anything I wrote.
The pendulum has swung away from dynamic typing but are we sometimes sacrificing expressivity as a result?
I don't really know Rust but from what I've seen of it, it doesn't feel like a natural fit for the web - either front or back-end.
Maybe I'm missing something?
I do think we'll see more simplicity (not Lisp-like) in the future.
Especially with Rust you have to think way more about banalities of the data model you normally really don't care about in web development.
I get a question over and over from front end devs when I teach or mentor about being a "real" computer scientist and picking up c, Cpp, or rust, which is silly. Who do you think invented the dynamically typed languages, English majors?
Yeah. The bill was paid when the language devs bothered to write a compiler, so that your runtime bugs become compiletime bugs and so you can understand what's happening when your program is bigger than a tiny script.
Now, on my old PC, the compiler is super slow so I end up prototyping tricky stuff (like maths) in python and then I port it to rust when I feel it's ready.
(my stuff is emulator: no DB, not much GUI but lots of performance, threading, etc.)
But jokes aside, Java’s type system can’t express HKTs, but up to that point it really is surprisingly strong — there is vavr, but I have also personally followed my former “define Haskell basic data types yourself in Haskell” class quite far in it, including Lists, Eq trait, Maybe type, etc.
This also means that if you architect your app right, you have have the front-end and back-end self contained in the same app, or split them over a network boundary.
So let's say you are writing a 3d modeling app or something. You write the engine and the gui in rust, and you ship that binary to your users. You can then also, again basically for free, put a network between the gui and the rendering engine, then you can serve the gui to client browser, and handle the rendering on a server.
The point is this is easy for the rust dev, so they don't need to be a JavaScript dev as well.
Others chose between Rust and Go, if performance was the most important thing.
The thing about dynamically typed languages and their expressiveness, is that you are sacrificing the ease of long-term maintenance for the ease of short-term prototyping.
Personally, I am a big fan of Clojure as a tool for designing software, but I would prefer having to maintain a code base written in Rust.
edit: and tangentially, the building and iterating lifecycle phase is of course usually the make-or-break bottleneck - maintenance phase sw engineering is comparatively a "happy problem".
Essentially, it's like two completely different reasoning models: inside-the-box (ALGOL / SQL), and outside-the-box (LISP / Datalog).
The first model (ALGOL / SQL) is about designing for machines to better understand, and the second model (LISP / Datalog) is about designing for humans to better understand.
I think that the main issue with dynamically typed programming languages is the lack of robust enforcement.
Rust is a low-level language, quite similar in the target niches to C++, while Go is a managed language with a barely-optimizing compiler for fast compile times, and a GC that prioritizes latency over throughput. They are nothing alike.
And sure, just as alike as Rust and D, Haskell, OCaml - they all produce a native binary with in-built GC, just like Go.
NIM supports concurrency and is as portable as the c and js it can generate to.
C#/F# work on x86 and arm which covers most targets today. And supports concurrency. And is situationally more performant than go.
I can't speak to the other languages mentioned, but they all seem quite similar to go as well, except for haskell.
Rust is more like c, c++, zig, ada etc.
IMO Rust is more expressive than most languages including languages like Python. Traits and enums are just... a joy to work with. It is also more constrictive in some ways, and a rust-like high-level language could do probably do better still (Swift/Kotlin/Elixir are close).
There's also a tradeoff between expressivity and performance and correctness. The way I see Rust is you get maybe 75% of the expressivity, along with much better performance and correctness guarantees.
I'd agree it's not a good fit for frontend, but IMO it's an excellent fit for backend.
I'm surprised this has been your experience. I've known some pretty strong Rust devs.
But IMO the Rust dev salaries are a bubble that's about to pop. Personally I'm ready to work with Rust at less than the crazy salaries that are offered (though I'd still expect more than the average JS dev salary).
Why would i want to choose Rust? "Speed" and "not requiring as much of a memory footprint as well as more service uptime with less crashes".
I dunno man. I'm not saying those aren't interesting but I'm not sure that when it comes to web development that those are big hang ups.
There's got to be something more compelling IMO before you swing away from a fairly rich and frankly developer rich pool in JavaScript land...
Granted I enjoyed the article and my interest is piqued but that's it.
The language you choose matters relatively little.
WASM is not unlike the JARs and SWFs we got shoved down our throat ten years ago when HTML and JS were lacking any useful web capabilities. Huge files with separate runtime that implement their own renderer and operating environment. Google Docs already does this, using a canvas element to render to rather than using HTML and CSS to lay out text.
That is independent to whether WASM is being used or not. Two completely orthogonal concerns.
I'm sorry, no.
[0] https://docs.rs/left-pad/latest/left_pad
Same thing for a Rust replacement for VSCode -- I am sure it is an interesting project, but VSCode performance is generally good enough (I don't ever complain about slowness while developing). A lot of the performance bottleneck comes from the language services anyway. If you improve the loading speed from 2s to .2s that is definitely great, but if at the cost of losing most of the existing extensions, I'm not going to consider it at all.
Yes you can technically maybe get off the ground more quickly up front with JavaScript, but as soon as you hit a certain code base size threshold (not sure what it is personally, it is probably different case by case), you would've been better off with TypeScript or Rust as JavaScript starts to "crumble" under its own lack of types, etc.
JavaScript is like Legos, durable and you can build many things in it.
Agreed. I would hate to see a CRUD spa written in Rust just because it was the fancy new thing. But sites like Figma, Miro, and Frame.io would make sense to look into a Rust WASM solution.
> but VSCode performance is generally good enough (I don't ever complain about slowness while developing).
The one thing I would say it can't handle is large files, like a large JSON file, I'm talking really large. It's something Sublime could handle and I used to keep it around just for that. This is not something I deal with often enough to really annoy me.
Honestly, a major benefit of strict/enforced type systems is that it substantially improves maintainability of the codebase. Large Python or JavaScript projects with no typing can be a huge nightmare.
Now:
What is compile times for real-world medium to large projects? Do these even exist? Rust is infamous for its compile times, and frontend dev often requires live reload on every change.
What does debugging look like? Can I set a breakpoint in rust code in my IDE? What do I see in browser devtools? Can I change values in my paused code at runtime, then resume execution?
This article from 2½ years ago shows what was already possible back then when you're debugging C++: https://developer.chrome.com/blog/wasm-debugging-2020/
Rust build times are huge at first, especially if you haven't downloaded any dependencies before, (comparable to running npm install) but incremental compilation makes small code changes very quick and easy.
Having worked on a Javascript code base that's grown over a few years, I don't believe Javascript is any faster than Rust when it comes to compilation/transcription/packaging, especially when you need to add a layer like TypeScript between your tools and yourself if you don't want to go insane with JS' lack of typing.
I wouldn't use Rust for a browser frontend, but I don't think the lack of tooling is a very good reason not to. The massive size of WASM binaries, the overhead, the lack of transparency, and all the other problems are, though. I'd stick with Rust on the backend instead.
There is hardly any language that doesn't have some kind of meta language that compiles to JS. And without exception they all are bad, except maybe if you have a backend which only needs some very basic front end which you prefer to write in the same language.
But with any decent sized front end project, JS or TS are the better choices. JS, obviously, because it runs natively in the browser. So all browser tooling works out of the box, debugging is easy because what you see is what actually runs. TS, although it doesn't run natively, at least was designed to be compiled to JS and is widely supported so tooling is good as well. But any JS substitute that was added to a backend language as an afterthought will suffer:
- inferior tooling
- more troublesome debugging
- and last but not least, because it was added as an afterthought, 95% of the language will work fine but the other 5% can give you as a developer serious head aches.
I do a lot of frontend development and I just cannot fathom how badly design JS as a language is and how awful the developer experience is. Every time I talk about JS shortcoming with other frontend dev, they point out that JS can do X or Y which other language cannot, but usually it is just a hack that are just not needed in other language because they actually do things properly (like having an actual sane type system and not having three ways to express that a variable is null). And TS is just a crutch that can barely help JS shortcoming.
Finally being able to compile from any language to a, reasonably sane, bytecode that can run in-place of JS is just a miracle and I don't understand why it took so damn long. JS should have been deprecated long ago. Even ActionScript was better.
Anyway, rant over.
Can you put breakpoints in WASM and debug frontend code?
Altering memory is more complicated, though.
Its problem is that the things Javascript excels at aren't all that useful, and the things it's bad at are often sold as features instead ("duck typing means I can iterate faster!").
Hum... Direct calling the DOM API is there already. You may be thinking about FFI marshaling, that there is something on the pipeline for helping (I don't even remember exactly what). But that's only a small improvement on speed, and that almost never is a dealbreaker.
For a while I thought the garbage collection helper was a dealbreaker (for anything except Rust), but GC languages are starting to compile into WASM too, with just a small performance hit. (I haven't looked exactly how.)
This year and the next are looking like some serious promising period for non-JS programing on the browser.
Rust-to-WASM is another attempt to abstract away the pain of JavaScript, attempts which began soon after the world discovered XHR. In fact Google released GWT specifically to appeal to Java devs who took one look at JS and said "no thanks".
This is not so say that there aren't legit uses for this technology - its a great way to port other software, like sqlite or linux into the browser. But as a way to make applications designed to run on the web?
I suggest that any dev that thinks this is necessary to have a good dev experience take the time to attempt to write a web app with just raw html, css, and js targeted at a modern browser. There's a lot of space there left to explore, I think, before labeling it as an unwieldy thing that must be wrapped in a safer abstraction to even think of touching.
This hasn't really been true anymore for quite a long time. Pretty much everything is bundled, minimized, and obfuscated now.
The thing people ship on their sites is compiled.
Yes, but there is a strain of software minimalism that eschews the front-end build entirely. This is relatively recently possible because of excellent implementations of relatively good standards starting with HTML5, CSS3, ES6, and SVG2.
https://www.jslint.com/ is an example of what's possible with ES6 and built-in modules.
It's Java but with silly names, stupid scoping, a unique prototype system nobody seems to get down, a strong influence from the worst years of Microsoft, and a legacy that forces it to make some pretty stupid choices moving forward.
It's incredible what browsers have been able to make Javascript do, but it's not exactly a well-designed language.
As for being business practical, WASM is already widely employed by web apps. The front end ecosystem is in its early stages so it's quite messy, but it's developing faster than I expected. It may end up being a real competitor for frameworks like Blazor and ASP.NET if it the tooling continues to improve like this.
let decrement = move |_| set_value.update(|value| *value -= 1);
Maybe I've lost that interest I once had in learning language syntax.. I just don't really understand this intuitively and the barrier to understanding this line feels unnecessary. When I compare Rust with JS/TS, Python, or even Swift I feel like those other languages are created in a way that's easy to pick up and transfer knowledge from other languages, then the deeper parts of the language are easily accessible once you're introduced to the basics.
I can't think on any modern language that lacks some short syntax for lambdas.
Hell, it's very easy to make a point that lacking short syntax for lambdas make a language not modern and unusable for our current standards.
let multiply = (a, b) => a * b;
Is this not a lambda?
My point is that the syntax isn't a problem, it's that Rust has very different semantics from the GC'd languages in the original comment and it all has to do with memory management.
let decrement = _=>set_value.update(value => value -= 1)
I don't understand your complaint about syntax. The real difference here is the concept of a move and a dereference. JS lacks these concepts and naturally has no syntax for them.
API Gateway + Lambda/OpenFaaS/Knative with rust handlers (low RAM/fast start), and typescript/react served via CDN.
with serverless platforms, it honestly matters not what language. Rust is just a convenience for compiling to arm for gravitron and low memory footprint. Languages that carry runtime bloat are less desired though for cloud functions.
These are things that are, IMO, just too engrained as being possible in JS/TS for people to give up easily, especially in terms of UI programming.
I've used both quite a bit - I am pulling for Rust to become more ergonomic for this use case where it makes sense because it has lots of other advantages.
But when the rubber hits the road and you start writing, I think Rust gets in the way too much for UI programming. For a small project it may be OK, but in most orgs you have sweeping design changes occurring (probably too) often. Rust is best when things have stopped churning and stabilize.
UI code often churns like a relentless beast, so something extremely approachable/flexible but strongly typed is best I think. This is why TypeScript is winning in this arena.
I'm optimistic headway will be made, but Rust currently feels a lot better to write for back-end and systems. It's not a surprise since that's what it was designed for.
Besides all this, I'm totally unsure where the size of the distributable comes in. In JS things can be chunked per page easily which keeps load times small. With WASM you get the whole thing by default, correct? That could be problematic.