Skip to main content
Solved

Minify/Uglify Client-Side JavaScript in MX Web

  • September 10, 2026
  • 1 reply
  • 39 views
Mike Warren

We’re using MX Web 10.6.2 and beginning to implement more client-side JavaScript. I noticed that the publish process creates a <script> tag in the body of “index.html” and inserts all of the project’s client-side JavaScript (that isn’t directly linked with a <script> tag pointing to a file name) into it.

 

The bulk isn’t a problem at the moment though I’m not keen on development team code comments being included. I expect that the bulk will increase substantially as we implement more JavaScript though. Is there a way to run a minify/uglify process over the project’s JavaScript during publishing? I’m thinking of something akin to a pre-build event hook that’s part of some IDEs used for other languages.

Best answer by Roger Van Valen

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.
 

View original

    1 reply

    Roger Van Valen
    Forum|alt.badge.img+2

    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.
     

      Still scrolling?
      Ask a question
      Terms & ConditionsAccessibility statement