3 ms·

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 le

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.
  - dozzie 10y ago
    > There seems to be a new generation of developers who think that 10,000 lines of code is a big program This one made my day xD 10kLOC is a top limit for my programs (I say that whatever has higher line count starts boring me), and those were just small tools for sysadmins since forever.
fenomas 10y ago
Big Web Frameworks aren't there to "keep code bases organized and consistent", they're there to do stuff like render state changes into a complicated DOM without causing jank, without FOUCs, without crashing IE9, etc. Those aren't problems that "adopting good coding standards" can solve. Web frameworks have architecture to them, but their value lies in solving technical problems, not architectural ones.
- Silhouette 10y ago
  Big Web Frameworks aren't there to "keep code bases organized and consistent", they're there to do stuff like render state changes into a complicated DOM without causing jank, without FOUCs, without crashing IE9, etc. Those aren't problems that "adopting good coding standards" can solve. I respectfully disagree. You don't need a framework to do any of those things. I do a lot of work with relatively complicated browser-based UIs. In my experience, the DOM/layout thrashing and jank issues that have been getting a lot of attention lately only became a big deal in the first place because the early frameworks were so horrifically slow compared to just doing manual updates of exactly what you needed to change. Even in the most demanding applications -- and not many web apps actually are this demanding -- you could achieve pleasant, smooth results with some modest attention to how you applied updates so you didn't cause the browser to regenerate layout unnecessarily. (This would be an example of a useful coding standard, BTW.) Flashes of unstyled content/text/whatever are a symptom of serving web pages in chunks and how browsers render incrementally as more of the chunks are available. Again, dealing with these effects just requires some understanding of what causes them and a little care in how your site/app is served and does its initial setup. The frameworks don't do anything magic that you can't do in your own code. And finally, we were solving cross-browser portability problems with script repositories and then libraries like jQuery a long time before any of the modern frameworks were on the scene, and in a much more varied environment in the early days. IE has certainly had its issues over the years, but for the most part at least the issues were well known and you could just work around them. And again, there weren't really that many horrible issues, and this was an area where having some basic coding standards worked OK even if for some reason you didn't want to just use one of the many utility libraries.

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.
- dozzie 10y ago
  > There seems to be a new generation of developers who think that 10,000 lines of code is a big program This one made my day xD 10kLOC is a top limit for my programs (I say that whatever has higher line count starts boring me), and those were just small tools for sysadmins since forever.

fenomas 10y ago

Big Web Frameworks aren't there to "keep code bases organized and consistent", they're there to do stuff like render state changes into a complicated DOM without causing jank, without FOUCs, without crashing IE9, etc. Those aren't problems that "adopting good coding standards" can solve. Web frameworks have architecture to them, but their value lies in solving technical problems, not architectural ones.

Silhouette 10y ago
Big Web Frameworks aren't there to "keep code bases organized and consistent", they're there to do stuff like render state changes into a complicated DOM without causing jank, without FOUCs, without crashing IE9, etc. Those aren't problems that "adopting good coding standards" can solve. I respectfully disagree. You don't need a framework to do any of those things. I do a lot of work with relatively complicated browser-based UIs. In my experience, the DOM/layout thrashing and jank issues that have been getting a lot of attention lately only became a big deal in the first place because the early frameworks were so horrifically slow compared to just doing manual updates of exactly what you needed to change. Even in the most demanding applications -- and not many web apps actually are this demanding -- you could achieve pleasant, smooth results with some modest attention to how you applied updates so you didn't cause the browser to regenerate layout unnecessarily. (This would be an example of a useful coding standard, BTW.) Flashes of unstyled content/text/whatever are a symptom of serving web pages in chunks and how browsers render incrementally as more of the chunks are available. Again, dealing with these effects just requires some understanding of what causes them and a little care in how your site/app is served and does its initial setup. The frameworks don't do anything magic that you can't do in your own code. And finally, we were solving cross-browser portability problems with script repositories and then libraries like jQuery a long time before any of the modern frameworks were on the scene, and in a much more varied environment in the early days. IE has certainly had its issues over the years, but for the most part at least the issues were well known and you could just work around them. And again, there weren't really that many horrible issues, and this was an area where having some basic coding standards worked OK even if for some reason you didn't want to just use one of the many utility libraries.