Programmers out there!

3 years ago

This weekend I've been looking into PHP frameworks. Everyone raves about them, so I thought I might as well read through a bit of a documentation (I say a bit, really it's pages and pages and pages).

So far I've looked into CakePHP, Symfony, Laravel, Zend and Kohana. Whilst I like the idea of switching to MVC-based development (would make REST APIing easy) and URL routing is rather nice, I keep coming back to one issue in the back of my mind:

All these things are going to be bloated and slow as fuck.

Can anyone else who's worked with them offer an opinion? Over the years I've built my own toolset for things like encryption, cookie handling, input sanitisation, etc etc. I've already designed the wheel, so to speak, so switching to a framework doesn't really change anything for me. I think primarily what I'm searching for is a way to just switch to MVC, but surely I can do this super quickly by myself without the aid of a framework?

Comments (32)

  • washyboy

    washyboy

    3 years ago

    if what you're looking for is to make RESTful APIs more easily in PHP, then try www.slimframework.com/

  • Holabalola

    Holabalola

    3 years ago

    I don't like using any kind of librarys or frameworks, they probably don't slow things down much but I prefer to always write code myself.

  • rupertjeff

    rupertjeff

    3 years ago

    We use CodeIgniter at my office and it's not only lightweight, but it also makes app development very easy. I was hesitant at first myself, but after using it for almost a year now, I wouldn't want to start a project from scratch OR use any of my own home-brewed code.

  • ACiDaRiS

    ACiDaRiS

    3 years ago

    I would suggest taking one or two of the frameworks for a test drive -- recreate a common system using one of the php frameworks, and use something like jmeter (a java based tool you can use to simulate load on a server) to fire up a bunch of threads to use the normal version and the framework version. You can time how long a request takes on average in both systems. See if the performance hit is large enough that it would seriously impact the site if you were to use it.

    On the subject of MVC: I like MVC because the separation helps make a clearer distinction between what code does what job, and allows me to more easily reuse the same Model code across different Views. It also allows you to better make automated tests for your code to make sure when you change something, you don't break something else along the way.

    As wikipedia will tell you MVC doesn't REQUIRE a framework, and you will be able to accomplish MVC methodologies without one, but it's possible a framework will accomplish what you want in cleaner ways than you would on your own.

  • Genek818

    Genek818

    3 years ago

    Well...Joel makes pretty good cookies...xD

  • Baillie1987

    Baillie1987

    3 years ago

    I literally have no idea what any of these things mean

  • zeel01

    zeel01

    3 years ago

    I am a firm believer that anything worth doing with a framework is worth figuring out a way to do myself.

    The framework designer found a way to do it, so why can't I find a way, that doesn't involve bloat/someone else's code to work with. So I would definitely recommend that you find your own way, relying on a framework might save time now, but it will suck later.

    • zeel01

      zeel01

      3 years ago

      Yes you can trim it down, you would need to decide if the time spent trimming is worth the over all benefit. I'm afraid there is just far more that needs to go into deciding this than a message board discussion can deal with.

      I think Ben will have quite a bit of work just determining the best course of action. Best of luck.

    • AndyHunt

      AndyHunt

      3 years ago

      zeel01
      You mention the percentage of features used in the processing of a request being low meaning the overheads are not worth it. However, experience tells me that plenty of frameworks can be trimmed down to the essentials (core stuff and what you need) without any damage to functionality, speed or maintainability. By removing excess "fat", you can raise the percentage of used functionality and regain the benefits.

      However, as you so rightly say, situation is everything; and it should be that which guides a decision, not purely technical information.

    • zeel01

      zeel01

      3 years ago

      AndyHunt
      That can be true, it really depends on one thing: What percent of the frameworks features will you be using per average page load? If the answer is a high, the overhead is worth it, if the answer is low it certainly is not worth it.

      It would probably be beneficial to take a look at what you are doing, and what the framework will do for you. Compare the numbers, and let them guide your choice.

    • zeel01

      zeel01

      3 years ago

      Possibly, but it seems like that could be taken care of by documenting the code well. I have learned all I know from reading, it isn't that hard. So if you provide the new employee with a full set of documentation, and an overview, I imagine anyone worth hiring should be able to pick it up rather quickly.

    • AndyHunt

      AndyHunt

      3 years ago

      As Ben pointed out, not having to familiarise new developers with some proprietary code is a big benefit. It's also worth adding to that the considerable contributions and knowledge base of the surrounding community of the chosen framework.

      Strictly following the "anything worth doing with a framework is worth figuring out a way to do myself." will quickly lead to you unnecessarily reinventing the wheel.

      "Good programmers know what to write. Great ones know what to rewrite (and reuse)." The Cathedral and the Bazaar (Eric S. Raymond)

    • Ben

      Ben

      3 years ago

      One of the important benefits though is the ability to hire more developers down the line who are already familiar with your backbone. I wouldn't need to train every new employee anywhere near as much.

  • Radius55

    Radius55 Site Admin

    3 years ago

    Ah, all I've got is a few years of Java and C, and a bit of HTML. Never really got into web design.

    Good luck learning it, though.

  • K25125

    K25125

    3 years ago

    I recently moved from PHP to Ruby. Rails specifically is great for MVC, and it's relatively easy to implement complex stuff, considering how well documented it is and how consistent the conventions in Ruby are across frameworks.

    Your main issue with it would be deployment, since it takes a bit of work if you use Apache, but it's definitely possible.

  • AndyHunt

    AndyHunt

    3 years ago

    What you're looking at is a careful balance between maintainability and the cost of overheads. Of course, it all depends on the context. If performance is EVERYTHING, then the overheads are costs you can't afford. For most other situations, the overheads are an acceptable loss.

    As for specific frameworks, Zend and Symfony have been proven, by industry, to be strong frameworks for industrial use.

    If you don't already read it, programmers.stackexchange.com has a lot more information on this topic, and will be able to give far better answers than the people of the Rooster Teeth community - fantastic as they are.

    • AndyHunt

      AndyHunt

      3 years ago

      Oh, and as for Kohana: while it's a very good framework with good extensibility, tools and all that jazz, the documentation is very poor; they advise you to read the source code instead.