Frameworks in web-development

[birbal]

i have seen in many web developer job recruiting criteria they demand of knowing any framework or some of them ask for CMS. I have not used any of them yet and still not decided to learn any of them. I stil feel its better experience to do it by yourself.I like to know, is there any good reason to learn any of them (except the time saving part of using frameworks.)? and if anyone uses any framework or not for their work? i want to know mainly about php frameworks, but it will be great to hear about js or css frameworks too. Thanks!

Edited August 2, 2012 by birbal

[justsomeguy]

Other than saving time, frameworks are usually wrappers around existing functionality that are either more powerful, more consistent, or easier to use. You should look into Zend Framework 2 for PHP.

[birbal]

do you use zend framework 2 for your work? will it be worthy for future to give time behind it?

Edited August 3, 2012 by birbal

[justsomeguy]

I don't use it now, but the upcoming rewrite of our application will use it. It will be worth learning. Take a look at the documentation and see what's in it, it's pretty comprehensive.

[birbal]

i have downlaoded zf2 and its docs and will read it soon. thank you! is there any specific reason your application is rewritten using that and moving to ZF2? i am curious to know.

[justsomeguy]

I'm not sure exactly what you're asking, but it's certainly time for a rewrite of this particular application and it makes a lot of sense to move to a common framework that can replace most of the custom classes I've written. Classes in the framework like Authentication, Cache, Config, Crypt, Db, Log, Mail, Permissions, and Session can replace things I've built or downloaded, and there are several other helpful classes (like EventManager, Mvc, etc).

[birbal]

i wanted to know what could be the reason for someone like you to rewrite the whole apps using a framework which has already you wrote and worked well. you said 'common framework', i guess it is the one of the reason to use framework that there will be common standard to use among other developers.I was reading about using frameworks and pro and cons of it and when to use it. though they have not any specific answer and said it is judgmental on situation. that is why i was curious to know what could be the reason, a developer could move on to a framework in a practical case.

[justsomeguy]

Consistency is a big part of it. Instead of needing to cobble together a series of libraries or build my own classes, I can just use a single framework that people have already built which does everything I need and does it all the same way. When I'm building my own classes I'm basically creating my own framework, so it makes sense to use a framework that is already built and tested for most of the basic things and let me fill in the blanks with custom classes for my particular application. I'm not rewriting the application just to use the framework though, I'm rewriting it because it needs to be rewritten at this point, and I've decided that if I'm going to spend the effort to rewrite then I'm going to upgrade everything it uses, including the framework. This application still uses a 2.x version of ExtJS, for example, so I'm updating that to the latest version and updating the PHP code to align with modern practices instead of things that we were using 4 years ago. The application uses the mysql extension, for example, that's one thing that needs to go.

[niche]

I completely agree with birbal's original post. I deal with this issue everyday. I've come to view it in terms of value (one of my hot buttons). DIY approach lets you deal with the whole business/organization model (top-line (revenue) & bottom-line (cost)). Wheareas, the frameworks approach is usually just about cost reduction. That's just code for "I'm fresh out of ideas". We can't afford to be around people like that any more. They always exhaust too many people for what's, at best, a struggle for just a share when, non-frameworks approach would've got it all. It's the red ocean vs. the blue ocean. Competition is just too bloody.

[justsomeguy]

I view it as increasing efficiency, and decreasing maintenance. I have very little time to update the classes I originally wrote for this application, nearly all of my time is spent working on new paid changes or fixing bugs. Instead of me going back into my database classes to replace the use of the mysql extension I need to work on things that people are paying us for. I want someone else to maintain the lower-level framework architecture to leave me free to work on the high-level application architecture and features that matter to our customers. We don't have a single customer who is going to pay me to rewrite anything, they only pay for their own pet changes. Which is fine, but it doesn't leave us with a lot of time to optimize or rewrite existing code. Using a framework that gets independently updated is one way around that. We've been using the DIY approach for several years and it has worked to an extent, but the more our programming team grows and the more clients we take on, the more we need higher levels of efficiency when we're working on this. I don't want to have to teach everyone about the classes I've built, I want to point them to the Zend documentation and then teach them how we're using it. I also don't want to hire a new programmer who wants to come in and convert everything to his personal framework, that's not going to help anything. New programmers need to be able to adapt to whatever we're doing, whatever tools we're using. It's just like installing and updating software. Yeah, it's possible to do all of that by hand, by yourself. It may take you several days to update all of our clients, but it's possible. But instead of paying a programmer for several days of work to update our clients, it's better to automate that process and spend a few days to put together some scripts that will update every client installation and database at once. There's no reason to pay someone to "do it yourself" for several days, and possibly have them screw up along the way, when we can automate that in one shot and move on to the next job. We have too much on our plates to be messing around with little mundane things like rewriting custom frameworks or manually updating installations.

[niche]

I've dedicated most of my career to efficiency and continuous improvement and have found them to be too often unlinked to enough profit. I completely agree that efficiency and continuous improvement is better than none at all. Though If we're to earn a piece of the action, in addition to our fee, I find it difficult to believe a client will continue to pay us as much as they do after they get a whiff that we're using a framework. How do you avoid this potential problem?

Edited August 8, 2012 by niche

[justsomeguy]

What would you say to a client when they decide your team is an inter-changable part?

