6 ms·

Couldn't agree more on async everything. Been building out a market charting and tracking application and boy oh boy has it been the biggest pain in the ass hav

Couldn't agree more on async everything. Been building out a market charting and tracking application and boy oh boy has it been the biggest pain in the ass having a good amount of UI rendering be dependent on async calls. Wish the UI components would just render regardless of whether or not an async call was finished, rather than have to write conditionals for the components to display based on returned promises, populated states/context... I've grown to really hate react these last few months

PaulHoule 5y ago
If it wasn’t for async everything your web browser would be locked up and unresponsive half the time. It’s one reason why Electron rules the roost…. Look at how often conventions GUI apps go out to lunch.
- Jensson 5y ago
  You know you can do concurrency without async calls? Async isn't a good solution for loading data in a data heavy application, game engines doesn't do it that way and they are the most data heavy applications you can find.
  - PaulHoule 5y ago
    Game engines are not as dependent on the network as web browsers. Usually they do all the disk I/O up front, are designed to drop events if the network goes bad, drop frames instead of hang if deadlines are missed. It’s like your compiler just skips an import if it the disk is slow.
    - Jensson 5y ago
      > Game engines are not as dependent on the network as web browsers You do know that web browsers aren't implemented in Electron either and that they don't use javascript to load the resources of a web page concurrently? You were talking about why Electron/Javascript/Node.js rules all. I'm not aware of any web browser implemented in those technologies. I know Electron is based on chromium, meaning they used a browser to implement it, but I am talking about the other way around ie implementing a browser in Electron.
      - PaulHoule 5y ago
        It is the other way around. Electron embeds a web browser, which is a highly complex asynchronous application which is written in C++ by one of only a handful of super high tech companies. It is notorious that efforts to make web browsers with other runtimes (e.g. Hotjava) have failed. The web browser is async from top to bottom so it never blocks when loading possibly hundreds of resources that make up a web page. JavaScript is asynchronous so it can be embedded in the web browser, if it wasn’t it could lock the whole thing up. I looked at what the options were for cross-platform guis written by applications programmers and they were not pretty, had serious warts, and all went out for long lunch breaks.
        Jensson 5y ago
        Pretty sure that browsers loads resources in one dedicated thread just like complicated games do. It is a solid and simple technique to implement in C++, there are many good tools to handle that. That isn't the hard part of making a browser, the hard part is implementing all the different file formats/videos, rendering and scripting engine, security etc.
    - eska 5y ago
      You’re talking about very simple games here. Open world games are constantly streaming huge amounts of data, much more so than a browser, at much tighter timing limitations. What more complex games do (simplified) is put file IO on one thread, network IO on another, and use async (worker threads with jobs) for the rest.
  - linkdd 5y ago
    Godot use "Servers"[0] to implement the game loop, which is async by design. [0] - https://godotengine.org/article/why-does-godot-use-servers-and-rids https://godotengine.org/article/why-does-godot-use-servers-a...
- smitty1e 5y ago
  Isn't node.js then stand-alone server-side product? What's the browser got to do with it?
  - PaulHoule 5y ago
    Because that's the circular path that gets you the hated "async only" programming model. For every node.js server there are probably 100 CLI programs that get run by the way.

PaulHoule 5y ago

If it wasn’t for async everything your web browser would be locked up and unresponsive half the time. It’s one reason why Electron rules the roost…. Look at how often conventions GUI apps go out to lunch.

Jensson 5y ago
You know you can do concurrency without async calls? Async isn't a good solution for loading data in a data heavy application, game engines doesn't do it that way and they are the most data heavy applications you can find.
- PaulHoule 5y ago
  Game engines are not as dependent on the network as web browsers. Usually they do all the disk I/O up front, are designed to drop events if the network goes bad, drop frames instead of hang if deadlines are missed. It’s like your compiler just skips an import if it the disk is slow.
  - Jensson 5y ago
    > Game engines are not as dependent on the network as web browsers You do know that web browsers aren't implemented in Electron either and that they don't use javascript to load the resources of a web page concurrently? You were talking about why Electron/Javascript/Node.js rules all. I'm not aware of any web browser implemented in those technologies. I know Electron is based on chromium, meaning they used a browser to implement it, but I am talking about the other way around ie implementing a browser in Electron.
    - PaulHoule 5y ago
      It is the other way around. Electron embeds a web browser, which is a highly complex asynchronous application which is written in C++ by one of only a handful of super high tech companies. It is notorious that efforts to make web browsers with other runtimes (e.g. Hotjava) have failed. The web browser is async from top to bottom so it never blocks when loading possibly hundreds of resources that make up a web page. JavaScript is asynchronous so it can be embedded in the web browser, if it wasn’t it could lock the whole thing up. I looked at what the options were for cross-platform guis written by applications programmers and they were not pretty, had serious warts, and all went out for long lunch breaks.
      - Jensson 5y ago
        Pretty sure that browsers loads resources in one dedicated thread just like complicated games do. It is a solid and simple technique to implement in C++, there are many good tools to handle that. That isn't the hard part of making a browser, the hard part is implementing all the different file formats/videos, rendering and scripting engine, security etc.
  - eska 5y ago
    You’re talking about very simple games here. Open world games are constantly streaming huge amounts of data, much more so than a browser, at much tighter timing limitations. What more complex games do (simplified) is put file IO on one thread, network IO on another, and use async (worker threads with jobs) for the rest.
- linkdd 5y ago
  Godot use "Servers"[0] to implement the game loop, which is async by design. [0] - https://godotengine.org/article/why-does-godot-use-servers-and-rids https://godotengine.org/article/why-does-godot-use-servers-a...
smitty1e 5y ago
Isn't node.js then stand-alone server-side product? What's the browser got to do with it?
- PaulHoule 5y ago
  Because that's the circular path that gets you the hated "async only" programming model. For every node.js server there are probably 100 CLI programs that get run by the way.