ganjasensation0098
New Member
- Messages
- 36
- Reaction score
- 0
- Points
- 0
Should I use a framework when developing a project in php? or I used my scratch php code to do it?
Last edited:
PHP Frameworks or not?
- Thread starter ganjasensation0098
- Start date
- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
If you're a single programmer working on your own project, it would likely be best to cook from scratch. That's generalizing in a big way, though.
There are a couple of types of frameworks to consider. One is the class of environments that work similarly to Ruby on Rails, like CakePHP. These can be characterized by the "convention over code" principle -- as long as you can define the data consistently, much of the work is done for you (the databases will be built in a particular way, an object-relational map layer will be created for you, and basic UI views, forms and often AJAX actions will be generated). Your task, then, becomes a relatively simple matter of customizing what the framework provides. Of course, if you stray too far from what's in the box you will lose the advantage that the framework provides. In fact, you'll probably find yourself fighting the system at every turn, and there will be much profanity.
Then there are "enterprise class" frameworks. Like .NET and J2EE, they provide a lot of classes that do the kinds of heavy lifting that you'd normally have to do in your own code. But then you've just traded writing the code for a constant reliance on reference material (don't even try it without a framework-aware IDE like Zend Studio). The advantage of these frameworks is consistency when the project gets large and there are a lot of programmers working on the code base; the disadvantage is that you end up loading and running a lot of heavy code that you really don't need to be running in order to get the job done. Do you really need to have string handling classes that are immune to the Turkish I Problem?
If you're coding with an eye to getting a job in the corporate world (or at least that part of the corporate world that isn't married to the Microsoft stack), then jumping down the rabbit hole to the land of frameworks might be a good idea. If you're doing it for yourself (or with an eye to consulting to the SME world), then learning to create code that is robust, lightweight, maintainable and does no more than it needs to do will serve you far better.
But that's just an old fart's opinion.
There are a couple of types of frameworks to consider. One is the class of environments that work similarly to Ruby on Rails, like CakePHP. These can be characterized by the "convention over code" principle -- as long as you can define the data consistently, much of the work is done for you (the databases will be built in a particular way, an object-relational map layer will be created for you, and basic UI views, forms and often AJAX actions will be generated). Your task, then, becomes a relatively simple matter of customizing what the framework provides. Of course, if you stray too far from what's in the box you will lose the advantage that the framework provides. In fact, you'll probably find yourself fighting the system at every turn, and there will be much profanity.
Then there are "enterprise class" frameworks. Like .NET and J2EE, they provide a lot of classes that do the kinds of heavy lifting that you'd normally have to do in your own code. But then you've just traded writing the code for a constant reliance on reference material (don't even try it without a framework-aware IDE like Zend Studio). The advantage of these frameworks is consistency when the project gets large and there are a lot of programmers working on the code base; the disadvantage is that you end up loading and running a lot of heavy code that you really don't need to be running in order to get the job done. Do you really need to have string handling classes that are immune to the Turkish I Problem?
If you're coding with an eye to getting a job in the corporate world (or at least that part of the corporate world that isn't married to the Microsoft stack), then jumping down the rabbit hole to the land of frameworks might be a good idea. If you're doing it for yourself (or with an eye to consulting to the SME world), then learning to create code that is robust, lightweight, maintainable and does no more than it needs to do will serve you far better.
But that's just an old fart's opinion.
ganjasensation0098
New Member
- Messages
- 36
- Reaction score
- 0
- Points
- 0
Thanks for that essellar. Right now, I'm working on a project only by myself (that is almost finished) and I use codeigniter framework. In my next project, i'm confused if I should use the framework again or create my code from scratch.
- Messages
- 1,420
- Reaction score
- 46
- Points
- 48
In this case then I would ask whether you enjoyed using the framework and whether you felt it helped or hindered you? Also, use of a framework in your next project may also depend on the size and expandability you desire from it; a good framework may make light work of some major projects, but for smaller ones it may make little or no difference to how you interact with the data.
ganjasensation0098
New Member
- Messages
- 36
- Reaction score
- 0
- Points
- 0
As of now. I think I should a framework and maybe if the framework does not fit in my needs, thats the time that I will make my own framework.
- Messages
- 1,165
- Reaction score
- 27
- Points
- 48
The thing is, if you are going to make some simple PHP apps you don't actually need any framework, on the contrary, it would be more complicated and you'll end up with much slower app comparing to what you could do with pure PHP. On the other hand, if you are making your own custom CMS solutions or any other complex PHP app or system your best bet is to use PHP frameworks. I do a lot of complex PHP systems and apps and from my experience frameworks are always a good thing.
As for the codeigniter I find it quite useful. I started using it few years ago and I'm still using it. Simply put I love it.
To be honest, once you start making some crazy stuff you'll eventually end up making your own framework
As for the codeigniter I find it quite useful. I started using it few years ago and I'm still using it. Simply put I love it.
To be honest, once you start making some crazy stuff you'll eventually end up making your own framework
Last edited:
efrenbautistajr99
New Member
- Messages
- 9
- Reaction score
- 0
- Points
- 0
Which framework do you think is the best?
bhupendra2895
New Member
- Messages
- 554
- Reaction score
- 20
- Points
- 0
In my opinion zend framework is best because they are part of php project and offers certification courses too which has value in IT industry.
- Messages
- 5,255
- Reaction score
- 192
- Points
- 63
I my opinion i suggest CodeIgniter.I like it very much.Easy to use,and also their documentation is very good.I also use Cakephp.I just started to use it.Seems good.
- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
There is no "best framework"; there is only "the framework that makes my job simplest". For some types of applications, that may mean something simple and small like CodeIgnitor (you really can build a blog in twenty minutes -- well, twenty minutes plus however long it takes to mess about with graphics and CSS). For others, it means something like the Zend Framework, the PHP world's version of Java Enterprise Edition (a team of twenty developers can build a blog in twenty weeks -- but it can support twenty thousand simultaneous users distributed across twenty nations using twenty different languages, and it can tie in to your catalog and invoicing systems, track customer service issues, and prepare the buffet for your launch party).
You don't have to use everything a big framework provides, but it can be frustrating to have to wade through the documentation in order to find what you do need if you're not working with it all full-time. Smaller frameworks may conveniently leave out things you really wish you had, but you can always add to them as necessary.
If your project is relatively simple (a handful of UI elements dealing with a relatively small number of tables across one or two databases), you may find that something like CodeIgnitor or CakePHP will get you to 90% in next to no time. For realz. (Both of these frameworks are excellent, by the way. Which one you'd use is really a matter of taste.) You can bang out a small site with a blog/news section, a forum, a contact form and a way to create semi-static content pages in a couple of days (modulo design work). But you may find that you have to step outside of the framework in order to provide unique features, and that can be frustrating -- sometimes it's difficult to make framework-provided features work with your custom code and vice-versa.
I've always preferred the "bottom up" approach to programming myself. As Leviathon noted above, you are going to end up with your own bag of tricks eventually by simply surviving the development wars, and as long as you don't throw everything away at the end of every project, you'll wind up writing applications in your own version of the language rather than in raw PHP. The difference between your "framework" and the off-the-shelf varieties is that there will be no black boxes, no surprises, and no absolute limits.
You don't have to use everything a big framework provides, but it can be frustrating to have to wade through the documentation in order to find what you do need if you're not working with it all full-time. Smaller frameworks may conveniently leave out things you really wish you had, but you can always add to them as necessary.
If your project is relatively simple (a handful of UI elements dealing with a relatively small number of tables across one or two databases), you may find that something like CodeIgnitor or CakePHP will get you to 90% in next to no time. For realz. (Both of these frameworks are excellent, by the way. Which one you'd use is really a matter of taste.) You can bang out a small site with a blog/news section, a forum, a contact form and a way to create semi-static content pages in a couple of days (modulo design work). But you may find that you have to step outside of the framework in order to provide unique features, and that can be frustrating -- sometimes it's difficult to make framework-provided features work with your custom code and vice-versa.
I've always preferred the "bottom up" approach to programming myself. As Leviathon noted above, you are going to end up with your own bag of tricks eventually by simply surviving the development wars, and as long as you don't throw everything away at the end of every project, you'll wind up writing applications in your own version of the language rather than in raw PHP. The difference between your "framework" and the off-the-shelf varieties is that there will be no black boxes, no surprises, and no absolute limits.
- Messages
- 4,467
- Reaction score
- 95
- Points
- 0
At first, I wrote "pure PHP" apps. All the code was mine. After a while, I started grouping similar functions in classes and putting them in separate files, it was my custom framework. Then later on, to upgrade and extend my application, I ported it to a framework that enabled me to keep most of my app-specified application logic. At that time, I was using frameworks for everything: the simplest web notepad (a form that saves to a database and a list to view all the pages) to complex websites with semi-static pages, a blog and forms. After a while, I started fighting against the various components of the frameworks and started using a mix of framework components and custom framework code.
kariciu
New Member
- Messages
- 2
- Reaction score
- 0
- Points
- 0
Go with the manual php coding. With a framework you will almost endup in "stuck" somehow.
But... there is a mater of size, how big is the website? if it's too big...a framework or cms is the only alternative when time is a problem. And you also get to know the framework better, unless....
from that experience, witch i think you had, get to the conclusion that a framework or cms is always gonna be slower and more problematic than manual php, html, css and some kind of javascript. You can create a custom code and keep using it as a fundation for you're future projects. Something like you're own framework or cms, but...simpler, faster and easy to use than anything else, and you won't need a manual.... I think the most important step in developing a website is create a realy good list of ... what the site is suposed to do, and make it do only that, fast, with the minimum amount of code, in the shortest time posible.
Have a nice coding!
But... there is a mater of size, how big is the website? if it's too big...a framework or cms is the only alternative when time is a problem. And you also get to know the framework better, unless....
from that experience, witch i think you had, get to the conclusion that a framework or cms is always gonna be slower and more problematic than manual php, html, css and some kind of javascript. You can create a custom code and keep using it as a fundation for you're future projects. Something like you're own framework or cms, but...simpler, faster and easy to use than anything else, and you won't need a manual.... I think the most important step in developing a website is create a realy good list of ... what the site is suposed to do, and make it do only that, fast, with the minimum amount of code, in the shortest time posible.
Have a nice coding!
- Messages
- 1,165
- Reaction score
- 27
- Points
- 48
I don't quite agree with you there kariciu. Frameworks are made to simplify and speed up the coding process.
If you get "stuck" with the framework you can easily extend it to do exactly what you need it to do. They are all OpenSource you know.
If you get "stuck" with the framework you can easily extend it to do exactly what you need it to do. They are all OpenSource you know.
- Messages
- 3,295
- Reaction score
- 227
- Points
- 63
I'm pretty sure that "slower" was meant in terms of execution speed, not the dev process. Frameworks are a trade-off: developer time versus code bloat. (Admittedly, some of the more lightweight frameworks minimize the bloat, but at the expense of increasing the likelyhood that you'd need to write extensive custom code.) It really depends on what's most important -- if you have to emphasize scalabilty (whether that's because you expect a Facebook-size user community or because you need to stay under the limits of shared hosting), then minimizing memory space, the depth of the call stack, database hits and general processing is a lot more important than developer convenience (and, to an extent, maintainability -- comments and documentation stop being optional). When developer time, coding conventions and consistency are the limiting factors (and hardware/network concerns come a distant second) then a framework makes a lot more sense.
Let's take the Wordpress problems here as an example. Anyone with a modicum of skill on the LAMP stack (or, really, on any runtime environment for the web) can write an app that is indistinguishable from a themed instance of Wordpress and that will run with a much smaller memory footprint, have fewer database hits, and go like stink. But it's going to take a whole heck of a lot longer than installing Wordpress, installing (or writing) a theme, and running config. But though it might be easily restyled (if the HTML is right), it won't be nearly as configurable as a Wordpress install. Why? Because the YAGNI code wasn't there by default.
The same sort of thing can be said for more general-purpose frameworks. CodeIgniter, for instance, has a wonderful little calendar class that is fine and dandy -- unless you actually need to create a calendar. You need to move up to something considerably heavier before you get to "the real thing" as a built-in class, but that class will need a model and an ORM below and a view above in order to be useful. Great if you are using it everywhere, but just bloat if all you wanted was a calendar (and the include/require pool is awfully deep -- file loads aren't free). It's quick and easy from a developer perspective, but there is always a computational cost to be paid.
So what am I trying to say here? "Horses for courses" is the best way to put it. There is no One True Way. Whether you're talking about development time or performance, the rule is still the same: good; fast; cheap -- pick any two.
Let's take the Wordpress problems here as an example. Anyone with a modicum of skill on the LAMP stack (or, really, on any runtime environment for the web) can write an app that is indistinguishable from a themed instance of Wordpress and that will run with a much smaller memory footprint, have fewer database hits, and go like stink. But it's going to take a whole heck of a lot longer than installing Wordpress, installing (or writing) a theme, and running config. But though it might be easily restyled (if the HTML is right), it won't be nearly as configurable as a Wordpress install. Why? Because the YAGNI code wasn't there by default.
The same sort of thing can be said for more general-purpose frameworks. CodeIgniter, for instance, has a wonderful little calendar class that is fine and dandy -- unless you actually need to create a calendar. You need to move up to something considerably heavier before you get to "the real thing" as a built-in class, but that class will need a model and an ORM below and a view above in order to be useful. Great if you are using it everywhere, but just bloat if all you wanted was a calendar (and the include/require pool is awfully deep -- file loads aren't free). It's quick and easy from a developer perspective, but there is always a computational cost to be paid.
So what am I trying to say here? "Horses for courses" is the best way to put it. There is no One True Way. Whether you're talking about development time or performance, the rule is still the same: good; fast; cheap -- pick any two.
- Messages
- 1,165
- Reaction score
- 27
- Points
- 48
Yes essellar, I'm working with Magento (eCommerce platform) now so I forgot about performance A default Magento installation has approximately 10000 files and around 70 MB! This is because Magento is the most robust eCommerce platform on the market. To put it simple, it can do anything.
A default Magento installation has approximately 10000 files and around 70 MB! This is because Magento is the most robust eCommerce platform on the market. To put it simple, it can do anything.