111–119 of 119 posts
Earlier quoted context omitted.
> A library is something you call. > A framework is some kind of application scaffolding that normally calls you. There is no real distinction between these two.
There is: https://en.wikipedia.org/wiki/Inversion_of_control
> Introduce new concepts that doesn't exist in the original stack That is also true for "macro" frameworks. > Wraps around the company/org-shared tech stack or framework That is often also true for "macro" frameworks. > Creators claim that the framework "magically" solves many problems, and push more people to use it That is often also true for "macro" frameworks. --- It is not clear from the reader's perspective wha…
> Introduce new concepts that doesn't exist in the original stack That is also true for "macro" frameworks. > Wraps around the company/org-shared tech stack or framework That is often also true for "macro" frameworks. > Creators claim that the framework "magically" solves many problems, and push more people to use it That is often also true for "macro" frameworks. --- It is not clear from the reader's perspective wha…
Maybe I should have written it more clearly, but the mini-frameworks I described in the article are not makeshift -- instead they're permanent and stay forever, expanding as time goes, until being replaced by something else.
However, for a beginner, specially if said beginner never worked in a larger company with resources to produce an internal framework, they might think you're referring to Flask or something like that (btw Flask-style microframework use can go very wrong but it's another completely different issue).
That's why I'm being nitpicky. The people who'll get the post are likely already experienced enough to evaluate those frameworks themselves.
This is one of the rare HN thinkpieces that's actually correct. You cannot remove essential complexity. You can shuffle it around, but it never goes away; you will have to deal with it. You can try to hand it off to someone else, like another team. But that actually makes it worse, because there's still some critical piece you depend on that's hidden behind the silo walls. Rather than trying to hide things to "ease a…
> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…
> Is it an argument against wrapping frameworks, or wrapping libraries? I think English is not OP's first language, framework here basically means wrappers.
Earlier quoted context omitted.
these things are hard, maybe impossible to define. For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.
React is 100% framework. They even bring their own DSL. It's absurd to call React library. Library is something that can be pulled off project and replaced with something else. There's no non-trivial project where replacing React with anything would be possible. Every React web app is built around React.
Most Spring (+Boot) projects have been far more painful to work with - numerous abstractions and deep and complex relationships between them just to support every technology and integration under the sun. Hard to work with, hard to debug (especially with proxies and how the DI works, alongside the nonsensical rules about how @Transactional works, e.g. how it doesn't if you call a transactional method from within the same component/service), sometimes performs like shit or leaks memory and migrations between major versions are a pain. We just spent multiple months migrating a project from an old Spring version to a more recent version of Spring Boot. It's a pain.
Compare that to Dropwizard: it is fairly stable and most updates are maintenance related. It uses a bunch of idiomatic packages from the ecosystem: Jetty, Jersey, Jackson, Logback, Hibernate/JDBI3, supports Liquibase or Flyway, there's also validation and views or whatever you want, but none of it is pushed down your throat. The docs are practical and more manageable just because it does LESS overall, the code is simpler and there are far fewer surprises. And because the logic is mostly just Java and there's no castle-in-the-sky bullshit with annotations, if you want to swap out HK2 for Dagger (if you still want DI), you can - which I think is good because Dagger also does a lot at compile time and avoids the whole Spring runtime injection can of worms altogether.
The size of a framework doesn't instantly make it good or bad, but oftentimes the bigger ones will be more difficult to reason about and sometimes the amount of abstractions gets out of hand.
Having been around in the industry for a while I'm seeing abstractions being misused all the time. Being guilty of it myself also when I was younger. For me, the only purpose of an abstraction is to reduce complexity, but often times I'm seeing it being used to reduce repetitiveness, which often times replaces well understood more verbose code with less understood less verbose and less flexible alternative. For me, a…
Everywhere I've worked that uses DynamoDB, someone will invariably write a bunch of abstraction functions that become very annoying to debug, to add functionality, and can break an entire app if changed. DynamoDB is admittedly very verbose, but it's almost always worth it to keep your CRUD operations written within the SDK rather than as an abstraction.
Earlier quoted context omitted.
If you look above the unorthodox library/framework distinction, I think the criticism is about birthing new (inadvertently leaky) abstraction layers with new semantics to capture the specifics of the domain. Often with either esoteric words attached to supposedly novel patterns, and/or unconventional usage of existing terminology. The promise is to simplify and unify things but as noted, such efforts often have the o…
Yeah had so many discussion with senior developers in my life to argue for just keeping things simple, but my god they love abstractions. They are clearly always very smart and understand the code base well. Maybe it’s their intelligence wanting to be more utilised or maybe they are bored and trying to over engineer simple problems