So it’s okay to use frameworks when you’re small and scrappy, but they will slow you down when you grow into an enterprise… because build processes? Enterprise

So it’s okay to use frameworks when you’re small and scrappy, but they will slow you down when you grow into an enterprise… because build processes? Enterprises have processes, lots of them, to maintain continuity for their many customers and compliance with their many legal obligations. They tend to adopt frameworks as teams to ensure some consistency in practices. Adding one more build step is minute, but creating a commonjs style guide and state management system isn’t. No, you don’t get to FTP into prod anymore and edit static files in vim. We use build processes to make sure code works efficiently and effectively across many browsers and devices. Editing CSS by hand makes sense for small and medium projects, but gets to be pretty large pretty quickly and serves users way faster if tree-shook and code-split. We use source control so we can make changes forward and back, with approval, constraint, and automation. There is a bitter tone here that tastes like sour grapes. Slogging through webpack can do that to be certain :) but this dismisses the collective work of hundreds of thousands of engineers who have worked to make the web do things it was never imagined to do, for an unthinkably vast and diverse audience. How they reason about organizing their tools and processes reflects the scale of the unique things they need to accommodate. They are not wrong for not just sticking with jquery. Sure I miss the HotDog HTML days sometimes, but then I look around and see that my desktop is in my pocket, and my bank is an app, and my word processor is a webpage.