VoltBuilder being able to create image assets and publish automatically is excellent and IMO a big step up from both PhoneGap Build and local builds.
Also the fact that you use original Cordova tools, the lead time for updating the building system is shorter than if you had used branded tools.
This might be arguable to some, but I find it great to work in an actual browser environment, the way Cordova does, as I can easily transfer knowledge and code/markup between client-side development and mobile app development. Also, UI performance is overall good, even without any “virtual DOM” framework. So, the Cordova paradigm is not dead yet. I also find Cordova to be much easier to work with than Capacitor, if it works at all.
What’s not so great, and not in any way NS Basic’s fault, but something you possibly could help the community with, is the state of plugins:
Many are developed by people that might have much more important things to do, hence very low attention level on bug reports etc.
They don’t keep up with phone OS changes fast enough. This especially relates to increased need for (and different uses of) permissions.
Increasingly plugins are abandoned.
Or they are forked/pulled to oblivion (which one to use?) because they are abandoned or the original author doesn’t respond to issue reports.
We are close to being in a situation where certain things can’t be done, except by developing own plugins, which could make a simple project balloon in complexity. This will not improve by itself. This will get worse.
Therefore I wish Apache Cordova would take more plugins under its wings and see to that:
only one “bestest” version exists per phone feature
they work with the latest OS’s with 1 month lead time or less
forking/pulling would not be allowed, or restricted somehow; rather new features should be adopted (or skipped if deemed irrelevant) in the core plugin, using normal product/requirement management
E.g. based on my use I wish there were core plugins for notifications, BLE, NFC, barcodes, dialogs, CORS-compliant AJAX, background mode, and abstractions for all possible forms of permissions.
Maybe NS Basic could partner with Apache Cordova to drive this, hopefully without much added work on your part, so Cordova lives longer than it otherwise risks to.
Just my 10 cents about my experience of using Cordova and VoltBuilder.
Thanks for the thoughtful message. We are looking into solving some of these problems in the short term by publishing a list of commonly used plugins. It won’t resolve the issue, but it should make it easier to find the right ones.
Because a lot of this input is for the Apache/Cordova project, I would suggest submitting it directly to them:
The Apache Cordova projects wants to understand the users and
contributors better. Therefore, we invite you take part in a short
survey for app developers and contributors of Cordova plugins.
The survey questions are designed to not contain any personal
information and can be answered anonymously. Please take note that the
survey is using Google Forms to process the responses. The Google
privacy policy[1] is applicable for the data processed.
Thank you very much for taking part in this survey. The goal of this
survey is to identify areas that can be improved by the Cordova
community together. The survey is open from now on to December 24, 2023.
The results will be shared on the Cordova blog.
Just wanted to strongly agree here. I’m a one-man-shop and I’ve built several Cordova apps over the years, leveraging my knowledge in HTML/CSS/JS to build some pretty feature rich apps.
I’ve looked into several other mobile app dev options (Capacitor, React Native, Typescript,etc,etc) and none of them are as easy and efficient as Cordova for multi-platform development. And I’m an old dog who doesn’t like learning new tricks.
Joomla solved this plugin problem by creating the Joomla Extension Directory (JED) site. Extension developers submit and users of the extensions can search, download (although some are paid and downloaded through the developers sites). Site developers can review the extensions. Each extension has a set of badges listing the versions they’re compatible with and when it was last updated.
I think the same format would be great for Cordova… I started down the path of aggregating all the news feeds (cordova, android, iOS etc) into one site with the long term goal of heading this way but too much life got in my way and I had to stop.
Wordpress does this too of course, and I’m sure Drupal has something similar.
npmjs does this somewhat, but is not dedicated and there’s no way to rank one plugin vs some other. I tend to look at:
amount of downloads
how recently it was updated
the GitHub page, primarily in terms of number of issues
It’s a pattern that the more issue reports an old (and fundamental) Cordova plugin has the more forks there are, due to people trying to solve issues that the original developers (that’s left the building) don’t fix, and will never fix.
But at times there’s simply no plugin for a certain “domain” that works anymore, and this will increase, as developers move on or get married or something.
Note that it’s not like for CMSs that developers post a free version and then have a premium version that motivates them to continue maintaining the plugin. For Cordova almost everything is free, so why hang on long term (read “why do work for free?”)?
That’s why I considered that the core team needs to have some influence on the selection of more core plugins, that they might not maintain themselves, but keeps a tab on which ones actually work, that they are updated to later versions of primarily iOS and Android etc.
I’ve been following this conversation and wondering what, in your opinions, the minimum viable solution is to this problem? What I’m hearing is that NPM is mostly there, except it lacks any form of curation. Are we talking about a curated list of plugins, or something more complex?
My main issue has been that it’s hard to figure out which fork to use of plugins, and that some plugins have become abandoned and useless altogether, with no (known) forking activity (possibly patched within a single company). If you just make “web forms as apps” this is probably not an issue, but even then people seem to use sharing, notifications, media or phone book access etc and noteably more than Cordova core plugins.
I would have liked to see:
A directory of plugins with descriptions, ranking etc pointing to NPM and/or GitHub for the actual code, making it clear from default filtering that “these are the best plugins for accessing this specific feature or performing this specific action, and they are up to date and work with the latest versions of Android, iOS etc”.
AFAIK NPM grabs information automatically from GitGub.
Also Cordova core plugins could be listed so that developers don’t choose any other for those specific features.
Leave open (and ask) for new plugin categories: for completely new device features, or for features not well handled by any of the current plugins.
Outright prune plugins that are abandoned, claimed by many to not not work etc. Could be automated, or filter-selected out.
Maybe tie a discussion group to each plugin or plugin category for comments about experiences using them.
Ideally the Cordova team would take on more plugins as core, avoiding abandonment and (forced) forks altogether, but I’m sure they have limited resources already, but maybe they could handle this kind of directory.
I probably underestimate the risk of chaos and amount of labor.
Let’s look at this from a Product Management standpoint and ask if there’s a business case for this.
What are the developers pain points? I see four big ones:
Outdated plugins that are no longer compatible with current build systems.
Outdated plugins that build but no longer work with current mobile os’s
Plugins that cause conflicts with other plugins
Plugins with poor support
What are the business risk of doing nothing to help developers?
Developers find better tools with a well managed eco system. By better tools I mean they/we use Cordova less and less. (I think, over the last few years there has been a downward trend in npm downloads of cordova… @ghenne has the scripts I sent him for a dashboard which would verify this)
What are the business advantages?
Becoming a reliable resource provides a huge amount of exposure to the development community which is a marketing and sales advantage for Volt and AppStudio
It positions you as a knowledgeable source and industry leader
You may be able to capture contact information (sign in to look up), rank or comment on plugins
What is the business disadvantage?
Someone has to build and maintain it and there’s an opportunity cost inherent in that process *
Would Volt/AppStudio be better served by adding cloud build services for other cross platform build tools like DART/Flutter?
An MVP could be to take the list of plugins now approved, and add them to a forum of sorts with rating (including possibility to mark them abandoned etc) and possibility to comment per plugin, and link to further inforrmation on NPM and GitHub (or wherever the plugin might actually be).
I’m not saying this is something “sneezed out in 5 seconds”, but still realistic, and could be based on an off-the-shelf forum, possibly the same engine as this support forum.
Simply getting an understanding of others’ experiences might be enough to figure out the most suitable plugin to use, and possible workarounds.
Eventually this might be something Apache Cordova want to participate in.
That doesn’t answer the business value question of course, and I leave that to NSB to ponder.
