I am not prone to melodramatic statements, but seeing this I had the same feeling I had the first time I started using GMail.

It's not necessarily the DOM sharing, which is cool enough. I just think that the emergence of sockets in new browsers is going to bring in the "next level", whatever that ends up being.

Seriously incredible, especially considering the development timeframe.

It's fun, yes, but at the same time, it's nostalgic.

We've had such technology for decades. There have been desktop sharing apps for years, in Java applets etc.

So whilst it's cool that the browser wars are generating a ton of improvements, none of them so far are really things that will blow users minds. HTML5 is just catching up to where other platforms were 10 years ago.

Agreed. In some ways the browser actually lowered people's expectations of what "computers" can do.

Perhaps the focus shifted.

When I first saw Wolf3D as a kid I was amazed that the computer could do that. Same when I first used a GIS.

These days when people get "excited" about something like Facebook, it's not because it's a technical achievement. It's something more human. Which perhaps is why I don't get it.

Maybe browser technology is "good enough". Perhaps the point is to be able to get apps out to people as simply as possible. It's just a URL.

Due to the fact I don't feel a point coming on any time soon I'll end here.

I think that your final point has the most explanatory power.

Everyone knows that a sufficiently geeky person can make a computer do magical things.

However, apps (in the general sense) become much more exciting when they gain wide appeal, and the difficult discovery, install, setup, and maintenance experience of earlier approaches were an enormous drag on their wide success.

>none of them so far are really things that will blow users minds

It's not the actual feature that will be new, but the simplicity is what will make it from a 'technical tool' in their eyes to some far more common.

What's even great is that all these technologies are more or less platform agnostic. What is developed on a PC will work instantly on a Mac/iPhone/tablet/what not!

Yeah it's sweet. The only problem is keeping up with the current definition of "work".

Websockets, local storage, canvas, css3, fast and standards-compliant Javascript engines, and any other delicious candy that gets piled on top. It's like Christmas for web-devs, this is a good time to be building web apps, we're going to see some amazing stuff.

This is a cool demo; props to the guys who made it.

I have done a few demos like this, and it turns out to be surprisingly hard to turn it into a product. For instance, just because you can send over changes to the DOM, you can't necessarily reproduce the javascript side-effects, exactly. You can't just poll the state of the DOM because it doesn't reflect all of the state that lives in javascript closures that you can't even see.

One easier method, and probably what they did in this demo, is simply catch any user-generated event in browser A and re-emit it in browser B, thus letting the existing javascript code / browser logic do any actual DOM/state modification.

But what happens when each user triggers an DOM event at the same time? They end up getting applied in reverse order on the two browsers. In many cases this can cause the two browsers to fall out of sync.

Anyway, I love seeing WebSocket demos, and this is pretty fun. Just be sure you realize what a rabbit hole this is if you want to make a product.

I'd love to be able to just add a script tag to my website, and then log into some web based service which shows me a list of the current sessions on my website allowing me to click on one of those sessions and monitor their progress through the site using this dom mirroring technique.

There must be money to be made in this sort of service?

That's definitely one of our ideas for pushing this further!

Sounds like a novel way of stalking.

... or customer support.

Yes, with the user's permission.

I'm not sure why you'd need the users permission to view what they're doing on your site in real time? I don't feel like I need to gain permission before I tail my access log when people are viewing my website? How is this any different?

So you're telling you wouldn't mind someone watching every single mouse click and every word you type on a website without your consent?

The "someone" is the person running the website. So no, of course I don't mind. What is the danger?

I already leave a log of my IP address, the web browser I'm using, the links I click, the time/date of my visit and any data that I submit through forms. If they want to monitor my mouse position as well, then fine.

You're talking about small websites. I'm talking about websites with a lot of traffic and a lot of employees. You think only one person will be using that function? Not to mention the potential abuse by employees whose job is to monitor real-time user activity.

"You're talking about small websites."

No. I'm not. I don't get where you think the danger lies?

No wonder we're headed to a future with less privacy.

