But, especially with brand-new challengers appearing today, they seem to fall into the same trap: only talking about advantages without any hint of how those advantages were achieved.
This is most apparent when people write about code size. So Moon is like Vue.js or React, but faster and smaller. Reportedly.
So, well, how? The technical whizzes at Facebook aren’t inserting ASCII art of Rumsfeld into their source code or forgetting to enable UglifyJS. There’s no pinball mode you can engage by using setState. If the popular thing is bloated, and the newcomer is minimal, what’s the delta?
Or in other words: describing the difference between some project and your own by saying that yours is “smaller, faster, and better” is using marketing language where you should be in explanatory mode.
In quite a few cases, the difference between ‘small’ projects and ‘big’ projects boils down to:
- Reduced browser support.
- Fewer tests, and less protection from browser quirks.
- A design that makes native or server-side rendering more difficult.
- Reduced API surface area.
- A ‘small-core’ design that makes the main project smaller but requires more dependencies.
Sometimes “better + smaller” actually is true: which means there’s a great opportunity for all projects to benefit. But it hinges on people explaining concepts. Not just advertising a certain library, but promoting the core idea that makes that thing better. Or even better, it’s an opportunity to bring those improvements back upstream so that even users of the popular frameworks get their benefits.
We’re making progress, which is great. And it’s lovely that there’s a lot of experimentation in the field. But don’t fall for the marketing copy: look under the hood, and view these challengers with a proper dose of skepticism.