On the one hand, the scenarios described by "vertical integration" sound like a paradise to use.
On the other hand, in real life it's going to far too complex, far too brittle, and ultimately unworkable to maintain.
Tool boundaries exist for a good reason -- so you can swap tools in and out easily, and the toolmakers can stay sane by focusing on doing one thing well. With vertical integration, nothing is swappable, because you can only use tools built for your specific architecture. You become isolated from the broader ecosystem, and locked into one.
And then, that architecture is going to be this bespoke thing that becomes so enormously complex and hard to work with that everybody just gives up. Because every time somebody wants to change a tool, it turns out to be 10x more work to figure out how to make the change work with this vertically-integrated architecture.
Vertical integration isn't the "only thing that matters". Flexibility and swappability matter too, as does saving time and money by following common industry technologies and not inventing a bunch of custom architecture if it's not your core product and not absolutely necessary.
I am now thoroughly convinced that software engineers, if there is currently no snake whispering in their ear to throw away the paradise garden they're been handed on high, will find a way to do it anyway. Coders will, to the last, prefer self-inflicted misery over the heaven they've been gifted for free.
And if you don't believe me, let me tell you we already have a fully-vertically integrated tool stack, a whole family of them. It's called Smalltalk, it's been around since the 70s, and modern variants of course exist. You can build stuff in it today, and thoroughly enjoy your computing life as a result.
The second you turn your head though, your fellow teammates will conspire to replatform onto Go or Rust or NodeJS or GitHub Actions and make everything miserable again.
Don't buy the nonsense that vertical integration is hard. It's not. You just hire really sharp folks, get them excited about the idea, and they do all the hard integration work, then you release it to the community and let them build on it. Rails was like this back in the 2010s, there was this golden age where everything just worked. Then all of a sudden javascript took over the web world like cancer and the web stopped being fun.
It's not that it's hard, what it is is brittle. A vertically-integrated stack, by its very nature, cannot survive forces that jostle it in the horizontal direction. And coders are too afraid of falling behind that they end up fetishizing any new idea that comes along, no matter how daft. Javascript on the server?!?! Your solution to js's, let's call them problems, is gradual typing? That snake's never gonna run out of ears to whisper in, lemme tell ya.
Integrated toolsets can, have, and are still being done. You can use them now. But you don't want it. Even if you do, nobody you work with will trust it or keep it after you leave. And so companies have no motive anymore to sell them to you. Microsoft themselves stopped trying after 2019.
Is this not exactly the whole problem, though? Fault tolerance.
My chisel doesn't need to integrate with my hand plane which doesn't need to integrate with my band saw. One of them breaking doesn't break the others.
This is why experienced developers gravitate toward powerful tools that they trust deeply but that have extremely hard boundaries. It's why we're still stuck with ASCII text as the primary artifact for coding, for example. The moment we try to move off of that a single fault can bring down the whole house of cards.
ASCII is perhaps a poor example, all modern tooling is UTF-8 capable.
The development experience is almost always really smooth and there are more and more tools to further smoothen that experience every day.
There are definitely better tools out there but given how the web ecosystem functions, it could be much worse.
The deficiency in web standards that SPA frameworks were invented to resolve have all been fixed, there's nothing they offer anymore that you can't do without them. But they hang over the neck of the web world like an albatross.
Curious how would you use use Smalltalk in replace of GitHub Actions assuming you need a GitHub integrated CI runner?
There is a slight amount of NIH you have to fight, but for the most part, if a process is truly seamless, that NIH will get pushed to a different part of the stack that's more front of mind.
The real issue is that you're trivializing needs that live outside your purview and because of that you can't fathom why a js dev who wants a server to do something would want js on the server.
This kind of rigid, singular view of operational workflows based on precomposed automations not only constantly break but also inevitably introduce huge inefficiences.
I posted a longer comment on lobste.rs: https://lobste.rs/s/azpsqe/vertical_integration_is_only_thin...
"Vertical integration" in my experience has just been turning a group of simple tools into a complex monolith that no one understands and is extremely difficult to debug
But, to borrow a line from Warren VanderBurgh's ‘Children of the Magenta’: “(in the industry) we created you like this.”
Another key flaw of precomposed automations for rigidly-defined work-flows is that they usually exist in precisely the circumstances that give rise to their own subversion. (I might even go so far as to suggest that the circumstances are the cause of both the mistake and the maladaptive behaviours that address the mistake…)
Ultimately, deep stacks of tightly-integrated components forming a precomposed automation that enacts some work-flow—“vertical integration” as the post frames it—is obvious enough that it seems every big company tries it… only to fail in basically the same ways every time.
