The only way to win is not to play, but the best way to minimize the damage if you can't avoid it entirely is this: escape out of the framework code into 'normal' code as fast as possible. The framework only calls glue code. All of your real logic and investment is in code that uses Plain Old <Language> data structures and that's it. That'll keep you sane.

It also is a great way to pop out bits of your logic into separate little programs where you can do things like write utilities that let you reason about the bigger system in bite sized chunks, or even to use benchmarking tools to do A/B testing of different implementation details of one subsystem, without the noise of the rest of the system getting in the way.

They end up with code like

  class Command
    def initialize(a)
      @a = a
    end
    def run
      s = Service.new(@a)
      s.do_something
      s.do_something_else
    end
  end
  Command.new("a").run

Most OTP projects can benefit from a RabbitMQ/kafka message channel, as some jobs may end up visiting several languages, CPU and GPU architectures. =)

My very hot take is that we will start referring to everyone who bought first editions of the Design Patterns book as the Lost Generation, because we have completely misinterpreted Alexander's work, as it could apply to software.

One may also find it interesting how Elixir/Phoenix-framework uses the OTP to greatly simplify implementation. =)

Switching languages obviously requires a rewrite. But you aren't also rewriting the framework integration too. Some languages have work-alike frameworks, but they aren't ever exactly the same behavior and semantics. There are always subtle but important differences.

I guess my point was that while it is sometimes necessary to pipe messages though multiple languages & platforms under special circumstances (see BSON over AMQP post above alluding to decomposing multiple hardware-dependent programs/codecs into a standardized cluster API.) In general, it is cleaner to have a simple distributed framework that hides the fact it is _not_ a monolith from _most_ developers.

We can agree to disagree on this matter, as everyone's use-case differs. =)

Architecture is much bigger than making sure the doors open the correct direction.

I had seen someone decided to wrap a simple pixi.js project with a whole mvp framework and tons of command / facade / proxy patterns to make it like a oop program. So I hate it.

I heard it's wrote by a c# guy picked up for the project because no one had time to do so I could probably understand why. But, damn. It's so painful to read.

The chances of Spring Framework, React or .Net being deprecated are zero to none. Even if they are sunset, there will be a) years of warning b) a cottage industry of open-source options.

Or you can hamper your project by abstracting EVERYTHING in your software to be 100% free to switch any library or framework at a moment's notice with minimal work. In essence building a meta-framework yourself :)

MS told me it was for always and forever!

Cries

It was technically better than Flash in every way, but the Internet was in its "Micro$oft bad!" -mode at the time and shunned everything they made. They also took a bit too long to provide proper clients for OS X and Linux.

Silverlight itself was actually relatively good at the time, but HTML5 media tag standardization made it along with Real-player, QuickTime, and Flash effectively obsolete for their primary use-cases.

Or you just carry on using the deprecated version. It doesn't stop working.

If your team is sufficiently skilled you fork the framework and carry on developing it yourself.

There's lots of options other than just giving up.

Besides, how often is a framework deprecated? It hardly ever happens. This line of reasoning is the same as the old "We'd better use a database abstraction just in case we change database!", something that no one has ever done in the history of IT projects (this is hyperbole on my part, but it's pretty much true.)

So many of the decisions you make when needing to move quickly at the start of your growth curve, are the ones that slowly kill you after market saturation.

Being able to swap out a db would be nice.

You don't need a wrapper that understands the APIs for different databases when you're only using one database. What you need is to think about how you write your code.

Give it some thought and properly encapsulate your core business logic and you won't have that much trouble migrating to another framework or a custom solution if need be (especially easy if your current framework has good documentation, which Django definitely does).

Only small shops get hit hard when things go wrong.