6 ms·

If library is deprecated. You replace the library. If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because

If library is deprecated. You replace the library. If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. That's the difference. If you make abstract to make it suitable to port to another framework. Then you are writing yet another framework on the top of a framework. In my opinion, it's even worse.

hinkley 4y ago
In my experience, I lack the talent for truly graphic swearing that would be required to adequately communicate just how much worse it is. Wrapping frameworks is like throwing water on a grease fire. Or maybe like someone else throwing water on the grease fire while you're standing inside the splash radius. 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.
- pushedx 4y ago
  I like your garden path sentence.
- pmontra 4y ago
  On this line of development a customer of mine has a lot of small/medium Rails applications with very little in models and controllers and almost all of it in service and command classes. They use commands for code that does only one big complicated thing and services for bags of simple methods about one resource. 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 which is funny when I think that in Elixir I would write Command.run("a") and there isn't a good reason for using OO in this case, except that Ruby is very object oriented. Anyway, their code is quite separated from Rails except for the calls to ActiveRecord, but that could be ActiveRecord without Rails.
  - Joel_Mckay 4y ago
    Probably a different problem domain, but I like simple BSON message objects over AMQP into rabbitMQ to enforce a producer/consumer linear job queue from a distributed platform... where transactional ordering can on occasion be more important than the latency hit. Most OTP projects can benefit from a RabbitMQ/kafka message channel, as some jobs may end up visiting several languages, CPU and GPU architectures. =)
Joel_Mckay 4y ago
I find it highly improbable you have never encountered a Facade pattern. ;)
- hinkley 4y ago
  One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference. 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.
  - Joel_Mckay 4y ago
    I usually recommend "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" (2019 James Edward Gray, II, Bruce A. Tate) One may also find it interesting how Elixir/Phoenix-framework uses the OTP to greatly simplify implementation. =)
    - hinkley 4y ago
      I think the missed or perhaps unspoken observation in this thread is that if the language provides it, and you're using it, you're tying yourself to the language, which tends to last a lot longer than frameworks. 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.
      - Joel_Mckay 4y ago
        A clean pattern does not emerge naturally with a polyglot stack, as multiple languages with many library dependencies only lead to maintenance issues, duplicated code, and kludges. 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. =)
theshrike79 4y ago
You can affect this by picking the framework properly. 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 :)
- Attrecomet 4y ago
  Or, as TFA suggests, you separate your concerns with a framework just as you'd hopefully do with other elements of software development. While TFA starts out with strong language against frameworks (as defined in TFA), the conclusion is pretty sound, IMO.
- lll-o-lll 4y ago
  Just like with Silverlight. .net 1.0, wcf, .net remoting, app domains… MS told me it was for always and forever! Cries
  - theshrike79 4y ago
    Silverlight was around for 12 years (9/2007 - 1/2019). Not exactly a shooting star. 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.
    - Joel_Mckay 4y ago
      If I recall it was mostly the DRM and codec-licensing that strangled most projects. 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.
onion2k 4y ago
If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. 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.)
- lll-o-lll 4y ago
  Yeah but that sucks though. Imagine being a large company with a multi-million dollar annual spend that could be entirely free if only Postgres had been a bit more mature back when you started. 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.
  - onion2k 4y ago
    That's not true though. The answer isn't to use a database abstraction, but to architect your software to make changes straightforward. If you design your code properly (push database queries through a standard set of APIs that are reused everywhere, put queries in their own functions or classes, never put queries in components, etc) then moving to a different database is a relatively simple matter of updating your DB layer. A database abstraction makes people think "I can change my database just by changing the db adapter, so why think about my DB code at all!" That is the problem. 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.
    - throwaway290 4y ago
      Exactly. It seemed to me as if the author originally thought with a framework they don't ever have to think about the architecture, but of course it's still possible to shoot yourself in the foot and end up with a tangled unrefactorable mess. The article channels misplaced disappointment. 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).

hinkley 4y ago

In my experience, I lack the talent for truly graphic swearing that would be required to adequately communicate just how much worse it is. Wrapping frameworks is like throwing water on a grease fire. Or maybe like someone else throwing water on the grease fire while you're standing inside the splash radius. 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.

pushedx 4y ago
I like your garden path sentence.
pmontra 4y ago
On this line of development a customer of mine has a lot of small/medium Rails applications with very little in models and controllers and almost all of it in service and command classes. They use commands for code that does only one big complicated thing and services for bags of simple methods about one resource. 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 which is funny when I think that in Elixir I would write Command.run("a") and there isn't a good reason for using OO in this case, except that Ruby is very object oriented. Anyway, their code is quite separated from Rails except for the calls to ActiveRecord, but that could be ActiveRecord without Rails.
- Joel_Mckay 4y ago
  Probably a different problem domain, but I like simple BSON message objects over AMQP into rabbitMQ to enforce a producer/consumer linear job queue from a distributed platform... where transactional ordering can on occasion be more important than the latency hit. Most OTP projects can benefit from a RabbitMQ/kafka message channel, as some jobs may end up visiting several languages, CPU and GPU architectures. =)

Joel_Mckay 4y ago

I find it highly improbable you have never encountered a Facade pattern. ;)

hinkley 4y ago
One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference. 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.
- Joel_Mckay 4y ago
  I usually recommend "Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" (2019 James Edward Gray, II, Bruce A. Tate) One may also find it interesting how Elixir/Phoenix-framework uses the OTP to greatly simplify implementation. =)
  - hinkley 4y ago
    I think the missed or perhaps unspoken observation in this thread is that if the language provides it, and you're using it, you're tying yourself to the language, which tends to last a lot longer than frameworks. 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.
    - Joel_Mckay 4y ago
      A clean pattern does not emerge naturally with a polyglot stack, as multiple languages with many library dependencies only lead to maintenance issues, duplicated code, and kludges. 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. =)

theshrike79 4y ago

You can affect this by picking the framework properly. 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 :)

Attrecomet 4y ago
Or, as TFA suggests, you separate your concerns with a framework just as you'd hopefully do with other elements of software development. While TFA starts out with strong language against frameworks (as defined in TFA), the conclusion is pretty sound, IMO.
lll-o-lll 4y ago
Just like with Silverlight. .net 1.0, wcf, .net remoting, app domains… MS told me it was for always and forever! Cries
- theshrike79 4y ago
  Silverlight was around for 12 years (9/2007 - 1/2019). Not exactly a shooting star. 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.
  - Joel_Mckay 4y ago
    If I recall it was mostly the DRM and codec-licensing that strangled most projects. 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.

onion2k 4y ago

If framework is deprecated. You give up the project or rewrite 'everything' to use another framework because essentially your project is build on it. 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.)

lll-o-lll 4y ago
Yeah but that sucks though. Imagine being a large company with a multi-million dollar annual spend that could be entirely free if only Postgres had been a bit more mature back when you started. 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.
- onion2k 4y ago
  That's not true though. The answer isn't to use a database abstraction, but to architect your software to make changes straightforward. If you design your code properly (push database queries through a standard set of APIs that are reused everywhere, put queries in their own functions or classes, never put queries in components, etc) then moving to a different database is a relatively simple matter of updating your DB layer. A database abstraction makes people think "I can change my database just by changing the db adapter, so why think about my DB code at all!" That is the problem. 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.
  - throwaway290 4y ago
    Exactly. It seemed to me as if the author originally thought with a framework they don't ever have to think about the architecture, but of course it's still possible to shoot yourself in the foot and end up with a tangled unrefactorable mess. The article channels misplaced disappointment. 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).