It an entirely custom toolkit, so don't expect it to have a native look and feel, but it's a GPU-first design with multiple back-ends. It can be used in native OpenGL apps too. It's an immediate-mode UI, so it's very easy to build and update even complex windows. Great choice if you want to prototype a game.
The biggest downside of this is that everything is painted as "graphics", and you can no longer use the web inspector to modify the fonts, colours, etc.
While few people (like myself) do this directly, lots of people use it indirectly through extensions like Adblock, Stylus, etc.
For example, I find the fonts hard to read due to the colour choices; then I zoom in and it's better, but now this "Widget gallery" no longer fits on my screen and there is no scrollbar.
Checked demo. Bugs when interacting. For example when clicking buttons on top does not switch to supposed part. just flushes screen momentarily. Clicking refresh on browser right after that fixes the situation.
Major pita is keyboard handling when selecting, cutting, pasting text in edit controls and markup editor
Can confirm this lib is very good. I use it to simplify my status app, it allows me to keep everything in Rust so that I don't need to know too much about react and other web tech.
There's demo apps that you can just grab and edit to your liking, and the docs explain what you need to build the WASM app and run it.
Why don't apps like this leverage gpu hardware acceleration?
On my old tablet, Netflix runs a-ok, the media player has hardware acceleration and runs a-ok, but Amazon Prime stutters.
I haven't checked it in years, so maybe it is better now, but I am skeptical this is the case, because if the original creators of the Android app didn't think hardware accelerated video might be a nice idea, why would it be different now? This is a structural issue.
There is a cross sectional problem between what codecs that specific hardware supports (and generally is supported by all the popular devices), how much bandwidth you have on your connection and how many different codecs the various streaming services can support and cache locally.
> HD is not available because you're not using Windows
when using Windows
> HD is not available because you don't have HDCP
Graphics driver begs to differ.
Prime SD is usually somewhere between 240p and 320p, HD looks like a decently encoded 720p file. Never seen it but I'm guessing 4K might actually approach the quality of a 2007 Blu-Ray.
Prime 4K's bit-rate is ~15Mb/s. A UHD Blu-Ray has a bit-rate that's more like 70Mb/s, and a 1080p Blu-ray has a bit-rate of ~28Mb/s. Of course, 4K is usually encoded with H.265 while 1080p is encoded with H.264, so the raw bit-rate numbers are not as useful for comparison - but still, that's almost twice the bit-rate for a quarter of the pixels, and H.265 isn't magic.
I saw these errors the one time I tried Prime Video and laughed out loud, and ended the trial on the spot. It was like being turned away by a bouncer from a awful looking bar because they didn't like your shoes. Thus ends our relationship!
Prime video has unbelievably bad performance on LG WebOS, and it’s not the platform because Hulu, Netflix, Disney, YouTube are all fine. If this is new and makes their app work acceptably, then great!
Just checked and Prime using 90MB in my TV, while YouTube uses 214KB, so maybe I already have the wasm monstrosity.
HDR content is somewhat better when played through the Prime Video PS5 app, though it still seems much darker than HDR content played on the Netflix/AppleTV/HBO LGTV apps.
I found most LG WebOS apps to have issues of some kind. A quick Google search tells me that they finally now have an HBO Max app, but that was a major issue for the longest time for me. I got a Google stick instead.
haven't noticed any performance issues on mine (edit: relative to other apps in that ecosystem) - tho is a newer model. the UHD for in-house productions is pretty darn atrocious tho (looking at you, goliath)
edit: HDR, not UHD...tho have only noticed it predominate on their originals vs purchases.
And yet they can't even implement Picture-in-Picture mode on their Android app. A basic feature has been stable for years among any app that plays videos.
Not to mention that their show recommendations are the worst ever, I would be ashamed to be part of their ML team honestly. (For reference I'm an American/North African woman staying in France and all of my recommendations are for Indian action movies, literally all of them. I've never seen a single Bollywood film ever.)
Anyway this is to say, technical innovation won't undo the damage done by shitty product managers.
Personally, to me, whenever I read these stories about how Amazon is doing this novel use of WebAssembly, or how Uber is doing ludicrous engineering effort to keep their React-based app under 300MB for the App Store, I can't help but think:
"Man, that's an awful lot of work to avoid writing a native app."
The challenge would be that Prime Video is distributed on many client devices. Here’s a list of a few TV OSes: https://en.m.wikipedia.org/wiki/List_of_smart_TV_platforms. How would you manage a different native app for each of them?
Caveat: previously worked at Prime Video though not in this area, still at Amazon
Uber is a bad example because they need to have support for literally every payment method on the planet. And all of that needs to be preloaded ahead of time just in case the user decides they're going to fly to Mumbai tomorrow. Their app absolutely needs to be bloated or it won't work at all.
Likewise, Amazon needs to run on all sorts of different smart TV platforms, not just iOS and Android. All of those apps need to be consistent to each other, rather than to their host platforms. That's almost the textbook case for using a cross-platform framework.
For web & phones, I'm inclined to agree; a native app outperforms a web or hybrid app any day of the week. I do believe Facebook and Google are companies who ran into limitations though, binary size, number of classes / identifiers, build times, for which using web technology was a solution.
But for TVs, ehh. There's a lot more fragmentation on the TV market. And if things were slightly different, we'd have a lot more fragmentation on the mobile market as well. Actually there are plenty of mobile alternatives, but developers don't really want to support all operating systems - and these cross-platform tools often have substandard support for mobile operating systems that aren't iOS or Android.
HTML+JS+CSS is a very refined toolset for building UI that provides you with a content to consume. Sometimes, especially when the content is text, video and images, it’s actually easier to build high quality experience that works very well on all the platforms because it provides interaction modes out of the box that are the same everywhere.
Native apps shine when you do something novel, something that’s beyond text, images and video consumption or you leverage platform specific functions.
IMHO, sticking to Web technologies is a better option for things like Netflix or Amazon Prime but not good for Uber and alike.
You can render OpenGL with C++ and compile it to Wasm but alsk have it build and run natively (Emscripten or your own bindings or whatever). So this can be a way to do both, while keeping the reach of web. Depends on what kind of application you're building and whether this makes sense for that, for sure.
Between electron, webassembly, and other technologies, I don't think the line between web app and native app is as clear as it used to be, especially relative lift and performance. In the end, the only difference may be "one is launched in a browser and one is launched from the start menu"
I love native apps. But on the scale of Amazon (and having to compete with Netflix), slightest bit of friction, in this case downloading and installing an app, accepting permissions, etc takes a minute or two. It would be absolutely catastrophic to their competitiveness. You need to think more broadly on scale.
I hope native apps die. Most companies won't put in the level of effort into their engineering that the Chrome/Firefox teams do - specifically, they're not going to take security as seriously.
I've never had a problem with the functionality of Prime Video across any apple/webOS devices.
The UI, however, is easily the worst of any streaming platform. Why is a search result returned for each individual season of a TV series? Why doesn't it follow ANY of the Apple TV UI conventions?
But somehow it's more reliable than Netflix, Hulu, and HBO Max (hbo isn't that high of a bar though).
On systems such as iOS which you don't have JIT, performance is going to be real bad, as if you are dancing with a pair of iron made shoes. Honestly Amazon should afford going full native, at least for the scene and animation stuff.
What was the reason for web assembly versus just running rust directly on the target hardware? Is the idea that the constrained WASM environment requires less QA than if the hardware was targeted specifically by the rust compiler?
It's an alternative that gives them the updatability of JS. When they describe their original (JS/C++) architecture they mention this as a motivating factor:
> This architecture split allows us to deliver new features and bug fixes without having to go through the very slow process of updating the C++ layer. The downloadable code is delivered through a fully automated continuous integration and delivery pipeline that can release updates as often as every few hours
They do support a lot of device types, which means a lot of compilation to produce many different binaries and probably more reliance on the app update systems of third parties.
It's nice to see a big company like Amazon using Wasm in something that actually sees the light of production (and in something that's used by so many people). I always see tech giants supporting or contributing to newer technologies like Wasm without really using them in important applications.
as of late last year - of the large tech companies - it seems that amazon and microsoft might be the biggest Rust (in prod) evangelists. they basically swiped all the mozilla rust devs that were laid off and made their own dedicated Rust teams. so far, this has been good for the ecosystem as they continue to contribute to the community but i know there's a lot of community members that feel uneasy about those moves. here's to hoping the worries amount to nothing :)
Language success is in large parts driven by what system adopts that language.
Objective-C’s success was driven by iOS.
C’s success was driven by Unix.
C++’s early success was driven in large part by 90’s GUI frameworks ( MDC, OWL, Qt, etc.
I think Wasm is shaping up to be huge in that you can safely run, high performance code across multiple operating systems/CPU’s. Of all the languages, I think Rust has the best WASM tooling, and the 2020’s may end up being the WASM/Rust decade.
On the one hand the proliferation of features such as WebGL, WebRTC, WASM, etc. greatly increases browser attack surfaces. On the other hand, it allows a single relatively constrained system to focus on for security hardening / sandboxing.
Regardless, being open standards, not obnoxiously object oriented, and better designed to interoperate with normal HTML content, the modern HTML5 ecosystem is certainly way more promising than Java applets / Flash / Silverlight.
It is the worst of the major streaming apps. It's very slow and has lots of loading/reloading on every piece of hardware I've used it on (Android phone, iPad, AppleTV, AndroidTV).
I imagine the other streaming apps use similar techniques to share code, so I wonder why theirs is so poor in this regard.
Outside of the major players though it gets a lot worse - Funimation's streaming app is horrendous, as is Crunchyroll's. At least Prime Video is doing better than that tier.
I cannot believe how Amazon is one of the biggest company on the planet and still cannot seem to figure out UI/UX for any of their product. Amazon (the website) having an awful UX might be "by design" (i.e dark patterns) but it make no sense for Amazon Video, AWS dashboard, the kindle/device side of the Amazon website, ...
I'd be happy with surround (5.1) upon windows, alas it seems you can only get that via an Amazon device. HD 5.1 would suit me over any 4k and do feel many streaming services use the 4k etc as marketing more than anything else and fail upon the audio aspect in regards to surround, which IMHO add's way more to the viewing experience than a bump in resolution - though others millage may vary.
first time i've seen practical wasm system design and the transition written about. that being said, i would really love a deeper dive. the graphics were also insightful -- cheers, alexandru
Our Wasm investigations started in August 2020, when we built some prototypes to compare the performance of Wasm VMs and JavaScript VMs in simulations involving the type of work our low-level JavaScript components were doing. In those experiments, code written in Rust and compiled to Wasm was 10 to 25 times as fast as JavaScript.
For video processing, especially high fidelity, high frequency, and high resolution video, I can see WASM crushing JavaScript performance by orders of magnitude. But, that isn’t this. They are just launching an app.
I have verified in my own personal application that I can achieve superior performance and response times in a GUI compared to nearly identical interfaces provided by the OS on the desktop.
There are some caveats though.
First, rendering in the browser is offloaded to the GPU so performance improvements attributed to interfaces in the browser are largely a reflection of proper hardware configurations on new hardware. The better the hardware the better a browser interface can perform compared to a desktop equivalent and I suspect the inverse to also be true.
Second, performance improvements in the browser apply only up to a threshold. In my performance testing on my best hardware that threshold is somewhere between 30000 to 50000 nodes rendered from a single instance. I am not a hardware guy but I suspect this could be due to a combination of JavaScript being single threaded and memory allocation designed for speed in a garbage collected logical VM opposed to allocated for efficiency.
Third, the developers actually have to know what they are doing. This is the most important factor for performance and all the hardware improvements in the world won’t compensate. There are two APIs to render any interface in the browser: canvas and the DOM. Each have different limitations. The primary interface is the DOM which is more memory intense but requires far less from the CPU/GPU, so the DOM can scale to a higher quantity of nodes without breaking a sweat but without cool stuff like animation.
There are only a few ways to modify the DOM. Most performance variations come from reading the DOM. In most cases, but not all, the fastest access comes from the old static methods like getElementById, getElementsByTagName, and getElementsByClassName. Other access approaches are faster only when there is not a static method equivalent, such as querying elements by attribute.
The most common and preferred means of DOM access are querySelectors which are incredibly slow. The performance difference can be as large as 250,000x in Firefox. Modern frameworks tend to make this slower by supplying additional layers of abstraction and unnecessarily executing querySelectors with unnecessary repetition.
pornel|4 years ago
https://emilk.github.io/egui/
It an entirely custom toolkit, so don't expect it to have a native look and feel, but it's a GPU-first design with multiple back-ends. It can be used in native OpenGL apps too. It's an immediate-mode UI, so it's very easy to build and update even complex windows. Great choice if you want to prototype a game.
Beltalowda|4 years ago
While few people (like myself) do this directly, lots of people use it indirectly through extensions like Adblock, Stylus, etc.
For example, I find the fonts hard to read due to the colour choices; then I zoom in and it's better, but now this "Widget gallery" no longer fits on my screen and there is no scrollbar.
throw14082020|4 years ago
This is the context. They use egui to display debugger information - performance does not matter for the debugger information.
FpUser|4 years ago
Major pita is keyboard handling when selecting, cutting, pasting text in edit controls and markup editor
lordnacho|4 years ago
There's demo apps that you can just grab and edit to your liking, and the docs explain what you need to build the WASM app and run it.
agumonkey|4 years ago
rafale|4 years ago
malermeister|4 years ago
unknown|4 years ago
[deleted]
f00zz|4 years ago
Sunspark|4 years ago
On my old tablet, Netflix runs a-ok, the media player has hardware acceleration and runs a-ok, but Amazon Prime stutters.
I haven't checked it in years, so maybe it is better now, but I am skeptical this is the case, because if the original creators of the Android app didn't think hardware accelerated video might be a nice idea, why would it be different now? This is a structural issue.
lathiat|4 years ago
There are trade offs to be made.
formerly_proven|4 years ago
> xyz [4K/UHD]
4K is not available when using a computer
> HD is not available because you're not using Windows
when using Windows
> HD is not available because you don't have HDCP
Graphics driver begs to differ.
Prime SD is usually somewhere between 240p and 320p, HD looks like a decently encoded 720p file. Never seen it but I'm guessing 4K might actually approach the quality of a 2007 Blu-Ray.
chaosite|4 years ago
verytrivial|4 years ago
thinkingemote|4 years ago
jeffbee|4 years ago
Just checked and Prime using 90MB in my TV, while YouTube uses 214KB, so maybe I already have the wasm monstrosity.
laurencerowe|4 years ago
HDR content is somewhat better when played through the Prime Video PS5 app, though it still seems much darker than HDR content played on the Netflix/AppleTV/HBO LGTV apps.
Commodore63|4 years ago
bick_nyers|4 years ago
unknown|4 years ago
[deleted]
jozzy-james|4 years ago
edit: HDR, not UHD...tho have only noticed it predominate on their originals vs purchases.
curiousgal|4 years ago
Not to mention that their show recommendations are the worst ever, I would be ashamed to be part of their ML team honestly. (For reference I'm an American/North African woman staying in France and all of my recommendations are for Indian action movies, literally all of them. I've never seen a single Bollywood film ever.)
Anyway this is to say, technical innovation won't undo the damage done by shitty product managers.
gjsman-1000|4 years ago
"Man, that's an awful lot of work to avoid writing a native app."
Kaedon|4 years ago
Caveat: previously worked at Prime Video though not in this area, still at Amazon
kmeisthax|4 years ago
Likewise, Amazon needs to run on all sorts of different smart TV platforms, not just iOS and Android. All of those apps need to be consistent to each other, rather than to their host platforms. That's almost the textbook case for using a cross-platform framework.
twelvechairs|4 years ago
lukasb|4 years ago
ihuman|4 years ago
https://eng.uber.com/how-uber-deals-with-large-ios-app-size/
Cthulhu_|4 years ago
But for TVs, ehh. There's a lot more fragmentation on the TV market. And if things were slightly different, we'd have a lot more fragmentation on the mobile market as well. Actually there are plenty of mobile alternatives, but developers don't really want to support all operating systems - and these cross-platform tools often have substandard support for mobile operating systems that aren't iOS or Android.
shroompasta|4 years ago
From a startup pov, going with native apps will require multiple teams (Usually just Android + iOS, but occasionally Windows as well)
React Native will only require one team, or just one engineer depending on the size of the project
Better yet, If your front end developer is fluent in React(web), then that developer is already fluent in React Native.
I completely disagree on the "awful lot of work", when you could literally get your FE developer to work on your "native" apps.
Sure, where performance must be squeezed, it's probably optimal to go native, but that bar is set a lot lower than where it actually should be.
If React Native is good enough for Discord, it's good for 3 quarters of all apps out there.
mrtksn|4 years ago
Native apps shine when you do something novel, something that’s beyond text, images and video consumption or you leverage platform specific functions.
IMHO, sticking to Web technologies is a better option for things like Netflix or Amazon Prime but not good for Uber and alike.
nikki93|4 years ago
madrox|4 years ago
hashimotonomora|4 years ago
systemvoltage|4 years ago
unknown|4 years ago
[deleted]
unknown|4 years ago
[deleted]
staticassertion|4 years ago
sheeshkebab|4 years ago
jackson1442|4 years ago
The UI, however, is easily the worst of any streaming platform. Why is a search result returned for each individual season of a TV series? Why doesn't it follow ANY of the Apple TV UI conventions?
But somehow it's more reliable than Netflix, Hulu, and HBO Max (hbo isn't that high of a bar though).
alx__|4 years ago
beardedman|4 years ago
colesantiago|4 years ago
rustworld|4 years ago
chj|4 years ago
ec109685|4 years ago
aylmao|4 years ago
> This architecture split allows us to deliver new features and bug fixes without having to go through the very slow process of updating the C++ layer. The downloadable code is delivered through a fully automated continuous integration and delivery pipeline that can release updates as often as every few hours
They do support a lot of device types, which means a lot of compilation to produce many different binaries and probably more reliance on the app update systems of third parties.
exdsq|4 years ago
zlei|4 years ago
johncolanduoni|4 years ago
rappatic|4 years ago
dwmbt|4 years ago
RcouF1uZ4gsC|4 years ago
Objective-C’s success was driven by iOS.
C’s success was driven by Unix.
C++’s early success was driven in large part by 90’s GUI frameworks ( MDC, OWL, Qt, etc.
I think Wasm is shaping up to be huge in that you can safely run, high performance code across multiple operating systems/CPU’s. Of all the languages, I think Rust has the best WASM tooling, and the 2020’s may end up being the WASM/Rust decade.
ummonk|4 years ago
Regardless, being open standards, not obnoxiously object oriented, and better designed to interoperate with normal HTML content, the modern HTML5 ecosystem is certainly way more promising than Java applets / Flash / Silverlight.
nojito|4 years ago
Still pales in comparison to .NET
Shadonototra|4 years ago
Nope, C/C++ has, emscripten remains undefeated
You don't just put a name and expect things to skyroket
C++/Go/C# has more chance to become the standard toolkit for WASM than rust
rust problem, is people promotes more the "rust"™ rather than their project, the crabs definitely shadows them, it's unfortunate
astrange|4 years ago
Well, Objective-C is from 1984 and its major success was being cloned to make a programming language called Java.
TruthWillHurt|4 years ago
myko|4 years ago
I imagine the other streaming apps use similar techniques to share code, so I wonder why theirs is so poor in this regard.
Outside of the major players though it gets a lot worse - Funimation's streaming app is horrendous, as is Crunchyroll's. At least Prime Video is doing better than that tier.
maeln|4 years ago
Zenst|4 years ago
bluehex|4 years ago
Jyaif|4 years ago
alvarlagerlof|4 years ago
dwmbt|4 years ago
pacificat0r|4 years ago
If you have any specific question, I could try to answer it here.
oofbey|4 years ago
austincheney|4 years ago
Our Wasm investigations started in August 2020, when we built some prototypes to compare the performance of Wasm VMs and JavaScript VMs in simulations involving the type of work our low-level JavaScript components were doing. In those experiments, code written in Rust and compiled to Wasm was 10 to 25 times as fast as JavaScript.
For video processing, especially high fidelity, high frequency, and high resolution video, I can see WASM crushing JavaScript performance by orders of magnitude. But, that isn’t this. They are just launching an app.
I have verified in my own personal application that I can achieve superior performance and response times in a GUI compared to nearly identical interfaces provided by the OS on the desktop.
There are some caveats though.
First, rendering in the browser is offloaded to the GPU so performance improvements attributed to interfaces in the browser are largely a reflection of proper hardware configurations on new hardware. The better the hardware the better a browser interface can perform compared to a desktop equivalent and I suspect the inverse to also be true.
Second, performance improvements in the browser apply only up to a threshold. In my performance testing on my best hardware that threshold is somewhere between 30000 to 50000 nodes rendered from a single instance. I am not a hardware guy but I suspect this could be due to a combination of JavaScript being single threaded and memory allocation designed for speed in a garbage collected logical VM opposed to allocated for efficiency.
Third, the developers actually have to know what they are doing. This is the most important factor for performance and all the hardware improvements in the world won’t compensate. There are two APIs to render any interface in the browser: canvas and the DOM. Each have different limitations. The primary interface is the DOM which is more memory intense but requires far less from the CPU/GPU, so the DOM can scale to a higher quantity of nodes without breaking a sweat but without cool stuff like animation.
There are only a few ways to modify the DOM. Most performance variations come from reading the DOM. In most cases, but not all, the fastest access comes from the old static methods like getElementById, getElementsByTagName, and getElementsByClassName. Other access approaches are faster only when there is not a static method equivalent, such as querying elements by attribute.
The most common and preferred means of DOM access are querySelectors which are incredibly slow. The performance difference can be as large as 250,000x in Firefox. Modern frameworks tend to make this slower by supplying additional layers of abstraction and unnecessarily executing querySelectors with unnecessary repetition.
unknown|4 years ago
[deleted]