5 ms·

"Frameworks are designed to take your project hostage" Wow, that is some enterprise level FUD, and with zero citations to back up that assertion. While one

"Frameworks are designed to take your project hostage" Wow, that is some enterprise level FUD, and with zero citations to back up that assertion. While one could possibly see 3rd party external dependencies pose a variable cost, service risk, or security issue... a standalone/maintainable site should not have 25 domains for every lame js widget a designer thought looked cool. Those who do not use a good framework, are simply doomed to rewrite a buggier implementation. https://www.youtube.com/watch?v=wvVPdyYeaQU https://www.youtube.com/watch?v=wvVPdyYeaQU

smeagull 4y ago
You don't need a framework. You can control execution and use libraries. Once you use a framework changing back is hard. Removing a library on the other hand is easy. Because for libraries you control execution, and for frameworks you have to fuck your code so it will obey the requirements of that framework.
- Joel_Mckay 4y ago
  Easier still, Spiral-development doesn't have to plan anything except the next feature... works right up to the point it implodes. Thank you, I will see myself out... ;)
  - oriolid 4y ago
    Did you mean Agile?
    - Joel_Mckay 4y ago
      Depends how much you hate a project, but one could go full polyglot for each team member... =)
mmis1000 4y ago
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. =)
jgrpf 4y ago
With framework maintainers providing paid support, extending services or an ecosystem with commercial components it somewhat makes sense even if not outright obvious or intentional.

smeagull 4y ago

You don't need a framework. You can control execution and use libraries. Once you use a framework changing back is hard. Removing a library on the other hand is easy. Because for libraries you control execution, and for frameworks you have to fuck your code so it will obey the requirements of that framework.

Joel_Mckay 4y ago
Easier still, Spiral-development doesn't have to plan anything except the next feature... works right up to the point it implodes. Thank you, I will see myself out... ;)
- oriolid 4y ago
  Did you mean Agile?
  - Joel_Mckay 4y ago
    Depends how much you hate a project, but one could go full polyglot for each team member... =)

mmis1000 4y ago

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. =)

jgrpf 4y ago

With framework maintainers providing paid support, extending services or an ecosystem with commercial components it somewhat makes sense even if not outright obvious or intentional.