7 ms·

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another langua

> By using Rust for both our frontend and backend, we have a unified stack of Rust everywhere, simplifying our hiring. > I can write web apps in another language than JavaScript > I can write web apps that are fast Yeah, this is what's worrying me. If you look at rerun.io website, you will notice that it's built with Next.js, i.e. is using a React framework to build pages that have no interactivity whatsoever. Next.js is used for the blog, despite it being just a collection of simple static html pages. Meanwhile, the user has to download around 200kB of javascript for no reason whatsoever; and the only reward that they get for their trouble is an avalanche of javascript errors in the browser console [0]. Is the Rust/wasm future going to look like that? [0] - https://i.imgur.com/TpYW0Rj.png https://i.imgur.com/TpYW0Rj.png

Thaxll 4y ago
Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.
- flohofwoe 4y ago
  Typescript and React project build times are easily in the same ballpark as Rust or C++ for similar code base sizes though, yet they are used in the frontend 'at scale' ;)
  - hsn915 4y ago
    Yes but you can use esbuild to make it fast. My projects take less than a second.
- ttfkam 4y ago
  Obviously not fast enough for Google since they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java.
  - traceroute66 4y ago
    > they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java. And then ironically they then use a complex and runtime-heavy Java-based CI/CD to manage the compilation of their Go codebase. Go is great though, best bit is how its so useable for web-stuff out of the box. Unlike Rust where you have to spend half your life either re-inventing the wheel or choosing which of hundreds of crates you want to use to do stuff that should be part of stdlib.
  - fuckstick 4y ago
    Of all the criticisms I’ve heard hurled at Java, compile time isn’t one of them. Have you actually used any of these things you comment on?
    - vips7L 4y ago
      Javac isn't even an optimizing compiler. There's few things faster than it.
    - ttfkam 4y ago
      I used to work for Google and have yet to see Java compile faster than Go.
  - thesuperbigfrog 4y ago
    >> Obviously not fast enough for Google since they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java. Go was created to overcome complexity issues and compile times of C++ (not Java): https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti... https://go.dev/talks/2015/gophercon-goevolution.slide#4 https://go.dev/talks/2015/gophercon-goevolution.slide#4
    - ttfkam 4y ago
      I misspoke (miswrote?). You are correct, it was created to address the issues Google had with C++ and—crucially—other internally supported languages like Java and Python could not adequately fill C++'s role. If Java could have filled this role in both compile time and memory efficiency, Go in all likelihood would never have been created. But yes, Go beats Java in compile-time speed as well.
- traceroute66 4y ago
  > There is a reason why JS was invented. I disagree. As I see it, JS was invented as a browser utility, as the name implies "script", i.e same as shell script languages such as BASH, for doing small amounts of interactive stuff. What JS has morphed into is a Jeckyll & Hyde monstrosity. Frontend devs now routinely dump 200kb+ of junk down the pipe at people's browsers because its somehow "better" to dump the processing/rendering on the user's desktop instead of server side. And then there's the monstrosity of server-side JS. I think few people can argue that JS was ever supposed to be server-side. Things like Node are basically square-pegging JS into that round hole.
  - EamonnMR 4y ago
    Of course it's better to do processing client side. You pay for server side compute, you don't pay for client side compute.
  - horsawlarway 4y ago
    I think you're failing to address the elephant in the room: The browser is simply the single best application distribution method humanity has ever created. Full stop. There are literally no other tools that give anywhere close to the same benefits. So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of applications 200kb is ridiculously small. When was the last time you installed an application on Windows/Mac/Android/iOS that was under a single MB? Yet you install (& run) applications ALL DAMN DAY on the web, without a thought or care. Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb and load in less than a few seconds. Ex: Outlook used to be a mail client you installed. The installer was several hundred MBs, and it took 10+ minutes to run. Now you point your browser at outlook.com and you get a nearly identical experience. That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. Music player? It's a website now. JS. See my point? So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.
    - masklinn 4y ago
      > So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing. That web application delivery is "fucking amazing" doesn't mean javascript is. Javascript very much is not. What javascript is, is the only complete option until wasm is way more fleshed out than it currently is. > Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb With an entire browser and server farm to do that. > and load in less than a few seconds. Instead of instantaneously. > That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. 10% the functionality, 20% the performance, at twice the heft. Amazing. > Music player? It's a website now. JS. Your music library? Doesn't exist now.
