6 ms·

I'm more surprised that it uses Node.js in the first place!

by kozak 6y ago

falcolas 6y ago
Probably in the store and/or the news feed. 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.
- chmod775 6y ago
  You think node.js specifically has anything to do with that being slow?
  - hobby-coder-guy 6y ago
    Why not?
  - falcolas 6y ago
    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.
    - chuckhendo 6y ago
      It likely is being used server side. I seriously doubt Node is being used on device
      - falcolas 6y ago
        I hope so as well. Still honked off about the performance of the store though.
    - _-o-_ 6y ago
      Not sure about processing power, but Switch has 4 times more memory than my DO VPS and Node isn't struggling there in any way.
- STRML 6y ago
  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.
  - falcolas 6y ago
    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.
    - arghwhat 6y ago
      "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.
      - falcolas 6y ago
        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.
        colejohnson66 6y ago
        V8 and SpiderMonkey use JIT compilation, not interpretation
- golergka 6y ago
  I'm in love with Node as a developer, but this is definetly not what it was created for.
- Cthulhu_ 6y ago
  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.
  - kuschku 6y ago
    > 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.
    - projektfu 6y ago
      Right, like is that the reason that Symbian succeeded?
  - Shacklz 6y ago
    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.
  - 6y ago
chmod775 6y ago
Maybe not in the console itself, but instead on one of their websites/servers. I don't think lawyers would understand or care about the distinction, hence the license text is there.
- hprotagonist 6y ago
  hey man, “better safe than sorry, include the license” is a nice change of pace! I’ll take it.
- XaspR8d 6y ago
  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".
cwmma 6y ago
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)

I'm more surprised that it uses Node.js in the first place!

by kozak 6y ago

I'm more surprised that it uses Node.js in the first place!

Probably in the store and/or the news feed. 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.

chmod775 6y ago
You think node.js specifically has anything to do with that being slow?
- hobby-coder-guy 6y ago
  Why not?
- falcolas 6y ago
  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.
  - chuckhendo 6y ago
    It likely is being used server side. I seriously doubt Node is being used on device
    - falcolas 6y ago
      I hope so as well. Still honked off about the performance of the store though.
  - _-o-_ 6y ago
    Not sure about processing power, but Switch has 4 times more memory than my DO VPS and Node isn't struggling there in any way.
STRML 6y ago
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.
- falcolas 6y ago
  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.
  - arghwhat 6y ago
    "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.
    - falcolas 6y ago
      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.
      - colejohnson66 6y ago
        V8 and SpiderMonkey use JIT compilation, not interpretation
golergka 6y ago
I'm in love with Node as a developer, but this is definetly not what it was created for.
Cthulhu_ 6y ago
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.
- kuschku 6y ago
  > 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.
  - projektfu 6y ago
    Right, like is that the reason that Symbian succeeded?
- Shacklz 6y ago
  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.
- 6y ago

chmod775 6y ago

Maybe not in the console itself, but instead on one of their websites/servers. I don't think lawyers would understand or care about the distinction, hence the license text is there.

hprotagonist 6y ago
hey man, “better safe than sorry, include the license” is a nice change of pace! I’ll take it.
XaspR8d 6y ago
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".

cwmma 6y ago

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)