If you send the url to them by hand or even just post it on your website, people who come to the plans page can then register quickly (only 4 fields: user,email,password,confirm).

Unlike evite, on Planypus your friends can also control when they get emailed, text messaged, and so on so they can actually turn off emails if they don’t want to be bothered!

Upcoming.org and Skobee didn’t (when I tried them), and it’s just a huge turn-off. I don’t want to force my non-techy friends to register in yet another web site.
This really should be the number 1 feature, prioritized way ahead of any social-oriented feature.

So at the object level… I’m interested to know why you assume pubsub isn’t scalable. We use the asynchronous Twisted framework, which should soon support a better epoll reactor (there will very shortly be a post about it on the Twisted blog if you’re interested). We’re certainly not experiencing any problems at all with scalability, and from our experience at KnowNow we don’t expect to have any issues we can’t deal with in future. Just to hint at the direction of our thinking: the pubsub server was built by a team with a lot of experience with Spread.

Also, I think it’s a mistake to think of pubsub as being a cute but unnecessary JavaScript thing. In my mind, it’s a full-on messaging engine and queue that happens to be delivered over HTTP. It just happens to enable this fun real-time stuff in the browser… but that’s almost a side effect of the internal architecture.

At a meta level… I agree that full-on no-polling Comet is an untested and not unproblematic technology. But someone has to be the first to try new things, and the whole community benefits from our experiments IMHO. I’m more than happy if you want to track us over time, even in a skeptical way. :-)

Feel free to contact me directly if you want to discuss Comet further Leland, I think you can figure out my email address :-).

In creating Planypus we found that a short delay using ajax pull techniques is just as effective for realtime conversation since people need time to write their replies anyway. With a ten second ajax poll, conversation flows fluidly and appears just as ‘real time’ as a comet conversation to the end user, without the drawbacks of poor browser support or scalability issues.

Besides, in most cases when you’re making plans with your friends you won’t all be online at the same time so the real-time aspect should not be a primary feature of a social planning service, or one on which browser support decisions are made…

I know you’re not with Renkoo any longer, but I wonder if there were any discussions along these lines during its development?

Leland

No need to cry while grinding your own ax. Just stop whining and. We all have a right to complain irregardless of the cost. If the developers don’t like it, then they should shut up and get out of web development. If that doesn’ stop your blubbering, then go visit kleenex.com

We were far from lazy in trying to get it to work… we lost many painful days of our lives suffering with Safari before we cried uncle and waited for Apple to come to the rescue and add support with their browser. I’m a mac user, and it pained me that we could only support Firefox at the time.

Obviously, if spiking the CPU to 100% and locking the browser was an easy issue to fix for more complex async use cases like Renkoo, it would have been resolved a year ago. There are many sites that use Dojo that do not have this issue, because they aren’t pushing as hard as others when it comes to the number of async requests, that don’t exhibit this initial page load slowdown.

Dojo is certainly not without problems and issues and limitations, which is really no different than every other toolkit and product out there, and we are doing everything we can to address those issues and to assist our users. As you probably know, Dojo, Prototype, jQuery, MochiKit, and many other toolkits are open source, community sponsored projects, created by people that work hard and don’t like repeating their efforts. It’s pretty disturbing sometimes that we spend so much time and effort defending ourselves when we basically give the stuff away for free, rather than just investing the time in building better products.

And when I read comments like Yan’s, I can’t help but wonder why he’s here in public bickering about Renkoo vs. Planyp.us and Dojo vs. Prototype. I used to work for Renkoo before I started doing my own thing, and I have to say that the single most frustrating and humbling thing about working on Renkoo and on Dojo is that everyone online seems to take great pride in being the first to slam your hard work and put you down. Whether it is Digg or Ajaxian or TechCrunch, 90% of the comments are negative about the things that “the little guy” are pouring their hearts and souls into. Can’t we all just get along once in a while, instead of bitching about how much everyone’s stuff that they are giving away for free sucks? What’s the point if everyone hates everything except their own thing they’re trying to pimp out?

By the way, I’ve been using the WebKit nightlies for the last 2 months with hardly a hiccup. I hardly ever use Safari itself anymore, except when I really need my browser to remember that damn password I’m too lazy to lookup in Keychain. Oh, and when I have to drag out Firefox to give me access to the one or two sites who have content I need but whose developers are too lazy to get a Mac for testing with Safari.

The problem with most libraries is that they occasionally scan the DOM for elements, which slows down Safari to a crawl. This is resolved in the WebKit nightlies, but they are unstable. Viewing a digg comments page with more than 100 comments can cause Safari to hang for 10 seconds or more before I can resume browsing.

Planypus doesn’t require anything but a title so it takes about 10 seconds to spark some new plans with your friends. Fast n simple…

Kris, I’ve heard this before but I think the Dojo problem is deeper than that. I believe some of the key Dojo contributors are behind Renkoo and if getting rid of the Dojo browser freezes is as simple as explicitly specifying Dojo nodes as opposed to the default page scan, why would this (an other interning, selective build) optimization not be done to the site?

I’m not trying to bitch about Dojo As I’ve said, I’ve used it quite a bit and it has served me well for which I’m very thankful, but there seems to be certain gremlins (like the freezes, dialog / tabs slowing down browser) that I feel are showstoppers as far as taking web sites from development to production. I’m less interested in the cool new features anymore, just hoping for production level stability. Dojo has pushed the envelope and wowed the community, but it think sorting out that 20% should now be the priority.