#CSS and JS Frameworks

It may seem tempting to add some frameworks to the Page that will make adding some specific functionality easier, but this always comes at a cost.

#jQuery

JavaScript frameworks like jQuery are often used to do simple things like add a date picker or update content on the Page after loading. This very quickly becomes unmaintainable. Debugging event listeners and what part of the Page is changed due to which event and which JQuery script those events are defined in can be a large time investment, just to see how it works.

Not only that, jQuery doesn't do anything JavaScript can't do. jQuery is a convenience feature for developers, but it generally makes developer's life harder and can waste huge amounts of time for the designer trying to update markup when they don't know why their changes are being overwritten by a script.

Beyond that, MercuryCMS has a powerful templating system that avoids the need for sending the client an incomplete or incorrect Page and having JQuery make modifications after the fact.

jQuery also adds a maintenance and compatibility problem where certain plugins require different versions of jQuery to work and some plugins require other plugins, creating a large chain of script loading to do something as simple as validating a form field.

#Bootstrap

Bootstrap is unnecessary in almost all cases. It is a collection of CSS classes that lets you do things that are built into CSS. Simple grid or flex layouts combined with @media rules completely replace Bootstrap's functionality.

By adding Bootstrap, you introduce the need for other designers to know it, and you must avoid conflicting class names when making your own classes. Much of the time you will use a Bootstrap class and then have to override it anyway, creating more CSS to override CSS you didn't need.

Even complex, media-heavy Pages with transition effects, animations, and user interactivity typically require less than 200 lines of style in MercuryCMS and all of it is available in one place, making it very easy to understand.

#React

React advertizes its ability to make it easier to make reactive content on a Page, but adds a large amount of tooling and overhead and generally makes the developer do the heavy lifting.

For reactivity, Vue is significantly easier to understand, more capable, lighter weight, more intuitive, and easier to learn. It also doesn't require a huge list of plugins to do basic functionality like store data.

While MercuryCMS does support using React on Pages, there are no instances where using React has an advantage over Vue.

#Bundlers

It is possible to write code outside of MercuryCMS using a bundler such as Webpack that combines npm dependencies, configuration, and even assets into a large ES5-compatible distributable script file.

There is no need for this in almost all cases. Dependencies can be handled using MercuryCMS' Tags System, or natively-supported dynamic imports. This eliminates the need for developers to set up local dev environments, manage Node versions, install npm packages, configure build systems, etc. It also avoids large distributable sizes and nonsense like base64-encoding images into CSS or JS files.

There is definitely a place for Node, bundlers, and build processes (MercuryCMS uses all of these), but you can largely avoid the need for these using MercuryCMS' features.