3 ms·

If you're doing it for yourself and nobody will ever have to maintain your code? Sure, knock yourself out! If you have a large organization that can absorb the

If you're doing it for yourself and nobody will ever have to maintain your code? Sure, knock yourself out! If you have a large organization that can absorb the cost of maintaining the framework long after you have gone, and can ensure the entire company is invested in this framework? Sure, someone will hate you in five years because they will hate your opinions, but you won't sink a company. But if it's in between, you are doing a disservice to whoever is paying you. You won't document it like a great framework. You'll be fine with a hack or need to skimp on testing during a deadline, and three years later people will be stuck around decisions that seemed right at the time. I have seen how bad of a drag this can be up close.

duxup 6y ago
There was an HN submission that was something like: "Make libraries, not frameworks." from some poor soul who was unweaving the magic of some framework someone long gone left behind that nobody understands. It pretty much echoes your statement that unless you know you and others will be documenting and maintaining (and that is a big commitment), your probably just doing everyone a disservice long term.
fimdomeio 6y ago
I would just add an in between. If the project is small enough that a fellow coder can understand what's happening by spending a day or two looking at the code it's also ok. Other than that fully agree, the power of documentation stackoverflow and forums can be easily overlooked but is incredibly valuable. This even if we all feel a little miserable every time the framework fails at any of the magic things it does and we just patch it up and end up never fully understanding the root cause.
samvher 6y ago
I feel like mainly this article is about building generic tools as you are developing your application. I think the word "framework" is used liberally - base classes and higher order functions are classified as tiny frameworks in the article. In some cases I think it's a tricky call. I'm currently working on a "framework" and am worried about all the issues that you mention. The reason I'm still building a framework is that as far as I can tell there is really no existing framework for the task at hand, and we do need the economies of reusable code (consistency across deployments & avoidance of double work). I hope the organization is large enough to absorb this and keep it going down the road, and am aiming to make it open source in the hope that a community can form around it as well. Fingers crossed, I guess.
- ebiester 6y ago
  There are all sorts of nuance that are not captured in a short post. In 2012, I built a micro front-end framework for front end because I wanted something closer to what turbolinks is today, and I am sure people have cursed my name in years since. (Of course, the alternatives were things like knockout and backbone, and I had issues with those and my use case.) So, to be fair, many of us have done it. The best case is that you can open source it and everyone can benefit from your work.

duxup 6y ago

There was an HN submission that was something like: "Make libraries, not frameworks." from some poor soul who was unweaving the magic of some framework someone long gone left behind that nobody understands. It pretty much echoes your statement that unless you know you and others will be documenting and maintaining (and that is a big commitment), your probably just doing everyone a disservice long term.

fimdomeio 6y ago

I would just add an in between. If the project is small enough that a fellow coder can understand what's happening by spending a day or two looking at the code it's also ok. Other than that fully agree, the power of documentation stackoverflow and forums can be easily overlooked but is incredibly valuable. This even if we all feel a little miserable every time the framework fails at any of the magic things it does and we just patch it up and end up never fully understanding the root cause.

samvher 6y ago

I feel like mainly this article is about building generic tools as you are developing your application. I think the word "framework" is used liberally - base classes and higher order functions are classified as tiny frameworks in the article. In some cases I think it's a tricky call. I'm currently working on a "framework" and am worried about all the issues that you mention. The reason I'm still building a framework is that as far as I can tell there is really no existing framework for the task at hand, and we do need the economies of reusable code (consistency across deployments & avoidance of double work). I hope the organization is large enough to absorb this and keep it going down the road, and am aiming to make it open source in the hope that a community can form around it as well. Fingers crossed, I guess.

ebiester 6y ago
There are all sorts of nuance that are not captured in a short post. In 2012, I built a micro front-end framework for front end because I wanted something closer to what turbolinks is today, and I am sure people have cursed my name in years since. (Of course, the alternatives were things like knockout and backbone, and I had issues with those and my use case.) So, to be fair, many of us have done it. The best case is that you can open source it and everyone can benefit from your work.