3 ms·
> if your economics are such that servers are a bigger cost than payroll Sorry, and I may be oversimplifying the author's situation, but this really sounds lik
by _bxg1 7y ago
> if your economics are such that servers are a bigger cost than payroll
Sorry, and I may be oversimplifying the author's situation, but this really sounds like a case where you need to not be using JS for your server. On the client you don't have much choice, but on the client the pure-JS performance rarely gets tight enough to warrant this degree of micro-optimization work.
Author makes some good points - it would be great if the JIT were more profiler-friendly - but I have to question a little bit how important it actually is, the way the use-cases line up.
- erik_seaberg 7y agoWhen someone realized you pay a lot for cycles at the server, but you pay nothing for cycles at the client, that was the moment the world-wide web began to die.
- dimgl 7y agoWell this is hyperbolic.
- deleted 7y ago[deleted]
- _bxg1 7y agoThis is baseless mudslinging. The bottleneck on the client is virtually never the cycles consumed by the actual running of the actual app's JS code. It's usually, in order starting with the most common: - Piles of ads/analytics scripts which have no motivation not to slow down the page - Reflow; i.e. needlessly many elements on the page causing the browser to do extra work calculating layout - The initial loading and JIT-ing time of a needlessly heavy JS bundle
- pjmlp 7y agoThey are, Common Lisp, Java/Android and .NET all provide very developer friendly graphical profiling tools.
- caleb-allen 7y agoThe profiling and tooling integration of Intellij with Java has probably been the biggest thing keeping me from using another ecosystem for my personal hacking