The VulcanJS Framework
By Andreas Pauschenwein
Starting with the cloning or forking of the vulcan-starter repository. Afterwards the necessary npm packages will be installed as well as with Pup.
git clonce email@example.com:VulcanJS/Vulcan-Starter.git
meteor npm install
The standard functionality of VulcanJS is significantly lower than Pup — so the installation is much faster. It takes less than 4 minutes for the Vulcan tutorial to be locally available for the first time — which is a bit more than half the time of what Pup needs.
However, there is a problem with the installation immediately: npm’s automatically running audit reports three vulnerabilities classified as “high” in the used libraries. In any case, the app should not be set productively in that form. However, the problem has now been resolved and a simple solution provided . In the current version 1.12.13 the problem has already been fixed.
The Vulcan-starter repository contains several tutorials that explain step-by-step how to use VulcanJS. Each tutorial runs locally as a meteor application and describes each step directly in the browser. If the mentioned files are changed accordingly, the website is updated automatically and the tutorial continues.
This makes it clear which change is causing what. Related adjustments, even across multiple files, are sometimes explained with alternative solutions. This makes the underlying system easier to understand for the user.
VulcanJS has been in development for several years. The name Vulcan is only used since version 1.3.2 — previously the framework under the name telescope nova was rather unknown. Originally started with the Meteor version 0.8. In order to get to the current state, the framework had to implement many refactoring work. In some places this is still noticeable. Not all tutorials adhere to current Meteor Guide rules and not all videos match the descriptions and the associated source code. But that does not matter much, as these tutorials will are updated bit by bit.
All in all, the tutorial leaves a safe, though not too deep, impression of the feature rich framework.
Another development approach
A direct comparison with Pup is not entirely acceptable, as the template and framework are targeted at different audiences and applications. At Pup you get a starting point for a working app. At VulcanJS, on the other hand, you get the tools needed to do this, including an enrollment. When developing a new app both approaches can be followed and here I would like to respond to the differences.
If you have started a project with Pup, then the current version of the boilerplate will inevitably be used as a basis for the project. A later update of this basis is relatively difficult, because you changed exactly this boilerplate for your own purposes.
This is different with VulcanJS. Your own application is developed from the beginning as a package, encapsulated from the framework. As a result, an update to a new version of VulcanJS can be performed easily and the code can be adapted to any changed functionality faster. If you need more profound changes in the process, VulcanJS offers different entry points in your own packages — so-called hooks.
How to understand this package-based architecture is explained in the documentation.
Furthermore, VulcanJS differs from Pup in the choice of packages used. Instead of Bootstrap or Fur, the styling is not bound to any particular library. Instead, the user can choose what fits. The separation between modules and UI elements with the extension .jsx in the file name is also helpful.
Instead of the graphQL Playground in Pup, VulcanJS uses the graphiQL IDE to access the graphQL API. Instead of prepared and separately stored resolvers, mutations and queries at Pup, VulcanJS explains what makes a resolver and collects related data together.
The initial database filling with random values that was implemented at Pup with the in-house Seeder Package is missing from VulcanJS. Start values are created here only statically — the contribution of a random component or interdependent data must be implemented by yourself.
VulcanJS also provides simple support for multilingual text output with the I18n Package.
Conclusion and recommendation
Basically I can say: The further and more limited the functionality of the app to be developed has already been specified, the more I would advise to use Pup. If the requirements are rather vague or if the skills in handling Meteor are not yet established, we recommend the use of VulcanJS.
A comment from the package maintainer
Sacha Greif commented the article on the Meteor forum:
Thanks for the review! You touched on it, but I think the key difference is that Pup is a boilerplate, while Vulcan is a framework. In other words the way Vulcan is architectured, you can easily add/remove/update packages at any point in your app’s lifetime, whereas with a boilerplate you’re kind of on your own after you start. I think they both have their pros and cons, like you pointed out.
(I also think Vulcan and Pup might differ when it comes to actual features, but I’m not familiar enough with Pup to really say)