4 ms·
Indeed. This excerpt from that paragraph is a good thesis for the essay as a whole: > The point is not to never use frameworks, but to isolate them. To call th
by akprasad 4y ago
Indeed. This excerpt from that paragraph is a good thesis for the essay as a whole:
> The point is not to never use frameworks, but to isolate them. To call them from a single place. One that we own. That we are responsible for and that we limit very much in what it can touch.
- OJFord 4y agoI think an easy example of that is what frustrates me the most in JS-land: everything has it's own CLI. Why? Quick start: `npm run nouveau-framework create@app 365 --with-voodoo`. I don't want that. I want (maybe, at my discretion!) to add your framework as a dependency, read some API docs, and just start plugging it in where necessary. But they all focus on greenfield projects, they all think the whole project is about/driven by them.
- wjdp 4y agoThis does frustrate! On more than one occasion I've spun up a create-x-app project just to see what an implementation looks like to then do it manually inside an existing project. Then again when I'm greenfielding having the option to be up and running in 2 minutes is rather nice.
- arinlen 4y ago> > The point is not to never use frameworks, but to isolate them. To call them from a single place. One that we own. That we are responsible for and that we limit very much in what it can touch. I had the misfortune of working on a project which abstracted a framework. It was awful. It ended up being an ad-hoc component that was half-façade, half-adapter that was inadvertently tightly-coupled with the framework. It added an awful lot of complexity with the only tradeoff being theoretically being able to abstract away the underlying framework. It was not worth it. It created far more problems than those that it solved.