A little while ago I read a great article which described a number of reasons against using any of the RAD frameworks available for PHP. Basically, it argued that a good framework should get you off the ground quickly, and then should get out of your way. But none of the PHP frameworks did that. It pointed out that Django was good at doing just that (but that's obviously not a PHP framework).
For the life of me, I can't find the article now.
So I'm curious. Does anyone have any solid arguments as to why applications should not be built on top of a RAD framework? And I'm not necessarily talking about generic applications (frameworks by definition try to solve a generic problem. The quesiton is does that translate well to specific problems).
And when I say built on top of, I mean from the ground up based on the framework. I don't mean referencing the framework as a series of libraries. I mean basing the entire architecture of the application off of the framework (which then ties you into the framework).
I'm also not really talking about rapid prototyping where the code will likely be re-written anyway. I'm more looking at long-term applications that have a specific business requirement to meet, and must be supported and maintained (and modified) for a relatively long period of time.
We always hear about why we should be using a framework. There are reasons galore:
Not reinventing the wheel (although I hate this reason)
Faster development time (since architecture is skipped)
Easier to bring new developers in
Common problems are already solved
etc...
But I'm looking for the antithesis...
Any thoughts?
It is implied that frameworks being written by some unknown heroes who is smarter than you by default.
But as a matter if fact it's often not true.
It has bugs, it can be messy and unnecessary overcomplicated.
Thus, having your own helper library is often more handy than using such a monster, knowing roughly 10% of it's features.
A few ideas:
The type application you are creating does not have a commercial or free framework available (custom hardware-based apps come to mind) (this is the obvious answer)
The system has extensibility requirements that are made more difficult by using a RAD framework (i.e. framework values convention over configuration, where you really need the configuration)
The project scope is small enough that it doesn't make sense to invest the learning curve into using a RAD framework (if you already are past the learning curve, this may or may not apply)
The tools/approach/back-end/platform requirements provided by the framework will introduce unnecessary complexity (YAGNI, using a framework without a business need for its features may increase support costs as you have to support the whole thing, including unused features)
My fear has always been, what happens when a framework stops being maintained/updated (for whatever reason)? Your project is locked into whatever PHP/MySQL versions the framework supported.
I'm doing a little framework research lately.
http://matrix.include-once.org/framework/
And to some extend I have to agree. The majority of frameworks don't significantly simplify development. Particularily the "MVC" frameworks are about abstraction more than utility. There are however always features which do help for everyday tasks. ActiveRecord/ORM come to mind as reducing tedious manual work. Form helpers might do, but I haven't seen a seriously helpful one yet.
Generally I believe, the more functional library code a framework provides, the higher the productivity. But in the case of Zend Framework, it's randomly dwarfed by complexity. However, check some of the smaller frameworks out. Avoid the overly abstract. Look for scaffolding tools, not libraries.
One of the main advantage to not use a framework is that you have more flexibility in what you can code. For project with a smaller scale, it is often better to have that flexibility.
Some frameworks need shell access to deploy.
Scalability, I've read that sharding is an issue
If performance is a priority, frameworks tend to slow down execution speeds
Not all developers familiar with MVC pattern so maintainability if developers rotating in/out of project could be a challenge.
Related
I'm currently trying to find the best solution/technology to build our ERP.
Our line of work is very specific, no ERP on the market would fit our needs (or 50% of them), so we decided to go for an in-house solution.
We were advised to choose a client/server solution (.net + WPF), but the result of the first delivery is below our expectations.
We are currently thinking about starting over in php (with the same SQL Server Database), and wondering :
Would a php framework (Symfony, Laravel) be a good pick ? We need to have freedom, to ensure maintainability over time
Would a front-end framework (Bootstrap, Foundation, Materialze) be a good idea
Or should we do everything from scratch
Our main concerns are :
Those framework (and the web itself) will evolve, meaning we have a high maintenability risk (although we can prevent our employees to not use our recommanded browser)
Those frameworks are already well organised, meaning it might be difficult to do whatever we want with them
If we use addons (like UI Kits, JQuery scripts), we will multiply compatiblity risks over time
Considering the investment, our solution should have a 10-year lifetime (with maintenance and improvement over time, of course)
While this question is based on advise and not really suitable for this website. I will do my best to answer your questions.
Would a php framework (Symfony, Laravel) be a good pick ? We need to
have freedom, to ensure maintainability over time
It would, Laravel is based on Symfony and has more out-of-the-box solutions. With Symfony you have more freedom.
Would a front-end framework (Bootstrap, Foundation, Materialze) be a good idea Or should we do everything from scratch
You could use any of those font-end frameworks, however they update reguarly, keeping up with trends. Updating a font-end framework means updating every view you have. You could choose not to update however.
If we use addons (like UI Kits, JQuery scripts), we will multiply compatiblity risks over time
jQUERY has been around since 2006 and is not likely to go anywhere anytime soon. It would advise it is safe to use.
I'm currently working in a company that made a from scratch ERP 8 years ago. They had a similar line of work and no ERP fits the needs.
So 8 years later (today), the erp is still used every day, but it's like impossible to maintain. Php (and tech in general) evolves so fast that you can't waste time (and money) evolving it.
Server version
Security failures
...
I recommend to use a "safe" framework with :
long term support
Easy migration system between versions (which means you can evolve your erp easily)
So yes, using a framework is the solution imo. And symfony seems to be the safest. You'll first need to learn how to use it properly but after that you'll be free to do whatever you want with it. Moreover, you can find help everywhere on this framework. It has a strong community which is an important strength.
In the front office, Bootstrap and JQuery are safe too. Bootstrap has a strong community too, and jQuery is not moving on versions.
I'm working on ERP solution and all I can is tell you about how we do it:
PHP framework should be used for your project because it gives you a
good base on what to work on and speeds you up. I'm working in
Laravel and it has all I need.
We are using Bootstrap 3. I'd recommend using some sort of front-end
framework because if your html will be written in easy-to-read manner
then upgrading to newer versions of framework shouldn't be hard.
We use JS + jQuery + vue.js. All I can say is: you shouldn't rely on
JS, php is what your project is based on. JS should be used for
simple stuff that make page feel more dynamic. As JS libraries are
written in JS they will barely lose any functionality over time.
I really should vote to close this - it's both too broad and primarily opinion based.
If you want to develop a web based application using Java, C or C# then a framework is pretty much essential. But with PHP it's a very different story - you are starting with a language specifically designed for the purpose which comes with a rich library of tools from a single vendor. Further if you develop on a Linux platform then the development tools and the platform all come under one provider for patch management. As soon as you start adding in third party components, the problem becomes much more complicated.
For seem reason, Open Source projects seem to thrive and do well when they are making frequent releases. For commercial software regular releases are important for generating revenue streams. When a product is finished in development it seems it is finished in the market. Consider pound vs haproxy.
IME the quality of code you can download from the internet varies greatly. Sadly popularity does not always equate to quality (but price has little relationship either). Frequently programmers are too focussed on delivering functionality to consider security, performance and scalability. Indeed there seems to be a belief that adding more functionality into a framework gives it some advantage over other products (more functionality = more complexity = more bugs = less security + harder to fix).
A problem specific to PHP frameworks is most seek to be all things to all people (more complexity) - providing session abstraction, templating, database abstraction, templating, routing... There are some exceptions of highly focussed tools (e.g. smarty for templating, metabase or AdoDB for database abstraction, jQuery for interacting with the DOM) which focus on doing one thing and doing it well.
Once you start adding third party code into your system, you need to ensure methods for ensuring that code is up to date - but the cost is up front - adding the second, third, fourth... package has a lot less impact than adding the first one (assuming that you do put proper process in place around the management of sourcing and deployment). Using composer helps (but falls a long way short of fixing) the base problem.
Yes, you will be encountering problems that other people have written solutions for. Using a (good) framework or library will probably save costs early on in the project (once you have dealt with the bump of getting your development team up to speed).
Those frameworks are already well organised, meaning it might be difficult to do whatever we want with them
I suggest that if they are well organised it should make it easier for you to do whatever you want with them!
But have a look around SO - frequently people are posting questions asking how do I do xyz with CakePHP / Falcon / CodeIgniter / Laravel. In most cases, what they are asking would be easier to do without the framework rather than via the framework.
I could go on, but this reply is already too long.
There is no answer to your question. If there was it would depend on a lot of other factors like available skills, risk appetite, budget....
If you decide to use a framework (or frameworks) then do consider building the system around micro-services and (if practical) avoid using the frameworks front controller. This will reduce your dependence on the framework if you ever need to re-engineer it out.
Many conversations on frameworks tend to discuss ease of use and speed of development. These issues are important but they tend to come from developers who are creating new low traffic projects over and over for different clients. It is important in that situation to be able to knock out a solid solution for the client in as little time as possible. I myself have operated in this area for many years and have used many MVC frameworks with much successes.
But what about when you are working on a single high traffic application for several years? Now ease of use and speed of development start to take a back seat to scalability and speed. It doesn't matter how easy it is to use or how fast you can write code if the application won't function because of speed and scale.
My question to any large scale developers out there is, are frameworks still useful in this situation and if so which have been used successfully in large scale production situations?
common frameworks: zend, symphony, codeignitor, cakephp
When it comes to large applications, it's not the framework you should be concerned about, it's the database.
First decide which database you going to use, then look for a framework that has good support for that database. If you want your app to scale to unlimited size and still be fast, you should eliminate Mysql as an option right from the start.
Look for NoSQL solution, find the one that you like. Cassandra, MongoDB, CouchDB are the top 3 choices, but there are others. All of these are fairly new, but some of the biggest sites in the Internet are using them. Do your research, choose database, then choose framework.
I don't know most of the frameworks, I looked at Zend and Symphony2, both support MongoDB, both are pretty fast. I would look at either one of these 2, no reason to look anywhere else.
But really, if you plan on writing a really large application you should really write your own code and don't use frameworks. This way you will have only the functions that you need and none of functions you don't need. Remember most frameworks offer you a lot more functionality then you really need. Unnecessary functionality usually slows down your app.
if you want a fast app, then it has to be lean, only do what you need and nothing else.
symfony is used by Yahoo on it's Bookmarks and Answers site.
You should note they ditched the ORM so the database remains as the main concern for scaling (as Dmitri stated), you can read more about it here.
Dailymotion is also using symfony.
My question to any large scale developers out there is, are frameworks still useful in this situation and if so which have been used successfully in large scale production situations?
I've seen symfony-based applications successfully scale up to many thousands of users so is a strong candidate.
The creator of php liked codeigniter(in the past) the best, because it is the fastest framework when he benchmarked it. You can listen to video about that over here.
To add on to what the others have already said:
You can start off with any framework as your starting point. As your application gets bigger (and I mean, BIG), you can start modifying the framework and customizing it to your application's specific needs. After all, frameworks are a general solution to most problems.
You should pick whatever framework you're most comfortable with, and tailor it to your needs if your application ever grows extremely large. No point worrying about a million visitors when you don't have them yet.
WordPress.com is about the 22nd most popular website in the world and it runs on (you guessed it) WordPress, which is a framework with a large amount of overhead. So it definitely is possible.
Whether you are using a framework or not, you end up working on the same kinds of problems as your site gets to massive scale. Building on top of a framework means that you'll have one less problem (no custom framework to write) while working on other scaling issues. However, you may have to extend or tweak that framework to work with whatever technology you need to scale.
And in general, what I would recommend is that you don't blaze your own path. Find an app or site that is comparable to the one you are building and figure out what technology and techniques they used to build that site (many like WordPress.com, Twitter, Google projects are well documented or have chatty developers) and use the same technologies and techniques. You'll benefit from them figuring everything out ahead of time.
Zend Framework is a good framework but not very fast.
Can you tell whether it's worth using Zend Framework for highload projects, for example, for email marketing service that can inlude about ten or houndred thousand of users?
Is it possible to achive acceptable performance using Zend Framework?
Has anybody such an expirience?
Thank you very much.
For what I have seen, the definitive defense of Zend Framework performance and recommendations for performance optimization comes from Padraic Brady at:
PHP Framework Benchmarks: Entertaining But Ultimately Useless
In particular, note his four recommendations for performance optimization:
Don't use Zend_Application. While Zend_App is great for creating consistent complex bootstraps within a standardised structure, it doesn't come without a significant performance hit to baseline performance. A more direct bootstrap (typical of ZF until Zend_App arrived) is far faster and can also be done without configuration files.
Skip using the ViewRenderer plugin. Without the ViewRenderer, you need to manually configure Zend_View and add render() calls to Controllers. This is actually very simple to do and is fairly fast - fast was never really part of the ViewRenderer's genetics.
Use autoloading. Strip require_once calls from the framework library so unneeded files are ignored. Replace uses of Zend_Loader_Autoloader with a not-so-crazy autoloader function. In fact, pray Zend_Loader is never used - it does a lot of file ops that, to date, have never been explained to me as having any value.
Preload everything (Symfony 2 Preview does!). It buys you some performance cookies and equalises the speed baseline. Using a simple preload script is not that hard.
We've used ZF in a lot of high traffic sites, and we've had no issues so far. We did have to jump through a few low-hanging hoops, though.
Some suggestions:
use Zend_Queue to help with batch mailing
use Zend_Cache whenever possible
Use plugin loader cache
Strip require_once calls in favor of autoloading
Get rid of components you don't want. (as suggested, you would not need MVC stack for CLI / mail)
We chose Sphinx in favor of Zend_Search_Lucene (enormous performance gain)
The bottom line for us has been this: development time is much, much more expensive than hardware. The flexiblity and higher re-use of code completely trumps any minor performance losses we had to deal with. For the most part, the performance overhead was very fixed.
You ask:
Is it possible to achive acceptable performance using Zend Framework? Has anybody such an expirience?
Yes, I have experience with a site with millions of users. But you do need to use techniques to deal with the high load. Caching etc...
A CDN can help a lot. Look into developing with the cloud. Amazon might be a pain to get started with but it helps you scale if need be.
I guess what I'm saying is, the Framework may cost you a bit of performance, but helps make maintenance possible and building it faster (once you get over the learning curve). Then you you have to evaluate what needs to be done to improve performance (although it helps a lot to plan for what will be obvious problems, right from the get go).
I know of several companies that use ZF in high-performance/high-load scenarios. I don't know which ones I can state and which ones I can't, but some of them are media companies who have to handle popular TV shows. Others handle live sporting events. Others are multi-billion dollar companies who need to serve their internal organizations. So, ZF is being used by plenty of companies who run pretty high-load sites. One of our case studies is Fox Interactive (http://framework.zend.com/about/casestudies) and I know of several other customers who use it for high-performance websites.
Zend Framework MVC, out of the box, will be quite fast. My blog comes back in about 100ms without caching and there's a fair amount of stuff that happens on my front page. I could probably drop that down to 50ms with some internal caching (Full page caching could drop it down to single digit ms, but then it's not touching ZF).
Seconding Joe's answer. I've also seen ZF deployed on a few sites handling millions of requests and have yet to encounter a problem. When dealing with that amount of traffic it's a good idea to use other strategies beyond your framework, including but not limited to caching and the use of a CDN.
I've found most frameworks will call or create many class instances per request which I think is what causes people to say that framework X is slow without having any real world experience with it. Any hit you take there can be easily mitigated by using an accelerator and caching.
If you already have a team of devs you've hired, I'd suggest using what they feel most comfortable with and have the most experience with. Best case they'll be able to tune their code for that framework.
A lot of the framework, any framework really, is used for building and managing the project development but the resulting project is 'just' php, html, css etc. the same as any other php web site. So what evidence do you have, that's real timing against other framework and non-framework built sites not anecdotal evidence, that a Zend project site is slow.
Edit -- answers to below --
I don't think the structure that the framework uses will hurt performance. It may be more a question of PHP being acceptable and then how much 'overhead' is added with the site design and the optimisation of loading say JavaScript's etc. I would imagine that using the Yui guidelines of minifying JavaScript and CSS and loading them in the correct order and making sure the PHP code is efficient will help. You can also use other standard things such as DB Caching and Zend Accelerator will speed things up. One thing to be careful of would be the DB connection. The use of an ORM layer might have an impact.
However back to the original question about the framework i think it is similar to asking if using Eclipse or Textmate has an effect on the speed of the resulting site.
Yesterday Facebook launched HipHop, a sourcecode-converter from php to c++. The set of php functions and constructions is more limited than in standard php.
Are the current popular php frameworks (ZF, CakePHP, symfony) compatible with HipHop? If not, which parts of these frameworks are not usable?
If I'm not mistaken, HipHop has not been released yet -- even the wiki page linked from the Facebook annoucement yesterday is not up yet.
So, it's going to be a bit hard to answer, right now.
I suppose it'll all depend on :
The features used by the Frameworks -- like already said here and there, stuff like eval is not supported by HipHop
The PHP extensions used by the Frameworks : only a couple of those have been ported by Facebook to HipHop.
Depending on the Frameworks and your specific needs, maybe/probably some subsets of the Frameworks you are using will be supported, even if not every available components... I suppose time will tell which ;-)
With at least ZF and Symfony being used for Enterprise level applications, chances are pretty good they will run with HipHop. If not now, then sooner or later. However, the question is not so much if they can run with these frameworks, but how your supporting IT architecture looks like.
HipHop is for scaling large multiserver high traffic sites like Facebook. In your regular web application, you will likely get no advantage out of it. Just continue to use memcache and APC.
See these related articles:
http://www.readwriteweb.com/archives/rasmus-lerdorf-php-hiphop-facebook.php
http://ilia.ws/archives/213-My-Thoughts-on-HipHop.html
http://terrychay.com/article/hiphop-for-faster-php.shtml
http://www.brandonsavage.net/hiphop-for-php-who-benefits-who-doesnt/
While I'm sure most of us are curious about what HipHop is going to be, I know it will not be a replacement for PHP - it's very much a niche product: unless you're running a large server farm then the performance benefits vs the maintenance costs just wouldn't justify it.
Perhaps it might be an interesting alternative to use encoded PHP for some people - but again this introduces even greater maintenance overheads. The only low-volume scenario where a compiled PHP would seem to make a lot of sense is for embedded devices (where the software exists to support the hardware and not vice versa) and for very high security installations (where its not a good idea to have a interpreter available).
It's far to early to be able to say what PHP software will work with it. However even once thats established, I'd want to see a solid commitment from any supplier that they were going to explicitly support HipHop in the future before I switched.
C.
I won't repeat what has already been said, I'll just add that as soon as HipHop is released you can count on the opensource community to submit patches for your favorite framework for increased compatibility with HipHop.
Also, one good way to test whether your favorite framework is compatible or not would be to launch the test suite using HPHPi (you then know where to concentrate your patching effort ;).
Searching for 'eval' gives a lot of false positives, as you get hits for the word "evaluate" in comments, or escapeValue if the search isn't case sensitive, etc.
If you search for 'eval(' in ZF 1.11 you'll find in once in Zend/Serializer/Adapter/PhpCode.php on line 59, in a method that unserializes stored PHP code. The method isn't a part of the MVC architecture, db component, and actually isn't used anywhere else in the framework (Zend_Serializer_Adapter_PhpCode isn't instantiated anywhere else in the code base).
So if eval breaks your ZF-Hip Hop app, don't use Zend_Serializer_Adapter_PhpCode, or eval in your consumer code.
Simple answer: I don't think it would.
Just saw this on hiphop page: https://github.com/facebook/hiphop-php/wiki/
"You keep coding in simpler PHP, then HipHop executes your source code in a semantically equivalent manner and sacrifices some rarely used features – such as eval() – in exchange for improved performance."
Did a search for 'eval' on ZF 1.9 and there are over 100 occurrences.
We are about to start a new Web2/AJAX app and are trying to decide if its worth the time and effort learning Ruby/RubyOnRails instead of PHP, CodeIgnitor and JQuery we currently use.
The key issues are clean/fast/modern AJAX UI, robust error handling, ans maintainability.
I would appreciate unbiased (if thats at all possible talking languages/frameworks) comments from experienced PHP and RUBY developers.
I can't say too much about Ruby, but I can say that I often feel like PHP gets a bad rap. PHP is what you make of it. Yes, there is a lot of awful PHP code out there, but you know, it was mostly written by people who would have written awful Ruby, or awful Python. PHP has such a wide audience that programmers of all stripes and abilities are using it, and many of them are writing bad programs.
That said, you can write good programs in PHP. Do you have good developers? If so, you can certainly write good code in PHP.
PHP has a terrible reputation because it is so accessible. Anyone can start writing PHP, and most hosting solutions offer PHP these days, so there are a lot of non-programmer types writing programs in PHP. These programs lack proper computer science discipline.
There is a very widespread movement within the PHP community to move toward readable, well formed code as PHP starts to adopt modern language features. With PHP5, OOP became a practical reality and with that an explosion of books and material written about OOP best practices and development patterns. While PHP is often used to write malformed sloppy spaghetti code, the language facilities are there to allow developers to program in development paradigms like MVC, OOP, and TDD.
Not to mention, PEAR has greatly improved the quality and accessibility of community scripts. PHP's strongest asset is its community, and it has been becoming stronger and more disciplined. In many ways, PHP is very much like JavaScript--it had a very sloppy beginning from which the developers and community have been trying to recover. JavaScript is a very sloppy language, but there are some extremely powerful parts of that language that have brought it some well deserved respect in the age of Ajax and interactive web applications.
Languages like Ruby and Python are chock full of things geared toward computer programmers. If you hire a Python or a Ruby programmer, just by virtue of knowing the language that programmer is many, many times more likely to appreciate clean, well organized code than a PHP developer. That is part of the culture of those languages, and the people who evangelize them.
There is nothing inherently better about Ruby or Ruby on Rails in my opinion. Rails was the first mainstream MVC development framework, but its popularity and success has catalyzed the development of similar frameworks in every language imaginable. The choice to write Rails in Ruby isn't an indication that Ruby is better than PHP, which many could argue. Considering the time in which Rails was written and 37signals' fascination with obscure things, I can understand the move completely. At the time, web scripting languages were pretty lame, and 37signals was looking for a language that catered more to the needs of application programmers, not scripters.
You're not being held back using a PHP framework like Zend Framework, CakePHP, or symfony. CakePHP and symfony are both directly modelled after Rails, even if they aren't direct ports. Akelos is an actual port of Rails to PHP. Zend Framework is the most fully featured framework I've used so far. Don't be afraid to experiment, but jumping ship to a completely different platform isn't necessary and it won't change the way you do business. It's the same business in a different dialect.
The most important feature of a language is how much you enjoy using it. If you enjoy the language that you use, not only will your life be better, you will write better code and be more productive. Of course, this is completely subjective; however, I've never heard any first-class programmers talking about how much they love PHP.
Of course, getting to the level of fluency in a language / framework combination that you really know whether it is going to float your boat takes a big investment of time. In my opinion, the time that you spend will make you a better programmer even if in the end you decide that you like a different tool better, so, go for it!
I think it's not about the language but the disciplines that are used in the community. If you are PHP developer who doesn't unit or functional test his code, nobody cares. There are bunch of PHP developers like that. If you are Rails developer and doesn't test your code automatically you're weird, something must be very wrong with you.
Ruby on Rails seems to me more than a framework, all the tools that come with the community. It is recommended that you use some kind of semiautomatic deployment tool like Capistrano. If you're not, you're weird again. And so on.
I agree with dicroce that you can shoot in your leg with both languages/frameworks. You could go with PHP and try to use some of the tools originally ment to Rails and i believe you get a great result.