For whom is Symfony UX intended?
Primarily for developers or developer teams where there is a low representation or rather low experience with front-end development. You can therefore use it perfectly on the projects where you want to have the best possible ratio of price/UX. Typically for quick prototyping when you need to deliver MVP to be able to validate the business value of the given project.
In this way, you do not have to manage the work of back-end and front-end developers, all the work can be easily done just by a more experienced back-end developer with minimum overlap to JS. You can therefore use the saved resources for the development of new functionalities or possibly for writing automated tests.
Prototyping? That sounds like not being production-ready…
On the contrary. With the help of Symfony UX, you can build a production application with perfect, intuitive, and usable UX, no matter whether you develop e-commerce projects, extensive ERP/CRM systems, intranets, or your new startup.
Does it mean that we can throw away React, Vue, etc.?
Definitely not. Symfony UX fulfills a long-term gap that has so far been solved by each developer on their own. The application will thus not be fully reactive but gets very close to it. An overwhelming majority of users will not notice the difference between the ajaxified application with the help of Symfony UX and the application written in React. And this is the point.
Symfony UX is hence one of the possibilities of how to develop applications that are more user-friendly with the use of the current stack, without the necessity of investing tens to hundreds of hours in reactivity with the help of SSR, especially at the already existing projects.
The use of Symfony UX does not restrict you in any way from the use of other front-end libraries. But it’s good to keep in mind that for such a mixed stack of multiple technologies that solve one thing differently, you should have a good reason. It depends a lot on what project you are actually developing.
Swup — for the SPA-like applications
During the development of modern web applications which are usually being rendered on the server, the ajax requests are used for the improvement of UX — this means sending or retrieving the content in such a way that there is no disruption in displaying the existing page.
Most developers have so far solved the handling of the ajax requests on their own which often complicates the reusability. With the help of the Swup.js integration, you can easily add dynamic elements, smooth transitions between pages even with the change of URL in the address line. As a result, the application will approximate the SPA.
The technical part
How does it all work? First of all, it must be said that no innovative solution is concerned. Other frameworks, e.g. snippets in Nette, have been working on a similar principle for many years. Your first ajax demo probably used the same approach. Which is not essentially wrong.
As a side effect, we have a size reduction of the transmitted content and thus a burden on the infrastructure.
It must be mentioned that the integration of Swup with Symfony did not go such a long way. The response always comes back as a whole and defined snippets are consequently redrawn from it. As a result, there is considerable space for optimization here. On the other hand, the implementation of such a solution does not require changes in PHP code, but only on templates.
Other prepared integrations
Together with the Swup integration, the following components are ready to use:
- Dropzone — drag&drop elements for Symfony forms
- Cropper.js — easy trimming of images
- LazyImage — using the method of blurring as a placeholder for psychological optimization
- Chart.js — rendering of graphs directly from PHP
Currently, the whole Symfony UX initiative is presented as experimental, which means that it is not subject to Symfony’s BC policy, although there is an effort to preserve it.
It will also be interesting to watch whether and in which way the community accepts the offered hand. Whether there will be a sufficient number of developers or whether it is just a dead end as was the case with Symfony 1 and Prototype.
Some developers have therefore objections to the used library Stimulus, in the same way as the managing of front-end dependencies by means of Composer — the winner here was evidently the simplicity over the “correctness” of a solution when front-end dependencies should be managed by a front-end package manager like NPM, Yarn, etc.
Symfony UX brings a certain measure of standardization and the first components for ajaxification of Symfony applications in an official way. Therefore, this is another logical step in the direction that was already shown earlier by e.g. integration of Webpack.
If you do not have a crowd of front-end developers and a sufficient budget related to it, the matter concerned is the must-have solution for the development of web applications based on Symfony with a pleasant user experience.