Many Nextcloud apps that serve a front-end component have been rewritten in Vue.js recently. With this change to a more modern framework and concept for building user interfaces, more apps have also started using webpack to bundle scripts, styles and even icons. In this post I would like to reflect on why this is important and why more apps should do it.
🕵️ Writing Nextcloud app – the old approach
Before bundlers like webpack became popular in the Nextcloud community, most apps did not use any bundling for their assets. This means scripts and style sheets were included via HTML’s
This style of front-end programming comes with a few problems and limitations.
🐌 Increased number of requests
With the modular architecture of Nextcloud and having loaded many apps, this design results in numerous requests for a page load without a populated cache. The more files (modules) an app has, the more requests the browser has to wait for before the page can fully work.
Some developers start with small modules, others split larger onces when they refactor their code that might otherwise become unmaintainable. However, if you are aware of the problem of too many requests on page load, you might rather inline a small module than separating it into a self-contained module. Eventually, this leads to a lower code quality and less maintainable code. Here is a prime example.
🧮 Loading order
With splitting code into modules, you will face problems with module dependencies. That means you have to load all your script files in an order in which each module is loaded after the modules it depends on. You can solve this problem with topological sorting, but not all dependency graphs are easy to identify, nor is it always possible to prevent cyclic dependencies. Moreover, these modules are very fragile to refactor, because moving code around can break out due to loosely defined dependence on another module, usually via the assumption of the existence of global variables.
💥 Using custom libraries and frameworks
In the same context, apps loading their own libraries will pollute the global namespace as libraries register themselves there 🤦. Should two apps try to load the same library, they will overwrite each other’s instance. Again, this is the dependency hell problem. With this type of module design, it is impossible to use two version of the same library on the very same page.
💣 Browser compatibility
If source files are loaded in the browser directly, they have to be written in a syntax that is compatible with all the browsers that are supported. Sometimes this is easy, sometimes this is hard to test because many developers only develop and test on fast, modern browsers while legacy browsers should be supported as well.
🙌 The Solution
🤔 The Long-term Goal
In the long run, it would be great if more apps switch to webpack or a similar tool. Because then the server component will be independent of apps again, so that its code and dependencies can be managed, updated and removed independently without breaking any apps that rely on them.
Leave a Comment
Your email address will not be published. Required fields are marked *