3 ms·

Let's say I'm building a web app and develop my own patterns and practices. Obviously it'll be a bad idea to have everyone working on my project create their ow

Let's say I'm building a web app and develop my own patterns and practices. Obviously it'll be a bad idea to have everyone working on my project create their own patterns and will make sense to mandate everyone follow one set of patterns so we don't have to keep context-switching whenever we're working on a different part of the app. To an outsider who needs to now contribute code to my web app, what's the difference between following my patterns and following a framework's patterns if a framework was used instead? What's good about most frameworks is the fact they come with documentation, tutorials, tests and all that good stuff so someone new to the framework can quickly get up to speed. The author even admits to having people have problems understanding his architecture. My advice to the author is don't worry, people will eventually get better. JavaScript seemed inaccessible to a lot of people (including myself) until jQuery came along. The more jQuery code I wrote and gained more experience in JavaScript, the more I learned how little I needed to use jQuery to accomplish a ton of stuff. Backbone, Angular and other frameworks will probably have the same effect on people some day.

pags 12y ago
The difference is that the framework is built to be an open source framework - it has general abstractions. Your own patterns and practices are developed to apply directly to what you're building.
- acjohnson55 12y ago
  But a good framework has well chosen abstractions that took many person-hours to settle upon, a community of engineers working to perfect it, and probably uncountable hours of production battle-testedness.
  - pags 12y ago
    I'm not sure that time and bodies necessarily produce good abstractions.
  - jdlshore 12y ago
    > has well chosen abstractions That's a rather large leap of faith. It's more likely that it has a bunch of abstractions that were chosen early in the project when the maintainers were young, dumb, and eager; that have since shown their age and have been worked around repeatedly; but can't be removed due to being core to the framework and having a large body of applications depending on them.
    - acjohnson55 12y ago
      Not all frameworks. Good frameworks. The best incorporate the lessons learned from working with previous frameworks.
antris 12y ago
> Obviously it'll be a bad idea to have everyone working on my project create their own patterns and will make sense to mandate everyone follow one set of patterns so we don't have to keep context-switching whenever we're working on a different part of the app. You're right, nobody wants that. What I have found to be the best way to avoid this is to actively talk to each other and together choose the simplest solutions that fit the case. Mixing and matching different patterns is good if they fit neatly. This results into less boilerplate and/or messy spaghetti code, as the abstractions fit the problem domain perfectly. So essentially, talk to each other and work together as a team. Don't just hack on things randomly.

pags 12y ago

The difference is that the framework is built to be an open source framework - it has general abstractions. Your own patterns and practices are developed to apply directly to what you're building.

acjohnson55 12y ago
But a good framework has well chosen abstractions that took many person-hours to settle upon, a community of engineers working to perfect it, and probably uncountable hours of production battle-testedness.
- pags 12y ago
  I'm not sure that time and bodies necessarily produce good abstractions.
- jdlshore 12y ago
  > has well chosen abstractions That's a rather large leap of faith. It's more likely that it has a bunch of abstractions that were chosen early in the project when the maintainers were young, dumb, and eager; that have since shown their age and have been worked around repeatedly; but can't be removed due to being core to the framework and having a large body of applications depending on them.
  - acjohnson55 12y ago
    Not all frameworks. Good frameworks. The best incorporate the lessons learned from working with previous frameworks.

antris 12y ago

> Obviously it'll be a bad idea to have everyone working on my project create their own patterns and will make sense to mandate everyone follow one set of patterns so we don't have to keep context-switching whenever we're working on a different part of the app. You're right, nobody wants that. What I have found to be the best way to avoid this is to actively talk to each other and together choose the simplest solutions that fit the case. Mixing and matching different patterns is good if they fit neatly. This results into less boilerplate and/or messy spaghetti code, as the abstractions fit the problem domain perfectly. So essentially, talk to each other and work together as a team. Don't just hack on things randomly.