- toyg 4y ago
  > There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time Lol. That's not why JS was invented, at all. JS was invented to provide basic interactivity to static html pages. By accidents of history it snowballed in the current monstrosity.
- Thiez 4y ago
  In Rusts defense, I can't think of a situation where you would need `OsString` in a frontend, and I don't think you will need `CString` either since strings are passed into webassembly by address + length (so exactly what Rust expects, no null-terminated nonsense). So you would just use the one default string type (`String` + `&str`).
  - chrismorgan 4y ago
    You shouldn’t ever need to deal with OsString itself on wasm32-unknown-unknown, since that target basically just doesn’t cover functionality that needs it, but the actual situation is genuinely worse than OsString: Rust insists on valid Unicode (as is right and proper), but the web suffers from the affliction of ill-formed UTF-16. If you blindly convert from JavaScript strings to Rust strings, you will encounter data and functionality loss in a few situations, in practice always involving IME (or similar) text entry on Windows. The first bug I filed about this: https://github.com/Pauan/rust-dominator/issues/10 https://github.com/Pauan/rust-dominator/issues/10, and you can follow further links if you’re interested. IE and Edge used to be largely immune to this, but IE is dead and I suppose Edge will have regressed in this way with the Chromium migration, since the bug filed in Chromium a few years ago <https://bugs.chromium.org/p/chromium/issues/detail?id=949056 https://bugs.chromium.org/p/chromium/issues/detail?id=949056> has languished. (Firefox too, with <https://bugzilla.mozilla.org/show_bug.cgi?id=1541349 https://bugzilla.mozilla.org/show_bug.cgi?id=1541349>.) In the worst-case scenario, careless use like was the case in rust-dominator will mean that some users typing with particular software in a language that’s outside the Basic Multilingual Plane will not be able to type anything.
- commitpizza 4y ago
  Why wouldn't it? Saying that it will never seems very definitive. It's like these famous quotes that "we will never need more than 4kb of memory" or similar. Saying that something will never change is just a lack of imagination of the future. There are big pushes behind wasm and Rust is leading the way here in a big way. I think you underestimate people and their will not to run javascript. Rust and WASM in particular will make it so that you can bring whatever language you want to the front end. I believe that while it's very impractical now, wasm will slowly take over and in the future basically no one will use javascript except for basic things and most sites will use wasm for front end logic. Why? Because it just makes sense for many reasons. You can use whatever language you want both on the server side and in the browser, you can achieve near native speeds and we're already sending big minified javascript blobs anyway so we may as well just send a binary instead. yes it's very hard to make a SPA with Rust today but it is possible and the tooling will become better over time and especially with other languages joining in. To me it's clear that using javascript on the front end will become slowly irrelevant as more and more devs ship a binary blob. Right now, we need javascript as a glue but I think that will change as well with time.
