The thing I find most frustrating about “The Boring Revolution” is that it feels stuck in the particular year of 2015. Like, React has been out for 12 years. React is older now than Ruby on Rails was when the Boring essay came out. And yet I still hear people talk about React as this “shiny trendy thing”, even though it’s a mature technology with huge adoption, mountains of examples and documentation, and millions of developers with years of experience building in it.
If the essay had come out in 2008, Ruby on Rails would’ve been the “exciting” thing it was calling out. But instead, Ruby on Rails is generally considered in the “boring” camp, while things that came out closer to the essay’s publication like React are in a state of “Permanent Shiny”.
All of which blinds people to the fact that the web space has in fact settled down years ago and is not in the state of immense flux that actually was happening in 2015.
React to me will always feel like Java - a big solution by a big company for solving big company problems. When it is forced on small problems in small companies it creates unhappiness, yet, choosing something else feels like the "no one ever got fired for choosing IBM / Microsoft" dilemma.
React isn't big, it's about as small as a "framework" gets. The problem most people face is actually that the simplicity gives the developer unlimited freedom to craft whatever complex monstrosity they desire.
You haven't used vue 2 or svelte then. Modern React is big and opinionated (just like Angular). When people talk about react they are not just talking about a state management library anymore
Vue and Svelte are just as complex as React, I'd argue Vue often ends up being even more complex than react even though the barrier to entry is a bit lower for novices. If you disagree, I encourage you to link to a mature project on github built with svelte or vue that you regard as an example of simplicity.
That's exactly what I said. React is so simple and flexibile that it leaves a lot of room for developers to shoot themselves in the foot. The C analogy is spot on.
I'm not really sure how you expected the mantra of use mature technologies that are stable, mostly unchanging, and have staying power could have turned out any other way. React Hooks which required a partial rewrite for every code base happened in React 16-17 which was in 2020. This is neither a boring or stable technology to build a business on. This doesn't mean it's bad but it doesn't survive the "I can pick the code up after a few years and get it up to date with minimal effort" test.
Write boring code is about going down paths that are well troddened enough that they paved a sidewalk which isn't going anywhere any time soon. Most of the frontend world can't even conceive of an LTS release right now.
I genuinely don't understand the author, choosing boring technology is about making choices so that that platform on which you stand is rock-solid. It's easier to exercise fun, creativity, and new ideas on such a platform because there aren't any sharp edges and you can start pushing a technology. The examples with introducing Kotlin or Python/PL seemingly aren't motivated by anything other than "they're new." What problem are they solving and do you have that problem?
> If your answer to how to make it stable is never update then you're not working on a stable technology.
I didn't say "never update", I said that if you don't need the new features then don't upgrade. If you do need the new features then I don't understand what the problem is.
> Stable is being able to set up unattended upgrades on Ubuntu fearlessly.
lol what? I've never had a system survive an Ubuntu upgrade without breaking something.
Point is many of these libraries don't just let you get latest without rewriting some of your code. Multiple that by 10-20 and you are in for a real treat.
> Point is many of these libraries don't just let you get latest without rewriting some of your code.
True of every software platform in existence.
On the scale of upgrade complexity, react is a walk in the park compared to e.g. everything in the android and ios world, or e.g. any application written for a desktop platform. Ever tried upgrading a C++ app? It's a nightmare beyond anything I've ever faced in my career.
I've never worked with Rust in a professional environment, but I've been a big fan of it for my personal projects for some years now, however, the introduction of async was a massive disruption to the entire ecosystem.
In my opinion, complaining about JS complexity in particular reflects ignorance of the wider software world.
Well yeah but Rust isn't a boring technology and C++ has
its own reasons for being difficult. The goto examples of boring are C (and Objective-C), Java, Perl 5, PHP, Vanilla JS (the browser itself is remarkably stable), Rails, Django. Just a who's who of ecosystems people don't want to program in.
Perl code doesn't work today just as well as it didn't work 20 years ago.
Yep patching Ubuntu is so stable it's fully automatic and upgrading to the latest Ubuntu is 1-2 days work. Getting to the latest on our front end is a project.
I don't know in what company you work at. But you can't have outdated libraries in production forever. Vulnerabilities happen. Stable does not equate outdated. Look at .Net. You can pick a codebase from 2014 and make your way around easily. It is like home. Similarly, your 2014 dev could jump into a time machine into 2024 and work with .Net Core easily. Also, 2014 codebase can keep getting the latest security patches without having to rewrite the codebase.
That's not the case with React or most of the js frameworks
.net??? I worked with .net for about 10 years and over multiple versions of .net and .net core, the amount of time we spent facilitating upgrades was much more than I ever spent on upgrading a react app. In fact, at my last .net job I was hired specifically to transition the company's platform from .net to .net core. There was so much work involved that they literally created a role for it.
> I was hired specifically to transition the company's platform from .net to .net core
I can see this being the case if the codebase wasn't in a good state which is a problem of its own. But with proper separation layers. There is not much you have to update in a net framework 472 library project to move it to a net core library project which should contain most of your logic and be tech agnostic anyway. Most of the work is likely to be in the technology dependent projects (web projects and that kind). The common language features remain virtually unchanged. In a front-end project this is much harder, as that kind of abstraction is much harder to come across as the language and technology are tightly coupled.
In an ideal world, your component logic is tech agnostic and should work unchanged in React, Angular, Vue, etc. But in real life, you write your logic using the relevant tech and then when that tech breaks some keyword or how to do x, your app breaks in 50 components and you have to go and make the change manually in all those 50 components.
It's easier to exercise fun, creativity, and new
ideas on such a platform because there aren't any
sharp edges and you can start pushing a technology.
Yeah. I don't interpret "use boring tech" as "literally don't use anything newer than 10 years old" or whatever.
You absolutely can/should/must use more exciting things if they are relevant to whatever unique problem you're trying to solve.
But everything else possible in your stack (particularly foundational elements) should be as boring as possible - i.e. unless you are specifically innovating in the area of RDBMS systems, you should be choosing a "boring" existing RDBMS.
To reduce "the boring revolution" to a React aversion is a bit dismissive.
"Boring" is malleable. If your team is full of React experts, React is boring.
If your team is full of backend-oriented engineers who rarely deal with the frontend, React is much less boring.
"Boring" is also not binary; it is continuous. The mix of technologies in your stack culminate in some arbitrary measure of boringness. This measure can also be thought of as the degree to which teams choose cutting/bleeding edge technologies. If the mix is mostly cutting/bleeding edge, it's very likely that production support is not boring, and problems operating the stack in production are not boring.
Choosing boring technology is also not a panacea that solves every team's problems. Although doing so likely mitigates them.
There are plenty of "newer" technologies that closely mimic more "boring" tech too. For example, Svelte feels a lot like writing vanilla HTML and JS, Supabase is all built entirely on PostGRES instead of a shiny, noSQL database.
Before modern web dev practices my team was notified a dev had started the wipe/reinstall OS process on a 1,000 bare metal lab desktops and servers due to a bug in their deployment script
From prior experience I knew only the OS partition had been nuked so far not old data. So my team collected the disks, closed a campus computer, connected disks via USB adapters, shorted the two pins on ATX power supplies to provide power to the disks and booted from the lab machines it was all connected to into a live USB Linux system where we ran recovery tools on ~600-700 SATA disks (some servers had been snapshotted to backup and didn’t need the effort)
That was the most interesting day in tech I’ve ever worked and I started my career designing add on boards for a company that sold to Nortel before they imploded; my output literally shipped late 90s-early 00s internet users packets around
Noodling if else and for loops day in and day around some biz context I don’t care about but some Harvard grad has seed money to advertise is the lamest; the 2010s, an entire decade if my career and since, has been really boring.
That sounds like an architecture issue. In 10 years I’ve used React for a wide variety of projects from digital publishing tools to realtime medical dashboards to WebRTC-based videoconferencing apps with 3D graphics. I’ve never seen a build require anything like that much horsepower or time.
If the essay had come out in 2008, Ruby on Rails would’ve been the “exciting” thing it was calling out. But instead, Ruby on Rails is generally considered in the “boring” camp, while things that came out closer to the essay’s publication like React are in a state of “Permanent Shiny”.
All of which blinds people to the fact that the web space has in fact settled down years ago and is not in the state of immense flux that actually was happening in 2015.