But is this actually a good thing?
A brief history
Its development took 10 days. In comparison, it took Sun Microsystems 5 years for Java to become a public 1.0.
Jump forward to today
Getting more complicated
But even worse than all the new frameworks is the constant change in project tooling. Every single project seems to use a different build system / packager, and even if you look at a single project, it might switch its build system with the next release.
Let’s see what you will be using in 3–6 months.
It sometimes feels we have more work keeping our build-/packager-system alive during a project than working on new features.
I know how alluring it can be to switch or build your own tooling to get the last little bit of optimization quite right. But as developers, we shouldn’t be needing to care so much about the finer details.
Being a full-time Java developer, I can tell you that Maven or Gradle aren’t the best build systems ever built for every edge-case. But what do we want from them? We want a consistent, maintainable build system, so we can maintain our code, not the build system itself.
Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.
– Mark Zuckerberg
In my opinion, this quote is misunderstood most of the time.
Yes, moving fast is essential in today’s business environment. And some stuff will obviously break in the process.
But breaking it isn’t supposed to be the end of it… you need to fix it, too! Or you just end up with a broken system.
For your own little projects that might be ok. But building something with multiple people or some enterprisy stuff shouldn’t be in a constant state of being broken just for the sake of being fast.
Every time we update React-Native it’s hell because being fast is more important than being maintainable. Instead of fixing broken stuff, it’s more important to release new features, with their own set of new bugs. And most of the time it won’t reach 1.0 quality, instead, it will be replaced with another component or system.
Lower bar === lower quality?
Everyone who wants to enter the field of software development should be able to do so. Nobody should be forced to understand C/C++ in detail, or know how to write assembler first.
Everything you might need is already available as an NPM package. Actually, that’s a great feature of the ecosystem many other languages are missing.
And everybody can easily create and publish an NPM package for others to use!
Code duplication and reinventing the wheel can lead to so many problems, but as the left-pad fiasco showed that depending on external dependencies for everything might not have been the best idea. A few lines of code for a trivial function broke so many builds.
There are high-quality packages you can be sure about being around in the long-run. But the dependency graphs are getting longer every day. Are you using React-Native? So you now have 620 dependencies, with ~17 different licensing models. Are you sure all of these dependencies are future-proof?
PHP is also a simple language, that runs almost anywhere, with lots of beginner-friendly content. You can build great products with it, but you could also build a big pile of shit. To make it more usable, Facebook created a dialect Hack of its own.
This kind of reminds me of all the compiles-to-JS languages or addons like Flow. A language should be great, or at least good enough without the need for a lot of tooling and other stuff to make it productive and useful. It feels weird how much code is written around a language to fix its shortcomings so you can use the language everywhere.
It’s not a one size fits all solution. So stop treating it like one.