DI probably also involves at that time the cost of scanning it into film. I worked in the industry a little after this and some of the DI theatres rent out for 1K+ per hour, plus there’s conform artist time, incorporating new cuts, etc. I could see it.
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
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.
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".
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.
> 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.
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.
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.
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.
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).
ChowNow | Principal Front End Engineer | Los Angeles, CA (Playa Vista) | Full Time | Onsite | https://www.chownow.com/
At ChowNow, we build online ordering systems for thousands of restaurants. We're launching new projects in the coming months that I'm really excited about. Most recently, we launched https://eat.chownow.com and the iOS app (https://itunes.apple.com/us/app/chownow-food-delivery-and-re...). I love working here as a software engineer. It's a great balance of challenge, responsibility, and freedom.
We're looking to bring on a Principal Front End Engineer to help us build out the new products and update some of the existing ones. We use React for our newest projects and have some Ember.js projects too. The position is here: http://bit.ly/chownow-frontend
In addition, we'd like to hire another senior-level backend / full-stack engineer to work on our Python-based services (http://bit.ly/chownow-fullstack). This is the team I'm on! We have interesting opportunities coming up related to scaling, architecture, and new products.
I'm so, so glad I don't have to care about deliverables requirements anymore. Every studio has totally different set of requirements that are as complex as this and it's a real bear to make sure you're fully in compliance with them.
reply