251–260 of 550 posts
Better title: Using Rails will harm the maintenance of your software. Because Rails sucks. A framework like Phoenix (Elixir) is perfectly usable as a plugin.
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you a…
No, I'm not. The guy who quit 2 years ago was. I've worked with custom frameworks, and while they where both clever and powerful with some quite cool features which would have been tricky to do in a more generic framework, they where also virtually undocumented, fragile, difficult to extend and slow to get people up to speed on.
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you a…
Use frameworks, use libraries. They will save you time, make your code less buggy, make it easier to hire other people.
Writing your own ball of mud is great for a hobby but not for business.
Web framework code is typically riddled with comments like "this extra margin is added to the input to work around a bug in Internet Explorer 11 where Tibetan characters are cut off".
Good luck solving such issues without having tens of thousands of eyes and hundreds of hands to help you.
Earlier quoted context omitted.
> Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. And then you change a job and you take 80% knowledge with you and your now-past project is in deep trouble.
If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.
Rails will harm the maintenance of your software* *Is really the accurate summation of the article. And yes, this is well known. Every article about a company upgrading Rails is "it took us several years and only three people died." And we know better than to use MVC nowadays. No offense to Rubyists, but in the Ruby ecosystem, I have seen a disturbing lack of absorbing information from other programming ecosystems. T…
Now - I use RoR and other ecosystems and I really miss Ruby or RoR features in those other ones.
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you a…
The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating code. I agree with this but it requires a lead who's good at architecting such a codebase. That person also needs to stay with the company for a long time because they're essentially replacing the "framework" with bespoke human logic. I think many, maybe most, c…
I'd rather wallow in my own mess than wade through someone else's though
At some point we all wade through someone else’s mess. Hell, even your own mess revisited after a period of time is unpleasant.
The more you can do to make your software predictable and boring the less unpleasant it will be for everyone.
Earlier quoted context omitted.
> After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim I also have 25 years of experience and started my career w…
> There have been a few times that I have ripped out my own code in favor of a popular library when I discovered it. I'm much more likely to rip out the one function I need out of a framework or library and put it in my code, with a comment "// stolen from ". I've spent lots of time untangling the crux of someone's implementation away from the problematic abstractions they built up around it to make it universally ad…
Earlier quoted context omitted.
> or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application That's not what people commonly understand as a "framework". Nor is it a helpful definition because then where does "abstracting things" and "framework" start and end? No, the main difference between frameworks and what you describe is…
I don't agree with this simplistic distinction between framework and library. There are plenty of libraries that call back into user code. A better definition might be that a framework imposes an entire 'application model' on you, and trying to step outside that predefined model is at your own risk, while a library is a much smaller and flexible building block (also a building block for frameworks). But there's a lar…
> A better definition might be that a framework imposes an entire 'application model' on you, and trying to step outside that predefined model is at your own risk
This is the kind of definition were 50% will call something a framework and the other half will call it a library then. Not sure if that is really helpful.