4 ms·
This is actually 100% my experience, wow. I started with Rails many years ago, had absolutely no idea what I was doing. Was just googling for gems and snippets
by akurilin 12y ago
This is actually 100% my experience, wow.
I started with Rails many years ago, had absolutely no idea what I was doing. Was just googling for gems and snippets from Stack Overflow, if anything ever broke I was done.
A few years later I decided I was going to really dig deep into the meat of it and wrote my own framework in Clojure that we are still using to this day in production. It was incredibly liberating to know every nook and cranny of the framework because I had written it myself. I also figured out why so many decision had been made in other frameworks, it was a phenomenal learning experience.
I eventually realized that our super small team and I simply couldn't sustain keeping this super-custom framework maintained and updated, not with all the other work that needs to be done at the company. We moved most of our work to Haskell's Yesod framework, which has years of community work and incredible craftsmanship behind it. It's now pretty trivial to spin up a new application and have it reuse all of the components written for other apps in the same framework. I don't even bother with docs at this point, it's a lot more effective to stare at the source.
- coldtea 12y ago>I eventually realized that our super small team and I simply couldn't sustain keeping this super-custom framework maintained and updated, not with all the other work that needs to be done at the company. We moved most of our work to Haskell's Yesod framework, which has years of community work and incredible craftsmanship behind it. And then Haskell's Yesod gets abandoned when the core devs move to shinier things and nobody else is bothered, like several Clojure web frameworks that were touted back in the day... And you realise that maybe updating your own framework when and were you needed it, was not that big of a deal actually....
- akurilin 12y agoIt's a possibility, which is why you need to evaluate how much the community likes the project, how much they depend on it surviving, how many people would be likely to keep it afloat in case the core devs peace out, how active the core team has been over the long and short terms etc. There's a whole art to picking OSS tooling for your team, none of it is devoid of risk, there's no free lunch. Obviously, it'd also be totally OK for us to help maintain it with the rest of the people who care, that's a big part of it. Given how much you end up reading the source of frameworks once you really start using them (at least in my ecosystems), you're one step away from starting to change them.
- Joeri 12y agoIn the case where an open source framework loses its maintainer, in the worst case you are the maintainer. In that case you are no worse off than with your own framework, except that for a number of years the maintenance work was done for you for free.
- jacquesm 12y agoWith one small difference: you'll likely have a much larger attack surface because the third party framework was created to do much more than to just service your applications. And all that code will need to be maintained now. That can get very costly.
- emodendroket 12y agoIf that's really the case you could easily just cut out features you don't intend to use.
- scott_karana 12y agoReally? What about cross-cutting features like logging, sessions, debug hooks, et cetera? That's a non-trivial refactor right there.
- emodendroket 12y agoWell, true, although, from your list, it's hard to think of application where you wouldn't want those things.
- akurilin 12y agoExactly. And rolling your own is pretty wasteful when most "off the shelf" ones are good enough for most use cases.
- deleted 12y ago[deleted]