XML
Main selling point?
XML was dubbed as the "miracle" technology that would finally give structure to the largely myopic and completely cluttered space of HTML web pages.
Back before XHTML became a standard (a slight gimmicky bump on the standards roadway superseded by HTML 5), HTML could be whatever type of unmitigated mess the developer wanted it to be. We had tables nested in tables nested in tables. Browsers allowed developers to omit closing tags. There was no semantic structure to most web sites. I expect that I’d croak looking back at the horror that was the HTML code we were spitting out back then. But that was the way it was.
XML was supposed to help add the necessary structure by requiring some important rules like strict closing tags, matching tag syntax and strict hierarchical organization. It would allow developers to define the structure of their content and define not only how it looked, but what the data was all about inside it using custom made tags. Using DTD we could enforce structure and require the XML created matched our specifications. Using XSL and XSLT we could transform that XML into whatever type of output format we needed like HMTL, PDF or other formats.
Why it failed
Ok, to say it failed is a misnomer. XML is, by no stretch of the imagination, a failure. It is a powerful yet complex technology because…
- Creating XML by hand is a pain, especially for very large data files.
- Debugging is also difficult. One small syntax error and your file can be rendered effectively FUBAR by the receiving application (browser, script or program).
- It can be heavy to transfer depending on how much data is being sent and how it was marked up (namespaces, while helpful, could almost double a files size for instance).
- XML is never exactly easy to actually use once you get it. It needs to be parsed into an object and then traversed, usually with often confusing methods. Xpath was created to help with this, but traversing XML was never really as a simple a process we’d want it to be, especially when we had many sources of input.
- Defining the data once, and transforming it into multiple formats via XSL was a nice idea, but creating XSL transforms was typically an exercise in constant frustration. Therefore it never caught on in use for popular web development for web pages.
What do we use now instead?
JSON
JavaScript Object Notation has become almost the ubiquitous standard for front end data transfer, especially when paired with RESTful web services. JSON’s light compact format compared to the highly verbose and heavy XML and SOAP formats is a big plus for KB conscious web sites transferring large amounts of data. It is also now natively parsed by most modern browsers and has relieved developers of having to run their XML through an XML parser and then navigate a complicated and sometimes confusing system of twists and turns. JSON is converted into a JavaScript object that can be easily traversed and altered. And it generally doesn’t get much simpler than that.
XML is by no means a failed technology. Many enterprise systems rely on XML based SOAP data transfer as their primary workflows even today. It is utilized in many different types of ways and for backend applications it’s a popular configuration format, as in the case of Ant and Maven. But for widespread use in web sites and web pages, it lost its popularity to JSON.
Push/Pull
What was its main selling point?
Push/Pull was sold with the promise of constant content delivered to your desktop, without the user ever having to make an active request for it. Services like PointCast promoted themselves as TV stations on the web constantly streaming new content to users as it became available. The user’s client would poll the service for updates behind the scenes and refresh with new content as needed. All you needed to do was have the appropriate receiver and push pull would bring the world to your fingertips.
Why it failed
This type of constant client-to-server connection was, especially in the days before broadband became the norm, a massive drain on network resources, especially if multiple people within a network were using the services. Then there was the constant pushing of multimedia, which again, was limited by the considerably smaller storage capacity of users’ desktops. And because this technology emerged in the height of the 90’s browser wars, Both Netscape and Microsoft had competing implementations leading to difficulty supporting the initiative. It was an idea that’s time just came too early.
What do we use now instead?
Online streaming services
Flash fulfilled much of the promise of push/pull with Flash Communication Server which helped support persistent client to server connections. Flash movies could also get streaming content (on demand) from a backend resource such as additional Flash files, sound and video without a page refresh thanks to built-in server communication protocols. HTML 5 followed with Web sockets which also allows for a persistent connection between the client and the server. You can also talk to other clients cross domain.
The dominant player in the push/pull category today, however, has to be Netflix. It has helped usher in a new era of streaming content services and is one of the major consumers of internet traffic these days. It’s said about 1/3 of internet traffic in the US right now is from Netflix services. Wow. Take that 1997!
Active X
What was its main selling point?
ActiveX is a Microsoft technology based on its Common Object Model (COM) architecture whereby common features and functionality can be shared across different programs running on Windows. Users running Windows would already have these components installed making it a natural choice when paired with Internet Explorer.
ActiveX was supposed to bring this functionality to the Web and allow developers to harness the power of Windows within their web sites as well. How cool would it be to use a common Windows button in your site? Using the HTML object tag and the requisite attributes and object PARAMs, you could embed the control in your site and attached scripting to it to make it work.
OR, and here’s where things got really cool, you could create your own Windows components using tools like Visual Basic, export them as ActiveX controls and use them in your site!
Why it failed
ActiveX is an example of a technology where its greatest strength also turned out to be its greatest weakness. ActiveX is a Microsoft technology and therefore requires both Microsoft’s Internet Explorer browser to be running on Windows (or a windows server) to work. There were some attempts at making ActiveX work in other browsers such as FireFox, but there generally nowhere near as good as running ActiveX code in IE itself.
When IE was king of the browsers at the turn of the century, ActiveX served as a go-to standard that numerous businesses happily hitched their wagons to. Why not, right? Here’s an easy way to build and reuse Windows based components both in native applications and company web sites. Most companies used Windows for the corporate operating system and IE was the defacto web browser. What could go wrong?
Since IE’s grip on the browser market share has slipped, however, so has ActiveX’s popularity on the web. There were still a few holdout ActiveX controls available for IE (like the Flash Player) but by and large, ActiveX was a niche technology only for the Microsoft faithful. And with IE Edge, the successor of Internet Explorer that launched with Windows 10, ActiveX is effectively a dead technology.
That’s not to also mention the litany of massive security issues that ActiveX brought to the web as well.
What do we use now instead?
Plain ol’ JavaScript
JavaScript paired with HTML 5 has opened up an entirely new landscape of application development possibilities in recent years. And with constant increasing pressure form mobile devices, it’s only expected to continue to get better.
Flash
What was its main selling point?
Flash was originally designed as a drawing tool. Its main selling point was that it allowed for complex and rich animation and interactivity on the web within a very small file footprint thanks to its being a vector based tool as opposed to a binary. Vectors use math to calculate the necessary output at runtime rather than specifying a complex maps of pixel colors like bitmap based formats like GIF and JPEG so Flash took off as a popular way to seriously jazz up web site experiences. And for a long while, it came to rule supreme for animation, cartoons, amazing interactive web site experiences and later the granddaddy of interactive content, streaming video.
Why it failed
One word:
Jobs.
Steve mother f***ing jobs and mother f***ing Apple.
OK that was a lot of words with some colorful language mixed in for a highlighting effect. Jobs was a smart guy and probably made the right call but I had to emphasize the point. He wrote a now famous open letter on Flash back in 2010 where he clearly and definitely stated that Flash would never run on any iOS enabled device.
Ever.
Period.
Boom!
The announcement sparked a massive war of words over the existence, necessity and future of Flash. Its status as a closed technology chiefly in the controlling hands of Adobe all but sealed its fate on that very day. HTML 5 rapidly gained attention and clout with major technology players throwing their support behind it, almost overnight, while simultaneously distancing themselves from Flash.
Even Adobe’s attempts to convert Flash apps to native iPhone code also found resistance as Apple changed their app store guidelines to even exclude apps created with Flash and exported as iPhone Apps. Apple just had a serious death wish for Flash and it did all it could to see it put down.
What do we use now instead?
HTML 5, CSS and JavaScript
The anti-Flash shock wave (no pun intended) rippled through the web at lightning speed and Flash use has been on a steep decline ever since. While it’s still out there on the web, its prominence and place as a "go-to" technology for dynamic web sites, video and animation is taking back seat to the more mobile friendly HTML 5 standard. With the advent and growth of the CSS effects, the CANVAS tag and SVG technologies, Flash has continued to lose its share to more standard and universally supported technologies.
Not only that. But with many recent exploits and vulnerabilities continuing to be discovered, including this year’s Hacking News leak, large companies like FireFox, YouTube, Facebook and their CTO have been calling for the technology to not only be disabled, but put on the path for end of life like it’s the new electronic version of the Black Death.
Remember when Flash was the best way to bring fun animated ideas to the web? Sadly, those times are distant memories now.
VRML
What was its main selling point?
VRML enabled the promise of creating rich, navigable worlds within the confines of the user’s web browser.
Why it failed
VRML was itself a very cool technology and had tons of potential. I myself remember purchasing a couple books on it and began taking serious interest in it from an online game perspective. It was just ahead of its time. When it was emerging, web users were mostly connecting via slow dial-up internet access and downloading the often large text based files was prohibitive.
What do we use now instead?
X3D, SVG and HTML 5 Canvas
X3D is the official XML based successor to VRML. For scalable vector graphics on the web, SVG has come out as the clear winner. The HTML Canvas also come as a means to render interactive content on the web as well.
Honorable Mention
Browser (Netscape) Plugins
What was its main selling point?
While web browsers were cool when they first arrived, they quickly showed their functional limitations outside rendering HTML (which itself was clearly limited in its easiest incarnations). So the big brains at Netscape came up with the not so new idea of a building an API for developers to extend the browsers functionality by way of plugins. Developers around the world utilized this
Why it failed
Like ActiveX, compiled Browser plugins were complicated to create. And there was no interoperability between browsers. Plugins coded for Netscape generally did not work with Internet Explorer and IE ActiveX controls were not compatible with Netscape’s plugin API. Some other browsers like Opera allowed for Netscape plugins, but they never worked the same outside the native Netscape API.
What do we use now instead?
JavaScript (Yet again) based browser extensions
As Netscape’s popularity waned, so did the mass of plugins created for it. With the rise of Mozilla, the team tried to undo sins of the past and create a more open and extensible way to enhance the browser. They create XUL for designing the browser interface and an open JavaScript API for creating extensions.
Traditional plugins are still supported by FireFox so while they’re not 100% dead, the browser extension formats have come to rule the web instead.
So what have we learned?
There’s been a lot of innovation and trial and error with different technical solutions on the web in just the last 20 years. And as we stand here in 2016, two of the original players in the game, HTML and JavaScript, have matured into the de facto standards for enabling amazing interactive applications and experiences. If we’ve come this far in 20 years, what will the next 20 have in store for us?
