Dear App Builders and Developers,
soon some of our Apps are going to be transitioned to the new App Builder and hence we get the chance to restructure the Apps with the new possibility of Folders.
In the discussion about how to structure new Apps a few questions arose which i hope someone could answer:
- How can we achieve the best performance boost for our Apps?
- e.g. is the amount of elements/items within a folder influencing the performance (e.g. for saving the Apps code)?
- Can we influence the overall performance of the Apps with the new app builder (e.g. by clever structuring) but also in some other way the new App Builder provides us?
Thanks for your answers 
2 Likes
A wonderful good evening 
TL;DR
The structure of your files does not have an impact on the performance of the rendered app.
A noticeable performance boost for app-viewers (and the preview in the app builder) is not provided by the new folder structure.
However, from a performance PoV there are improvements for the builder. For example:
- Several processing steps have been reworked or removed, which speeds up the file switching, post-editing processing and preview generation.
- When opening the preview in a new tab, the communication process between the editor and the preview in the new tab has been reworked.
- Working without (or less) with the APP.JSON (former RAW) has been improved (for example via the global search and replace in the side-navigation). This can improve the performance of the app builder quite a bit, especially with huge (10k+ lines of code in the APP.JSON).
- Also the APP.JSON is now only formatted on demand (when opening the file), which reduces the computational load and thereby the performance of the app builder.
To get back to your actual question:
This means, that the structure of your files does not have an impact on the performance of the rendered app.
The preview or viewer do not even know that there is a new structure. We did this on purpose to guarantee the backwards compatibility of already published apps 
There are some more improvements I want to mention (next to those above):
- The new file creation dropdown with the included templates should improve getting a new file of whatever type rendered more quickly
- Being able to copy and past whole folders with the contained files allows to more quickly duplicate logical components (for example creating a new page based on an existing one by copying all files which are needed in the page).
- The free file structure (aka I can structure my codebase however I want). This is from my personal PoV the most important one. Being able to group files in folders and also nested folders by their functionality instead of based on the file types allows to group into “logical modules”.
Aka “those thingies which together represent the solution to some kind of business use-case”. Instead of having a huge elements folder and a huge datasources folder, one can put those elements, datasources (and whatever else) together which represent one feature. The “mental modelling” aka “understanding what this thingy does” becomes easier. Especially with huge apps 
.
As code is more often read then written, optimising for reading and understanding helps the long term quality of the codebase.
For example, If I need to do a small change as an adaption to a well structured app, with well isolated features in their own folders, I only need to understand the contents of the one single folder I am working in. Without having the risk of breaking something else or getting lost in 300 element files.
I think at some point I need to grab some bigger app and refactor it to showcase this 
PS:
In the future we plan to enabling saving single files instead of always saving the whole configuration. That should improve the app builder performance on slower networks.
Another “more in the future” approach could be partially updating the preview, but that is a story for another time
2 Likes
Thanks alout for your reply