[Kaedon]

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

[gjsman-1000]

I could be incorrect, but last time I did some reverse-engineering, Netflix had a Qt application that used native C++ bindings to knock out huge sections of that list.

That Qt application was only lightly modified for each platform, IIRC, and it appeared all over the place from those cheap Linux-based Blu-ray players to Smart TV clients. Anywhere that was embedded, generally Linux-based, and unlikely to get frequent updates.

As for some of the larger players like Roku or Android, those ones are more obvious where to hire. Java developers and BrightScript developers.

[mftb]

It all kind of undermines your original comment tho that they're trying to avoid native. It seems more likely that they're goal is to reach as many devices as they can and be able to do updates frequently. In the first paragraph of the linked article the guy says the trade-off is between "updatability and performance".

[nofunsir]

I am really sick of fast-churn and forced updates. Guys. Settle. Write a native app or three. It’ll be ok.

[klabb3]

As someone who is writing a cross platform app, I'd love to, but I can't.

There are too many different stacks with their own languages (which means different library ecosystems), no good FFI/IPC options that work across stacks, massive test matrix for every little piece of the code etc. All of this, when the native differences that supposedly should make each platform unique are so few, and virtually all UI and application logic is identical. Our platform lords have basically not standardized a single thing.

[WA]

> Our platform lords have basically not standardized a single thing.

And in addition, you have bugs in official native SDKs and then you end up writing your own text rendering engine, because some OS-level API didn't work properly.

[remus]

I think it's important not to conflate churn with fast updates. In it's essence the ability to deliver updates quickly (in this case by downloading a blob of wasm+js each time the app is started) is a great thing imo, as you eliminate a huge chunk of problems around delivering updates and clients on old versions. For 99% of users this is a huge win.

You can obviously abuse this by redesigning the UI every 6 weeks but let's not throw the baby out with the bath water.

[nofunsir]

I'm of the strong opinion that there simply does not exist, as you say, 'a huge chunk of problems around delivering updates and clients on old versions.' It's certainly not a win for users, but for lazy developers. Good software engineers are much more than fast-churn developers. In fact, they are different people.

[progmetaldev]

I'm 100% with you on this, but good software engineers are also much more expensive than fast-churn developers, and it seems to come down to how much spend these companies want to invest in their technology. There is just an overabundance of web developers out there, and the tech companies are taking advantage of that.

[remus]

I guess we'll have to agree to disagree. I just don't see barriers in getting updates out to people as a good thing.

It seems your argument is that it encourages developers to be sloppy, but in practice I think it just ends up as a net loss for users as the average user just isn't interested in updating software, however critical the bugs in their current version. Maybe I'm different from the average user, but for me the fact that chrome has gone through 90+ versions over 10+ years without me having to think about it is great (and, I suspect, strongly correlated to the relative lack of security issues over the years despite it having a huge surface area).

[syshum]

if they did that then only the most popular platforms would ever be support, happen to use a niche product, or a older product, well your SOL.