Need help with Drupal or Grav admin, site building, design, or content? Contact us!
Help Defend Democracy! â Join Battalion today.
Exploring the Symfony universe!
Explore this look at how JavaScript chaos on the frontend is impacting PHP CMSs and frameworks.
As the title of this article implies, developing for the frontend of the web can be a clusterfuck. I hope to help you make some sense of it in this in-depth article. And I mean in-depth.
Jonas Ulrich has a strong one if you want an alternative description of the problem.
My article grew from research. But not from intentional research about what this article will discuss. But rather from thinking about Mobile Atom Codeâs client projects a year or two down the road. Is a decoupled approach to their web presence justified? And if so, what is the best way to go about it? Or progressively implement it. What is the best frontend solution?
Consequently, I explored various approaches to tying the frontend and backend of web projects together. Monolithic, decoupled, hybrid, micro-services, and API first? SPAs, MPAs, or PWAs?
This article will share what I have learned and my opinion on the best approach for various scenarios.
So before the JS bros start trolling, note that the article will be most applicable to web apps for smaller yet professional organizations. Small business, non-profit, and government spaces are examples. The same recommendations might not apply to large enterprise-level applications. And again, I am primarily covering web apps, not native apps.
Everything we will look at is about handling frontend interactivity. Menu and button animations, form submissions, on-click events, asset loading, etc., and the bug-a-boo of âstate.â
But, before we continue, letâs look at some definitions because words are essential for intelligent people. I will let some people more intelligent than I define some of these.
Wikipedia time:
âA single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages. The goal is faster transitions that make the website feel like a native app.
In a SPA, a page refresh never occurs; instead, all necessary HTML, JavaScript, and CSS code is either retrieved by the browser with a single page load,[1] or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions.â
ThirdRock Techkno defines them like this:
âa multi-page application (MPA) is an app that has more than one page. It works in a traditional way, requiring the app to reload entirely every time a user interacts with it.
MPAs generally have large data and complex architecture. The pages in MPAs mostly contain static content and links to go to other internal pages. This is why MPAs have a more intricate and multi-layered user interface.
You can build an MPA simply with HTML and CSS. However, many developers also choose to use JavaScript and jQuery to improve the performance of the app.â
They can be monolithic, progressive, or decoupled.
Wikipedia again:
âIn software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.
A monolithic application is self-contained and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function.â
Via our friend Wiki:
âA progressive web application (PWA) is a type of application software delivered through the web, built using common web technologies including HTML, CSS, JavaScript, and WebAssembly. It is intended to work on any platform that uses a standards-compliant browser, including both desktop and mobile devices.
Since a progressive web app is a type of webpage or website known as a web application, they do not require separate bundling or distribution. Developers can just publish the web application online, ensure that it meets baseline âinstallability requirementsâ, and users will be able to add the application to their home screen. Publishing the app to digital distribution systems like Apple App Store or Google Play is optional.â
TechoPedia says:
âDecoupled, or decoupling, is a state of an IT environment in which two or more systems somehow work or are connected without being directly connected.
In a decoupled microservices architecture, for example, software services have none or very little knowledge about the other services. In theory, this means that a change can be made to one service without the developer having to worry about how the change will impact other services -- as long as the serviceâs application programming interface (API) remains the same.
A decoupled architecture allows software development teams to build, execute, test and debug application modules independently. This approach also allows each module to be developed and maintained by a different team of software developers.â
Technically, headless is backend -> API -> ???.
Decoupled is backend -> API -> frontend, which is what we are exploring here.
I can handle this one. A library, as the name implies, is a set of components for the UI (User Interface) that impacts the UX (User Experience). They can be used in everything listed above.
âIn computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific softwareâ, again according to Wikipedia.
OK! In a perfect world, here is where weâre heading.
Hereâs a quick word about Native apps vs. web apps.
Would you like to write your app code once with standard web tech and then deploy it to multiple platforms? No Kotlin? No Swift? Or just a little of them to provide non-browser features if needed.
Thatâs a cross-platform app.
Recently, browser performance has drastically increased. So you can use the simpler languages you love and provide the experience users desire.
According to Chris Nielsen:
âThe variety and maturity of development tools for web apps have also increased. Now we have React and TypeScript. The IDEs and Chrome debugger are light years ahead of the native equivalents. There are innovative design patterns and open source libraries for every conceivable purpose. The world of JavaScript is simply far more vibrant and alive than the worlds of Swift or Kotlin.â
See the full I Replaced My Native iOS App with a Cross-Platform Web App and No One Noticed article for more.
You can program CPAs with a tool like Flutter. Or Chris recommends Ionic. Or, if you are a sadist, you could roll your own.
Also, native apps are closed source and corporate. However, web apps can be open-source.
So, we should create cross-platform apps if we create an âapp store appâ.
But, what we should be creating instead are PWAs.
The JavaScript Conference expands on the definition above:
âProgressive Web Apps (PWA) are web apps enriched via modern web standards with features considered typical for native apps. In addition to HTML5 APIs such as geolocation and webcam access, these include offline functionality and, for mobile devices, a prominent icon on the home screen.
PWAs achieve feature parity with native iOS, Android, or Windows apps in many areas and, as web apps, circumvent many disadvantages of the aforementioned platforms. They escape the walled gardens of app stores and the classic web technologies HTML, CSS, and JavaScript now offer a respectable development ecosystem with a large variety of tools and frameworks.
PWAs have another big advantage: In principle, only one app needs to be developed that works on all platforms, since web browsers exist for every operating system. Instead of maintaining a separate app for each platform to be supported (usually written in a different programming language with completely different paradigms and patterns), there is now only one web app to serve them all â an extremely tempting offer, at least on paper.â
There are many ways to develop your web components or blocks. Lit, Stencil, Lightning, and many more come to mind. Of course, as always, you could roll your own. But, it would be better if they were standardized and interchangeable for any application.
We are not there yet, unfortunately. But a movement is afoot on this front. And they are looking for developers to help.
Gutenberg and the Block Protocol are cooperating on one attempt that is underway.
They are working on âan open standard for building and using data-driven blocks. Make your applications both human and machine-readable.
Blocks built with the Block Protocol can easily pass data between applications because the data within each block is structured.â
So, again thatâs a perfect world.
Of course, anything more than eleven humans are involved with is more likely to be a catastrophe than reach perfection. Itâs especially true if challenging conditions exist like state.
State is described by W3.org:
âAs defined by FOLDOC, state is how something is; its configuration, attributes, condition or information content. We use the term component to include software and hardware âthingsâ. Virtually all components have state, from applications to operating systems to network layers. State is considered to be a point in some space of all possible states.â
They continue:
âA component changes from one state to another over time when triggered by some kind of event. The event could be a network message, a timer expiring or an application message. Components that do not have state, that is there is no trigger that causes a transition, are called stateless.
Most interesting, particularly personalized, components have state of some kind, which is what allows them to provide personalized information when interacting with user agents on the web.
This finding concerns itself primarily with the following kinds of state:
Nolan Lawson had done some hard thinking and great writing on âstateâ. And we have featured him in Symfony Station communiques. So, I will provide a lengthy quote from him that sums up the frontend problems and chaos this article examines in terms of state.
He says:
âManaging state is one of the hardest things about writing software. And in many ways state management is a great boon to SPAs. In particular, you donât have to think about persisting state between navigations; it just happens automatically. In an MPA, you would have to serialize this state into some persistent format when the page unloads, and then rehydrate on page load.
On the other hand, the fact that the state never gets blown away is exactly what leads to memory leaks â a problem endemic to SPAs. Plus, the further that the state can veer from a known good initial value, the more likely you are to run into bugs.
Interestingly, though, itâs not always the case that an MPA navigation lands on a fresh state. As mentioned in a previous post, the back-forward cache (now implemented in all browsers) makes this discussion more nuanced.
In the past, Iâve tried to shed light on some interesting changes to MPAs that we might not have noticed. These changes are important, and may shift the calculus when trying to decide between an SPA or MPA architecture. And of course, frameworks are still innovating on both SPAs and MPAs.
The fact that SPAs neatly simplify so many aspects of application development â keeping state in one place, on the main thread, persistent across navigations â is one of their greatest strengths as well as a predictable wellspring of problems. Performance and accessibility wonks can continue harping on the problems of SPAs.â
State solutions may require decoupling for web apps.
Unfortunately, many people choose mainstream SPA frameworks to do it. And they compound the terrible decision by using them for their UI components. You can use web components within SPA frameworks. Ok.
image credit bubbers - stock.adobe.com
I am a developer version of Batman, a vigilante fighting JavaScript. I am on a jihad against it in both the Marvel and DC universes. Cross-over alert! And I am also good friends with a wonderful woman.
But seriously, letâs explore frontend frameworks, wannabe frameworks, and why you should not use them for 95% of web apps.
I would compare Angular to Ultron, unnecessarily over-engineered, over-engineered again, and dangerous.
Angular is famous for being difficult and thus is falling out of favor.
It was developed by âdonât be evil,â but I am anyway Google.
I will readily admit Iâm prejudiced against React. But, of course, I m also prejudiced against rednecks, religious fanatics, fascists, pedophiles, rapists, racists, conspiracy theorists, and stupid people in general.
Reactâs villain equivalent would be Penguin, overblown, prone to waddling, and incomprehensible. With an annoying accent.
Like Android, VHS, fast food, and pop music it sucks but is popular anyway. It was developed by a shit corporation, Facebook.
Its only redeeming quality is that it was forced into being open-source by WordPress. More on that will come below.
React itself is a component library, which would have been okay if challenging to use.
But to compete with real frameworks like Angular and Vue it has to add:
In other words, itâs a clusterfuck inside a clusterfuck. And that leads to disastrous offspring. Imagine if the Penguin and Orca had a baby.
Like Loki, you have difficulty telling if VueJS is a hero or a villain. Like Angular and React, it is used when it shouldnât be. But, if you insist on going all-in on a SPA framework, this is the one to use. Plus, more importantly, you can use it incrementally.
Vue has two versions that are incompatible with each other. So that sucks. But, hopefully, they learned their lesson and wonât repeat that mistake when it comes to new versions.
At least itâs genuinely open-source without the taint of Google or Facebook.
Plus, Batman and Loki could coexist if they had to.
Now, letâs finally examine how this horse-assery impacts PHP CMSs and backend frameworks.
First, letâs start with Vanilla JavaScript. Unfortunately, as I have implied, it is devouring the frontend of the web, like kudzu in the southern United States.
It sucks because of âhydration.â
âHydration is a solution to add interactivity to server-rendered HTML. This is how Wikipedia defines hydration:
âIn web development, hydration or rehydration is a technique in which client-side JavaScript converts a static HTML web page, delivered either through static hosting or server-side rendering, into a dynamic web page by attaching event handlers to the HTML elements.â
The above definition talks about hydration in terms of attaching event handlers to the static HTML. However, attaching event handlers to the DOM is not the challenging or expensive part of the hydration, and so it misses the point of why anyone would call hydration an overhead. Overhead is work that can be avoided and still leads to the same end result.â
How can we ameliorate this unnecessary villainy? AKA, kick its ass.
Github has an excellent article about getting rid of frontend JS frameworks altogether. And this is what we should aim for when developing our web apps.
They say:
âA new crop of server-side tools is making it possible to build web UIs without JavaScriptâ.
Get all the details at Move over JavaScript: Back-end languages are coming to the frontend.
Thatâs fantastic news in the long run. And I will discuss some of these tools further below.
*Note that MPAs can shine when it comes to eliminating JS.
But again, most frontend library components are made with JavaScript. They even include CSS frameworks like the ubiquitous Bootstrap.
But some arenât. So, if you canât use the server-side tools solution, you can use these first.
CSSUI promises pure CSS interactive components without any JavaScript at all. We use it on Symfony Station via asset injecting it into Drupal. It doesnât have everything, but it has many things you need. Start with this!
Itâs a powerful tool for creating reactive applications using only PHP and HTML. Itâs like a server-side template engine plus a frontend framework. You describe all components and logic in PHP, and then the tool transpiles them into native JS.
The project website viewi.net details the mechanism of operation and has code examples. And itâs pretty fast.
You can also follow a step-by-step tutorial and check out the Symfony integration. Great stuff.
SymfonyUX's Live Components are built with Twig and are JavaScript-free. As in disease-free. And it's yet another reason that Symfony is awesome.
If the situation calls for it, code a JavaScript-less web component of your own.
When CSSUI or Viewi or roll your own HTML/CSS components canât do the job, minimize your use of JavaScript.
Letâs examine some approaches that address hydration without the drawbacks of Angular, React, or Vueâs complexity.
Alpineâs creators say:
âAlpine is a powerful and lightweight tool for composing behavior directly in your markup. Think of it like jQuery for the modern web. Plop in a script tag and get going. You can do most of what you need to for JS with Alpine.â
It is a collection of 15 attributes, six properties, and two methods. Thatâs it.
Like other SPA frameworks, you can use it with almost anything.
The New Stack takes a solid look at it.
To quote Qwik: It isâ
But, itâs a SPA, decoupled type solution in the making.
According to Astro:
âAstro is a new kind of static site builder for the modern web. Powerful developer experience meets lightweight output. It uses a modern server-side templating language that renders directly to HTML & CSS, eliminating heavy JavaScript automatically. It only hydrates your essential, interactive UI.â
In the PHP world, you can use it with WordPress.
Unpoly works with any backend framework and like SymfonyUX (a PHP take on Rubyâs Hotwire) sends HTML not JSON âover the wireâ.
Its creator, Henning Koch describes Unpoly as:
âan unobtrusive JavaScript framework that enables fast and flexible frontends for server-rendered HTML views. It sends HTML over the wire, and no JSON API is required. It has no dependencies and works with any backend language or framework.â
The New Stack article linked just above says:
âUsing Unpoly, your views can do things that are not normally possible in HTML, such as:
To quote Svelte:
âSvelte is a radical new approach to building user interfaces. Whereas traditional frameworks like React and Vue do the bulk of their work in the browser, Svelte shifts that work into a compile step that happens when you build your app.
Instead of using techniques like virtual DOM diffing, Svelte writes code that surgically updates the DOM when the state of your app changes.â
Like React and Vue, you can use it with almost anything. And I like it.
Finally, how does this flood of approaches to the frontend impact my clients and maybe your projects?
Since we are in PHP land, I will examine the WordPress and Drupal content management systems, which are also the current solutions for my Mobile Atom Code clients.
Then their backend framework equivalents, Laravel and Symfony, will be explored. That covers the vast majority of PHP projects. All of this will apply to PWAs or regular websites.
First of all, with optimized hosting, caching, CDNs, and quality administration, most WP sites do not need a decoupled solution. So there is now no state problem. Wasnât that easy?
For better or worse, usually the later WordPressâs JS ship has sailed. Unfortunately, WordPress chose React for its new content block-based ecosystem, with some rump PHP. The WP admin will remain PHP driven. The only good thing (I guess) is they forced Facebook into making React open-source by choosing it.
Fortunately, there are several ways to create blocks without writing them in React. So there is no need to sully your hands with working in it.
Find out more here if you are interested.
Sometimes you do need a decoupled solution to WordPress. In a competitive eCommerce situation, for example.
WP Dev Academy has an approach they call âalmost headless WordPress.â They say:
âHereâs the gist:
You saw the advantages of Svelte above. So if I went the hybrid route, I would use its approach.
Hereâs a good video if you are interested.
By the way, I am working with a client now (summer 2022) using this solution.
Gatsby is used by many decoupled CMS sites. Itâs an abstraction of React that is easier to use. And if I had to go the fully decoupled route, I would consider Gatsby over straight React, Angular, or Vue. Fortunately, I donât. Because âŹïž.
If I had to go decoupled and had the budget, I would use a hosting solution that provides both front and backend technologies. Of course, like all decoupled solutions, there is double the hosting and double the coding, but at least itâs with one vendor.
Atlas is the decoupled solution from WP Engine. In addition, it includes FaustJS, which makes decoupled development easy by providing data fetching, authentication, and content previews from WordPress.
They say:
âBy bringing WordPress into the world of headless, Atlas rescues content publishers from losing essential features such as post previews, SEO optimizations, layouts, and rich content creation.â
Strattic as the name implies, is a static WordPress solution.
They say:
âStrattic is an all-in-one static site generation and hosting platform that instantly optimizes WordPress by converting it to a static architecture. With Strattic, content managers and marketers can continue to manage content in WordPress as usual. At the same time, developers get to bask in the glory (and enjoy the peace of mind) of a fully headless website.â
I donât know about glory. A stroked ego, yes.
Drupal is based on Symfony now and will remain a PHP-based CMS. Yay!
As with its competitor WordPress, most Drupal website projects do not need to be decoupled. It is especially true for the upcoming version 10 and its new default theme. Again a quality hosting service, caching, a CDN, and top-notch admin optimization are required.
There are various ways to integrate web components into Drupal including Gutenberg blocks. We use them with Symfony Station. And yes, I know itâs based on React. That doesnât mean I have to like it.
Hereâs Lullabotâs approach to Component Libraries in Drupal to give you an idea of other solutions. Single File Components is an interesting one where "the module allows you to provide frontend components in a single file. These components contain Twig, CSS, JS, and PHP code which acts similar to a preprocess function." And Outline is a web component-based design system starter kit that also works with WordPress.
Brian Perry gave an interesting presentation at the 2022 DrupalCon Portland. It is titled Drupal State and the Need for a JavaScript SDK. He proposes a standardized way for Drupal to interact with JS frontend solutions.
There are many Drupal modules dealing with decoupled and progressively decoupled frontend components. So, if interested, visit your favorite search engine.
In another DrupalCon presentation, John Locke noted:
âDrupal works extremely well as a backend headless CMS. But you donât need to switch over to headless all at once. With some setup, you can start incorporating rich frontend elements on existing Drupal sites today!â
Progressive enhancement is the advantage of Vue and the best way to use it.
Alex Borsody followed up his presentation at DrupalCon with an article. Check out A Drupal developer's guide to Progressive Web Apps.
The same as for WordPress goes with Drupal.
Drupal can build more than websites, so you might need a decoupled solution. Cross-platforms apps? Definitely. eCommerce? Probably. Drupal calls itself a digital experience platform for a reason.
Also based on React, Drupal Next uses Next.js, as the name implies.
Its creator ChapterThree also wrote an article on How to Progressively Decouple your Drupal site with Next.js and the JSON API.
So itâs like Vue; itâs not all or nothing.
According to Tomeâs creator:
âTome is a static site generator, and a static storage system for content.
Long story short, you can use Drupal the same way you would use other static site generators like Jekyll or Hugo - everything lives in one repository, and Drupal only runs on your local machine.â
See Gatsby WordPress above. And find out more about using it with Drupal here.
Acquia, when speaking of their decoupled solution, says:
âAcquia is an open digital experience platform that is made for building, managing, and optimizing Drupal-based digital experiences. Acquia offers a fully managed Drupal web hosting solution, Acquia Cloud, that includes support for Node.js to enable developers to build Drupal and headless Drupal sites on a single platform. With Acquia Cloud, developers can use their preferred JavaScript framework to develop headless Drupal or standalone applications, creating backend applications with Drupal and server-side rendered frontend applications with the tools of their choice.â
Acquia Cloud is very much an enterprise-level solution.
Pantheon also a decoupled hosting option for Drupal and WordPress.
"Front-End Sites on Pantheon run frameworks using Server-Side Rendering of Node.js and Static Site Generation to generate some of the fastest sites on the web. Site creation in our new dashboard shows options for spinning up Gatsby, preconfigured to play well with WordPress or Next.js with Drupal."
This is a more manageable solution for smaller projects. IMHO.
Of course, I have read and even edited posts about Laravel. But, I have little to no experience with it, so Iâll quote their solutionâs creators.
Livewire is one of the approaches explored in the GitHub article mentioned above.
They say:
âBuilding modern web apps is hard. Tools like Vue and React are extremely powerful, but the complexity they add to a full-stack developerâs workflow is insane. Say hello to Livewire.
Livewire is a full-stack framework for Laravel that makes building dynamic interfaces simple without leaving the comfort of Laravel.
If you follow us, subscribe to our emails, or frequently visit Symfony Station, you will have seen the Symfony solution for JS frontend conundrums.
And itâs genius.
It is an adaptation of the solution for Ruby on Rails examined in the GitHub article referenced earlier.
According to its creator, âStimulus.js is a JavaScript framework with modest ambitions. It doesnât seek to take over your entire frontendâin fact, itâs not concerned with rendering HTML at all. Instead, itâs designed to augment your HTML with just enough behavior to make it shine. Stimulus pairs beautifully with Turbo to provide a complete solution for fast, compelling applications with a minimal amount of effort.
Turbo uses complementary techniques to dramatically reduce the amount of custom JavaScript that most web applications will need to write:
Itâs all done by sending HTML over the wire.â
Symfonyâs version is Symfony UX and they say:
âSince its creation, JavaScript has always been focused on creating innovative User Experiences. It lets developers create the most intuitive and usable user experience possible for a specific problem.
In practice however, building great User Experiences with JavaScript is difficult. It takes time to choose reliable packages, to configure them, to integrate them in your pages, and to make your frontend code interact with the rest of your infrastructure.
This problem is not new: it looks a whole lot like the state of Symfony in PHP before Symfony Flex. We need a Symfony Flex equivalent for JavaScript: a tool to build amazing User Experiences as quickly as we can now setup an HTTP client, a Mailer or an administration panel.
Thatâs Symfony UX.
âSymfony UX is an initiative and set of libraries to seamlessly integrate JavaScript tools into your application.
Behind the scenes, the UX packages leverage Stimulus: a small, but powerful library for binding JavaScript functionality to elements on your page.
Symfony UX Turbo is a Symfony bundle integrating the Hotwire Turbo library in Symfony applications.
It allows having the same user experience as with Single Page Apps but without having to write a single line of JavaScript!
Symfony UX Turbo also integrates with Symfony Mercure or any other transports to broadcast DOM changes to all currently connected users!
Symfony provides a straightforward component, built on top of the Mercure protocol.
Mercure is an open protocol designed from the ground up to publish updates from server to clients. It is a modern and efficient alternative to timer-based polling and to WebSocket.
Because it is built on top Server-Sent Events (SSE), Mercure is supported out of the box in modern browsers and has high-level implementations in many programming languages.â
Sulu is the perfect enterprise 100% Symfony CMS to use with the frontend solution of your choice.
"Sulu tries to bridge the gap between classic or rather complex Symfony applications and content management systems, without making concessions in one direction or the other."
If you are a Symfony developer and need to distribute to multiple platforms, itâs the way to go.
William Pinaud gave a presentation on SPAs at a Symfony conference. It featured this insightful slide.
It shows when and when not to use SPAs. And SPAs are decoupled as you have seen. William makes an easy-to-understand point, you should not use SPAs 95% of the time. Props to him for the presentation and for allowing us to use the slide.
Ok. Weâve explored Frontend Madness with its morass of SPA, MPA, PWA, Decoupled, Hybrid, Monolithic, Library, and Framework solutions. Whatâs The Fix for your PHP backend?
So, after considering all I learned and my prejudice against React, here is the fix I recommend for your PHP backend web projects.
As you have seen, it is a bit of a wild west show on the frontend of the web. And it is bedeviled by unnecessary use of JavaScript. But you can be the sheriff of your town and provide some order without losing creativity. Cowpokes and townies can drink in the saloon without tearing it down in a bar room brawl. If a trouble-making SPA in a black hat wanders in, you now know how to handle outlaws. Warn him, arrest him, or hang him. You have options.
I hope you will benefit from the results of my research for Mobile Atom Code projects. Weâre sticking with the non-enterprise option 1 for now. A few use cases may require option 2 possibly with SvelteJS.
Thanks for reading my long and intricate article. Use the approaches discussed here in the manner that best fits your applications.
Some handy links are listed below for future reference.
Happy coding (with less JS) Symfonistas!
https://symfonycasts.com/screencast/stimulus
https://symfonycasts.com/screencast/reactjs
https://symfonycasts.com/screencast/vue
https://symfonycasts.com/screencast/vue2
https://javascript-conference.com/blog/one-app-to-rule-them-all/
https://microsoft.github.io/win-student-devs/#/30DaysOfPWA/core-concepts/01
https://nolanlawson.com/2022/05/21/the-balance-has-shifted-away-from-spas/
https://www.smashingmagazine.com/2022/05/you-dont-need-ui-framework/
https://css-tricks.com/web-components-are-easier-than-you-think/
https://developer.mozilla.org/en-US/docs/Web/Web_Components
https://dev.to/kickstartds/unlocking-the-frontend-a-call-for-standardizing-component-apis-pt1-26p9
https://www.joelonsoftware.com/2022/01/27/making-the-web-better-with-blocks/
https://github.com/readme/featured/server-side-languages-for-front-end
https://laravel-news.com/livewire-inertia
https://stimulus.hotwired.dev/
https://thenewstack.io/javascript-framework-unpoly-and-the-html-over-the-wire-trend/
https://www.builder.io/blog/introducing-qwik-framework
https://www.builder.io/blog/hydration-is-pure-overhead
https://thenewstack.io/svelte-and-the-future-of-front-end-development/
https://thenewstack.io/alpine-js-brings-javascript-interactivity-without-complexity-to-html/
https://mrtnschndlr.medium.com/decoupling-frontend-and-backend-development-the-easy-way-5b93a6513e0d
https://polcode.com/resources/blog/develop-apps-using-symfony-and-react-in-perfect-harmony/
Symfony Station covers the essential news in the Symfony, PHP, and Fediverse development communities with a focus on protecting democracy. Please use the button above to make a small donation to help cover our out-of-pocket costs. Our labor is provided free of charge to support the communities we write about.
Subscribe to The Payload, our weekly newsletter exploring the Symfony Universe.