Mini apps operate on a simple but powerful principle: they split what you see from what the app thinks. This is a decoupled architecture. The rendering layer, which handles all the visual elements like buttons and text, is separate from the logic layer, which manages data, processes user input, and communicates with the outside world.

Think of it like a restaurant. The dining room is the rendering layer. It’s what the customer sees: the tables, the menus, the decor. The kitchen is the logic layer. It takes orders, prepares the food, and manages inventory. The two are connected, but they operate in separate spaces with a clear interface between them—the waiter taking an order.

In mini apps, this separation is enforced by the host platform. The visual part runs in a WebView, which is essentially a stripped-down browser window. The thinking part runs in a separate, non-visual environment, often a JavaScript engine like JsCore or a Service Worker. This design creates a sandbox, restricting what the mini app can do and ensuring it doesn't interfere with the host application (like Telegram or WeChat).

This separation is why a mini app isn't just a small website embedded in another app. While they both use web technologies, their environments are fundamentally different. A website runs in a full-featured browser with access to standard web APIs. It can store data in cookies or local storage and generally expects to maintain its state across sessions.

They are designed as session-oriented interfaces. When you close a mini app, the host platform might completely tear down its environment. This forces a different development philosophy, one that treats the frontend as temporary and relies on the host app or a backend server to manage persistent data.

Different platforms implement this architecture with their own unique twists. Telegram and WeChat are two of the most prominent examples, and their approaches highlight key trade-offs.

Telegram's Web App platform leans heavily into standard web technologies. Developers can build their UI with familiar tools like React or Vue. However, the platform's SDK enforces a philosophy of 'frontend amnesia'. The mini app is expected to be stateless. It should be able to be launched, perform a task, and be closed without retaining any memory on its own. Any state that needs to persist must be managed through Telegram's cloud storage via their SDK or by your own backend server. The app essentially 'forgets' everything the moment it's closed.

WeChat, on the other hand, provides a much more rigid and proprietary framework. It uses a strict dual-thread model. One thread runs the logic (in a JsCore-like environment), and another handles rendering the UI. Communication between the two is asynchronous, happening over a bridge. Instead of HTML, developers use WeChat's own markup language, WXML (WeiXin Markup Language), and for styling, they use WXSS (WeiXin Style Sheets), a subset of CSS with some extensions. This gives WeChat more control over performance and the user experience but requires developers to learn a platform-specific toolset.

Ultimately, the architecture of mini apps turns them into distributed interfaces rather than self-contained applications. They are lightweight frontends whose primary job is to provide a user interface for a single session, while the heavy lifting of state and logic happens elsewhere—either in the host app or on a server.