Blanet statements like this are always wrong. Architecture needs to be a result of finding the correct solutions to problems. For instance, if you're building a browser game you don't want to be using the server side for rendering.

I don't think they mention maintenance burden specifically. Using a framework with packages means you have to track upgrades, do upgrades, check release notes, breaking changes, support and end of life cycles, license changes, etc. It's a have maintenance burden if you keep it live, even if you don't intend to make any changes.

Vanilla doesn't have this problem. Server-side has it too, but in a slightly different flavor.

The heavier and integrated the framework, and the more additional packages you include, the heavier the burden.

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.