I won't lie to you. Hardhat is not designed to replace all the other frameworks. It is designed to be simple to use to develop websites and web applications.
If you are like me, you have had an experience like this. You need to put up a website quickly for some purpose. You want to have some structure to it because it may expand in the future, but you don't really want to go through the hassle of configuring some framework for it. You long for a simple framework that will help you get it done rather than get in your way. If this sounds familiar, Hardhat may be for you.
Hardhat automatically replaces all post transactions with redirects to a get transaction so it is not possible to accidently resubmit a form. Plus by separating the Post transaction from the ensueing Get transaction, it makes a nice clean separation of concerns. This is an area that I feel most frameworks overlook.
Posting data is fundamentally different than displaying a screen. With Hardhat, the Post transaction is processed, data is updated (if it passes validation), and a Get transaction is issued to display a screen. If the validation failed, it is likely that the input form will be redisplayed with a message. If the update was successful, a confirmation page may be displayed. The point is, that it is a new transaction, and if the user then refreshes the screen, it will reissue the Get transaction, not the previous Post. This means they won't get the annoying "do you want to repost data" message.
I should point out that in the above scenerio, it is likely that it would never get that far because Hardhat includes logic to help format jQuery commands for the jQuery validation routine. See the next item.
You can specify validation rules that will drive validation on the server and the client as well. Let's face it. You have to have server side validation because you can't trust the client to do it. But, client side validation is so much more friendly to the user. With Hardhat you can specify the rules once and they will be used for both. Client side validation is done via the JQuery validation plugin.
Add a field to the database and it is available in the view. What could be simpler. Of course, if you want to update it, there is still the process of filtering and validating the input before it is inserted into the database. Hardhat will help you with that too.
Smarty helps make sure your HTML looks like HTML and not a bunch of PHP code. It also helps you to resist the temptation to put business logic in the view. Smarty is really a nice templating engine, and for most things you only need to know a few key things, which are documented in this guide.
Ok I understand not everyone is a fan, but there are some good reasons to use it. If you really don't like it, it is easy enough to just not use it and use pure php as a replacement. You can read about why I like Smarty here.
If performance is your issue, remember that Smarty Templates are compiled the first time they are accessed, and after that you are executing pure optimized php code.
Hardhat uses a classloader which contains an autoload procedure so that classes can be automatically loaded when they are referenced. This eliminates the need for a whole bunch of require_once statements all over the code.
Hardhat uses an xml file (commands.xml) to map all urls to action classes. This gives you complete control of urls for search engine optimization, or even to redirect urls of a rewritten system. This also documents all access into the system in one place. If it is not in the commands.xml file it can't be executed.
Some Frameworks, Code Ignitor and Zend to name a couple, use a controller model where part of the url maps to the controller module, and part maps to the function within the module. Here is the problem I have with that approach.
First it means that some code will be loaded that is not being used. It is doubtful that you would be adding a record, deleting a record and updating a record all at the same time. So why would you want to load all that code at once? Hardhat only loads what is needed for that particular transaction.
More importantly when you are looking at the code, you can easily get lost and get the update record logic mixed up with the add a record logic. If each module only did one thing, you would know for sure that everything in there was related to that one thing.