David Benton 01 Jun 05

That’s beautiful. I’m gonna have to get me a Mac one of these days.

I program a bit, but nothing beats excel for simple, mathy apps. I’ve made: trip cost calculators for every vacation I take, a tool for determining total calories and fat:carbs:protein calorie ratio for a given menu (for planning paddling/biking trips), and a heat map of correlations from card sorts, to list a few. Love excel.

Andy Crouch 01 Jun 05

Okay, I’ve watched the movie, but I don’t quite get why this is so significant. What is really faster about this than the Ajax-enhanced tools for entering content on the Web page? I call up Backpack from LaunchBar (the Quicksilver competitor), click on a button, and I’m entering content. The point of this alternative is…?

kingbenny 01 Jun 05

I think the point is that it IS an alternative, and that there will be many more alternatives.

JF 01 Jun 05

I think the other point is that you don’t have to interrupt your workflow — you just invoke Quicksilver, type away, hit tab a few times, and bam — your data is into Backpack. No web browser, no URL, no leaving one app for another.

Ed Knittel 01 Jun 05

OT: can anyone offer any insight as to how the video was captured? Mac as well as PC options? Thanks.

JF 01 Jun 05

Snapz Pro probably.

Kenneth Miller 01 Jun 05

Joel makes some good points about the upsides and downsides of SOAP here:

http://www.joelonsoftware.com/news/20020425.html

I think it is pretty easy to argue that the big boys are “repeating the complexity game of the last decade” when what you build are (extremely well designed) small web applications. By “small” I mean “does not require 500-1000 tables to properly represent all captured data in the third normal”. The game changes at that level. The game also changes when security becomes a major concern. But David is certainly entitled to his typical myopia.

“The new wave of Web 2.0 applications are targetting the simplicity of vanilla XML over HTTP first and keeping SOAP and XML-RPC as a �possibly, maybe�. “

What examples have you?

David Heinemeier Hansson 01 Jun 05

The 37signals suite, naturally. But also apps such as 43things, Flickr, a bunch in development, and even Amazon (through the REST interface) are doing the vanilla XML thing. Sure, going the simple route is not going to work in every application. Few approaches of any kind works in all situations.

The key is that SOAP and friends may be Web Services, but they’re surely not the only way to do web services. And that the interest in a simpler approach is growing.

Kenneth Miller 01 Jun 05

“Few approaches of any kind works in all situations.”

—Agreed.

I think that, for the most part, you will find the camps divided up between those who use a development environment which has built-in support for SOAP based web service development, and those who don’t. As for myself, using C# and VS.NET, building a SOAP based (as well as get and post) web service is as simple as writing a class method. It is stupid easy….everything is generated for me (this would make me uneasy if I did not understand the internals). I will say though, having recently developed a WS_(POLICY, SECURITY, SECURECONVERSATION, ETC. ETC.) web service security framework for AMEX based on the MS WSE framework there is a point at which things become ridiculously complex. Enough to make you want to go back to paper.

Probably already mentioned in another post, but I ran across some basecamp references in a Business 2.0 (which is actually a little ironic considering 37s condemnation of �Business 2.0 speak�) about KidRobot�s company project management procedures. They mentioned Basecamp so many times I thought you guys had paid them for it! Hahah�seriously though, nice work. You can�t pay for that kind of press. I love basecamp…I just like giving David a hard time…which I am sure he has enough of while hand-rolling all those XML packets ;)

pb 01 Jun 05

My company launched it’s web services based on SOAP and experience is that 50-97 percent of the effort is spent on understanding SOAP as opposed to the application itself. SOAP has turned a fairly trivial application into a mess of complexity.

It’s difficult to exagerate how bad SOAP is. If you want DCOM or CORBA, use them. But please don’t cripple web services so much.

The Backpack API can be described in full on one web page and a novice CGI programmer can have it running in an hour. What’s wrong with that?

Chris Woods 02 Jun 05

Our company released its first set of web services in 2000. Simple XML over HTTP/S, doing dozens of thousands of transactions per day initially and probably well over a million per day currently.

In each of the dozens of client integration experiences, the capabillity of the interface met the client’s requirements.

Since then, we have developed several similar applications and have chosen to stick with the simple XML over HTTP and in some cases, the simpler REST/name-value pairs CGI.

Maybe there is a case for SOAP in very complex situations, but I have not yet encountered one.

For one thing, my eyes glaze over when I even try to get through the SOAP spec.

Sam Newman 08 Jun 05

Of course one of the benifits of SOAP can be that it allows for more complex objects to be sent over the wrire, and for the marshalling to be handled by automatically generated language stubs. Anyone who has seen how easy creating webservices is in .NET wouldn’t be at all suprised by how popular webservices powered by SOAP are - it really is incredibly simple. The problem comes if you are having to talk via SOAP without a nice, generated stub - even Java’s SOAP-stub generation is far from nice.