My holiday gift to you all is an simple and amazingly useful tool for cutting through the nonsense in web dev discourse.
It’s a very simple question that you just ask yourself whenever you read about a new dev tool, framework update, or somebody’s opinion on a dev tactic:
“Will this help me build a sustainable software business?”
(Use ‘organisation’ instead of ‘business’ if you’re in the not-for-profit/charity game like me.)
SPA vs hydration vs server-only vs Turbolinks? No. those debates won’t help at all because YMMV, always.
React vs vanilla js vs Svelte vs Vue? No. Use the best tool that suits the task and you are familar with. Get to know more tools over time because that gives you options. YMMV, always. Whether it helps you build a sustainable business depends on the business, not the tool.
All those CSS debates? You’re always going to have to learn standard CSS before you can reliably use a tool that abstracts over it. Until then, use what works best for your use case. YMMV, always. Whether it helps you build a sustainable business depends on the business, not the tool.
Debating the UX of various approaches? YMMV, always. Sometimes the best UX ever is just solving the core problem well. Sometimes not. YMMV, always.
(One of the best web services I’ve used is the Icelandic healthcare portal Heilsuvera. It’s server-rendered-and routed, 2000s-style. It literally could have been made with late 90s web tech and it’s amazing.)
Typescript? Webpack vs rollup vs snowpack? YMMV, always. Whether it helps you build a sustainable business depends on the business, not the tool.
Don’t buy into tool zealotry or dev-tactic extremism. Your task is to solve the problem at hand not to participate in popularity contests.
Start with your actual problem, not the “how many angels can dance on a pinhead” abstract problems the web dev community manufactures to keep online discourse going.
“Will this help me build a sustainable software business?”
That’s it. That’s your starting point for any tool or tech disc.
YMMV, always. Or, to quote Frederick Brooks’s 1987 paper: “There is inherently no silver bullet.” Building software will always be hard.