- maeln 4y ago
  > People doing frontend dev don't want to bother with slow compile time Honestly, with my previous experience as a frontend web, compile time for frontend is starting to become as bad as a standard compiled language. When you start to have a whole framework, many (many!) dependencies (you know, the kind that make just deleting the node_modules directory slow) and webpack with some plugins for CSS, es-lint and all that, the tooling just can't keep up. It doesn't help that much of the tooling is also done in JS which is fast but not that fast.
  - littlestymaar 4y ago
    Yeah, this is really an instance of “tell me that you're not doing front end while not telling me you're not doing front end”. Build time are a really annoying part of modern web jobs…
  - 5e92cb50239222b 4y ago
    It's pretty fast with modern tooling. Try vite or swc if you have the time and inclination. vite builds one of my large $DAYJOB projects in ~45 seconds (which is insane compared to how webpack performed). If you don't need vite's extensibility, you can go with 'pure' esbuild and slim down transpilation + minification + bundling to only a few seconds. https://vitejs.dev https://vitejs.dev https://github.com/swc-project/swc https://github.com/swc-project/swc https://github.com/evanw/esbuild https://github.com/evanw/esbuild
    - toyg 4y ago
      When JS was born, "building" was F5 in a browser. 45 seconds is an eternity in comparison.
      - 5e92cb50239222b 4y ago
        You also couldn't use JS of that time to build anything remotely like modern SPAs. Unlike some Silicon Valley unicorns, we're using SPAs only where they fit, to replace legacy desktop applications. (It's boring intranet stuff, but they make a lot of sense there.) I was a skeptic initially, but it grew on me.
- masklinn 4y ago
  > There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time You have never actually looked at the history of javascript have you? Or at the current "best practices"?
- api 4y ago
  JS ecosystem front end builds can be complex and incredibly slow these days. It's rare to see a JS app that is just written in JS and shipped as-is without some kind of long "compile" pipeline with translation to support different browsers, minifiers, CSS compilation, and tons of other cruft. I've definitely seen JS builds be slower than medium to large size Rust builds on the same machine, especially since JS builds often involve large steps that are not parallelized. Rust parallelizes builds pretty well until the very last optimization pass and linker stage. Go builds are impressively fast, so if that's a big pain point for you I'd look at Go frontend stuff.
- nordsieck 4y ago
  > Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. > And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload. IMO, it really depends on the workload. For the stuff that JS is being used for today, you're probably right. But say someone wanted to implement a CAD program in the browser. I'd say, JS is probably inadequate for that[1]. In that case, performance matters more than for a chat app. If you look at web development as a spectrum from webpage+ to high performance application, Javascript is a good fit for a large section of that spectrum. But probably not all of it. --- 1. I suppose it depends on the complexity of what you want to display, but "regular" local applications struggle to display extremely complex models today. I'd imagine putting the software in the browser would only introduce additional performance problems.
- maxsilver 4y ago
  > People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. As someone doing both, my frontend JS/react pipeline has noticeably longer compile times (both to build locally, and for users rendering client-side) than my server-side one. > There is a reason why JS was invented. JS isn't here because it's "fast". JS is here because it shipped in browsers, and browsers were popular. JS got fast, after lots of people put a ton of effort into their JS implementations for almost two decades straight to make it so. (See https://blog.mozilla.org/javascript/2012/12/04/arewefastyet-improvements/ https://blog.mozilla.org/javascript/2012/12/04/arewefastyet-... from ten years ago as just one of many, many examples)
- insanitybit 4y ago
  Our TS frontend compile times are worse than our Rust compile times.
- deathanatos 4y ago
  I have a real-world codebase of considerable complexity in both BE & FE code where I work. Our Rust compile time, across all targets we build (which includes a lot of tooling that's not really "backend", but we compile all the Rust together, so…) is 7m47s. Our FE build time was ~20m (and is part of our CI's critical path).
- bartq 4y ago
  JS is the best language for web - and generally for high level systems design - and honestly I don't know why people don't want to see it. Good parts of JS are: first class functions and closures and prototypical inheritance. Find decently popular language with those things implemented well, good luck. Rest of JS features are a noise, improvements of developer work ergonomics (all those let/const, modules, async/await and what not etc) and unfortunately pile of bad decisions which cannot be undone because web has to work correctly and do not break constantly. JavaScript really is a Scheme in disguise with a little bit of Smalltalk. Which really is good. If you don't like junk coming from {}+[] - don't use it, but I consider the lack of errors thrown to be a correct behaviour. Use TS or any other linter to control stuff. As we can see, Clojure wasn't accepted widely despite the fact it also has first class functions and closures. In my opinion the answer is simple: people want to have syntax for stuff which we agreed is good. Using macros and ((())) is not what people want to do long term.
  - blep_ 4y ago
    Because lots of languages have first-class functions, and prototypical inheritance isn't actually that good an idea and most people just use it to implement bad class systems.
    - panzi 4y ago
      These days nobody even knows that its prototypical inheritance. There is a class syntax now and everyone uses that. `class Foo extends Bar { ... }`
emilern 4y ago
Hi, author here! We are building the frontend of our _application_ in Rust and rendering it to a canvas using egui.rs. For the web site we are using more "traditional" tech, as you've noticed. I am not a big fan of the complexity of modern web sites (including our own), which is exactly why I created egui. However, it is targeted at web apps, not web sites.
- chanks 4y ago
  I'm very curious how well this is working for you in practice, since I've been thinking about what it would look like to share a single Rust UI implementation across a webapp and native apps.
  - emilern 4y ago
    So far so good! Putting the UI in a canvas elements have some distinct drawbacks (https://github.com/emilk/egui/tree/master/crates/eframe#problems-with-running-egui-on-the-web https://github.com/emilk/egui/tree/master/crates/eframe#prob...) but for us it is definitely worth it. Having one unified codebase for our web app and native app, and having it all in Rust, is just amazing. We're currently working on a 3D renderer based on wgpu (https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu) that we will likewise use for both web and desktop.
- panzi 4y ago
  How does egui interact with screen readers and other accessibility APIs?
  - emilern 4y ago
    So-so. There is an experimental screen reader you can enable in the "Backend" panel of egui.rs. There is ongoing work to integrate AccessKit (https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit) which will improve things significantly.
    - mwcampbell 4y ago
Existenceblinks 4y ago
What's worrying me is wasm binary size from Rust. People talk about writing web apps in other languages, which is what I wish for, but elephant in the room has few to non existence of discussion.
Traubenfuchs 4y ago
> an avalanche of javascript errors in the browser console Dear god. And then you can't even visually tell if you are at the main, "Team" or "Blog" page from the menu bar. This says one thing very clearly: "This website was not made with love." -which says NOTHING about the product they are offering.
UltraViolence 4y ago
They may be static pages, but usually you need a CMS to manage those static pages and their content. So it containing Javascript to fetch the content isn't all that far fetched.

Thaxll 4y ago

Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload.

flohofwoe 4y ago
Typescript and React project build times are easily in the same ballpark as Rust or C++ for similar code base sizes though, yet they are used in the frontend 'at scale' ;)
- hsn915 4y ago
  Yes but you can use esbuild to make it fast. My projects take less than a second.
ttfkam 4y ago
Obviously not fast enough for Google since they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java.
- traceroute66 4y ago
  > they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java. And then ironically they then use a complex and runtime-heavy Java-based CI/CD to manage the compilation of their Go codebase. Go is great though, best bit is how its so useable for web-stuff out of the box. Unlike Rust where you have to spend half your life either re-inventing the wheel or choosing which of hundreds of crates you want to use to do stuff that should be part of stdlib.
- fuckstick 4y ago
  Of all the criticisms I’ve heard hurled at Java, compile time isn’t one of them. Have you actually used any of these things you comment on?
  - vips7L 4y ago
    Javac isn't even an optimizing compiler. There's few things faster than it.
  - ttfkam 4y ago
    I used to work for Google and have yet to see Java compile faster than Go.
- thesuperbigfrog 4y ago
  >> Obviously not fast enough for Google since they literally invented a new programming language (Go) to address the compile time and runtime limitations of Java. Go was created to overcome complexity issues and compile times of C++ (not Java): https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti... https://go.dev/talks/2015/gophercon-goevolution.slide#4 https://go.dev/talks/2015/gophercon-goevolution.slide#4
  - ttfkam 4y ago
    I misspoke (miswrote?). You are correct, it was created to address the issues Google had with C++ and—crucially—other internally supported languages like Java and Python could not adequately fill C++'s role. If Java could have filled this role in both compile time and memory efficiency, Go in all likelihood would never have been created. But yes, Go beats Java in compile-time speed as well.
traceroute66 4y ago
> There is a reason why JS was invented. I disagree. As I see it, JS was invented as a browser utility, as the name implies "script", i.e same as shell script languages such as BASH, for doing small amounts of interactive stuff. What JS has morphed into is a Jeckyll & Hyde monstrosity. Frontend devs now routinely dump 200kb+ of junk down the pipe at people's browsers because its somehow "better" to dump the processing/rendering on the user's desktop instead of server side. And then there's the monstrosity of server-side JS. I think few people can argue that JS was ever supposed to be server-side. Things like Node are basically square-pegging JS into that round hole.
- EamonnMR 4y ago
  Of course it's better to do processing client side. You pay for server side compute, you don't pay for client side compute.
- horsawlarway 4y ago
  I think you're failing to address the elephant in the room: The browser is simply the single best application distribution method humanity has ever created. Full stop. There are literally no other tools that give anywhere close to the same benefits. So 200kb of scripts might seem "HUGE!" to someone who's thinking about the web as a tool for distributing static information (blog distribution). But in the context of applications 200kb is ridiculously small. When was the last time you installed an application on Windows/Mac/Android/iOS that was under a single MB? Yet you install (& run) applications ALL DAMN DAY on the web, without a thought or care. Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb and load in less than a few seconds. Ex: Outlook used to be a mail client you installed. The installer was several hundred MBs, and it took 10+ minutes to run. Now you point your browser at outlook.com and you get a nearly identical experience. That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. Music player? It's a website now. JS. See my point? So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing.
  - masklinn 4y ago
    > So is JS a monstrosity? For blogs, sure. For apps? Hell no. It's fucking amazing. That web application delivery is "fucking amazing" doesn't mean javascript is. Javascript very much is not. What javascript is, is the only complete option until wasm is way more fleshed out than it currently is. > Things that used to come with 100MB+ installers? Those are web apps now. They serve you 200kb With an entire browser and server farm to do that. > and load in less than a few seconds. Instead of instantaneously. > That spreadsheet app? Just a sheets.google.com away. Loads in seconds - using JS with a tiny payload. 10% the functionality, 20% the performance, at twice the heft. Amazing. > Music player? It's a website now. JS. Your music library? Doesn't exist now.
toyg 4y ago
> There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time Lol. That's not why JS was invented, at all. JS was invented to provide basic interactivity to static html pages. By accidents of history it snowballed in the current monstrosity.
Thiez 4y ago
In Rusts defense, I can't think of a situation where you would need `OsString` in a frontend, and I don't think you will need `CString` either since strings are passed into webassembly by address + length (so exactly what Rust expects, no null-terminated nonsense). So you would just use the one default string type (`String` + `&str`).
- chrismorgan 4y ago
  You shouldn’t ever need to deal with OsString itself on wasm32-unknown-unknown, since that target basically just doesn’t cover functionality that needs it, but the actual situation is genuinely worse than OsString: Rust insists on valid Unicode (as is right and proper), but the web suffers from the affliction of ill-formed UTF-16. If you blindly convert from JavaScript strings to Rust strings, you will encounter data and functionality loss in a few situations, in practice always involving IME (or similar) text entry on Windows. The first bug I filed about this: https://github.com/Pauan/rust-dominator/issues/10 https://github.com/Pauan/rust-dominator/issues/10, and you can follow further links if you’re interested. IE and Edge used to be largely immune to this, but IE is dead and I suppose Edge will have regressed in this way with the Chromium migration, since the bug filed in Chromium a few years ago <https://bugs.chromium.org/p/chromium/issues/detail?id=949056 https://bugs.chromium.org/p/chromium/issues/detail?id=949056> has languished. (Firefox too, with <https://bugzilla.mozilla.org/show_bug.cgi?id=1541349 https://bugzilla.mozilla.org/show_bug.cgi?id=1541349>.) In the worst-case scenario, careless use like was the case in rust-dominator will mean that some users typing with particular software in a language that’s outside the Basic Multilingual Plane will not be able to type anything.
commitpizza 4y ago
Why wouldn't it? Saying that it will never seems very definitive. It's like these famous quotes that "we will never need more than 4kb of memory" or similar. Saying that something will never change is just a lack of imagination of the future. There are big pushes behind wasm and Rust is leading the way here in a big way. I think you underestimate people and their will not to run javascript. Rust and WASM in particular will make it so that you can bring whatever language you want to the front end. I believe that while it's very impractical now, wasm will slowly take over and in the future basically no one will use javascript except for basic things and most sites will use wasm for front end logic. Why? Because it just makes sense for many reasons. You can use whatever language you want both on the server side and in the browser, you can achieve near native speeds and we're already sending big minified javascript blobs anyway so we may as well just send a binary instead. yes it's very hard to make a SPA with Rust today but it is possible and the tooling will become better over time and especially with other languages joining in. To me it's clear that using javascript on the front end will become slowly irrelevant as more and more devs ship a binary blob. Right now, we need javascript as a glue but I think that will change as well with time.
maeln 4y ago
> People doing frontend dev don't want to bother with slow compile time Honestly, with my previous experience as a frontend web, compile time for frontend is starting to become as bad as a standard compiled language. When you start to have a whole framework, many (many!) dependencies (you know, the kind that make just deleting the node_modules directory slow) and webpack with some plugins for CSS, es-lint and all that, the tooling just can't keep up. It doesn't help that much of the tooling is also done in JS which is fast but not that fast.
- littlestymaar 4y ago
  Yeah, this is really an instance of “tell me that you're not doing front end while not telling me you're not doing front end”. Build time are a really annoying part of modern web jobs…
- 5e92cb50239222b 4y ago
  It's pretty fast with modern tooling. Try vite or swc if you have the time and inclination. vite builds one of my large $DAYJOB projects in ~45 seconds (which is insane compared to how webpack performed). If you don't need vite's extensibility, you can go with 'pure' esbuild and slim down transpilation + minification + bundling to only a few seconds. https://vitejs.dev https://vitejs.dev https://github.com/swc-project/swc https://github.com/swc-project/swc https://github.com/evanw/esbuild https://github.com/evanw/esbuild
  - toyg 4y ago
    When JS was born, "building" was F5 in a browser. 45 seconds is an eternity in comparison.
    - 5e92cb50239222b 4y ago
      You also couldn't use JS of that time to build anything remotely like modern SPAs. Unlike some Silicon Valley unicorns, we're using SPAs only where they fit, to replace legacy desktop applications. (It's boring intranet stuff, but they make a lot of sense there.) I was a skeptic initially, but it grew on me.
masklinn 4y ago
> There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time You have never actually looked at the history of javascript have you? Or at the current "best practices"?
api 4y ago
JS ecosystem front end builds can be complex and incredibly slow these days. It's rare to see a JS app that is just written in JS and shipped as-is without some kind of long "compile" pipeline with translation to support different browsers, minifiers, CSS compilation, and tons of other cruft. I've definitely seen JS builds be slower than medium to large size Rust builds on the same machine, especially since JS builds often involve large steps that are not parallelized. Rust parallelizes builds pretty well until the very last optimization pass and linker stage. Go builds are impressively fast, so if that's a big pain point for you I'd look at Go frontend stuff.
nordsieck 4y ago
> Rust will never make it to the frontend at scale. There is a reason why JS was invented. People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. > And the fast argument is missleading at best, every modern language are "fast" enough, if Amazon and Google runs Java that mean it's fast enough for 99% of workload. IMO, it really depends on the workload. For the stuff that JS is being used for today, you're probably right. But say someone wanted to implement a CAD program in the browser. I'd say, JS is probably inadequate for that[1]. In that case, performance matters more than for a chat app. If you look at web development as a spectrum from webpage+ to high performance application, Javascript is a good fit for a large section of that spectrum. But probably not all of it. --- 1. I suppose it depends on the complexity of what you want to display, but "regular" local applications struggle to display extremely complex models today. I'd imagine putting the software in the browser would only introduce additional performance problems.
maxsilver 4y ago
> People doing frontend dev don't want to bother with slow compile time or 3 strings implementation. As someone doing both, my frontend JS/react pipeline has noticeably longer compile times (both to build locally, and for users rendering client-side) than my server-side one. > There is a reason why JS was invented. JS isn't here because it's "fast". JS is here because it shipped in browsers, and browsers were popular. JS got fast, after lots of people put a ton of effort into their JS implementations for almost two decades straight to make it so. (See https://blog.mozilla.org/javascript/2012/12/04/arewefastyet-improvements/ https://blog.mozilla.org/javascript/2012/12/04/arewefastyet-... from ten years ago as just one of many, many examples)
insanitybit 4y ago
Our TS frontend compile times are worse than our Rust compile times.
deathanatos 4y ago
I have a real-world codebase of considerable complexity in both BE & FE code where I work. Our Rust compile time, across all targets we build (which includes a lot of tooling that's not really "backend", but we compile all the Rust together, so…) is 7m47s. Our FE build time was ~20m (and is part of our CI's critical path).
bartq 4y ago
JS is the best language for web - and generally for high level systems design - and honestly I don't know why people don't want to see it. Good parts of JS are: first class functions and closures and prototypical inheritance. Find decently popular language with those things implemented well, good luck. Rest of JS features are a noise, improvements of developer work ergonomics (all those let/const, modules, async/await and what not etc) and unfortunately pile of bad decisions which cannot be undone because web has to work correctly and do not break constantly. JavaScript really is a Scheme in disguise with a little bit of Smalltalk. Which really is good. If you don't like junk coming from {}+[] - don't use it, but I consider the lack of errors thrown to be a correct behaviour. Use TS or any other linter to control stuff. As we can see, Clojure wasn't accepted widely despite the fact it also has first class functions and closures. In my opinion the answer is simple: people want to have syntax for stuff which we agreed is good. Using macros and ((())) is not what people want to do long term.
- blep_ 4y ago
  Because lots of languages have first-class functions, and prototypical inheritance isn't actually that good an idea and most people just use it to implement bad class systems.
  - panzi 4y ago
    These days nobody even knows that its prototypical inheritance. There is a class syntax now and everyone uses that. `class Foo extends Bar { ... }`

emilern 4y ago

Hi, author here! We are building the frontend of our _application_ in Rust and rendering it to a canvas using egui.rs. For the web site we are using more "traditional" tech, as you've noticed. I am not a big fan of the complexity of modern web sites (including our own), which is exactly why I created egui. However, it is targeted at web apps, not web sites.

chanks 4y ago
I'm very curious how well this is working for you in practice, since I've been thinking about what it would look like to share a single Rust UI implementation across a webapp and native apps.
- emilern 4y ago
  So far so good! Putting the UI in a canvas elements have some distinct drawbacks (https://github.com/emilk/egui/tree/master/crates/eframe#problems-with-running-egui-on-the-web https://github.com/emilk/egui/tree/master/crates/eframe#prob...) but for us it is definitely worth it. Having one unified codebase for our web app and native app, and having it all in Rust, is just amazing. We're currently working on a 3D renderer based on wgpu (https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu) that we will likewise use for both web and desktop.
panzi 4y ago
How does egui interact with screen readers and other accessibility APIs?
- emilern 4y ago
  So-so. There is an experimental screen reader you can enable in the "Backend" panel of egui.rs. There is ongoing work to integrate AccessKit (https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit) which will improve things significantly.
  - mwcampbell 4y ago

Existenceblinks 4y ago

What's worrying me is wasm binary size from Rust. People talk about writing web apps in other languages, which is what I wish for, but elephant in the room has few to non existence of discussion.

Traubenfuchs 4y ago

> an avalanche of javascript errors in the browser console Dear god. And then you can't even visually tell if you are at the main, "Team" or "Blog" page from the menu bar. This says one thing very clearly: "This website was not made with love." -which says NOTHING about the product they are offering.

UltraViolence 4y ago

They may be static pages, but usually you need a CMS to manage those static pages and their content. So it containing Javascript to fetch the content isn't all that far fetched.