4 ms·

I think that's a naive way of thinking about the problem. Do people write rich server-side web apps in Plain Ol' Python? Of course not. Why reinvent the wheel?

I think that's a naive way of thinking about the problem. Do people write rich server-side web apps in Plain Ol' Python? Of course not. Why reinvent the wheel? For a tiny app, sure, maybe it's not so bad to just use jQuery. But if you're working on something with a very rich front-end architecture, a framework gives you a very necessary...er...framework to use to eliminate boilerplate and organize your work. Not only that, but you get to minimize your code debt to your actual business logic, not the plumbing.

exodust 13y ago
Maybe people are trying to avoid work? If that's the case, be careful losing your innovative and creative edge from being shackled to an interlocking formula of tools and frameworks. This debate feels loose. We are lucky to have so many options. It all depends what project you're working on. I prefer rich possibilities in design and functionality rather than rich possibilities in minimising how much I have to think/solve/innovate. I don't want a crutch, I want a turbo boost of creativity in web development... and that comes from hard work, not automating your life. These tools are often about slapping the same old stuff down day in day out. Where's the fun in that? Am I re-inventing the wheel? Spreading boilerplate code around in a mess? No I am not. My boilerplate code is nicely organised and easily deployed thanks very much! And the wheels.. well, the wheels I make are lightweight, and I know and trust them inside out. They're my wheels. I made them, and they stand out from the crowd.
Silhouette 13y ago
Do people write rich server-side web apps in Plain Ol' Python? Perhaps not, but plenty of us write them using a lightweight framework like Flask rather than heavyweights like Django, and even in a relatively mature field like ORMs, there are downsides to using them that sometimes outweigh the advantages. For a tiny app, sure, maybe it's not so bad to just use jQuery. I've got ~100,000 lines (before minimising etc.) and ~5 years of successful maintenance "just using jQuery" for one web app that I can quickly check from here that is still going strong. I think most of us would agree that's not a tiny single page application.
- acjohnson55 13y ago
  That's great, but it sounds like this project predates the modern frameworks. It probably doesn't make sense to try to shoehorn it into a framework at this point. But to write 100,000 of framework-less JS today on a green field project seems ridiculous. 5 years ago, some person was probably bragging about their 100,000 line app built without jQuery. 5 years from now, someone will be bragging about how all they use is Backbone.
  - Silhouette 13y ago
    But to write 100,000 of framework-less JS today on a green field project seems ridiculous. Why? I've worked on non-web software projects 1-2 orders of magnitude bigger that didn't need anyone's magical framework to develop and maintain a sound architecture. How come we can't just use good design that fits the project if the software we're writing happens to be the front end for a web app? It's about picking the right tool for the job, the same as always. For some projects and some development teams, I'm sure these modern JS frameworks and tools have proved valuable and will continue to do so. On the other hand, we're currently planning another web app that is expected to grow at least as big as the one I described earlier, and no-one on the team is seriously considering using any of the current crop of front-end frameworks. That's not because we don't know what they do or how they work. It's simply because none of us thinks it's a smart idea to build such a large and hopefully long-running project with a fundamental dependency on the kind of technology that typically measures its time at the top in months.
- lmm 13y ago
  How many lines would it be if it used a good framework? IME any application which grows that large without using a framework ends up inventing its own. If the code's maintainable by people other than its original author you've presumably separated the routing code from the template rendering code (and have a module that's effectively a generic template renderer) from the backend service access (and again, probably have a module that's some kind of generic service access layer). You'll have a set of utility functions that's more or less equivalent to underscore. And so on.

exodust 13y ago

Maybe people are trying to avoid work? If that's the case, be careful losing your innovative and creative edge from being shackled to an interlocking formula of tools and frameworks. This debate feels loose. We are lucky to have so many options. It all depends what project you're working on. I prefer rich possibilities in design and functionality rather than rich possibilities in minimising how much I have to think/solve/innovate. I don't want a crutch, I want a turbo boost of creativity in web development... and that comes from hard work, not automating your life. These tools are often about slapping the same old stuff down day in day out. Where's the fun in that? Am I re-inventing the wheel? Spreading boilerplate code around in a mess? No I am not. My boilerplate code is nicely organised and easily deployed thanks very much! And the wheels.. well, the wheels I make are lightweight, and I know and trust them inside out. They're my wheels. I made them, and they stand out from the crowd.

Silhouette 13y ago

Do people write rich server-side web apps in Plain Ol' Python? Perhaps not, but plenty of us write them using a lightweight framework like Flask rather than heavyweights like Django, and even in a relatively mature field like ORMs, there are downsides to using them that sometimes outweigh the advantages. For a tiny app, sure, maybe it's not so bad to just use jQuery. I've got ~100,000 lines (before minimising etc.) and ~5 years of successful maintenance "just using jQuery" for one web app that I can quickly check from here that is still going strong. I think most of us would agree that's not a tiny single page application.

acjohnson55 13y ago
That's great, but it sounds like this project predates the modern frameworks. It probably doesn't make sense to try to shoehorn it into a framework at this point. But to write 100,000 of framework-less JS today on a green field project seems ridiculous. 5 years ago, some person was probably bragging about their 100,000 line app built without jQuery. 5 years from now, someone will be bragging about how all they use is Backbone.
- Silhouette 13y ago
  But to write 100,000 of framework-less JS today on a green field project seems ridiculous. Why? I've worked on non-web software projects 1-2 orders of magnitude bigger that didn't need anyone's magical framework to develop and maintain a sound architecture. How come we can't just use good design that fits the project if the software we're writing happens to be the front end for a web app? It's about picking the right tool for the job, the same as always. For some projects and some development teams, I'm sure these modern JS frameworks and tools have proved valuable and will continue to do so. On the other hand, we're currently planning another web app that is expected to grow at least as big as the one I described earlier, and no-one on the team is seriously considering using any of the current crop of front-end frameworks. That's not because we don't know what they do or how they work. It's simply because none of us thinks it's a smart idea to build such a large and hopefully long-running project with a fundamental dependency on the kind of technology that typically measures its time at the top in months.
lmm 13y ago
How many lines would it be if it used a good framework? IME any application which grows that large without using a framework ends up inventing its own. If the code's maintainable by people other than its original author you've presumably separated the routing code from the template rendering code (and have a module that's effectively a generic template renderer) from the backend service access (and again, probably have a module that's some kind of generic service access layer). You'll have a set of utility functions that's more or less equivalent to underscore. And so on.