I would offer to help with the move in any way I can, and tell them good luck. We've had clients who are dissatisfied with how some of our processes work and looked at other vendors, but they come back to us when they realize they pay us a fraction of what other competitors charge. To put that into figures, we have a client who has about 44,000 active user accounts out of about 150,000 total user accounts. We charge that client around $500/month, or $6,000/year. One of our competitors, which charges on a per-active-user basis would charge that client $2.4 million dollars per year. That client just came back to us and signed a 4-year master service agreement. The system I designed has beat out competing systems by Oracle, for a client that even used Oracle in all of their other systems and would have had the benefit of integrating their online system with the rest of their systems. But they chose us instead, and went ahead to order over $50,000 worth of changes to our system to help support their needs. Our company has beat out Microsoft, Adobe, Cisco, etc, (enjoy your silver medal awards guys, thanks for the competition) so I'm not very worried on that front. Using a framework would have zero effect on our clients' decisions as far as I'm concerned, literally not a single one of them has ever asked about the PHP code that runs it. They don't care how it works, they only care that it works. For more proof of that, see all of Apple's customers.

[niche]

Sounds like you're on top of the situation (as I'd expect you to be). Are you using frameworks? If so, what are some ways you've merged it with your process? If not, but plan to, what are some ways you've merged it with your process?

[justsomeguy]

A lot of our process is changing, we're restructuring how we do things as we grow. The only third-party framework we're using in the current version is ExtJS, for the interface. We'll be updating that to the latest version and adding Zend 2, which will replace various Pear packages and custom classes. We're allocating about a year's worth of work for the effort, for one person. We'll have multiple people working on it, but we still need to allocate some people to continue working on custom paid changes. We're at the early stages still though, we haven't formally designed the next version and aren't planning on starting the actual rewrite for several months still. The programmers would like to start that now, but we need to keep making money while we're doing it. There are too many already-paid-for changes pending right now to stop production and start a rewrite, but we're telling people with new changes that it's probably going to be a while. I even just quoted a change for $45k that I would really, really like to do in the new version but they are very persistent that they want it now. That may be a good opportunity to make a little money even if it leads to a duplication of work efforts. That one is a seemingly-minor change that actually requires a lot of fundamental changes to the system. I'd like to be on the call when they hear the price, but then again I hate meetings.

[niche]

You've given me some eye-openers that I won't ignore. Thanks.

[thescientist]

Do you handle any sort of unit testing or continuous integration for your projects? How about version control?

[justsomeguy]

Version control is a necessity, we've got several branches going at any time for various features that eventually get merged back into the trunk and then we tag specific versions periodically. Our installer and updater uses the repository to install or update from a specific branch or tag, or from the trunk. Our testing regimen is probably the most lacking part of our process right now, we typically don't have a formal test plan. The tester just goes through the requirements and checks what he can, but several edge cases usually get missed that we need to end up fixing after the fact.

[boen_robot]

Well, in fairness, testing an app (as in a web site) isn't exactly trivial for automation.Then again, that also illustrates another benefit of relying on a framework - the framework can be (and if you've picked a good framework - is) tested with automated tests (typically PHPUnit), so that you can at least not worry about the framework being unstable.

[niche]

You guys are shaking my world. I completely get the productivity and efficiency benefits of a framework, but what about what's next? Can a framework be modified enough to produce some highly profitable new solution without loosing the advantages of the framework?

Well, in fairness, testing an app (as in a web site) isn't exactly trivial for automation.

I take that to mean the problems of automation are mostly random and one-off especially in dynamic content situations (my words). Unless they have a framework for that of course. Do they?

[justsomeguy]

There are several unit testing frameworks for PHP: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#PHP

[niche]

How do you decide on a framework when your focus is the display and tracking of dynamic content that's transaction oriented? Before this topic I wasn't prepared to believe such a thing existed. I'm still not sure.

[boen_robot]

Can a framework be modified enough to produce some highly profitable new solution without loosing the advantages of the framework?

Maybe. Maybe not. Depends on what you're trying to do, what are your priorities, and how closely does the framework of choice already align with that.Every framework has a "breaking point", beyond which you'd have to "hack" on it (as in "override its foundations"), perhaps using a different framework (although that's rare; developers typically hack with their own framework).

I take that to mean the problems of automation are mostly random and one-off especially in dynamic content situations (my words). Unless they have a framework for that of course. Do they?

Errr.... that's nothing like what I had in mind. And as mentioned, there are testing frameworks, the leading one of which is PHPUnit.What I'm talking about is that tools for automated testing, such as PHPUnit, are geared towards testing PHP code. That's fine, except that a web site is also client side (HTML, CSS and JavaScript...) code, some of which is generated by PHP, but is not PHP itself.A PHP framework is a collection of PHP code, and as such, it is typically tested by PHPUnit. The client side code that a good PHP framework produces on its own is minimal, if at all existent, and as such is mostly reliable.There are also testing frameworks for JavaScript too, but they also account only for JavaScript itself, not for how JavaScript interacts with HTML, CSS and PHP.Or to put this in another way - testing frameworks, in general, account for ensuring a piece of code "works", not that other pieces of code that use it would work.

[niche]

I didn't catch the frameworks - testing unit distinction. I thought the testing unit was part of the framework. Thanks for the clarification boen robot. Is there a good summary for frameworks that you can recommend?