As a website developer, when I hear about multimedia technology on the web, I conjure up memories of things like Java Applets and Flash sites. They made the internet look more aesthetically pleasing and functional but also introduced significant performance and security issues. Flash brought 2D animation to the web since the beginning of the web, and Java Applets brought 3D graphics to the web and even at one-point outperformed JavaScript and HTML elements. So why did these technologies die?
The introduction of HTML 5 on October 28, 2014, killed the need to have external plugins for multimedia objects. HTML 5 introduced web application programming interfaces (API) for multimedia objects controlled directly by the browser. JavaScript now had access to the WebGL 3D interfaces that Java Applets had as well as a safer API to access files. This is what removed the need to have Java Applets that year. The new APIs also included a means to manipulate 2D images and create simple animations. This would have replaced Flash, except for the fact that it had a huge following, a better user interface, and interactivity built-in. What eventually killed Flash was Apple’s refusal to support the plugin on their mobile phone browsers. As of last year, Adobe has stopped support completely for Flash. So how do developers add multimedia sites today?
Today web developers rely on HTML 5 web APIs for multimedia aspects on their sites. The problem with these APIs is compatibility between various web browsers and even web browser versions. Many of these APIs were not fully supported by browsers until the beginning of this year. JavaScript has been at the forefront of this. Modern JavaScript frameworks like Angular and React have made these APIs much easier to use and have polyfills for browsers that do not support specific APIs. This has taken JavaScript from just a DOM manipulator to a Graphic’s manipulator. But what if you did not have to wait for browsers to adopt a particular feature without polyfills? What if you had direct access to the browser rendering engine? Then you could render virtually anything in the browser at breakneck speeds.
Enter Houdini, the JavaScript APIs that give direct access to the browser’s CSS rendering engine. Houdini allows developers to access the CSS Object Model (CSSOM) much like they would the DOM in JavaScript. The Houdini code does not wait for the first render like inline styles; instead, it occurs during the first render of the page. Developers can create renderable styles before any other scripts load. Its StylePropertyMap can access every element and style sheet in the DOM. To create a Houdini script to manipulate the CSSOM, you must implement a worklet. A worklet is much like a JavaScript Service Worker in that it is a low-level API to access browser methods that is portable and modular. Worklets give you access to the browser’s render engine, where service workers provide you with access to the browser’s caching engine. This access gives developers control over some powerful methods. This is all accomplished without the need for frameworks, postprocessors, or preprocessors.
CSS Parser API
With access to this method, you can parse any text document and turn it into some form of CSS. Think typescript for CSS or even SASS, but that compiles automatically in the browser as fast as a regular CSS document would load. CSS Properties and Values API This allows developers to create custom CSS properties, for instance, creating a property called font-awesomeness with values like fabulous, ok, and meh that translate to real renderable objects.
CSS Typed OM
It takes the overhead out of typing the CSSOM for JavaScript Objects making the whole API more performant.
CSS Painting API
It lets you literally draw anything on the screen anywhere, think Canvas or SVG, only it renders before either of those, and you can render in any element border or background.
The implications for having access to such APIs are great for web performance as a whole. You can draw anything to the screen before anything else loads as fast as CSS, creating animations outside the current window’s context asynchronously. Having the ability to perform all of this without having to worry about which browser the user is utilizing is huge. It will reduce the weight of web applications that have to polyfill for unsupported browsers and get rid of bulky frameworks that must wait for the first browser render and slow pre- and post-processors.
Here are some examples from Google Chrome Labs
https://googlechromelabs.github.io/houdini-samples/
References:
https://thehistoryoftheweb.com/the-story-of-flash/
https://en.wikipedia.org/wiki/Java_applet#:~:text=Java%20applets%20were%20introduced%20in,be%20run%20by%202015%E2%80%932017.
https://en.wikipedia.org/wiki/HTML5
https://developer.mozilla.org/en-US/docs/Web/Houdini
During the holiday rush, every shopper matters
Optimize the customer journey before the eCommerce event of the year.
