Why would I rely on something that keeps being re-invented by everyone every month, with unknown future support?
I'm not insane. I'm writing my own web application framework. If I'm the one writing it, I know it inside-out. If I use it, I update it myself. That's the only way to be sure.
Truly, you are correct. In fact, why would you rely on a programming language that keeps being changed every few months. I am writing my own programming language. If I'm the one writing it, I know it inside-out. If I use it, I update it myself. That's the only way to be sure.
In fact, why would you rely on an operating system that keeps being changed every few months? I am writing my own operating system (written in the programming language I created of course). If I'm the one writing it, I know it inside
Frameworks trade the time needed to learn the framework for time writing your own code. The presumption that you will learn the framework as well as your own code is questionable at best. Odds are you won't need everything in the framework. The benefits of a wide community using the framework, and, if the framework is well maintained, having it tweaked as the community reports problems, is a big plus; but it is counter-featured by problems and vulnerabilities affecting wide swaths of users (until fixed or patched) and by input from users that becomes less significant as the size of the community grows, as well as a noise factor where requests for features and fixes begin to cost significant time just to figure out which ones are worthwhile, and which ones are not. Finally, bugs in a widely used framework may go unfixed for considerable lengths of time, or may never be fixed.
If you're a good enough programmer, languages like python make writing server-side functionality pretty much a doddle. We're a long way from the obfuscatory nightmare of perl on the interpreted side of things. C still provides the "big dog" of speed and power, providing that you have decent memory management and string handling available to you in your own collection of source (and I think most C programmers should have such tools... I sure do.) If you're a client-side person, there are certainly various options, but I'm not qualified to talk about them, as I am not a fan of client-side processing at all. As far as I'm concerned, the compatibility benefits of server-side processing trump anything the client side has to offer.
The benefits of rolling your own are pretty significant. Bug? Not only do you "know the programmer", you're the Most Important User, so you get to set the priorities. Want a feature? No one knows better than you just how to make it fit with the existing codebase. Hacking? No one sees your code but you, and you can ensure that everything, and I mean everything, goes through "washer" functions limiting length and character set and range. Security by obscurity can really be extremely effective.
I'm not saying there's anything wrong with using a framework; but I am saying that it is quite wrong to consider rolling your own as "right out." It is fairly easy to do, builds you a toolkit that is all yours (and consequently something you will know very well how to use), offers a measure of security unavailable in a public framework as well as any type of security the public framework might use, puts your priorities right up front, hones your programming skills at a higher level than using canned functions does, and it is very rewarding in the general sense -- there's something valuable to be said for "I wrote that."
Web application framework? (Score:0)
Why would I rely on something that keeps being re-invented by everyone every month, with unknown future support?
I'm not insane. I'm writing my own web application framework. If I'm the one writing it, I know it inside-out. If I use it, I update it myself. That's the only way to be sure.
Re: (Score:0, Redundant)
Not so cut and dry (Score:2)
Frameworks trade the time needed to learn the framework for time writing your own code. The presumption that you will learn the framework as well as your own code is questionable at best. Odds are you won't need everything in the framework. The benefits of a wide community using the framework, and, if the framework is well maintained, having it tweaked as the community reports problems, is a big plus; but it is counter-featured by problems and vulnerabilities affecting wide swaths of users (until fixed or patched) and by input from users that becomes less significant as the size of the community grows, as well as a noise factor where requests for features and fixes begin to cost significant time just to figure out which ones are worthwhile, and which ones are not. Finally, bugs in a widely used framework may go unfixed for considerable lengths of time, or may never be fixed.
If you're a good enough programmer, languages like python make writing server-side functionality pretty much a doddle. We're a long way from the obfuscatory nightmare of perl on the interpreted side of things. C still provides the "big dog" of speed and power, providing that you have decent memory management and string handling available to you in your own collection of source (and I think most C programmers should have such tools... I sure do.) If you're a client-side person, there are certainly various options, but I'm not qualified to talk about them, as I am not a fan of client-side processing at all. As far as I'm concerned, the compatibility benefits of server-side processing trump anything the client side has to offer.
The benefits of rolling your own are pretty significant. Bug? Not only do you "know the programmer", you're the Most Important User, so you get to set the priorities. Want a feature? No one knows better than you just how to make it fit with the existing codebase. Hacking? No one sees your code but you, and you can ensure that everything, and I mean everything, goes through "washer" functions limiting length and character set and range. Security by obscurity can really be extremely effective.
I'm not saying there's anything wrong with using a framework; but I am saying that it is quite wrong to consider rolling your own as "right out." It is fairly easy to do, builds you a toolkit that is all yours (and consequently something you will know very well how to use), offers a measure of security unavailable in a public framework as well as any type of security the public framework might use, puts your priorities right up front, hones your programming skills at a higher level than using canned functions does, and it is very rewarding in the general sense -- there's something valuable to be said for "I wrote that."