Hacker News Reader

Comment by Joel_Mckay | Hacker News Reader

"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

View on HN

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.

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

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.

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.

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

Large firms have the resources to overhaul infrastructure, and even with a project failure rate of 54% often manage to complete migrations.

Only small shops get hit hard when things go wrong.

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.

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.

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

I like your garden path sentence.

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 :)

Just like with Silverlight. .net 1.0, wcf, .net remoting, app domains…

MS told me it was for always and forever!

Cries

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.

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.

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.

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

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.

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

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.

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

I’ve read the original and was underwhelmed from a software epiphany standpoint. Design patterns are just names for deliberate design decisions, so you can communicate them to others who can then deliberately make those decisions themselves. Half the industry still seems to think the GoF book is about C++ not having first class functions.

The problem is that they are milquetoast. They are “design decisions” in the same way that white space is technically code style but really distracts from the real elements of style like structure and meaning (don’t create three meanings for the same word, for example).

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

Well, there are many collections of patterns, GoF doesn't claim to be exhaustive. Enterprise Integration Patterns is more high level, for example. But for everyone who hand waves away something like the Strategy pattern as trivial, I have to work with a dozen libraries which accept a massive dictionary of static options to configure their behaviour instead of allowing me to choose an arbitrary, dynamic policy at runtime. I don't think that's a conscious design decision on behalf of most API developers. I suspect it's because the industry largely received the original GoF book as a bunch of cut and pasteable code and later rejected it as symptomatic of Java-esque OO excess. We could instead have received it as a network of signposts telling us what's possible, when and why. Not earth-shattering stuff (neither is Christopher Alexander's original) but useful nonetheless.

I think, wrapping an api or a few methods is okay. But wrapping a whole platform/framework is just wtf.

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.

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.

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

Did you mean Agile?

Depends how much you hate a project, but one could go full polyglot for each team member... =)

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.

Reply on news.ycombinator.com