6 ms·

I often feel I'm on another planet when I see timings for browser things people are recommending - Insert one message - best 9ms, insert 20 messages - best 33ms

I often feel I'm on another planet when I see timings for browser things people are recommending - Insert one message - best 9ms, insert 20 messages - best 33ms, worse - >8 Seconds! Why bother? just write a native client.

radex 5y ago
Browser-based apps have use cases even when you reject PWAs generally as a replacement for native apps. Trying out a new tool quickly, or short-term when using a tool with a customer, in enterprise where you can't install native tools, etc...
- chadcmulligan 5y ago
  Well make a binary that doesn't require installation, this is a very narrow use case for a technology thats being advocated for more than that use case
  - tatersolid 5y ago
    Most enterprise users can’t download and run an arbitrary binary due to numerous security controls and regulations. This is true even if that binary is signed - if it isn’t on an allow-list maintained by high priests it can’t be used. The real world demands web apps in the enterprise even in 2021.
    - deleted 5y ago
      [deleted]
    - chadcmulligan 5y ago
      This is a poor reason in 2021 - app stores exist. Software developers have an obligation, as professionals, to present the costs of web apps vs binaries when developing new projects, the browser is not an operating system and has real limitations - as this project demonstrates.
typingmonkey 5y ago
When you insert 20 messages, there is way more happening than 20 db writes. Each insert will affect the UI which will cause a layout change. Also the changes will be replayed in different browser tabs and might also be replicated to the backend. Then there is things like conflict resolution, validation and encryption. You just cannot compare these speeds with your MySQL insert operation.
- deleted 5y ago
  [deleted]
- chadcmulligan 5y ago
  You see, the fact that you do all that for a write is what's wrong. The interface should be decoupled from the message write, and the GUI notified a change has happened and update if needed.
  - typingmonkey 5y ago
    Yes, this is exactly what is happening. But still you only have one CPU in JavaScript, so the GUI part will take the resources from the database part.
    - chadcmulligan 5y ago
      So the browser isn't really suited to this sort of thing
      - typingmonkey 5y ago
        The browser is an abstraction layer. It will always be slower. But all this does not matter because your user will not write 20 chat messages / second.
        chadcmulligan 5y ago
        I hate to say slippery slope but - its bad, so why not make more bad stuff on top of it. I feel the bad parts of the browser are glossed over in software development decisions, this is a very bad approach for any engineering discipline. The surprising thing is how few software devs know how to do anything non browser, how can proper technology evaluations be performed without this? This is just the latest in a long line of such.

radex 5y ago

Browser-based apps have use cases even when you reject PWAs generally as a replacement for native apps. Trying out a new tool quickly, or short-term when using a tool with a customer, in enterprise where you can't install native tools, etc...

chadcmulligan 5y ago
Well make a binary that doesn't require installation, this is a very narrow use case for a technology thats being advocated for more than that use case
- tatersolid 5y ago
  Most enterprise users can’t download and run an arbitrary binary due to numerous security controls and regulations. This is true even if that binary is signed - if it isn’t on an allow-list maintained by high priests it can’t be used. The real world demands web apps in the enterprise even in 2021.
  - deleted 5y ago
    [deleted]
  - chadcmulligan 5y ago
    This is a poor reason in 2021 - app stores exist. Software developers have an obligation, as professionals, to present the costs of web apps vs binaries when developing new projects, the browser is not an operating system and has real limitations - as this project demonstrates.

typingmonkey 5y ago

When you insert 20 messages, there is way more happening than 20 db writes. Each insert will affect the UI which will cause a layout change. Also the changes will be replayed in different browser tabs and might also be replicated to the backend. Then there is things like conflict resolution, validation and encryption. You just cannot compare these speeds with your MySQL insert operation.

deleted 5y ago
[deleted]
chadcmulligan 5y ago
You see, the fact that you do all that for a write is what's wrong. The interface should be decoupled from the message write, and the GUI notified a change has happened and update if needed.
- typingmonkey 5y ago
  Yes, this is exactly what is happening. But still you only have one CPU in JavaScript, so the GUI part will take the resources from the database part.
  - chadcmulligan 5y ago
    So the browser isn't really suited to this sort of thing
    - typingmonkey 5y ago
      The browser is an abstraction layer. It will always be slower. But all this does not matter because your user will not write 20 chat messages / second.
      - chadcmulligan 5y ago
        I hate to say slippery slope but - its bad, so why not make more bad stuff on top of it. I feel the bad parts of the browser are glossed over in software development decisions, this is a very bad approach for any engineering discipline. The surprising thing is how few software devs know how to do anything non browser, how can proper technology evaluations be performed without this? This is just the latest in a long line of such.