Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prime Video Uses WebAssembly

amazon.science

Post reply on HN
Print view View original

241–250 of 254 posts

Re: Prime Video Uses WebAssembly

#241

Post by saagarjha »

nexuist wrote: post #218
saagarjha wrote: post #181

Earlier quoted context omitted.

> It would take centuries for one single person to grasp what is going on in an iOS "Hello World" app. Not really. Several years, maybe.

I have been developing iOS apps since 2014, and was active in the jailbreaking scene before then. I don't believe any one person understands the entirety of what is going on when they launch an app. Remember, iOS is based on macOS, which is based on NeXTSTEP, last released in 1995! iOS has been plagued by a whole host of bugs from the 90s and below. Remember effective Power? ( https://apple.stackexchange.com/a/189064…

I started working on iOS apps around that time as well, soon after I started programming. If you put your mind to it tracing the startup process of an iOS app is not actually as difficult as you think it is, especially if you skim things like “how does RunningBoard manage my app’s lifecycle?” or “is this launch being logged by CoreDuet?”. Also, FWIW, Core Text has several engineers working on it–text rendering is not a solved problem in the slightest–and is public API depended on directly by many apps.

Re: Prime Video Uses WebAssembly

#242

Post by xxs »

astrange wrote: post #231
pjmlp wrote: post #189

Earlier quoted context omitted.

Well, https://cs.gmu.edu/~sean/stuff/java-objc.html And Java EE started as an Objective-C project, https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

Swing also seems to be heavily inspired by AppKit. Although leaving out messaging and leaving in both int and Integer are weird choices if their language was supposedly inspired by Smalltalk/ObjC.

>Although leaving out messaging and leaving in both int and Integer

Both are great choices... from performance point of view. Java is still modeled after plain C 1st and foremost. int should be the default and Integer(and Long) should be avoided. Up to java1.5, it took a manual operation (Integer.valueOf/intValue) to convert, so it was not abused as much. Marked integers have been in the works and they take a significant engineering effort for a nice to have feature.

When collection framework was introduced, it should have had primitive Maps/Lists - there was a regret (around java8 times) not including them initially - Streams attempted to amend the damage. The primitive types map directly to the hardware. Wrapped ones - they are pointer to an immutatable primitive and enjoy little optimization from the JIT.

As for swing, beans and properties - I'd say Delphi would have the most similarities.

Re: Prime Video Uses WebAssembly

#243

Post by labawi »

Beltalowda wrote: post #226
labawi wrote: post #160

Earlier quoted context omitted.

Concur. I block wasm and webgl, mostly for security and privacy, so don't use sites that require it. Unfortunately, as I also block trackers, most site operators won't even realize people like me visit their sites.

Does blocking WASM improve privacy? As I understand it, it essentially has the same capabilities as regular JS(?) but I never looked very deeply in to it, so maybe there's some parts I don't know about(?)

Theoretically, wasm shouldn't have more access, though I would be moderately concerned about bugs, and better access for timing and rowhammer.

Practically, it's mostly used for tracking and making users' machines execute even more inscrutable code. IMO, if you need wasm for |"normal" pages and apps, you're doing something wrong. There are notable exceptions (say machine emulators, maybe 3d games and such), but they are spread far between most pages.

Re: Prime Video Uses WebAssembly

#244

Post by IshKebab »

throw14082020 wrote: post #204
IshKebab wrote: post #113

Earlier quoted context omitted.

It does if you're debugging performance issues.

If you need good performance to debug "performance issues" - lack of good performance - I don't think you will solve your problem.

I'm not.sure what you're saying. You need good performance in your debugging tools to debug performance in your main app, otherwise when you enable the debugging tools they will dominate any measurements.

Re: Prime Video Uses WebAssembly

#245

Post by AtlasBarfed »

maeln wrote: post #137
TruthWillHurt wrote: post #64

Prime Video app sucks. Spend less time over-optimizing, more time improving usability.

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, ...

Have you seen the AWS UI?

Or the AWS API?

I actually think this is a product of Amazon's workplace culture. The old joke about the first 90% taking 90% of the time and the last 10% takes the other 90% of the time. Amazon only invests in the first 90%, and doesn't give a shit about the rest of it because they have already won the monopoly, and their sociopathic stack ranking forced firing culture won't reward people working on polish.

In UIs, that second 90% is polish. Polish comes from low priority ticket/feature fulfillment, and if you're working on low priority tickets, that means you're getting fired in the next reaper cycle.

Re: Prime Video Uses WebAssembly

#246

Post by seanw444 »

labawi wrote: post #243
Beltalowda wrote: post #226

Earlier quoted context omitted.

Does blocking WASM improve privacy? As I understand it, it essentially has the same capabilities as regular JS(?) but I never looked very deeply in to it, so maybe there's some parts I don't know about(?)

Theoretically, wasm shouldn't have more access, though I would be moderately concerned about bugs, and better access for timing and rowhammer. Practically, it's mostly used for tracking and making users' machines execute even more inscrutable code. IMO, if you need wasm for |"normal" pages and apps, you're doing something wrong. There are notable exceptions (say machine emulators, maybe 3d games and such), but they a…

