No hype (just Hipe)
Hipe makes sense.
All good display servers provide some form of 'display language' or interface through which graphical applications interact with the display.
Hipe uses the Document Object Model (DOM), consisting of HTML tags and CSS styling rules, as its fundamental display language. In Hipe, everything is done by manipulating individual HTML tags directly. The DOM is a model that every web developer and blogger on the Internet already understands. It's also fast becoming the world's most versatile and ubiquitous presentation standard.
Let's look at how other display servers compare. On Apple OS-X systems, the display server is called Quartz and the fundamental display language of that operating environment is PDF. Meanwhile Windows uses GDI and X uses Xlib. These are obscure display languages that increasingly fewer developers understand. And their layout capabilities are comparatively weak. While the graphical capabilities of Webkit-based web browsers have risen to awesome heights, most display servers for native applications have fallen behind.
Hipe is not the Web.
We've mentioned that Hipe uses stuff that comes from the Web.
However, the Web itself has several characteristics that make it unsuitable for native applications. Web protocols were designed for information rather than interaction.
Hipe does not use web protocols. Instead Hipe uses its own two-way synchronous message passing protocol so that native applications can manipulate screen elements and receive events in real time, just like you'd expect from a native display server. Here are some noticable differences:
- Hipe doesn't provide Javascript support. Using a native display model means there's no need for it.
- Hipe doesn't know what a URL is. Resources such as images are loaded directly into the display server instead.
- Although user interfaces are made out of HTML elements, Hipe doesn't parse blocks of HTML code itself. Instead, tags have to be created and manipulated individually using the Hipe instruction set API.
Hipe is faster.
Applications written in Hipe start up faster because the Hipe client API is simple enough to be statically linked. Application start-up lag arising from runtime linking is eliminated, and simple applications start instantly.
Preliminary testing indicates that GUIs created through Hipe are very responsive as well. Performance is on par with native environments because Hipe is a native environment. Despite using uses Webkit for rendering and layout, Hipe is not the web. Information flows freely in two directions between Hipe and client applications, without the overhead that would be inherent in trying to do the same thing with web protocols. There is still plenty of room for code optimisation in the Hipe display server, which means that it can only get faster from here.
Hipe is secure.
Hipe applications need to obtain a security key in order to connect to a Hipe environment. Hipe environments (called 'framing managers') are also nestable, meaning specific types of applications can be sandboxed. Unlike X (currently the dominant display server on GNU/Linux operating systems) where no protections are available and any application can access or modify another application's data, Hipe applications are fully insulated. That means in the future, you will be able to safely run remote applications in your native desktop environment with the same threshold of trust as you currently have for the tabs in your web browser.
In summary, Hipe provides...
- Effortless content fluidity and advanced rendering capabilities, as achieved by the industry's agressive development of modern web browsers.
- The ubiquity of using HTML elements – a display language that developers actually understand.
- Direct access and manipulation of on-screen user interface elements by the application at a native level; something web applications lack.