X Windows-esque JS UI Client

All,

I've had an idea kicking around for a while now: Is there a standard graphics library/protocol like X Windows for HTML+JS? I'm primarily a desktop developer with experience in technologies 开发者_StackOverflow中文版like C#/WPF, but I'd like my piece of the web revolution. :)

To me most web technologies for displaying interactive apps seem to be too proprietary, slow, or graphically poor compared to what I expect from a desktop app on even a slow computer. It seems like if there were a way to use an abstracted graphical and user input layer and solid quasi-two-way communication, it wouldn't be terribly difficult to make true desktop apps displayed in nearly all browsers.

Now what I'm saying isn't just idle chat: I've gotten a little something cooked up with WPF to start extracting graphics primitives at the milcore layer and am pushing those out across the web using simulated sockets via orbited and Raphael for front-side rendering primarily as a fun hack. So far it wasn't that hard, so I figure somebody else must have done it. WPF isn't everybody's cup of tea, but on the flip side many folks would probably love to have a solid OOP language to code most of the backend stuff with a standardized graphics protocol to the front end that's not just HTML/CSS.

Now to me this seems like a very basic thing - a truly graphical client in the browser, on almost all browsers, sans plugins. We have browsers that can do all these high-level things and play audio and videos. I just want to draw triangles that can change. I assume I've just missed the boat and am reinventing the wheel. Can somebody please point me to a project that does this already so I can make some awesome web apps?

---

The fact that you're interested in low level control from the backend at run time is probably a show-stopper, unless you can accept lots of lag.

It takes a lot longer to communicate between the server and client in the web world. In a desktop, the lags are not worthy of measurement, but on the web, with HTTP requests, the delays are real, highly variable and potentially UX-destroying.

1. Client notices a user click and calls out to let the server know (+50-500ms to transfer)
2. Server finds out, issues an instruction to animate a triangle (+100ms to process) (+50ms-500ms to transfer)
3. Client gets instruction, animates triangle (user perceived lag: 200ms to 1100ms)

So... I'm not sure the exact architecture you're thinking of is feasible on the web.

If you revisit your assumptions a little, your options grow quite a bit. Removing the requirement to make roundtrips all the way to the backend for the application logic, for instance, would be very liberating. Try this interpretation of the desktop paradigm on for size:

• X-Windows → The browser rendering engine (lowest level API, equivalent to hardware)
• WPF → SVG, Raphael, jQueryUI etc. (higher level drawing APIs)
• C# application logic → Client-side JS logic (OOP style)
• File system → Web Server with DB

Interesting question!

---

If I understand correctly, you are looking for a library that makes the process of putting together a UI less of an HTML piecemeal effort. Well, it's worth stating the obvious; unless something drastic happens in the near future all plugin-free web apps will, ultimately, be based on HTML+JS. Raphael is a great tool for generalizing graphics calls on all browsers providing a consistent drawing API, however it is not meant to be a UI solution by itself.

You might want to take a look at extJs, now a part of Sencha. I have used it myself for a fairly elaborate internal BOM management tool. It provides a massive collection of ready-to-use UI components, much like WPF. It also provides an integrated RPC mechanism for integration with server-side logic.

---

There are Several companies, don't have the names on hand, that have pure javascript RDP clients that work well. There is also an open source project called Guacamole which can talk RDP and VNC.

You run their server on a machine that has Remote Desktop Services and it acts as a websockets gateway to the "client". Works beautifully. We're going to use it for an application where there are huge amounts of data feeding the UI.

Imagine having to write a complicated application that took 10 million data points and allowed you to zoom in to any zoom level. Creating a web app to do that would be a waste of resources.

With websockets available now in most browsers, I'm frankly surprised that I don't see this more often. I'm sure