It's ridiculous to me to even call these things web browsers anymore. A more realistic term is any-type-of-application-cross-platform engine. But that's not really concise. Why did the web have to become the primary development platform for nearly everything, with WebAssembly, WebGL, notifications, etc?

I, for one, am a fan of the fact that Gemini is growing in adoption (at least as far as I can tell). Such a nice, stout protocol.

Re: Prime Video Uses WebAssembly

#247

Post by Ha_Mei__33 »

the_duke wrote: post #69
Shadonototra wrote: post #24

Earlier quoted context omitted.

> I think Rust has the best WASM 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

Your comment seems to rooted in your dislike of Rust, rather than provide any technical arguments. The Rust tooling certainly was the best, no question. As the Mozilla WASM devs have moved on the WASM tooling has stagnated, sadly, and The C++ tooling has caught up. Languages like C# and Go are inherently worse for WASM because they require GC and have big runtimes they have to bring along.

>> Languages like C# and Go are inherently worse for WASM because they require GC and have big runtimes they have to bring along.

People are streaming GBs of content with their devices. At startup most of the social media apps or websites are downloading tens of MBs. Users don't care or notice.

I don't know the size of the C# runtime in WASM, but the Go runtime is compressed at about 0.5 MB. Downloading this at startup is unnoticeable unless you are deep in the wild. With TinyGo (https://tinygo.org/) it's less than 50 KB (don't know the exact number, I think around 30 KB). So really small.

The weight of a runtime is not a convincing argument against C# or Go.

On the other hand, GC and runtime make development of memory safe and concurrent code much easier than C/C++/Rust. Also, performance of C# and Go is so very close to C/C++/Rust, that for most use cases they are fast enough.

Bottom line: C# or Go are not *inherently* worse for WASM. You still need to develop your app. With both C# and Go you can do it with much less mental overhead compared to C/C++/Rust. You have more time and energy to focus on your problem to solve than to manually manage memory. If you really need the absolute cutting edge performance, not WASM but native would be more appropriate anyway.

Re: Prime Video Uses WebAssembly

#248

Post by shmerl »

ChuckNorris89 wrote: post #202
dannyw wrote: post #150

Earlier quoted context omitted.

The reason is because it's harvested from a laptop chip; and in laptops, the Ryzen 5000 media engine features AV1 decode, so it's wasted die space. Still, the 6500 XT is an awful GPU.

>the Ryzen 5000 media engine features AV1 decode No it doesn't.[1] Ryzen 5000's iGPU is based on the older Vega architecture and has no AV1 support, so everyone like me who just bought a brand speaking new laptop with Ryzen 5000 will be screwed soon enough. [1] https://cpufinder.com/amd-ryzen-7-5800u

Yeah, you need to wait until 6000 series. AMD really dragged their feet with APUs.

Re: Prime Video Uses WebAssembly

#249

Post by gk1256 »

pacificat0r wrote: post #153
gk1256 wrote: post #146

Earlier quoted context omitted.

I can dislike Rust too, but the facts are facts. Emscripten is the leader of WASM world and lot of its code is based on C++.

Emscriptem is targeted at browsers and for that rust does have the target wasm32-unknown-emscripten However, when targeting wasm outside browsers wasm32-wasi is usually a better option.

"Emscripten" can target platform outside browsers. You have STANDALONE_WASM flag for that.

Re: Prime Video Uses WebAssembly

#250

Post by AmyNever »

aylmao wrote: post #29
ec109685 wrote: post #20

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…

>probably more reliance on the app update systems of third parties.

Exactly right. Big platforms with guaranteed support is one thing, but here's the situation for smart TVs right now:

It's 2022. You build an app for SuperScreen's latest range of smart TV. You update it every so often, and SuperScreen are happy to certify those updates and help you push them.

It's 2023. You port your app to SuperScreen's latest range of smart TVs. You keep updating your 2022 app, but SuperScreen are slightly less helpful now, as most of their attention is focused on the 2023 set (and upcoming 2024 range).

It's 2024. You port your app to SuperScreen's latest range of smart TVs. But when you want to update your 2022 app, SuperScreen say "hmm, we don't really have a lot of time now to certify apps for these older devices, please try to make as few updates as possible". It's a little tough but you have to do it, as the alternative is that 2022 TVs don't get any of your new features.

It's 2025. You port your app to SuperScreen's latest range of smart TVs. But now SuperScreen refuse to certify updates to your 2022 app saying "these are legacy devices and we can't justify the time or effort to certify apps on this platform any longer... unless you were to pay us a LOT of money".

You might get approval for one last update, paying SuperScreen the money, and then you effectively mothball your 2022 app. It becomes a "legacy" app for you as well, stuck in maintenance mode, not getting any updates or new features. And this is on a TV that is only four years old. So the best way forward is to make your native layer as small and light as possible, and shift all of the heavy lifting into the runtime client layer. If most of your client UI is a downloadable JS / WASM runtime, then you can keep supporting it even if the platform owners don't want to play ball any more.

Post reply on HN