This post is part of an article collection where each article builds upon previous articles. If you just landed here, you may want to start reading from the beginning.
What has worked well for mini apps #
In this chapter, I want to look at lessons I learned from researching mini apps from a web developer's point of view, or answer the question what does it mean to develop the mini app way.
Rather than reinvent the wheel and make developers build yet another implementation of common UI paradigms like tabs, accordions, carousels, etc., mini apps just ship with a default selection of components that is extensible in case you need more. On the web, there are likewise many options, some of which I have listed in the chapter on mini app components. In an ideal world, component libraries on the web were built in a way that you could mix them freely. In practice, too many times, there is a certain lock-in regarding a design system you need to buy in to when you use a component, or the component library is distributed in a way that it is all or nothing, but no individual components can be easily added to a project. There are, however, atomic components that you can use in isolation, or libraries like generic-components that are unstyled on purpose. Finding an using those seems like a good idea.
The model–view–viewmodel (MVVM) architectural pattern—that facilitates the separation of the development of the graphical user interface (the view) via a markup language from the development of the back-end logic (the model)—means the view is not dependent on any specific model platform. While there are some documented disadvantages of the pattern, in general it works really well for applications of the complexity of mini apps. It can shine especially with rich templating libraries (see next chapter).
Page-wise thinking #
Build process #
Powerful capabilities #
Success: Read on to see an example project that puts this way of programming into practice.