everytime i run npm install i feel i'm about to embark on a bunch of side missions
Hey one import and you can have 1000+ dependencies :)
The Problem with Frameworks
51–60 of 111 posts
Re: The Problem with Frameworks
#52Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…
> In a sense, you are often assembling your own framework
No you aren't. This is a thought-terminating cliche. I think what people mean by this is you are assembling your own architecture. Frameworks often come bundled with an architecture, and that is a core value proposition for a lot of folks.
But you're not building a reusable tool to scaffold other apps with, you're building a bespoke architecture for a single app.
Mobile apps, for instance, have no "framework." iOS and Android require you to implement certain classes to participate in the app lifecycle, but it is not at all the same idea of "framework" as Rails, which really pushes you to use DHH's Favorite Things over everything else.
Re: The Problem with Frameworks
#53Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…
I'd like to add this: - There's the possibility you will do something very wrong if you roll your own from libraries For example, HTTP serving frameworks are popular because the HTTP protocol is complicated , not to mention best practices around security that have evolved over decades and are still evolving, and the (ideal framework) will handle a lot of high-level protocol logic (do you really want to parse mimetype…
Using the author's definition (necessary when comparing the two) of "I consider a piece of software development technology to be a framework if it dictates the way all or most aspects of an application built using it will be programmed and how the code will be organized, while a library covers only a specific aspect of the system and is usually less opinionated about architecture.", I'm not sure your criticism really holds; Rails is a framework, but Sinatra is a library - both serve HTTP.
Even then, a library or framework can choose to split up functionality and allow you to include it or not based on your needs; even if it doesn't, there's a high likelihood that problems that aren't unique to you already have a default solution (i.e., HTTP serving frameworks/libraries that make CORS, CSRF protections, and other browser only considerations a piece of middleware that is trivial to include if you want it. An example being Spring, where I believe the only place CSRF tokens are supported is in Spring Security).
Re: The Problem with Frameworks
#54Once you adhere to any API, moving away from it requires refactoring.
Good luck removing Lodash from your code, unless you're replacing it with an equivalent Underscore.
Re: The Problem with Frameworks
#55Ok, I'll take the counterpoint and offer a few challenges I've seen with libraries. In a sense, you are often assembling your own framework. No judgement there--just good to know what you are getting into. - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered un…
> In a sense, you are often assembling your own framework No you aren't. This is a thought-terminating cliche. I think what people mean by this is you are assembling your own architecture . Frameworks often come bundled with an architecture, and that is a core value proposition for a lot of folks. But you're not building a reusable tool to scaffold other apps with, you're building a bespoke architecture for a single…
Ok, that's fair. Assembling your own architecture. But I feel the same risks and caveats apply.
Re: The Problem with Frameworks
#56Earlier quoted context omitted.
Ideally you would choose dependencies with minimal dependencies of their own ( very few if any common dependencies), so you have a manageable number of versions and near complete freedom of choice of those versions.
And ideally, you'll wrap them too. In what is often called "Anti-Corruption-Layers". Often very simple Proxies or Adapters. Consequentially, this makes testing (in isolation) far easier too. Which also means you'll choose libraries that are decoupled by design because the others are really hard to write such wrappers for.
Sometimes quite useful, yes, though I would strongly emphasize that the goal is not to wrap the entire API of the dependency -- that is pure busywork and doesn't stave off "corruption". Just the (consciously quite minimal) parts you actually need.
Re: The Problem with Frameworks
#57Earlier quoted context omitted.
I'd like to add this: - There's the possibility you will do something very wrong if you roll your own from libraries For example, HTTP serving frameworks are popular because the HTTP protocol is complicated , not to mention best practices around security that have evolved over decades and are still evolving, and the (ideal framework) will handle a lot of high-level protocol logic (do you really want to parse mimetype…
Using the author's definition (necessary when comparing the two) of "I consider a piece of software development technology to be a framework if it dictates the way all or most aspects of an application built using it will be programmed and how the code will be organized, while a library covers only a specific aspect of the system and is usually less opinionated about architecture.", I'm not sure your criticism really…
Sinatra is a framework, it's very light in that it doesn't dictate where you put your files in directories (but neither does, say Phoenix, which is definitely a framework). In sinatra, the system calls into the functions you write and you have no choice but to organize your endpoints the way that sinatra wants you to, even if some things are light relative to rails.
Re: The Problem with Frameworks
#58Earlier quoted context omitted.
"But we'd like a quick chat to understand why the last 20% took so long" — Also Management
I love the phrase “quick chat” because it’s rarely ever actually quick. If it was actually quick, they’d just ask it. Over time I’ve learned that the correct response is, approximately, “Sorry, I’m in the middle of [important work], please book 30 minutes for us and [stakeholders] to discuss it.” Gives me time to prepare so that I’m not caught off guard. And to bring backup if I think I need it.
I actually had a quick chat with my teammate today. 5 minutes (well we chatted about dumb shit like changing oil on our cars for another 5). Also it wasn't bad, I was checking in to make sure his career objectives were being looked after (he just onboarded a few weeks ago).
Re: The Problem with Frameworks
#59Earlier quoted context omitted.
Using the author's definition (necessary when comparing the two) of "I consider a piece of software development technology to be a framework if it dictates the way all or most aspects of an application built using it will be programmed and how the code will be organized, while a library covers only a specific aspect of the system and is usually less opinionated about architecture.", I'm not sure your criticism really…
Sinatra is a framework, it's very light in that it doesn't dictate where you put your files in directories (but neither does, say Phoenix, which is definitely a framework). In sinatra, the system calls into the functions you write and you have no choice but to organize your endpoints the way that sinatra wants you to , even if some things are light relative to rails.
Did...did you miss my callout to the author's definition? Per that, Sinatra is a library. The structure of endpoints is no different than function calls; where they go is not proscribed.
I'm not saying that's a good definition.
Re: The Problem with Frameworks
#60I keep saying it again and again: Dependencies strangle dev teams to death. A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. And I'll add that a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers around technologies that work…
I've been struggling with this for years in the front-end / JS space, to the point where I just want out and live happily in my reasonable Go dependency management / aversion space. It's a convoluted mess. A while ago I made the move to migrate to Yarn 2 / 3, because it uses less disk resources (dependencies are in .zip files). But because most tools still expect a node_modules folder, it required a lot of workaround…
FWIW my experience is that Yarn 2/3 work great, as long as you stick with the `node_modules` linker (which works the same way Yarn 1 and NPM always have, by extracting all packages to disk) instead of the "Plug 'n Play" option (which keeps all packages zipped up, and requires that Yarn own all filesystem access to decompress files on the fly).