No hype (just Hipe)
Hipe makes sense.
Every display server gives applications some kind of 'display language': the way they say what should appear on screen.
Native display systems grew up around drawing. Some took their model from printing (Display PostScript at NeXT, PDF in macOS's Quartz); others, like X11, offer drawing operations that modern toolkits bypass anyway. Layout, text and interaction were left to toolkits: a different one on every platform, and often several on each.
The web took the other road. Its Document Object Model (DOM), made of HTML tags and CSS styling rules, handles layout, typography and multimedia in one coherent standard that every web developer already understands. But bringing it to the desktop today means bundling a web browser with every application, as Electron does: hundreds of megabytes each, slow to start, and exposed to everything that comes with the web.
Hipe gives native applications the DOM itself. An application's interface is made of tags, and the application changes them directly as it runs, with no browser in between.
Hipe is not the Web.
Hipe takes the web's display model, and none of the rest.
The web was designed for publishing information, not for interactive applications. Hipe doesn't use web protocols, pages or addresses. Applications talk to Hipe through its own two-way instruction protocol, changing what's on screen and receiving the user's input as it happens, as you'd expect from a native display server.
- There's no JavaScript. Applications change their interfaces directly, so it isn't needed, and Hipe's display engine doesn't include it.
- There are no URLs. Images, fonts and media are sent straight to the display server by the application that shows them.
- Applications can send ready-made HTML, or build their interface one tag at a time. Either way, they keep direct hold of every element they want to change later.
Hipe is faster.
Hipe applications link a small static library, with no runtime dependencies to load, so even simple applications start instantly.
Interfaces built on Hipe are responsive, because Hipe is a native environment. Its display engine, hipecore, is built from WebKit with the browser taken out, and information flows in both directions between applications and the display server without the overhead of web protocols.
Hipe is secure.
A Hipe application needs a single-use security key before it can connect, and it can only see and change its own part of the screen. Applications can't read or alter each other's elements or snoop on each other's input, unlike under X11, where any application can. Framing managers can be nested, so particular applications can be sandboxed together.
Interfaces are fully interactive, with animation, video and sound, but the display engine itself never runs scripts, reaches the network or reads files. Everything that changes on screen is changed by the application it belongs to.
In summary, Hipe provides...
- The layout, typography and multimedia of a modern web engine, for native applications.
- A display language developers already understand: HTML elements and CSS.
- Direct, real-time control of every element on screen, at a native level; something web applications lack.