Creating an HTML page with embedded JavaScript was and is still more art than science. Invariably we ask ourselves many questions:
- Does the page render fast enough?
- Do we have too many images that are slowing the load time?
- Have used the correct code and syntax that runs optimally?
- Does this form enhance the user experience or detract from it?
Having created code back in the early 2000s when HTML and JavaScript were very new, a lot of the syntax and the way things were done back then have changed. But the real question to ask is are we adapting to the new syntax or stuck in our ways?
We unfortunately until COVID-19 reared its ugly head most of us did not have the chance to evaluate if we need to change our coding style and syntax. With an unlimited amount of time and clients that no longer asked for constant changes, we changed our Javascript library from what we had been using for about 8 years to another one called Webix.
About 400 forms need to be updated to use the new library. Our code is program generated, so our driver program needed to be updated to generate Webix code. Moreover, all of the custom code written for the other library had to be adapted to the current library. A lot of code is dynamic so there are many things we need to do with the HTML DOM tree to finagle it so that we get the result we are looking for.
After getting all of these things changed, tested, and released to our customers we thought life was good. Then one of our clients pointed out that they were getting Violations in Google Chrome: "[Violation] Avoid using document.write()." Sure enough, when we turned on the developer tools it was there with this link. The thing we took away from the article was: "With this data in mind, Chrome, starting with version 55, intervenes on behalf of all users when we detect this known-bad pattern by changing how document.write() is handled in Chrome...[t]he script in the document.write() is parser-blocking..."
This technique is how we were able to add dynamic code to our static pages. For instance, if you were using the material UI and wanted to change to Webix contrast UI, we would have to change the form code to the correct cascading style sheets to handle those color and interface changes. On average, we had about 3 document.write() per form. The total hit for rendering the page was about 100 milliseconds according to Chrome. That means we are waiting for 1/10 of a second for Chrome to handle 3 dynamic code links. That is really bad.
It took a few days to digest what this meant for our code generator changes and updating all of our custom code where needed. Next, we need to figure out what code would work since our "Pacer" code would have to be replaced. We search the internet and found this JavaScript code. Of course, we did not use it exactly as they had but someone our staff had already written a dynamic link load code in our standard toolset. Our code generated has been updated to call the JavaScript function and the code has been tested and released to our clients.
Although we are pretty proud of our come, our clients did not notice that the forms loaded any faster. Nonetheless, we celebrated with another toast to code from the 2000s that should have been updated and removed as least in the year 2016 instead of 2021. Oh, by the way, our CEO owned a Pacer back in the day!