I'm all for securing your privacy. I'm just not one of those people who thinks my privacy is being invaded if somebody looks at me when I'm walking down the street.

Thanks for all the great feedback, everyone! This was our Node Knockout submission, so if you get a chance, please give us a vote. Give us some big points for innovation!

http://nodeknockout.com/teams/starcraft-2-destroyed-my-marri...

Pretty cool, potentially very handy, though I wonder why they didn't synchronize scrolling.

I asked myself the same. Anyway this is an impressive demo and I voted accordingly. :)

Really good demo. I see multiple business ideas in there.

Definitely has potential for the live support market

Actually, I have been working on something like this for some time now.

Sounds like a security risk to me. If someone tricks you into starting this they could follow you to other websites and collect data.

Security risk in what? Users not paying attention to the URL bar?

Suppose I send you a link to a page I own. I start this thing on said page and track what you do with the rest of the session on the off-chance that you do something sensitive with it. It's like a single-tab key/screenlogger. Combine this with traditional phishing methods (which already work) and you might get valuable data. It's going to be at least as effective as current phishing methods, with the added advantage of not asking for personal data on the landing page as well (so users don't get scared off).

A similar attack would be to override the back button. You know those sites where the back button takes you to a redirect that takes you to the same page? Take one of those, but on the redirect page save the referring URL. Then when the user hits back, have the redirect page start the session sharing and redirect to the referrer. Sounds plenty dangerous to me.

You understand this works by proxying webpages, right? The URL bar is going to show the URL of the proxy, not my bank.

If you consider this to be dangerous that's a flaw in every web browser ever, not this piece of software. This kind of thing was possible 10 years ago too.

That's how every phishing plot works, no? And still they get data. This makes it a step smoother.

Re: "sounds plenty dangerous to me"

Often, it's the "sounds plenty dangerous" innovations (fire, automobile, chainsaw, theory of relativity), that provide the most utility.

Oh, certainly. The fact that it can be used for evil makes it no less impressive and useful for other purposes. But thinking of this attack makes me wonder if our browser security models are getting outdated. With things like this possible, and so much valuable data being web-based these days, is there any way of using cool things like that yet avoiding the major risks?

Flight, gunpowder, surgery, sailing, heliocentrism.

There's nothing here that a simple XSS attack couldn't do in terms of security risk which at least doesn't declare to the world "The owners of this URL are hax0rs!" As a company, all we have to do is throw a loud red banner across the top of the page, etc...

I was thinking through something like this just last night, after reading up on Smalltalk and system images. Are you loading each domain in an iframe? How did you manage to overcome Twitter's clickjacking protection? Using the new sandboxed iframe attribute? High five!

It's done via proxy, node.js, and websockets =) No iFraming. Since we're proxying, we can dynamically hijack the links and insert JS.

What are you using for server side dom manipulation? jsdom? apricot? node-xml? libxmljs? I spent a lot of the weekend working on a webcrawler, but couldn't find a xml parser that didn't choke on the internet-at-large.

Any chance you'd consider open-sourcing?

I haven't seen their code, but I'm not sure why you'd need server side DOM manipulation for this. I'd implement all of that in the browser, and just let the server handle passing events back and forth.

Since they're proxying the page, they replace all <a>s with proxy <a>s, as well as adding a <script> and a <div> with some content to the bottom. Try viewing source on http://starcraft2destroyedmymarrage.no.de:3000/app/4

Do you have any examples of the kinds of things that libxmljs choked on?

I don't recall the urls - I was recursively crawling from a user-provided seed url and had trouble with apricot, node-xml, and libxmljs. I had the least time to play w/ libxmljs because of hassle w/ joyent --- I had to compile v8 and node to link against and scons wasn't playing nice w/ the build environment.

--

Edit: I should add that I'm using libxmljs in production (http://newsbasis.com/news) as an rss parser (streaming sax-push-parser) and it works quite well for that sort of xml.

this is cool!

I made a similar nodejs application too sometime back, but mine is still with some bugs.