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.
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.
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.
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.
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.
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.
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?