I can’t think of a nice way to say this, but I wonder if this is part of the reason they both perform so poorly once you’ve loaded a lot of data into them. I get so frustrated trying to use the on-console store after only a few pages of scrolling.
Quite likely; iirc the Playstation's UI (and store) are also made with web technology, and its performance is just so bad.
For a product that is responsible for billions in revenue every year, I would expect them to have some of the best native developers working on it. Instead, they sorta wrangled web technology to sorta work. I don't understand why the performance is so bad on the PS4 of all things, given how it's a pretty decently specced machine.
They, and many other companies, should really look at the iPhone's early success - a BIG factor there was native code, meaning they could run on a single core machine for years while Android was struggling to push device specs up just to get their UI to feel performant.
And Apple's wasn't even optimal; they used objective-c which adds some overhead with every single function call (simplified: 'can I call this method on this object? Yes? Then call the method on the function call'. Only fixed with Whole Module Optimization in Swift iirc).
But it made such a huge advantage in terms of performance and battery life, Apple was easily five years ahead of any competition.
When minimum viable product becomes the actual product.
To be blunt it's probably more cost-effective for them to hack something like that together, then to take time to actually fix it. If you bought a ps4/5 you're effectively stuck with using that interface. I think they're moving to flutter now, but this is just how big companies work.
Not enough customers are going to not buy a PS4 because the web store is a little clunky.
Wow, I'm surprised to see it used in that large of a capacity that soon. I was under the impression that it was still a somewhat-glitchy prototype (especially in any non-mobile uses), but maybe it's time to give it another look. Thanks for mentioning this.
Another justification for purchasing disks, I guess. A much more solid 'ownership' model for games, the loading speed's about the same (since most things are installed to SSD, instead of read from the disk), can purchase second-hand... yup. Disks for me, thanks.
I thought that too with my Switch: use cartridges when I can, but it got frustrating swapping them out when it was docked. So I started doing digital only purchases onto a 256 GB microSD card, and it’s so much better (IMO). I haven’t noticed a difference in load time either.
It doesn’t help that game updates go onto the SD card, not the cartridge. So updates to the whole game basically make your cartridge a DRM dongle.
Did you ever try to use the playstation platform (network? store? whatever they call it) in the browser?
It's absolutely atrocious; I don't think this has much to do with them using webtechnology, it's just an atrocious heap of spaghetti (and probably, guessing from the weird settings syncing and authentication, an architectural nightmare).
The ball of mud would roll faster if it were written in C++, for sure, but it would still be a ball of mud.
> They, and many other companies, should really look at the iPhone's early success - a BIG factor there was native code,
?????? Honestly I don't understand this argument - the iPhone didn't even support apps at launch, only the 2007 equivalent of today's PWAs, pinned websites.
The slowness of the store UIs on
consoles is largely attributed to fact they are running their Javascript engines in interpreter mode, for security reasons.
Yes, the store is terribly slow. That's almost certainly at the UI layer, which may indeed be something like Electron, which would explain the slowness.
Node.js isn't slow, especially for this use case, but any sort of HTML-based layout definitely is.
Node - V8 - isn't slow when running on a device with a decent processor and fast RAM. The Switch is not such a device.
IME, it's not the presentation, is the loading of assets into memory. Once the assets (like thumbnails, descriptions) are loaded, the display is as fast as always, but you scroll beyond what's cached and it turns back into molasses.
"XYZ isn't slow if run on a fast enough processor" is an utterly useless statement.
My personal gripe with the eShop is the horrible startup time (compare to the time it takes the settings application to open - part of this can be assigned to it being a web application indeed), lack of partial/incremental presentation, and possibly lack of prefetching. Asset loading causing bad UX is always a frontend problem.
Any interpreted language is going to its performance/memory barriers long before a compiled language as the CPU and memory shrink. It's inevitable; the interpretation is an unavoidable overhead.
Sure, you can write slow code in any language, but the language will limit how fast your code can ever be.
This from a Python fanboi, FWIW. I'd never try and use Python on an embedded device where performance matters, not only for UI responsiveness, but for battery life.
No, it affects warm-up, which is not the same. JS is only JIT'ed if the interpreter decides that it has been running code enough for it to make sense, and then not even permanently.
Some things will never JIT. Some things will JIT much later, leading to sudden CPU spikes later. And importantly, code will often deoptimize a few times, meaning that it drops back to interpreted to re-trace even if it had already optimized this code block.
And as most web "applications" are loaded only to be thrown away as you finished reading fixed text, all of those resources were burnt for nothing. This includes an application like the eShop, which has limited need for JS for anything other than lightweight asset handling.
It’s extremely frustrating. I like looking at the new releases every few days, but if I wait too many days before checking, I have to go through screen after screen of scrolling and it freezes when it loads the new preview images.
I noticed this yesterday. I don't know why HTML would be to blame, as I've used web browsers on low power devices before and they can be very snappy.
One thing I noticed was that when attempting to switch between e.g. 'Offers', 'New' and 'Highlighted' or whatever the headings are, there's a large lag / hangup. It certainly doesn't feel like they're working on keeping it fluid and snappy. That might not be a priority, but I'm certainly put off browsing and buying when it's unpleasant to do so.
To be fair, it's worse on other consoles IME, and if I keep my browsing light, stay at the top of lists and don't get too impatient, it's okay.
I've never noticed HTML based layouts being slow unless someone explicitly designed a slow UI. The bigger problems are slow startup time and excessive RAM usage. Running multiple browser instances is not sustainable.
If it's true it's just terrible. The store is not that much of a complext software, yet they still decided to use these bloatware when they can just use their fine GPU and renderer natively.
It's a remarkably low spec device, and anything that's not fairly well optimized is going to behave poorly (games show this constantly). Node.js (V8) was optimized for use on servers and general purpose computers with multiple gigs of RAM and absurd levels of processing power.
So, yes, I think that using Javascript on a low spec device is probably a source of slowness.
Heck it might've been just a part of development and not a part of the production/user-facing features. I know my former employer lists everything that was ever in our process "just in case".
I don't think they are, I think they are using jszip in some sort of client side context and bundling it up with browserify or webpack which is bringing in some dependencies that are based off of node (like readable-streams)
