Looking back at code written a decade ago is like opening a time capsule. It transports you back to an entirely different era of web development—a time before ES6, before the native fetch API, and long before modern bundlers and framework ecosystems took over.
In 2014, the frontend landscape was deeply fragmented. jQuery was the undisputed king, and Internet Explorer was still a major factor in every technical decision. It was in this environment that the MITO JS SDK was built—a lightweight, "jQuery-less" plugin designed to interface with the api.mito.hu validation service.
Revisiting this codebase provides a fascinating look at the challenges developers faced and the patterns we used to overcome them.
The "jQuery-less" Badge of Honor
In the early 2010s, it was almost assumed that any web project would include jQuery. The provided HTML boilerplate for the MITO SDK project even includes jQuery 1.10.2 and Modernizr 2.7.0 by default. However, the SDK itself prominently advertises itself as a "jQuery-less plugin".
Choosing to write "Vanilla JS" for a drop-in library was a deliberate architectural choice. It meant consuming applications could utilize the SDK without inheriting a massive dependency overhead. But going vanilla in 2014 meant building your own cross-browser safety nets from scratch.
Traversing the Cross-Browser Minefield
Today, making a network request is as simple as calling await fetch(url). In 2014, it required hand-rolling a cross-browser XMLHttpRequest wrapper.
Looking at the _getXHR function in the SDK reveals the true reality of the era:
var _getXHR = function() {
var http;
try {
http = new XMLHttpRequest();
} catch (e) {
// shitty IE fallback
var msxml = [
'MSXML2.XMLHTTP.3.0',
'MSXML2.XMLHTTP',
'Microsoft.XMLHTTP'
];
for (var i = 0, len = msxml.length; i < len; ++i) {
try {
http = new ActiveXObject(msxml[i]);
break;
} catch (e) {}
}
}
return http;
};
**
This block of code is a perfect artifact of the browser wars. To support older versions of Internet Explorer, developers had to iterate through an array of proprietary Microsoft ActiveXObject strings just to instantiate a basic HTTP request.
Similarly, the SDK includes a fallback for JSON parsing. If JSON.parse was natively unavailable, the code resorted to a heavily regex-sanitized eval('(' + data + ')'). This was standard practice before the ECMAScript 5 specification was universally implemented.
The Callback Paradigm
Before Native Promises or async/await were widely adopted, asynchronous operations relied entirely on callbacks. The MITO SDK’s API signature is a classic example of this pattern. To make a request, developers provided the endpoint, the parameters, a success function, and an optional error function:
MitoApiSDK.api('/phone/withcountry',{
'country':'hu',
'phonenumber':'+36123456789'
},
function(r) {
console.log(r);
},
function(err) {
console.log(err);
}
);
**
State management during the request was handled by a manual polling mechanism (setInterval) checking the XHR object's readyState === 4, rather than relying on modern event listeners.
State Encapsulation: The IIFE
Without modern module systems like ES Modules (import/export) or CommonJS, protecting the global namespace was paramount. The entire SDK was wrapped in an Immediately Invoked Function Expression (IIFE):
var MitoApiSDK = (function(w) {
'use strict';
var _apiUrl = 'http://api.mito.hu';
var _isInitialized = false;
// ... logic ...
return {
init: function(options) { ... },
api: function() { ... }
};
})(window);
**
This pattern allowed the creation of private variables like _apiUrl and _isInitialized, exposing only the public init and api methods to the window object. It was an elegant solution to JavaScript's lack of native privacy controls at the time.
Conclusion
The MITO JS SDK was built to do one thing well: provide a fast, reliable bridge to the api.mito.hu endpoints (from validating global phone numbers to checking Hungarian tax and firm numbers) without bloating the host application.
Today, much of the boilerplate code in this SDK has been replaced by native browser APIs. We no longer need to write fallback arrays for ActiveXObject or rely on setInterval to check ready states. Yet, looking back at this code instills a deep appreciation for the ingenuity of the 2014-era frontend developer. It was a time that required building your own bridges to cross the gaps between browsers—a testament to how far the web platform has come.