The more we dig into this, the more I try to understand the path to Vue. As corporate experienced developer I understand the need to enforce some sort of unity for the end-use and for fellow developer. In that universe, a Nextcloud app dev you can jump from one codebase to another without an issue. Although it sounds for me as a corporate trap, I get how that kind of conclusion can be reached.
But this reasoning is harder to grasp in the context of Nextcloud application development.
Regarding simple interaction elements, like dialogs, buttons, I can try to mimick the ones of the Vue provaided library. But when it comes to integrate into processes like “should-i-get-the-password-of-the-user-before-calling-the-endpoint” I cannot do anything else than integrate the 500 kB… And that make me sad…
Yes, I could develop my app in Vue (I currently do that for a living) but no. I feel that our user deserves a better and lighter web and I want to have fun writing my Nextcloud App.
My reactions/comments to statments above:
I will look into that.
I then think
OC should not be part of the
@nextcloud/typings packages or there should be one for application developer and one for core.
So Nextcloud IS indirectly trying to push into Vue (for a better developer experience). For some packages, I have a real effort to make an abstraction (like the dialog or password request packages) to allow a usage as a function although I still have to include some Vue related things in my build And live with the sad result of growing the bundle size as I obviously don’t use Vue.
Another issue I see is that as the UI components are provided as Vue components, it is not as straight forward to copy them onto another framework that would have a smaller foot-print (vs. an HTML/CSS library).
That depends on the definition of significatly, including l10n also includes its dependencies like dom purify.
None of the builds shown in my picture are using Webpack. Both are using Vite if I read correctly the
password-request package so the problem is not only webpack and/or terser.
Big bundle size might not only be annoying for the first page load but also fills memory with things the engine has to parse and which might, in the end, impact performance. This is especially true for either old devices or low-spec phones (or just shitty browser implementations).
My main issue is not duplication but the fact that the core Nextcloud team has decided that exposing things on
window is bad and with that goal in mind moves little by little those functionalities into modules for application to include in their code. Even if that makes each and every application over 500 kB (and probably to more).
I’m not the owner of the platform nor a stakeholder, just a guy, developer and user of Nextcloud as a product expressing my concerns about what I now know is the envisioned echo-system Nextcloud wants for its application developer. I’m day-to-day Jira (yes the bloated thingy) application developer so I have some grounds for comparing and what I saw here itches me (not that Jira echo-system is way better but it has some advantages with regards with integrations).