7 ms·

Frameworks are most often a bad idea. Use libraries instead. Sometimes they are useful though. For instance, they make sense when routing. But in those cases,

• sebastianconcpt 12y ago
  People learn using frameworks and discover using libraries. Some are pioneering-friendly others just-doing-the-job-friendly. Nothing static, all oscillating in a big Cambrian Explosion of JavaScript creativity
• morley 12y ago
  > Frameworks are most often a bad idea. Use libraries instead. People say this a lot, and it makes me wonder if they've ever worked on a team working on the same codebase. And if they do, what secret sauce they're drinking to not go insane. In my experience, when people on a team use libraries at their whim, the coding styles diverge wildly from feature to feature. One person decides they're going to write all their AJAX callbacks in an anonymous function; another likes to reference a function directly; another likes to both; and yet another uses promises. And as soon as someone needs to fix someone else's project, they do some combination of (a) getting wildly frustrated with this other coding style, (b) rewire their mental model to adapt to this new style, (c) spend a week rewriting it in their own style, (d) introduce a ton of bugs in the process, or (e) by some miracle, get it to work perfectly. So to combat this, the team works out coding standards and a style guide. You must tab with two spaces! You must pass a real Javascript function to your callbacks! You must separate your state from your view! And of course, once your style guide is big enough, lo and behold: you have your own hand-rolled framework. And hopefully it's tight enough that everyone writes in the same style, but is still expressive, and is still simple enough for a new team member to learn quickly. So if you're just starting a codebase, it makes complete sense to pick a framework on the outset because people have already gone through that headache for you.
  • nilliams 12y ago
    Absolutely, I'm beginning to lose patience repeating the frankly blinding-obvious-at-this-point-argument you just had to make, but I'm glad others like yourself haven't. The 'don't use frameworks, use libraries' argument is naive, and just does not hold up in the real world of teams trying to build things.
    • girvo 12y ago
      And I have found the "you're just writing your own framework" point needlessly repeated over and over, despite having never run into it in practice. Choosing a large framework does not insulate you from the concerns of the grandparent. You still must come up with a style guide, and a way of using the tools. The win is not obvious, imo.
      • nilliams 12y ago
        The style guide is surely longer when using a toolset with fewer conventions? If I'm using Backbone over Ember, my style guide has to cover things that would be covered by Ember's own docs, for example how to compose views, how to do nested routing, how to represent computed properties ... Your longer style guide is defining code patterns for those use-cases. Your longer style guide is a framework, just more verbose because you aren't actually abstracting away those patterns.
  • boomlinde 12y ago
    I don't think that a framework is a good substitute for a style guide or the processes like reviewing, documenting or factoring code that lead to consistency and readability. If your team members feel like they have to "rewire their mental models" or spend weeks rewriting code rather than adapting to it, the team has a problem that you should deal with in another way than pigeonholing your projects into frameworks. I generally disagree with the sentiment that collections of libraries are somehow inherently a better solution than frameworks, though. I just think that it is probably a poor solution to the problem you describe here.
  • nogridbag 12y ago