DrupalCon Nashville 2018: A farewell to Twig

Drupal's front-end architecture has become quite complex over the past years. Even though the theming experience has gotten a lot better, it still doesn’t fit into the expected workflow that many front-end developers now follow. In addition, organizations using Drupal are having a hard time finding front-end Drupal talent, as compared with JavaScript talent.

At the same time, expectations from users are growing at a striking speed. To accommodate these needs, front-end developers are inventing new tools to make their lives easier. Nonetheless, it's difficult to try to always provide the right tools since different problems need different solutions. As a result, many initiatives around decoupled Drupal have been gaining momentum.

The key questions that we want to discuss on this core conversation are:

Should we as a community put more focus on decoupling than trying to create a monolithic application that could solve all different aspects of front-end development?

If Drupal is being used for decoupled purposes, there is quite some unnecessary complexity that comes from the subsystems that are not required for decoupling. How could we reduce that complexity?

Is not decoupling even an option? Do we believe that there would be one solution that could work for everyone?

We don’t have answers to these questions yet, so please join the conversation!

[Eric-tbhc]

React and JSX has a huge learning curve and the amount of tooling required to work with it adds a lot of overhead. I would be more open to a web components like approach where Twig is still used for a lot of rendering but large portions of the website are ReactJS or Vue.JS rendered.

[BansheeVision]

Real world budgets and time constraints would currently be best served with the ability to incorporate a mixed combination of Twig, partially decoupled js, and web components. Unless a client has an insane budget with no rollout deadline and your team consisted of a small army of developers, a fully decoupled front-end on a complex commerce site would be a tough sell.
Building and incorporating web components over time (not up front) as a project evolves would stock the toolbox with what could be best leveraged throughout the development~life cycle. Straight (is it too soon to call it 'old school') Twig would/should for now, remain paving the less traveled back roads of a large complex site until a client deems funds are warranted to strategically modernize areas sections at a time.