20+ years into my experience as an IT architect I've battled with overly complex ideas non-stop. The worst part of jobs is usually having to go through a huge research and documentation process just to get a customer to adopt the solution I'm proposing because of all of the frameworks and tools floating around with deeply false promises.<p>I've found it's simply better to avoid working with devs that implement overly-complex and under-supported solutions.<p>A JS library, no matter how cool it works, often isn't supported properly after the 1-2 year mark if it's not maintained and updated responsibly. Less is more if a site or application runs flawlessly and if weak workarounds don't constantly need to be involved in every product release.<p>Many devs create complex code because they think perhaps that that is the way to retain job security, it simply doesn't work over time for anything beyond a portfolio site. In the business world, well-serving-mission-critical systems are either maintained by big teams and a lot of funding, or by tight knit teams using technology that is simplified and low-maintenance.<p>Blockchain, abstract JS frameworks, and many other new concepts are promoted these days as cutting edge, with buzz-word branding like "Web 3.0" etc... Because it's very hard to disparage a history of stability and reliability found in PHP, Python, C, and Java (etc) without trying to rebrand stable and proven solutions as "Old School" and "Legacy". Using those terms for proven solutions is wrong in my view, and it only serves to create a new revenue stream in refactoring and "screwing up" an ecosystem that's worked. Those "Legacy" ecosystems are still being updated by their support communities, and likely by leveraging far more organized, tested, and stable methods than those used by creators of newer frameworks.<p>In contrast, it's very hard, expensive, and time consuming to do a fully functional proof of concept and to maintain it over long periods of time especially when your solution is based on a small and fragile community of support, and with very little documentation because of that solution's infancy.<p>Stable (for me) always better than cutting edge in every solution I've built. The tools are not as important as the end product, it's fulfillment of business objectives, reliability, uptime, ease of use, and it's functional precision.<p>Design and Innovation do still have great merit in solutions, but they should never outweigh nor outrank reliability, efficiency (simplicity), consistency, and function of a solution.