Each customer project comes with its own specificities, and as developers at KNP it's usually our job to choose or advise on the suite of tools needed to implement them.
The javascript ecosystem is dizzyingly rich. I hope that this article will help developers, whether beginners or experienced, without a strong background in front-end web issues, determine what they need.
I'm not going to focus here on specific libraries but on patterns/tool types. This article is by no means exhaustive and only addresses general issues.

Why has choosing a front-end stack become so complicated?

When Symfony was created, Server-Side Rendering (SSR) was the norm. A client (usually a web browser) sent a request to your server, which returned an HTML page that was displayed as it is to the client. Javascript had a secondary role, allowing you to add a few nice interactions to the page.

Over the years, the possibilities offered by Javascript have multiplied. As it became more and more widely used, numerous frameworks were born... This is how Single Page Application (SPA) came about. With this architecture, the server simply sends back an empty HTML page, hydrated on the client side with javascript. Various entry points are then used to retrieve or interact with data (REST architecture, for example), always from the javascript application.

These frameworks have brought unprecedented efficiency to the organization of front-end assets (html/js/css), but are not without their drawbacks. These include the downloading of javascript code and the generation of client-side rendering, which can lead to slowness on arrival at the site, as well as less effective referencing by search engines.
We're now seeing the rise of javascript SSR frameworks, which use the same tools as those used to write SPAs, but this time execute them server-side.

However, we shouldn't make the mistake of thinking that each of these innovations replaces the previous one. Some applications don't need a javascript framework. Some SPAs don't need SSRs. And no program needs unnecessary complexity.

Do I need a javascript framework ?

Example: React, VueJS, Svelte...

Twig is not obsolete! The advantages of doing without a javascript framework are considerable:

• Your project architecture will be greatly simplified: fewer tools to learn and appropriate, one less service/server in your infrastructure,
  
• Better short-term productivity: less code to write, less configuration to set up.
  

On the other side of the scale:

• The user experience will be less fluid as the server returns each page in its entirety (there are technical solutions to this problem),
• It can be a real challenge to organize a large amount of javascript code without the help of a dedicated framework.

If you're developing an MVP, a small application, and/or the user experience is not central to your project, you probably don't need a javascript framework.

Do I need a javascript SSR framework ?

Exemple: NextJS, Gatsby, Nuxt…

So you've chosen not to SSR your Symfony application, but perhaps you'd like to combine the advantages of a javascript framework with SSR.

You'll need SSR if :

• SEO is important,
• The site needs to be accessible quickly, even to users with poor connections.

Do I need a state-management library ?

Exemple: Redux, Apollo Client, Mobx…

Javascript frameworks have built-in solutions for managing interface state. Despite this, state management libraries are often used. They help you organize the retrieval, storage and modification of data in your application.

You probably need it if your application meets any of these criteria:

• Your interfaces are complex and depend on the same data in several places,
• Your application involves a lot of data retrieval (by nature this is often the case with SPAs, since they start empty),
• You would benefit from a cache on the retrieved data to relieve your server.

Do I need a CSS framework ?

Exemple: Bootstrap, Bulma…

CSS frameworks provide you with classes to set up a design quickly. But they generally don't lend themselves well to overloading, and can quickly become a barrier between your css and what you want to achieve.

If you're happy with the elements they present as they are, they can save you a lot of time.

If you're working with mock-ups or want a customized interface, you'll have to pass.

Don't miss an opportunity to use just what you need... Less is more!

Need some advice? Contact us for a personal consultation :D