This article first appeared on Symfony Station.
What’s the fix?
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 article.
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.”
Definitions
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.
SPAs - single-page apps
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.”
MPAs - multiple page apps
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.
Monolithic apps - a united front and back end codebase
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.”
PWAs - progressive web apps
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.”
Decoupled - headless is a stupid term
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.”
Libraries
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.
Frameworks - Frontend and backend
“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.
Cross-Platform Apps
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”.
But, what we should be creating instead are PWAs.
PWAs - progressive web apps
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.”
Frontend components
Standardized Web Components
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.
The State Problem
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:
- application state, which broadly is the state of a particular application;
- resource state, which is generally the state related to a resource identified with a URI.
- per user or per session state, which can cause a resource to interact differently according to the user making the access or the network connection on which the request is received.”
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
SPA Frameworks, aka my Frontend Villains
I am like a developer version of Batman, a vigilante fighting Javascript. I’m on a jihad against it in both the Marvel and DC universes. Cross-over alert! And I am friends with a wonderful woman.
But seriously, let’s explore frontend frameworks, wannabe frameworks, and why you should not use them for web apps.
Angular
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.
React
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 ok if challenging to use.
But to compete with real frameworks like Angular and Vue it has to add:
- React Hooks
- React Router
- React Query
- Context API
- Redux
- Acid Reflux
- etc, etc.
In other words, it’s a clusterfuck inside a clusterfuck. And that leads to disastrous offspring.
Vue
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.
Now, let’s finally examine how this horse-assery impacts PHP CMSs and backend frameworks.
Javascript
First, let’s start with Vanilla JS. 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.
First, Eliminate JS
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
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!
Viewi
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.
Roll your own
If the situation calls for it, code a Javascript-less web component of your own.
Then, Minimize JS
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.
AlpineJS
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.
Qwik
To quote Qwik: It is”
- General-purpose: Qwik is familiar for React developers and can be used to build any type of website or application.
- Resumable: Qwik is resumable which means Qwik applications require 0 hydration. This allows Qwik apps to have instant-on interactivity.
- Progressive: Qwik takes full responsibility of how to load and download JS. No more manual code splitting.
- Reactive: Qwik semantics allow for fully reactive and efficient rendering.
- Fast: Qwik has unprecedented performance, offering sub-second full page loads even on mobile devices. Qwik achieves this by delivering pure HTML, and incrementally loading JS only as-needed.
- Scalable: Qwik application have O(1) constant scalability. It does not matter if your application has 1 million components, boot time is unaffected.”
But, it’s a SPA, decoupled type solution in the making.
Astro
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
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:
- Opening links in modal dialogs.
- Having links update only fragments of a page.
- Layer interactions.”
Svelte
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.
PHP CMSs / Platforms
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.
WordPress
Non-decoupled
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.
Decoupled Frontend
Sometimes you do need a decoupled solution to WordPress. In a competitive eCommerce situation, for example.
Almost Decoupled / Hybrid turn into h5
AlpineJS
WP Dev Academy has an approach they call “almost headless WordPress.” They say:
“Here’s the gist:
- The system uses AlpineJS for rendering. It’s light, fairly easy to understand, and it plays exceptionally nice with PHP server-side rendering.
- Most of the theme is is loaded around HTML template tags. These tags get populated by WordPress’s REST responses for post content.
- The system makes judicious use of session storage. This drastically reduces the number of REST API calls, and keeps the site running fast.”
Svelte
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.
Fully Decoupled
Gatsby
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 ⬇️.
All-inclusive Decoupled Hosting Solutions
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
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
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
Non-decoupled
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. However, 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.
JS SDK
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.
Hybrid with Vue Widgets
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.
Decoupled Frontend
Drupal can build more than websites, so you might need a decoupled solution. Cross-platforms apps? Definitely. eCommerce? Probably.
Drupal Next
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.
Tome
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.”
Gatsby
See Gatsby WordPress above. And find out more about using it with Drupal here.
All-inclusive Decoupled Hosting
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.”
Laravel
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.
- Livewire renders the initial component output with the page (like a Blade include). This way, it’s SEO friendly.
- When an interaction occurs, Livewire makes an AJAX request to the server with the updated data.
- The server re-renders the component and responds with the new HTML.
- Livewire then intelligently mutates DOM according to the things that changed.”
Symfony
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.
Stimulus/Turbo/Mercure
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:
- Turbo Drive accelerates links and form submissions by negating the need for full page reloads.
- Turbo Frames decompose pages into independent contexts, which scope navigation and can be lazily loaded.
- Turbo Streams deliver page changes over WebSocket, SSE or in response to form submissions using just HTML and a set of CRUD-like actions.
- Turbo Native lets your majestic monolith form the center of your native iOS and Android apps, with seamless transitions between web and native sections.
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 - Decoupled
Sulu is the perfect full Symfony CMS to use with the frontend solution of your choice. If you are a Symfony developer and need to distribute to multiple platforms, it’s the way to go.
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?
The Fix
So, after considering all I learned and my prejudice against React, here is the fix I recommend for your PHP backend web projects.
Non-enterprise
- Eliminate and reduce your use of Javascript within an optimized monolithic framework or CMS. Use quality hosting, caching, a CDN, and an optimized admin with your well-designed theme and content.
- Use a Hybrid / Progressively decoupled approach for a CMS with web components. Ditto for the infrastructure.
Enterprise
- For frameworks, use Symfony with Stimulus/Turbo/Mercure or Laravel with Livewire.
- Go the Hybrid / Progressively decoupled route with Svelte.
- If you must use a fully decoupled solution (suppose you are an eCommerce site where a slight difference in speed is crucial or you want a shopping app), choose Vue with a CMS or PHP framework backend.
Conclusion
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 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.
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!
Resources / Courses
Symfony
https://symfonycasts.com/screencast/stimulus
https://symfonycasts.com/screencast/turbo
https://symfonycasts.com/screencast/reactjs
https://symfonycasts.com/screencast/vue
https://symfonycasts.com/screencast/vue2
Reference Articles
PWAs
https://javascript-conference.com/blog/one-app-to-rule-them-all/
https://microsoft.github.io/win-student-devs/#/30DaysOfPWA/core-concepts/01
MPAs
https://nolanlawson.com/2022/05/21/the-balance-has-shifted-away-from-spas/
UI Frameworks / Web Components
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/
Server Side Solutions
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
JS Frontend Libraries and Frameworks
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/
Decoupled
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/
Top comments (0)