Smarty vs. PHP-Sugar

Smarty has several issues which led to the creation of PHP-Sugar. While PHP-Sugar avoids those issues, it does have a few down sides of its own compared to Smarty, and weighing these pros and cons is important for any developer seeking to choose a template engine.

Parsing Flexibility

The first issue is the inflexibility of its parse engine. Smarty is built by using a series of regular expressions to convert the input source into PHP code. Regular expressions, while powerful, are not a silver bullet for all text processing tasks, and parsing a complex language is one such task. PHP-Sugar uses a model closer to traditional language processors; it tokenizes the input and then runs the tokens through a hand-written parser. This allows for far more intricate expressions to be written in the template language than a regular-expression engine could ever handle.

Ease of Use

The Smarty syntax is very difficult to use. Many programmers find the syntax very restricted, which PHP-Sugar alleviates by using a more powerful parser allowing for almost as much expressiveness and flexibility as PHP itself. However, regular designers - the people who are supposed to be the main consumers of a template language - also find Smarty to be very painful to work with. The default Smarty tags, { and }, were very poorly chosen given how common they are in CSS and JavaScript. Variables must be manually escaped in Smarty, requiring that designers to more work to HTML-escape their data than to not escape it, which is backwards from how it should be - failure to escape data leads to XSS and other Web-based attacks. The Smarty function call syntax, while powerful and clear in expression, can be cumbersome for simpler functions and needs at times. Smarty makes variable assignment and math expressions difficult to perform. Finally, Smarty's separation of functions and "inserts" creates mnemonic overhead that is unnecessary.

PHP-Sugar has none of these problems, and is directly designed to be both powerful enough for programmers and obvious and sensical enough for designers. The <% %> tags are used, which are well supported by many editors as they are also used by ASP (unlikely to be in use with PHP-Sugar). PHP-Sugar supports both complex named parameters and simpler unnamed parameters for function calls. Macro output is safely HTML-escaped by default, and authors must explicitly mark which macros are safe HTML.

PHP Access

By default, PHP-Sugar disallows access to all PHP functions and does not allow templates to invoke methods on any objects set in template variables. These are both intentional security features, which ensures that template authors cannot execute PHP code which the application author did not intend to be callable from templates.

Registering most PHP functions for use with PHP-Sugar is relatively easy, as the Sugar API supports "simple" functions that use the regular PHP call mechanism instead of the named parameter system. Access to object methods can also be enabled by a Sugar API setting.

Using these two features allows advanced PHP features to be fully accessible in PHP-Sugar, but the default behavior is safer than Smarty.

Extensibility

Smarty is difficult to extend in terms of file storage. Creating a new resource type takes several functions, odd registration steps, makes efficient implementation of some file storage backends difficult due to the split between timestamp checking and source retrieval, and doesn't allow for the over-loading of cache storage. PHP-Sugar merges the file storage and cache handling into a single interface and allows the application to provide its own instance of the interface. This does require that more of the cache logic be implemented by users of the API, but this can be a benefit in some circumstances.