Hemlock, the open-source, real-time web framework, now available. | Hacker News Reader

Hemlock, the open-source, real-time web framework, now available.

hemlock-kills.com

24 pointsutku15 comments

As opposed to Hemlock, the open-source, real-time Common Lisp Emacs from http://www.cons.org/cmucl/hemlock/

Their layout is pretty busted on Safari :(

They use flash for display and XMPP polling with ejabberd on the backend. I can understand some of the motivation for this now, but I wonder how much will be obviated by HTML 5 with server-sent events and Web sockets. I guess it will depend on how quickly those things make it into IE.

i was interested until

By combining the scalability of XMPP with the flexibility of Flash [...]

building shiny fluff with flash is one thing, but making an entire application depend on it sucks.

- signed, a user of an operating system with no flash support

That is a good thing I guess - you are not interested in them, and, I am sure, they are not interested in you. Win-win!

is that the apple approach?

There's nothing stopping you from using Hemlock for just the client-server communication and doing all your UI work in HTML/CSS/JS. You could essentially do a Facebook chat or a Meebo, but using flash-run XMPP communication instead of AJAX or crazy iframe polling.

but the client-server communication is what requires flash, does it not? i thought the point of this framework was to implement comet-style communication but use flash.

platforms (like any non win/linux/mac os or the iphone) that don't support flash can't use applications developed with this because there will be no client-server communication.

If you're using this as only a slice of your app stack, instead of the whole stack, it's easy to build a failover to AJAX. The same way you have Javascript degrade gracefully to HTML, you could have the Flash degrade gracefully to AJAX.

That's three times the work if you're a designer that is already making your Javascript gracefully degrade to its HTML equivalent.

It's always going to be extra work to provide a 100% solution. My original suggestion would work 95%+ of the time.

This architecture works well for event based apps. For more flexibility though you should make sure the logic is in Javascript on the client and just use Flash to keep the socket open managing the xml snippets to the ejabberd server. As long as you are not pushing a lot of data between Flash and Javascript via ExternalInterface the performance is pretty good. Hopefully the need for the Flash bit will go away if Web Sockets makes it in HTML 5 (http://dev.w3.org/html5/websockets/)

If anyone is interested in real-time client-server communication without throwing away your favorite framework. Orbited may be a good fit for you. Sockets in javascript. Check it out:

http://orbited.org/

So it seems that this depends on a persistent connection between the user's browser and the server. Isn't there a problem with scaling with regard to the number of open connections that the server must now maintain?

Plot: built on the elegant combination of Ruby, XMPP, and Flex.

大家好

Reply on news.ycombinator.com