Node.js or Client-Side JavaScript? My Experience with Website Stability

When you invest months or even years of hard work and sleepless nights into developing a complex project – like my simulator with thousands of lines of code – you inevitably face the question: How do I protect this code from prying eyes?

If you leave everything on the client-side (in the browser), you risk having any curious visitor view your entire work with a single press of the F12 key. They can easily copy it, claim it as their own, or simply dig through your custom solutions.

The Idea: Move the Logic to the Backend with Node.js

I came up with a logical solution: Let's hide the code on the server! By using Node.js, the server would process requests in the background, and the user would only receive the final results on their screen. On paper, the plan was perfect, and the initial implementation seemed highly promising.

In the beginning, everything worked great. The basics – HTML, CSS, JavaScript, and MySQL connections – ran without any issues. It is true that everything loaded slightly slower compared to reading directly from an SQL database, but that was a price for security I was willing to pay.

Practical Issues: When the Server Suffocates

The problems began when I tried to run the more demanding parts of the application. PHP modules, such as Advanced Tools, System Tools, and time management, simply refused to cooperate. Instead of smooth execution, I received nothing but an endless stream of errors.

// Critical error in the background process
Fatal error: Allowed memory size exhausted in system_tools.php
Server process terminated unexpectedly.

The worst part came during testing. Whenever I tried to run such a heavy example 3 to 4 times in a row, the entire server simply crashed. Due to uncaught exceptions, the Node.js process died, making the website instantly and completely inaccessible to all visitors.

Moral of the Story: Stability Over Security

With classic PHP or client-side JavaScript, an error usually only affects the specific user who triggered it. With Node.js, however, a crashed process means "death" for the entire website until you manually restart the service. For a production site, this is obviously unacceptable.

Therefore, I made an important decision to return back to client-side, dynamic JavaScript. Here are the key takeaways from this experience:

1. Stability Comes First: If the code runs locally in the browser, a potential error will never bring down the entire server.
2. Faster Loading Times: Without redundant server requests for every single click, the page responds lightning-fast.
3. Alternative Code Protection: Instead of overcomplicating the system with Node.js, it is much better to protect the code using high-quality obfuscators, making it unreadable for unauthorized copying.