What is coming in the next versions?

What will future versions of Nette Framework bring and what is the plan for further development?

Nette is made up of several libraries, some of which are world leaders: Latte is the safest template system, Tracy is considered by many to be the most user-friendly debugging tool, Dependency Injection Container is among the most convenient to use. Many concepts have been created with a happy hand and have been operating virtually unchanged for 10 years, such as forms or component system presenters.

However, there are many opportunities for improvement and innovation in all areas. And there are plenty of ideas.

Nette 3 coming soon

The main priority is the early arrival of the new version of Nette 3. It will be designed for PHP 7.1 and will take advantage of its major innovations such as:

• will run in strict mode
• the code will use scalar type hints
• the methods will have return types

At the same time, the intention is to prepare:

• automated code update tool for the new version of the framework (as used for Nette 0.9 and 2.0)
• update documentation including examples
• generate API documentation on the web https://api.nette.org (currently missing documentation generator)
• ensure compatibility with the upcoming PHP 7.3

Other features will be included in Nette 3:

Application

• separate routing into a separate package
• CSRF protection for signal references

DI

• autodiscovery: automatic registration of services by mask, similar to presenters
• a validate schema for the NEON format
• support for the passing of an array of services of a certain type (@param Service[])
• support for passing an array of tagged services

Forms

• automatic CSRF protection
• example renderer for Bootstrap 4

Latte

• generate a “source-map” that Tracy will understand
• optional chaining support $​var?->call()?->elem[1]?->item

Tracy

• speeding up dump with JavaScript
• support source maps Latte

Nette 4

Immediately after the release of Nette 3, the development of Nette 4 would begin. The main innovation would be to change the internal architecture to middleware. The component for processing and sanitizing an HTTP request, router, PresenterFactory, and presenter itself would be middleware layers, which would easily include other layers or replace those existing ones. This should make it much easier to run different applications or even frameworks on the same website. Each layer could reject the request, for example, a router could legitimately throw an error 404. At the same time, the new solution should be fully compatible with existing presenters so that it will be possible to build applications using both new middleware presenters and current presenters.

This change in architecture will solve many issues that have existed in the framework for a long time, but it was not easy to bring them out of the world:

• RequestFactory: rejects invalid URL [WIP]
• Http POST with Content-type: application/json
• Character ? is ignored when canonizing URL site.com/? to site.com/
• Http\RequestFactory: added workaround for exceeded post_max_size
• redirect() in component does not respect server port
• MessagesStorage & RequestStorage
• Refactored flash session to Http\FlashSession

More plans

At least, I will try to mention other plans for important packages. In which version will be implemented is still open.

Application

• native presenter for REST and API
• easier to use LinkGenerator under CLI
• replace direct sending of HTTP headers (via HttpResponse) with abstraction
• speed​up link generation by caching
• possibility to insert template blocks into components
• solve the problem with the link this or form in Error presenter
• cmdline tool for pre-generating presenters and templates

DI

• resolve an issue with extension priority

Forms

• native support for fully dynamic forms
• support for native AJAX validation
• linking to entity classes, setDefaults() will receive and getValues() return the entity object
• modify the object design so that setValue() and getValue() can have the correct typins

Latte

• create a new AST parser to take macro options to a new level
• possibility of linking the template to the class (and its properties) so that code completion or static checking can work in the template as well
• implement sandbox mode
• simplify the validation of templates
• add support for other libraries and frameworks, create tutorials or converters for other template systems

Web and forum

• It is planned to change the navigation and division by components
• Replace the forum with a newer one, for security reasons
• and, of course, the gradual improvement of documentation as before

There are just a lot of plans.