4 ms·

This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps bu

This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps built on Rails end up with a business logic-level "framework" that is ad hoc and not obvious to newcomers, which results in bugs. Not to mention, the frameworks tend to be hard to use "correctly". Rails devs will have heard the term "the Rails way". In fact this article has an awesome example. There's a snippet of code of a controller checking to see if a User exists with the given email. Any Rails veteran would know that you can just call `User.create` in the controller and rely on validations for that kind of check. But that's another problem with frameworks - you have to know the whole thing in order to use it well.

Daishiman 4y ago
> But that's another problem with frameworks - you have to know the whole thing in order to use it well. This applies to whatever in-house monstrosities get built too, except that without docs or a million eyeballs to judge whether a workflow makes some sense to an outsider.
- resonious 4y ago
  Right. I'm definitely not trying to say that apps on a framework are actually larger and nastier than frameworkless apps. They both get large and nasty.
scarface74 4y ago
> But that's another problem with frameworks - you have to know the whole thing in order to use it well. The difference is I have plenty of resources at my disposal to learn how to use a popular framework. I only have hopefully the one “architect” who thought their problem was a special snowflake to ask about their framework - if they are still at the company.
flomo 4y ago
That has long been one of my complaints about Rails. It creates a nice directory structure for the framework's objects. But there's no obvious place by default to put business/application "your logic". So then all that stuff gets wedged into huge controller and model files. (in the old days there was a division between 'business objects' vs 'data objects' etc) #1 is definitely true. I had my own halfassed 'framework', and have dug into enough older web apps to know that everyone else had one too. (Or at least the smart ones did.)

Daishiman 4y ago

> But that's another problem with frameworks - you have to know the whole thing in order to use it well. This applies to whatever in-house monstrosities get built too, except that without docs or a million eyeballs to judge whether a workflow makes some sense to an outsider.

resonious 4y ago
Right. I'm definitely not trying to say that apps on a framework are actually larger and nastier than frameworkless apps. They both get large and nasty.

scarface74 4y ago

> But that's another problem with frameworks - you have to know the whole thing in order to use it well. The difference is I have plenty of resources at my disposal to learn how to use a popular framework. I only have hopefully the one “architect” who thought their problem was a special snowflake to ask about their framework - if they are still at the company.

flomo 4y ago

That has long been one of my complaints about Rails. It creates a nice directory structure for the framework's objects. But there's no obvious place by default to put business/application "your logic". So then all that stuff gets wedged into huge controller and model files. (in the old days there was a division between 'business objects' vs 'data objects' etc) #1 is definitely true. I had my own halfassed 'framework', and have dug into enough older web apps to know that everyone else had one too. (Or at least the smart ones did.)