Introduction
The world of web/frontend development is full of mysteries. There are client-side rendering frameworks (e.g., React, Vue), server-side rendering (SSR) frameworks (e.g., Next.js) based on client-side frameworks, and frameworks (e.g., Astro) that focus only on static site generation (SSG). The question is, do we really need so many frameworks, or can we achieve everything currently done by these three types of frameworks with just a client-side framework?
Server-side rendering (SSR) using Next.js
Next.js is a server-side rendering framework, and it puzzles me how Vercel managed to create such a large developer following around it despite the many flaws I can see in this framework -
It has two routers - pages and app where the later one was introduced many years after the first version of Next.js was released. File based routing is something which web servers have been doing for a long time (I have been seeing it for last 19+ years) but no web server created a hype or talked about it in a way which SSR frameworks like Next.js have done. It is such a basic thing that it is not even highlighted prominently in a web server documentation.
If there are five sibling pages and you want to apply a layout to only four of them, you need to copy it to the folders of those four pages.
React has one set of lifecycle hooks for client-side rendering, while in Next.js, you need to learn a completely different set of lifecycle hooks for server-side rendering.
Dehydration/hydration might be fun for framework authors, but many developers find it uncomfortable.
SSR is said to help with SEO, and this is partly true. However, this claim falls short when you use a charts library or some client side code that heavily manipulates the DOM, requires reactivity, or uses browser APIs not available in Node.js. In these cases, search engine crawlers will need to download additional JavaScript files and execute these after receiving a static HTML (which might be only 20-30% of the final page) on the first request. This negatively impacts the SEO of such pages. While SSR can improve SEO, it is not a silver bullet. Dynamic content that relies heavily on client-side JavaScript can still pose challenges for search engine crawlers.
Caching can be managed much better at the edge (e.g., Cloudflare cache). The benefit of edge caching is that it can be used across applications written with different frameworks, eliminating the need to learn different caching methods for each framework.
Sprinkling 'use client' and 'use server' directives here and there makes things confusing.
There can be compatibility issues with certain third-party libraries or tools that are not designed to work with server-side rendering.
In some cases, developers might find themselves duplicating code between client-side and server-side components, which can lead to maintenance challenges.
Static site generation (SSG) using Astro
When it comes to pure SSG frameworks:
Different people can't publish multiple changes at the same time unless you combine all such changes into a single commit for your production build. This affects the ability of different teams to push their changes independently.
Private APIs can't be used when different people have different permissions for various APIs. For example, your marketing team has access to one set of APIs, while your sales team has access to another set.
Any change, even a minor one, requires a full rebuild of the site, which can be inefficient and slow down the deployment process.
Such tools are limited to developers, and I haven't heard of them being used by non-technical people.
For very large websites, the build process can be time-consuming, as every page needs to be generated at build time.
MechCloud as all-in-one solution
Today, we are releasing a feature in MechCloud that lets you generate a static version of any dynamic site created through MechCloud directly from the browser. This shows that anything you can achieve with SSR can also be done with MechCloud. The advantages are:
You will only need to learn one client-side framework (Vue) instead of three, which greatly reduces the learning effort and confusion associated with multiple frameworks.
Both root layouts (called frames in MechCloud) and normal layouts are stored at a central location and can be mapped to multiple labels (a container for a set of pages) through configuration unlike SSR tools which duplicate these artefacts across a number of folders.
You can use any JavaScript library, no matter how complex, in your static websites, and MechCloud will deliver the full page to search engine crawlers on the first request. Unlike SSR frameworks, which may deliver only 20-30% of the final version initially, MechCloud avoids any additional sub-requests after the first one.
Pages can be published independently by authors working on a website.
If a page or a group of pages (e.g., all the pages under the legal section) need to be published by anyone on a team and these pages use private APIs then the only requirement is that the permissions on all such APIs must be the same for the people publishing the page or group of pages.
While pure SSG frameworks are infamous for duplicating global content (like top navigation) across all pages, requiring a full rebuild every time a new page is added or an existing page is updated/deleted, MechCloud stores global content separately. This means adding or deleting pages does not require a full rebuild of the website.
Global content, as described above, is injected at runtime into all pages. For search engine crawlers, it delivers the full pages on the first request without needing any additional sub-requests to build the complete page. This not only improves the authoring experience for page authors (as they don't need to rebuild the whole website after any change in the global content) but also maintains your SEO score. MechCloud makes both authors and search engines' crawlers happy instead of delivering poor authoring experience to make search engines' crawlers happy.
You can use RBAC in the MechCloud page builder to ensure that different teams (e.g., legal, marketing, etc.) can see and publish only their respective pages. However, the published static site will include pages from all the teams.
Hiding a page is as simple as marking it as hidden in the MechCloud page designer. This is useful for pages that are no longer needed but you want to keep as a backup. There's no need to use tricks like wrapping the folder name in parentheses to hide it from the navigation URL or hiding it altogether.
Demo website
Here is a static website which was created using this new feature of MechCloud page builder which shows how complex static websites, which include data from private APIs, can be created using this feature of MechCloud page builder -
In a future demo, we will show how such static websites can include a charts library of any complexity and still deliver fully generated pages to the search engines' crawlers on the very first request.
OIDC Proxy for publishing the static websites
Currently we support publishing static websites to cloudflare R2 buckets only and this requires deploying an OIDC proxy in your cloudflare account. We will be releasing the code for this proxy by the end of this week. This will allow MechCloud to publish the static websites in your cloudflare account directly but without storing any of your short/long term credentials into it.
Conclusion
The article explores the complexities and redundancies in web development frameworks, particularly client-side rendering (React, Vue), server-side rendering (Next.js), and static site generation (Astro). It questions the necessity of multiple frameworks, highlighting the drawbacks of SSR and SSG frameworks. The article introduces MechCloud as an all-in-one solution that simplifies static site generation, reduces learning curves, and improves SEO, while providing robust team collaboration and role-based access control.