Minify/Uglify Client-Side JavaScript in MX Web

Hi Mike,

Great question—and I appreciate you thinking ahead about scale. As you add more client-side JavaScript, payload size and maintainability definitely start to matter.

Current Behavior

You're spot on about what's happening: shared event functions are bundled into that `<script>` tag in the HTML body so they're available globally across all pages for event binding. This is by design, since these functions need to be accessible anywhere in the DOM tree at runtime. The trade-off, as you've noted, is that everything—including comments and full formatting—is visible in the browser's DOM tree when someone inspects it.

A Few Context Points

Before we talk solutions, a couple of things worth keeping in mind:

1. Engine-side JavaScript is the way forward. Actually, we're seeing most customers move toward engine-side JavaScript rather than scaling up client code. It's relatively new to the product, but it's where the investment is heading. Engine-side code is completely invisible to the browser—no comments, no code structure, nothing. If you have business logic, encryption, or anything sensitive, that's the place for it. You can always call engine-side APIs from client code when needed.
2. Window-scoped scripts are another option. If certain functions only need to live on specific pages rather than globally, you could use page-level script windows instead. They won't clutter the main DOM, though you do lose the convenience of global event binding.

What About Minification/Obfuscation?

There's currently no built-in minification or uglification feature in MX Web for client-side JavaScript during publishing. That said, you could absolutely create a build process yourself to handle this—run your bundled client code through a minifier (something like UglifyJS or Terser) as part of your deployment workflow, then feed the minified output back into the publish process.

The trade-off is clear: smaller bundle and hidden comments, but debugging becomes harder if issues crop up. Some teams manage this by keeping both versions—minified for production, unminified for troubleshooting.

Next Steps

I'm going to take this up with our Product Management team to explore whether we can add an optional minification/obfuscation feature for client-side JavaScript—ideally with a toggle so you can publish in either state depending on whether you're troubleshooting or going live.

In the meantime, I'd suggest leaning on engine-side JavaScript for anything sensitive or complex, and reserving client-side code for UI enhancements and event handling. That approach will keep your codebase cleaner and your secrets safer.

Happy to discuss further if you want to explore architecture strategies.

Cheers,
Roger.