But this also runs in the browser. Using HTML and Javascript. Except now it's done slightly differently in a way that's easier for browsers to optimize, if done well.
WebAssembly and Rust may be massive overkill for most web applications, but so is React or Vue or whatever Javascript framework is popular these days. When the inevitable rewrite happens, we might as well enjoy the benefits of the new, faster-than-the-old-evolved-moloch web UI.
If anything the move from the old system (React+WebAssembly) to the new one (Rust+minimal JS+WebAssembly) will make the web application itself smaller and easier to grasp.
They don't really use browsers. They have basically build their own react-native version, but instead of using system UI as the backend they have a backend abstraction layer with implementations for their own rendering engine or alternatively a browser on platforms that don't support WebAssembly.
They only use WebAssembly rather than native because updating native code typically requires an app update via the platforms update mechanism which is slow and unreliable.
It looks like the new Rust UI version just swaps out their react fork for rust code and it looks like they are dropping browser support altogether.
Rust is no panacea and rewriting a web application in Rust should not lead to any performance gains per se, unless your web application is doing number crunching in the mouse move handler. In most cases, you should be lucky to see no performance hits after a rewrite, because pleasing the borrow checker makes things unnecessarily more complicated.
A valid reason to switch to Rust should be a better developer experience, but it will require lots of upfront effort to realize the benefits. I doubt that it's worth it for small to medium-sized web applications.
Also, React itself is very much lightweight and fast, it's the developers who use it to program slow websites.
I have tested the reactivity difference between the current UI and the Rust rewrite and it is staggeringly faster, this is not just a dumb pet project.
Just to make sure we're on the same page here, this is the app that lets me move a highlighted rectangle using a controller with 300ms latency to select the next episode of Reacher, right?
In my experience of building consumer web applications, they all start fast.
Then someone says “We need to track every interaction in mixpanel. What’s even the point if we don’t know it happened”.
Then the sales team says “We need to track in Salesforce, nobody on our team looks at mixpanel”
Then the marketing team goes “We must consolidate in google analytics, nothing else fits our usecase”
Then the other product team says “We need Amplitude”
Then the re-engagement marketing team goes “Braze for us please, we must know when customers do a thing so we can trigger campaigns”
Then the product growth hacker marketing team says “Our recommendation engine needs to use the custom in-house framework so we can train our models”
Then someone goes “Hey it looks like we’re losing events sometimes, you have to make sure users don’t leave the screen until all events are submitted”
Then someone has a cool idea: “Wow it would be great if we could see where users are looking with something like Hotjar”
And now you have an app where every interaction triggers 20 different trackers, waits for all of them to settle, then reacts to your action. Just look at the AWS homepage one day – I once counted 70 requests blocked by Brave’s built-in blockers before I even moved my mouse. It’s slightly better after login – only a dozen or so tracker requests iirc.
And all throughout this engineering is saying "this is stupid, the app shouldn't know or care about those systems directly, it should offload the messages to some other service to handle" and yet management says "no time for silly things like basic software engineering, we need to move fast [and break things]"
Native apps queue up these requests on low priority threads that only execute when the system is idle. I guess that’s not a thing on the web? Genuinely curious, I’m not a web guy
A lot of nuance in that question. The web doesn’t work quite like native – you generally don’t think about threads and blocking in the same way.
Anything CPU-bound blocks the JS-based UI thread on web, but not necessarily the browser’s native UI thread. However you would have to do pretty egregious things for this to be a noticeable problem, you almost certainly won’t get there with tracking scripts.
The issue is I/O-bound work. This doesn’t block the UI, but you aren’t guaranteed that the user will stick around for you to make those requests. So you generally want to flush them immediately, or in critical cases even wait for them to complete.
As soon as you’re waiting for API requests to complete before updating the UI, you add 10s to 100s milliseconds of lag to every interaction. But this doesn’t block natively rendered interactions (like form inputs), just the parts you control via JavaScript (like what’s on the page).
Ah but you could just not render things with JavaScript and let the browser handle it! Yes. Except now you are almost guaranteed to lose tracking events because you trigger page-level navigation before even firing your asynchronous events. The browser bails on all requests the page was making as soon as you leave the page.
But once you build up enough of those background waiting tasks, you can actually cause enough CPU-bound work to be noticeable. Kinda like a garbage collection cycle. On top of that you’re limited to how many concurrent API requests (10 I think) the browser can make so if you’re sending requests to 10 different services, now the requests your user cares about are waiting in line.
tldr: on the web a user may hard close your app at any point, so people make things feel slow in an effort to work around this. There are also some hard limits you may run into if not careful
I wouldn't trust anyone saying that a Roku "runs great" in any fashion. This is the slowest piece of sh* hardware I ever had the displeasure to use, the waiting times when switching apps are insane. Typing was a dreaded galore, I would plug my laptop over hdmi whenever I could instead. Every interaction in such a device should always be 100% less-than-a-frame instantaneous.
Not sure loading megabytes of Rust-transpiled webassembly is going to speed up those app switching times, but I feel your pain. As a Roku dev there are many hardware variants. Roku requires you to support the ancient ones. It sucks.
My experience with Flutter applications in the browser is absolutely terrible. Rather unfortunate, as the things Flutter promised would make it excellent for web applications like these.
The concept behind the way these platform renders is very similar, so the new Amazon UI may be terrible as well, but I wouldn't expect whoever made the GUI framework they use now to make the same mistakes Flutter made.
Edit: after looking into this some more, it looks like the approach Amazon took is quite different from most Rust UI libraries. They have written their own framework that basically re-implements React but entirely on the WebAssembly side. I don't think it works by throwing a <canvas> onto the screen and implementing a browser rendering engine in JS+WASM like Flutter does. They also seem to target native code where they do all the rendering themselves, but probably faster because they control all the layers and don't need to build a general-purpose UI engine for their video player with extra steps.
> … but also in browsers because some living room devices today have just an HTML5 browser and don't even have flash space big enough to put our native C++ engine.
Ask the people buying and making those devices, not the people trying to get their services to work on them.
The answer is probably "because the alternative is worse". I too would rather make a single web app than separate Tizen/tvOS/WebOS/Android/whatever Roku runs apps.
My latest bad experience was whatever version fluffychat used last December, thst was the most recent time I've tried to make a web app work for me. Before that, every version of Flutter I've tried myself, both in debug and release builds. The UI is stuttery and unresponsive in a way that's not happening in mobile platforms, although even on desktop platforms I find the latency rather high. That also includes some rather small Flutter desktop+web applications I've written myself.
It seems like Flutter apps run better in Chrome, but I'm on Firefox. Could be a Flutter optimisation issue or something in Flutter triggering a Firefox bug. Whatever it is, it's making me avoid Flutter web apps.
It's a similar effort. Flutter is a cross platform Dart UI framework that compiles to WASM for the web and also has Android/iOS build targets. The web version can be laggy on trivial examples. I would guess this younger Rust framework is less featureful than Flutter but is more efficient/faster (one of the stated goals in the article).
Rust is finding itself everywhere. It's fantastic on the server. It's shaping up to be fantastic for UI.
It's fast, ergonomic, and the code has fewer defects than code written in other languages. (Google did a study on this.)
It's not as unapproachable as the memes make it seem. It's no harder or less productive than Java or Golang to write. (Google also did a study on this.)
The Rust WASM deploy story is sublime and is going to help it take over the world.
is it just me or does the prime video player seem to have a bug in chrome where the UI shows over the video and never goes away after pausing in full screen?
This isn't about someone building this as a side-project, it's something Prime Video is working on. Which would be clear if you had even just opened the article.
Runs great on an underpowered Roku in HTML and JavaScript. But I guess why not. Developers gotta developer.
My main issue is having to buy my parents a bigger TV every few years because the fonts keep getting smaller and their eyes keep getting worse.
But this also runs in the browser. Using HTML and Javascript. Except now it's done slightly differently in a way that's easier for browsers to optimize, if done well.
WebAssembly and Rust may be massive overkill for most web applications, but so is React or Vue or whatever Javascript framework is popular these days. When the inevitable rewrite happens, we might as well enjoy the benefits of the new, faster-than-the-old-evolved-moloch web UI.
If anything the move from the old system (React+WebAssembly) to the new one (Rust+minimal JS+WebAssembly) will make the web application itself smaller and easier to grasp.
They don't really use browsers. They have basically build their own react-native version, but instead of using system UI as the backend they have a backend abstraction layer with implementations for their own rendering engine or alternatively a browser on platforms that don't support WebAssembly. They only use WebAssembly rather than native because updating native code typically requires an app update via the platforms update mechanism which is slow and unreliable. It looks like the new Rust UI version just swaps out their react fork for rust code and it looks like they are dropping browser support altogether.
Rust is no panacea and rewriting a web application in Rust should not lead to any performance gains per se, unless your web application is doing number crunching in the mouse move handler. In most cases, you should be lucky to see no performance hits after a rewrite, because pleasing the borrow checker makes things unnecessarily more complicated.
A valid reason to switch to Rust should be a better developer experience, but it will require lots of upfront effort to realize the benefits. I doubt that it's worth it for small to medium-sized web applications.
Also, React itself is very much lightweight and fast, it's the developers who use it to program slow websites.
I have tested the reactivity difference between the current UI and the Rust rewrite and it is staggeringly faster, this is not just a dumb pet project.
Just to make sure we're on the same page here, this is the app that lets me move a highlighted rectangle using a controller with 300ms latency to select the next episode of Reacher, right?
Yes, and the difference is incredible. It leads to a much less frustrating experience when navigating around the app overall.
Perhaps we might ask not just how the new version is so fast, but why is the old version so slow.
> why is the old version so slow
In my experience of building consumer web applications, they all start fast.
Then someone says “We need to track every interaction in mixpanel. What’s even the point if we don’t know it happened”.
Then the sales team says “We need to track in Salesforce, nobody on our team looks at mixpanel”
Then the marketing team goes “We must consolidate in google analytics, nothing else fits our usecase”
Then the other product team says “We need Amplitude”
Then the re-engagement marketing team goes “Braze for us please, we must know when customers do a thing so we can trigger campaigns”
Then the product growth hacker marketing team says “Our recommendation engine needs to use the custom in-house framework so we can train our models”
Then someone goes “Hey it looks like we’re losing events sometimes, you have to make sure users don’t leave the screen until all events are submitted”
Then someone has a cool idea: “Wow it would be great if we could see where users are looking with something like Hotjar”
And now you have an app where every interaction triggers 20 different trackers, waits for all of them to settle, then reacts to your action. Just look at the AWS homepage one day – I once counted 70 requests blocked by Brave’s built-in blockers before I even moved my mouse. It’s slightly better after login – only a dozen or so tracker requests iirc.
And all throughout this engineering is saying "this is stupid, the app shouldn't know or care about those systems directly, it should offload the messages to some other service to handle" and yet management says "no time for silly things like basic software engineering, we need to move fast [and break things]"
Native apps queue up these requests on low priority threads that only execute when the system is idle. I guess that’s not a thing on the web? Genuinely curious, I’m not a web guy
A lot of nuance in that question. The web doesn’t work quite like native – you generally don’t think about threads and blocking in the same way.
Anything CPU-bound blocks the JS-based UI thread on web, but not necessarily the browser’s native UI thread. However you would have to do pretty egregious things for this to be a noticeable problem, you almost certainly won’t get there with tracking scripts.
The issue is I/O-bound work. This doesn’t block the UI, but you aren’t guaranteed that the user will stick around for you to make those requests. So you generally want to flush them immediately, or in critical cases even wait for them to complete.
As soon as you’re waiting for API requests to complete before updating the UI, you add 10s to 100s milliseconds of lag to every interaction. But this doesn’t block natively rendered interactions (like form inputs), just the parts you control via JavaScript (like what’s on the page).
Ah but you could just not render things with JavaScript and let the browser handle it! Yes. Except now you are almost guaranteed to lose tracking events because you trigger page-level navigation before even firing your asynchronous events. The browser bails on all requests the page was making as soon as you leave the page.
But once you build up enough of those background waiting tasks, you can actually cause enough CPU-bound work to be noticeable. Kinda like a garbage collection cycle. On top of that you’re limited to how many concurrent API requests (10 I think) the browser can make so if you’re sending requests to 10 different services, now the requests your user cares about are waiting in line.
tldr: on the web a user may hard close your app at any point, so people make things feel slow in an effort to work around this. There are also some hard limits you may run into if not careful
Sure and whoever planned and implemented all of this in a cludgy blocking way is innocent angel in this scenario.
case in point, AWS homepage is miles ahead any smart tv menu and I doubt they write it in rust.
Good question which is in large part answered in the linked article / talk.
I wouldn't trust anyone saying that a Roku "runs great" in any fashion. This is the slowest piece of sh* hardware I ever had the displeasure to use, the waiting times when switching apps are insane. Typing was a dreaded galore, I would plug my laptop over hdmi whenever I could instead. Every interaction in such a device should always be 100% less-than-a-frame instantaneous.
Not sure loading megabytes of Rust-transpiled webassembly is going to speed up those app switching times, but I feel your pain. As a Roku dev there are many hardware variants. Roku requires you to support the ancient ones. It sucks.
Wish they had said something about open sourcing their SDK.
They mentioned Leptos as an inspiration but this is clearly very different and has a lot of interesting features.
I'm not familiar with Rust or WebAssembly, but isn't Flutter more appropriate specifically for such applications?
My experience with Flutter applications in the browser is absolutely terrible. Rather unfortunate, as the things Flutter promised would make it excellent for web applications like these.
The concept behind the way these platform renders is very similar, so the new Amazon UI may be terrible as well, but I wouldn't expect whoever made the GUI framework they use now to make the same mistakes Flutter made.
Edit: after looking into this some more, it looks like the approach Amazon took is quite different from most Rust UI libraries. They have written their own framework that basically re-implements React but entirely on the WebAssembly side. I don't think it works by throwing a <canvas> onto the screen and implementing a browser rendering engine in JS+WASM like Flutter does. They also seem to target native code where they do all the rendering themselves, but probably faster because they control all the layers and don't need to build a general-purpose UI engine for their video player with extra steps.
Why is a browser required for "living room devices?"
From the article:
> … but also in browsers because some living room devices today have just an HTML5 browser and don't even have flash space big enough to put our native C++ engine.
Ask the people buying and making those devices, not the people trying to get their services to work on them.
The answer is probably "because the alternative is worse". I too would rather make a single web app than separate Tizen/tvOS/WebOS/Android/whatever Roku runs apps.
I suppose, but Flutter on a Rasberry Pi-like device is compelling as well.
It would be helpful to know what version of flutter you experienced this with, your comment caught my attention at least, thanks.
My latest bad experience was whatever version fluffychat used last December, thst was the most recent time I've tried to make a web app work for me. Before that, every version of Flutter I've tried myself, both in debug and release builds. The UI is stuttery and unresponsive in a way that's not happening in mobile platforms, although even on desktop platforms I find the latency rather high. That also includes some rather small Flutter desktop+web applications I've written myself.
It seems like Flutter apps run better in Chrome, but I'm on Firefox. Could be a Flutter optimisation issue or something in Flutter triggering a Firefox bug. Whatever it is, it's making me avoid Flutter web apps.
My understanding is the web app can stutter, but the builds for the rest were OK?
I wonder if Flutter could run via wasm in browser.
It's a similar effort. Flutter is a cross platform Dart UI framework that compiles to WASM for the web and also has Android/iOS build targets. The web version can be laggy on trivial examples. I would guess this younger Rust framework is less featureful than Flutter but is more efficient/faster (one of the stated goals in the article).
While it's possible to use Flutter for _some_ smart TVs and the like, it's not generally at the top of the recommendations.
Happy to learn what might be - especially from the one codebase to everywhere perspective.
No, it is not.
Wikipedia says that Flutter can be transpiled to WebAssembly for web deployment.
Rust is finding itself everywhere. It's fantastic on the server. It's shaping up to be fantastic for UI.
It's fast, ergonomic, and the code has fewer defects than code written in other languages. (Google did a study on this.)
It's not as unapproachable as the memes make it seem. It's no harder or less productive than Java or Golang to write. (Google also did a study on this.)
The Rust WASM deploy story is sublime and is going to help it take over the world.
WASM Components levels the playing field across all languages.
You can mix and match a C# Blazor component and a Rust component, and a Python component and they all compile to WASM and runs at equal speed.
sounds like someone hasn’t actually tried or benchmarked this :)
Those other languages will have a GC.
not Zig
Is this satire? I have difficulty identifying those.
I only hope that it is, but you never know.
is it just me or does the prime video player seem to have a bug in chrome where the UI shows over the video and never goes away after pausing in full screen?
wondering if that’s the UI in question
[dead]
[dead]
I'm not familiar with Prime or its Video UI. Wouldn't a YouTube front end be more appropriate to rebuild with this tech stack?
This isn't about someone building this as a side-project, it's something Prime Video is working on. Which would be clear if you had even just opened the article.
Opened it. Skimmed it. Got to the conclusion, that it sells a "how to build something like the Amazon UI as a tutorial" course.
Not just my predecessor was confused by the wording and categories put on the page.