4 ms·

> eschew platforms and libraries and roll my own most of the time That's what nearly everybody does, when they're one person hacking on a one-off project. I l

• pavlov 10y ago
  Thing is, complex frameworks like Angular tend to allow for 20 different ways to accomplish the same thing, so they don't really solve the underlying problem: team members still need to agree on a common approach and a shared set of idioms and coding styles. There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
  • buckbova 10y ago
    I picked up Angular quickly, insisted everyone in my group follow this style guide. https://github.com/johnpapa/angular-styleguide https://github.com/johnpapa/angular-styleguide We didn't need an expert.
    • jasonm23 10y ago
      Seems you were lucky that the expert you didn't need had written up a style guide.
      • buckbova 10y ago
        Definitely. We live in wonderful times.
    • thegayngler 10y ago
      I don't like Angular 1.xxx that much because in Angular 1.xxx building simple stuff in JavaScript is a no no. Angular doesn't play nicely with JavaScript. Instead you have to do Angularjs way and write the Angular specific code in your 50 Angular specific HTML attributes. Performance of data intensive apps is particularly lousy in Angular. In my opinion it's a framework written for people who like complexity for complexity's sake. I don't want to be hunting all over my code base just to figure out what is happening in a controller or component. JPs styleguide is awesome!
• DougN7 10y ago
  That's a really good point - it's very rare for someone else to need to use my web code.
• Silhouette 10y ago
  I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code. Or we could just adopt good coding standards and build with reasonable software architecture. That's been working for longer than anything like the modern Web has existed, to build software orders of magnitude larger than any web app by any useful metric I can imagine, without the need to resort to huge frameworks to keep growing code bases organised and consistent.
  • tomc1985 10y ago
    It's a format that doesn't lend itself very well to the current model of code-bootcamps-and-hello-world-tutorials. Now that I think about it, the zeitgeist here really does feel like those cheesy "Learn C++ in just 20 minutes a day!!!!!" books
    • Silhouette 10y ago
      The thing is, producing good software at any serious scale and maintaining it for any serious length of time needs more skill and understanding than you can learn from a 10 minute tutorial video and a couple of blog posts. There seems to be a new generation of developers who think that 10,000 lines of code is a big program, a web app doesn't need to last more than a year or maybe two at most, and any sort of in-house programming or software design work will be inherently inferior to any external code you can import instead. These people are probably doomed no matter what they do. There's a certain irony that in the one clear exception to that rule -- if you really are building a throwaway MVP in the expectation that it will either fail quickly or succeed enough be be worth rewriting properly later -- it mostly doesn't matter what tools or practices you follow. As long as you have some basic competence regarding security and you're keeping any important data somewhere safe so it can be transferred reliably to a new system later, the strategy is what it is. However, that also means many of the claimed advantages of frameworks are irrelevant to such projects, because you don't really care about things like longevity or being able to hire more developers already familiar with the framework or keeping growing teams consistent in how they design a growing code base.