Choosing a front end architecture for Symfony framework projects
The most prominent example of something like this is the React UI library and the accompanying ecosystem.Just this week the Laravel PHP framework announced that their preferred flavor is Vue.js. Laravel is known for being very opinionated and I feel adding a suggested front end framework is a good choice for that project. It takes one decision from starting work on the project, unless of course you specifically want to use a specific front end framework.
Symfony remains neutral to what is running in the front end of the project. As with most things in web development, there is no single "right" answer to which front end frameworks to use. You can make arguably make absolutely wrong decisions, but given that you select some option which follows the patterns of modern JavaScript development you should have a good starting point.
Traditionally back end frameworks and technologies have been the biggest influencer into which category the project has fallen, but with rich front ends increasing consideration should be done when architecting the front end of a site. As with anything the most common mistake to do is to over-engineer things, so while something maybe cool you might be just as fine without it.
The Symfony2 framework turned five this week and is now a very stable platform that thousands of developers know well. This brings routine and efficiency as opposed to spending time learning the philisophies of something completely new. For JavaScript the last few years have been a time of constant experimentation as many projects have also been the first using technology X.
One size does not fit all
The Symfony framework is a feature complete back end framework that can be used to create complex applications. Still many developers also choose to use the lightweight Silex micro framework or the Symfony Micro Kernel. You can also use single components from the Symfony project and in many cases this is enough. While it's not 1:1, you can think of front end tools with a similar division.
If your application logic is complex and heavily embedded in a JavaScript client, then you'll probably want to go with a full framework. They include everything from routing to rendering templates and everything in between. They're very opinionated choices that set you up with a complete toolkit. Finding information online is relatively easy at many people are working with the exact same set of tools. Some good options for this kind of projects are Angular 2, Aurelia, and Ember.js.
As the micro framework equivalent you can consider something that is a collection of individual components used to form a custom micro framework. This gives you superb flexibility, but the downside is that the setups can end up being very esoteric. This can lead to rotting components and fragmented documentation and hard-to-solve solutions to very basic problems. The most prominent example of something like this is the React UI library and the accompanying ecosystem, but Riot.js paired with RiotControl is a more straightforward option that wil take you a long way.
The component equivalent is using general purpose libraries like jQuery or Riot.js or just plain old JavaScript. They're very quick to implement and have very little boilerplate, but can easily get out of hand as your applications complexity increases over time. Most applications without anyone specifically designing the front end will end up looking like this.
React as a brand is in a gray area here, it's essentially a view layer component but needs a number of supporting tools to function as a full framework. In PHP terms it would be like saying the site is built on Twig, the template engine powering not only Symfony but tools like Drupal 8 and Slim Framework.
In addition to Twig you'll obviously need quite a bit of other libraries and glue code to create a complete application. This is why defining what "built with React" means is difficult, but it's getting better as the React team is creating standard project scaffolding.
Conclusion
Each of the three options mentioned above have their own uses. If your application is designed to have a short lifespan, then you might as well kick out a few lines with the drop-dead simple jQuery API and be content with that. For a content driven site with a long lifespan some complex interactive forms you might want to pick React.js without all of the available bells and whistles. If your Symfony back end will mostly be serving clients through a REST or GraphQL API, then you'll want a full framework.
The next time you're faced with starting work on a front end of a web site or web application built with Symfony, you can reflect on the experience you've got from the back end. There are usually many right answers and no absolute truths. In addition existing routine is obviously valuable, so if your team has a good routine with Angular it might not make any sense to switch to React.
Of course you'll need to experiment to keep up with the times, but again evaluate the risks and rewards. If you want to try out Propel instead of Doctrine ORM, go right ahead when the opportunity arises. For the toughest project of the year you'll likely be better off using the one you already know. And remember, there are no silver bullets - even in JavaScript.
Working on something you don't understand with tools you know is ok. Working on something you understand with tools you don't have experience is ok. Working on something you don't understand with tools you have no experience in is a recipe for disaster.
Related reading on this site:
- Introduction to Angular 2 for Symfony developers
- Introduction to React.js Components and Server Side Rendering in PHP
- Introducing Riot.js, RiotControl and RiotGear
- What is TypeScript and why should I care?
- The JavaScript language reboot is done