Earlier quoted context omitted.
This comes off incredibly naive of FE engineering. Buttons and Doodads? sigh. A significant factor as to why Apple has succeeded the past 2 decades is due to the design of their products - from the sleek aluminum bodies of their hardware to the UI/UX of their operating systems. Unless you want your UI to look like something out of 1995, you're going to have to make it look good. Making it look good will require a dec…
I, for one, would love if UIs looked like it's 1995 again. Imagine the crispness, everything is fast, responsive and written in sensible languages. A simpler, and better time.
Prime Video Uses WebAssembly
161–170 of 254 posts
Re: Prime Video Uses WebAssembly
#162Earlier quoted context omitted.
React and Flutter aren't immediate mode only because they're build on top of the DOM as primitive. Otherwise, conceptually they are evolutions of immediate mode. And they inspired plenty of GUIs outside the web to go "immediate" mode themselves.
Words don't have any meaning anymore if react (and the HTML DOM) is considered anything close to "immediate mode". For starters the DOM is a declarative thing - immediate mode means that you have a function called for each frame with imperative function calls written by the user of the immediate mode GUI toolkit for rendering each element of the GUI every time (unlike retained mode where a framework hides that behind…
In React's case, you tell it declaratively (your JSX component tree) with some procedural stuff thrown in (JS parts in the JSX). In classical immediate mode, by calling paint functions. But in both cases you tell every time - as opposed to performing actions on a pre-created widget graph. With the caveat that in React's case, behind the scenes, there is a widget graph, the DOM. But that's an implementation detail, as far as the dev writing React is concerned, they re-describe every GUI state.
So, you can say that React is an "immediate mode" abstraction over the retained DOM. In fact that's exactly what devs say about it:
https://twitter.com/ibdknox/status/413363120862535680
That's the inspiration from "immediate mode" that React brought - the GUI intention described by creating a new state, as opposed to manipulating state. And the diff algorithm is also inspired by the diffing algorithms used in immediate mode to draw less for each frame.
That React does this with DOM widgets under the hood as opposed to painting commands, and that those are higher level widgets and not lines and rectangles is not the part of the analogy people emphasize.
retained: user instantiated widgets, and changes their state (e.g. to clicked).
traditional immediate: for every 'tick', user issues commands to draw the new GUI state, usually with some smart diffing under the hood to minimize paint commands.
React immediate: for every tick, user describes the arrangement of widgets, text, etc for the next GUI state, usually with some smart diffing under the hood to minimize DOM changes.
Calling a "draw button" function, as opposed to declaring a "" in a JSX structure, is not that crucial of a difference, compared to the conceptual change between "manipulating objects" and "telling everything about how the UI should look at each tick".
Heck, a dev doing an "actual" immediate mode could trivially wrap the "draw button" function call to be driven from a declarative file (if you parse the term "button": call draw button, etc). It still wouldn't be retained mode.
And React and co also inspired interest in immediate mode GUIs, and inspired some new actual bona-fide immediate mode, with graphic calls and everything.
Re: Prime Video Uses WebAssembly
#163Personally, 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."
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.
Re: Prime Video Uses WebAssembly
#164Personally, 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."
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.
Re: Prime Video Uses WebAssembly
#165Earlier quoted context omitted.
A company that makes an awful lot of money can afford to not make an awful app on major platforms. A native app on Windows, macOS, iOS and Android (TV), and some other solution for other platforms, isn't an unreasonable ask in this context.
If you're already very successful, why would you spend a lot more money to produce a buggier product that will generate a lot more customer support requests and cost a lot more money in engineering effort to maintain forever going forward? It just makes no business sense. This reasoning is even less justifiable in the context of WASM which is quite performant.
I mean granted, for a lot of companies, having a substandard or suboptimal app simply does not matter to their bottom line, because the product trumps the implementation details in the end; people are willing to put up with e.g. a bloated web app because it gives them access to a good chat service (think slack, discord). People were willing to put up with Twitter's fail whale outages whenever Justin Bieber tweeted because they had something good (network effect?).
Re: Prime Video Uses WebAssembly
#166Earlier quoted context omitted.
I, for one, would love if UIs looked like it's 1995 again. Imagine the crispness, everything is fast, responsive and written in sensible languages. A simpler, and better time.
I don't know you, but from what i recall Windows 95 and 98 were anything but with fast and responsive UIs. Many windows were fixed size, and with significant input lag
And yeah - even if there was lag or slowness I don't recall, imagine those systems on today's hardware. I recently used a WinXP on fast hardware, and by god was that thing responsive, lean and fast.
Re: Prime Video Uses WebAssembly
#167Earlier quoted context omitted.
why not? so they aren't using webassembly correctly? who is a better example and why?
I use it on web/AppleTV/FireTV & IMO it doesn't have a great user experience on any platform. Generally it's a bit jerky/laggy & also often gets glitchy (on FireTV at least) post very long running videos. I'm not saying it sucks, but the apps for Disney & Netlix feel so much better to use. My comment wasn't directed at WebAssembly.
Re: Prime Video Uses WebAssembly
#168> Prime Video > 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.
Re: Prime Video Uses WebAssembly
#169Earlier quoted context omitted.
A company that makes an awful lot of money can afford to not make an awful app on major platforms. A native app on Windows, macOS, iOS and Android (TV), and some other solution for other platforms, isn't an unreasonable ask in this context.
If you're already very successful, why would you spend a lot more money to produce a buggier product that will generate a lot more customer support requests and cost a lot more money in engineering effort to maintain forever going forward? It just makes no business sense. This reasoning is even less justifiable in the context of WASM which is quite performant.
This assumes that, generally, native apps are more buggy. Why? This is contestable at best, or getting it the wrong way around at the worst. Perhaps at the hands of inexperienced developers it's right. But experienced developers coding in native APIs will probably produce an app with fewer bugs.
And we are talking about a billion dollar company. It can afford a handful of really good native developers for each platform. It can attract talented developers who can write cross-platform native code.
Cross-platform toolkits introduce their own class of bugs, which might require patches upstream to resolve, or annoying local forks.
As for the economics of it all, I'll leave that to the other sub-comment which deals with that with an excellent analogy to Apple. People will pay for quality.
Re: Prime Video Uses WebAssembly
#170Earlier quoted context omitted.
No. You just build one abstraction and then use a code generator to build a client for different targets. So as long as you have good developers with an interest in code generation and that will stick around for a few years to maintain the generators, then it works out fine. Resist the temptation to create a new DSL or programming language. Pick a language with a strict compiler, good typing system and good reflectio…
Isn't the abstraction essentially their wasm and js libraries? And they just use a vm instead of code generator.
I recently swapped out a big chunk of my codegen code and let my code call the flutter cli, so then I generate a flutter project which in turn can generate a few clients (like web, desktop, android etc). I'm currently optimizing the way I keep state between generations: certain parts can/should be overwritten but other parts need to be kept in tact. Trickier than it sounds.
I highly recommend people to try building their own generators, scaffolding & tools. Very enriching!