3 ms·

Question: What operations are being done on the client side that requires that much speed? Why is speed even a concern in this case? With modern hardware and th

Question: What operations are being done on the client side that requires that much speed? Why is speed even a concern in this case? With modern hardware and the type of applications I am familiar with (rendering tens of thousands of financial data points), I could 50x lower the speed of execution and the client wouldnt even feel it. So I´m geniunly curious what people are working on that requires that much speed/performance?

tcbasche 6y ago
Curiously, I would say that if a frontend technology is fast then that's already improved the user-experience. If your user can click around quickly and if making a mistake isn't a huge setback in terms of time to navigate through loading screens etc. It also gives developers a good starting point - no need to optimise if the language is just natively snappy. But, as is usually the case, your mileage may vary depending on your use case!
cellularmitosis 6y ago
> I could 50x lower the speed of execution and the client wouldnt even feel it Is that a typo? Did you mean "50%"?
- wesammikhail 6y ago
  no 50x. If you design your applications correctly with the right data structures, you rarely need all the computational power today´s machines have. In some cases, yea probably. but in most cases, hardware is already too good!
  - CryZe 6y ago
    Well it seems like the clock example they have can't even hit 60 FPS without consuming 100% cpu (of one core). So yeah you probably don't want to actually use Python in the browser (via a JS interpreter).
    - chownie 6y ago
      I'm getting 2.7% CPU usage with the clock loaded on Firefox, possibly platform dependant?
tgv 6y ago
I've just finished rewriting a standalone python application into a JS browser application, and runtime went from 20 minutes to 1.5s. The most important factor is that the original programmer didn't know what convolution is and that it's a linear operation, but in those 1.5s, V8 manages to run thousands of times through a 250k pixel array, convolve it, and draw it; changing the color mapping takes a mere 4ms, so it can be done with responsive controls. Python just can't do that. Edit: this thing transpiles to JS, apparently, so it might perform.
hombre_fatal 6y ago
This assumption is how you end up with Slack and Discord eating 100% cpu any time there's an animated gif. Something they probably don't notice on their powerful developer workstations. You should spend more time using/working on heavy clients from a slow device since it tends to quickly answer the question. You aren't just using Brython for your one $('box').hide(). Rather, you're using it presumably because you are writing a lot of client code.

tcbasche 6y ago

Curiously, I would say that if a frontend technology is fast then that's already improved the user-experience. If your user can click around quickly and if making a mistake isn't a huge setback in terms of time to navigate through loading screens etc. It also gives developers a good starting point - no need to optimise if the language is just natively snappy. But, as is usually the case, your mileage may vary depending on your use case!

cellularmitosis 6y ago

> I could 50x lower the speed of execution and the client wouldnt even feel it Is that a typo? Did you mean "50%"?

wesammikhail 6y ago
no 50x. If you design your applications correctly with the right data structures, you rarely need all the computational power today´s machines have. In some cases, yea probably. but in most cases, hardware is already too good!
- CryZe 6y ago
  Well it seems like the clock example they have can't even hit 60 FPS without consuming 100% cpu (of one core). So yeah you probably don't want to actually use Python in the browser (via a JS interpreter).
  - chownie 6y ago
    I'm getting 2.7% CPU usage with the clock loaded on Firefox, possibly platform dependant?

tgv 6y ago

I've just finished rewriting a standalone python application into a JS browser application, and runtime went from 20 minutes to 1.5s. The most important factor is that the original programmer didn't know what convolution is and that it's a linear operation, but in those 1.5s, V8 manages to run thousands of times through a 250k pixel array, convolve it, and draw it; changing the color mapping takes a mere 4ms, so it can be done with responsive controls. Python just can't do that. Edit: this thing transpiles to JS, apparently, so it might perform.

hombre_fatal 6y ago

This assumption is how you end up with Slack and Discord eating 100% cpu any time there's an animated gif. Something they probably don't notice on their powerful developer workstations. You should spend more time using/working on heavy clients from a slow device since it tends to quickly answer the question. You aren't just using Brython for your one $('box').hide(). Rather, you're using it presumably because you are writing a lot of client code.