Why "NO" to: MySQL, Symfony, CakePHP, Smarty, etc.
open solution
很有趣的观点，虽然都让say no，不过感觉被安利到了很多。
Why "NO" to: MySQL, Symfony, CakePHP, Smarty, jQuery, Bootstrap, etc
This article wasn't written just to look for good and bad sides of specific technological and programming solutions. Its point is to show philosophy Quick.Cart and Quick.Cms creators are guided by when choosing certain solutions over other.
This article is for those readers, who have at least the basic knowledge of webdesign. If you want to create a website or an online shop for yourself, your company, or maybe your friends, you should read it.
Our "NO" to MySQL
Lack of MySQL database is one of characteristics of our scripts. We're not against this technology, but a couple of years ago our enthusiasm was in fact bigger.
Our scripts are based on a file database, which makes them easier to manage. They don't require a database server, which allows them to work on wider range of servers including these on which MySQL is not available.
Installation and configuration of database is not necessary, because it's located in files included in the script and usually uploading script on the server is all it takes to make it work.
Lack of SQL database is also a kind of protection against popular SQL injection attacks, to which a script could be vulnerable if an unqualified person modified it.
The last argument is performance. Lack of MySQL database saves time that would be used to connect to the database and execute queries. In case of Quick.Cms and Quick.Cart, the database files are located on the server with the scripts what makes accessing them much faster.
Example of a database connection
Our "NO" to frameworks (Zend, Symfony, etc.)
As PHP based internet applications programming developed, all kinds of frameworks emerged, that help automatically solve the most common problems with code maintenance, database, etc. Among the most popular are Zend Framework, Symfony, CakePHP, Kohana, CodeIgniter. There are also frameworks developed for the needs of specific companies and projects. Such frameworks are often very useful, mostly free, but actively developed and have good support. They also have their flaws which can be quite significant.
It takes a lot of time to master a framework. Usually the most popular ones include built in mechanisms and functions that help to start working with them and don't require writing instructions for all from scratch. This however makes them often very complicated and it takes a lot of time to learn them. A person who creates new applications all the time could (and should) use them, but if it's just a one time deal or one's programming knowledge isn't very good, it doesn't always pay off. Unfortunately, even though there are many similarities, mastering one framework doesn't necessarily mean it would be easy to start using another. Each one has its own philosophy of working. Sometimes a difficult configuration may stop us from learning one framework and the truth is, that to choose one that would suit your needs, you need to test at least several.
And the size of it! Download a few frameworks to see that even the basic versions are quite large scripts (several to over a dozen MB). When a project is small, the large number of files and code makes it look like taking a sledgehammer to crack a nut. Then you have to consider performance, improvement of which should be the base reason for using frameworks, but it not always is.
And finally we should mention, that this kind of tools are useful for those who create diverse internet applications, because they are usually the base and not a ready-made software. If you develop websites, it's better to use a CMS which is made specifically for that.
Example of Symfony framework code
Our "NO" to templates (Smarty, Twig, etc.)
It's not about templates as in skins - just graphics. Smarts are probably the most popular template system. There are other more or less developed templates such as: Twig, Plates and PHPTAL. Just as it was with frameworks, small projects often emerge developing their own template system. Usually they are short-lived.
The idea behind templates it to separate the programming layer from the presentation layer. That's why a website based on templates in theory allows to change HTML structure without even knowing PHP. It sounds wonderful, but it also has it's flaws. Unfortunately HTML code included in templates requires for example attaching contents from database, sometimes creating a new loop known from programming (for example to display a list). It means, that a person who wants to work with templates, must know how they work, which is something like programming. In other words, using for example Smarts, means learning another language, that they use. You can do the same with PHP itself. In case of large projects using templates may be efficient and sometimes necessary, but for smaller projects it's often pointless to add another library (which itself isn't small) and complicate the project's structure.
The above issues make more and more programmers reconsider using templates and going back to pure PHP. This tendency is even shown in the template systems itself. A few of those were developed, that look more like pure PHP than what we know from Smarts, for example.
Quick.Cms and Quick.Cart used to work on custom made template system. But on one point we gave it up to increase performance and to avoid creating more obstacles for first time users. This way they don't have to learn templates, HTML/PHP knowledge is enough.
Pure PHP code and its Smarty template version
Our "NO" to jQuery
jQuery is a JavaScript library. It helps to write efficient scripts faster, simplifies the code and offers many ready-made functions. But as usual it's a trade-off. The library itself is growing. Optimization and code compression are very good, still jQuery increases website's code size by about 80 KB (first versions were only about a dozen KB). Also, often to use more advanced functions, additional plugins - extensions of the library are required. That is why jQuery with other additional scripts can often significantly increase website's size. If the library's functionalities are used a lot, it does make sense, but often a webmaster could manage without it writing his/her own JavaScript code. That code will be more efficient (if written the right way) and in case of small amount of functions, smaller than the library.
This is how Quick.Cms and Quick.Cart are for the moment. Basic versions don't use jQuery, because custom JS functions are sufficient. However jQuery is required more and more often and attached to some plugins. In the internet one could also observe a trend to create interactive elements on the browser's end. It's quite possible, that jQuery will sooner or later become a permanent part of even the simplest scripts.
Example of jQuery code
Our "NO" to Bootstrap
It's another interesting framework concerning only Front-End. It has many ready-made components for building websites on the end visible in a browser, for example: forms, menus, tables, etc. It is also helpful in preparing responsive version of websites, among others.
It's a very interesting solution, but unfortunately it includes plenty of redundant code which isn't always necessary when creating a small website. On the other hand trimming it doesn't make sense as well. If you're using a library, why limit its possibilities? To use Bootstrap even in the basic version, we must add over 100 KB of code (at minimum) not counting fonts or required jQuery. Comparing it with even the largest Quick.Cart.Ext script, JavaScript and CSS code necessary for the part visible on client-side is about 40 KB. The free edition Quick.Cms requires 14 KB of this code. Of course we can not state, that it is functionally equivalent. The question is, do we need all those functions if we're not using them?
Example of Bootstrap components
Summary
People visiting your website most likely won't even recognize what technologies stand behind it. For a visitor it's just another website he or she is browsing on the internet. The most important thing is to achieve the goal for which the person visiting your website came to see it. Too much code to be loaded or too much time it takes for the page to load due to redundant code that needs to be processed by the server or the browser and which you're not using anyway, may prevent them from that. For you, as the website's owner, it is important to make the website friendly and easy to use and not requiring going through all those complicated technologies and scripts, each of which takes time you could spend on something else.
You can see the difference yourself, check out the performance tests of our scripts ».
Our scripts' performance