Issues Embedding and Running a JavaScript-Based Morse Code Translator in Wix Studio

I run a Morse Code translator website that converts text to Morse code and back in real time using JavaScript, along with features like audio playback for dots and dashes, copy-to-clipboard, and dynamic UI updates. I’m currently trying to recreate or embed this functionality inside a Wix Studio site using Velo, but I’m running into several technical limitations and inconsistencies. While basic UI elements work fine, the more interactive parts of the translator don’t behave the same way as they do on my standalone website.

One of the main challenges is handling real-time input processing within Wix Studio. My translator relies on continuous input listeners to instantly convert text as the user types. However, when implementing this with Velo event handlers, there seems to be a slight delay or inconsistent triggering of input events, especially when multiple elements are updating at once. I’m not sure if this is due to how Wix handles frontend rendering or if there’s a more optimized way to structure event-driven logic in Velo.

Another issue is related to custom JavaScript execution and limitations within Wix. My original site uses modular JavaScript functions and some browser APIs for timing and audio generation. In Wix Studio, certain APIs either behave differently or require workarounds, and organizing larger chunks of logic inside page code becomes difficult to maintain. I’d like to know if there’s a recommended pattern for structuring more complex client-side logic in Wix, or if it’s better to offload some functionality to backend web modules.

Audio playback for Morse code tones is also inconsistent. The translator depends on precise timing between short and long beeps, but within Wix, I’ve noticed delays or slight timing mismatches, especially on mobile devices. Sometimes the audio doesn’t trigger unless there is a very clear user interaction, which may be due to browser autoplay policies combined with Wix’s environment. I’m looking for advice on how to reliably implement timing-sensitive audio features inside Wix Studio.

Styling and layout integration present another layer of difficulty. My Morse Code tool uses custom CSS for layout and responsiveness, but Wix Studio’s design system sometimes overrides or conflicts with these styles. Ensuring that the translator looks consistent across breakpoints while maintaining its interactive behavior has been tricky. I’m curious if there are best practices for isolating custom styles or building highly interactive widgets within Wix without breaking the overall site design.

Finally, I’m trying to decide whether fully rebuilding the Morse Code translator inside Wix Studio is the right approach, or if I should instead embed my existing external tool via iframe or link out to it. I’d appreciate input from others who have built interactive tools in Wix especially those involving real-time processing or audio on what architecture works best for performance, maintainability, and user experience. Sorry for long post!

This sounds like a very interesting project!

Based on everything mentioned, this sounds like an ideal use case for a Custom Element - https://dev.wix.com/docs/velo/velo-only-apis/$w/custom-element/introduction - since it allows for things like access to browser apis etc.

I hadn’t seriously considered using a Custom Element before, but it makes sense given the limitations I’m hitting with standard Velo components. Being able to encapsulate the translator logic and access browser APIs directly (especially for things like real-time input handling and precise audio timing) could solve a lot of the inconsistencies I’ve been seeing inside Wix’s native environment.

I’ll explore rebuilding the core translator as a Custom Element and then embedding it into the Wix page, rather than trying to force everything through Velo page code. That should also help with maintainability and isolating styles and scripts. Just curious have you seen any performance or integration limitations when using Custom Elements in more interactive use cases like this, especially with frequent DOM updates or audio processing?