Background in hard sciences, computing (FOSS), electronics, music, Zen.

  • 228 Posts
  • 924 Comments
Joined 2 years ago
cake
Cake day: October 2nd, 2023

help-circle



  • That may not be the wisest choice. For one thing, the client side can be as fast or faster than the ‘server’ side. Sending data to a ‘server’ which is ‘serving’ as a mainframe (reverting to a model from the past) will consume more time and bandwidth. So much for the performance goals.

    That also has the potential to create securiity concerns at both ends (which were not intense in those bye-gone days of yesteryear). Furthermore, wny should the client trust the quality of the code the ‘server’ uses? The popularity of the ‘new’ frameworks aside, the cost of bandwidth and processing by the ‘server’ will be born by the ‘client’. I’m not seeing any pluses except for thin clients, and big potential pluses for the ‘serving’.




  • I can’t speak for the performance of frameworks, but today’s ‘vanilla’ javascript both compiles and executes blisteringly fast. The better-optimized it is, the better. Staying away from modern syntactic sugar may also help.

    I can understand that those who choose to use frameworks may be newcomers, or may have productivity pressures. Neither source of slowdowns can be blamed in JS itself.

    But this headline distorts that reality by leaving out the fact that the article itself is about using JS frameworks. Whatever the ‘long-term performance goals’ may be, writing the fastest code can’t hurt them. Suggesting otherwise is a disservice to JS.