I often get the question about why we need multiple APIs or programming languages
or whatever. While I haven't been in the woodshop for a while, I still like to make
the comparison. There are certain tools that can do the job, while there are other
tools that are the right tool for the job.
For example, an impact
driver vs. a drill
motor. Given a phillips head bit tip, either tool can drive a screw into a piece
of wood. In basically all ways a good drill motor can replace an impact driver.
[as an asside, for those not familiar - a "drill motor" refers to the base (the
motor) a what is normally called a "dill". The "impact driver" is a tool that specifically
drives screws/bolts/etc using a combination or rotational force and impact (pounding).
The result is that an impact driver has significantly less toruqe on the user, with
better results on driving the target]
However, if I'm driving 100 screws into wood, i'll take the impact driver every day.
It is the *optimal* tool for driving screws. It can't drill a hole though.
This morning I bought a copy of SnagIt,
which is a screen capture program. A screen capture program! Alt+PrtScn works pretty
well, right? Again, the built in Windows screen capture is OK, but SnagIt is the optimal
tool. After five minutes of using it I saw how much better it was at grabbing a section
of the screen, automatically converting the format, and overall streamlining the process
I was doing for making figures for my book.
Which brings me to our developer platform.
The other day one of the developers on our team asked the question of why we needed
two APIs for something. Basically the question was if we should, in the future, move
to a single model for presentation. Today we have far too many - Windows Forms, ASP.NET,
Avalon, Avalon/E, HTML, DHTML, Win32, DirectX, etc, etc. - and we don't always have
clear guidance between them.
We ended up focusing the conversation of Avalon vs. DirectX. His argument was - the
only reason someone would use DirectX in the future is for performance and access
to low level hardware features. Avalon introduces some overhead when dealing with
scene graphs and hides some of the DirectX features (Pixel shaders specifically in
V1).
My view was different - I think that sometimes the right tool for the job varies for
people. I think that developers will find one tool to be their "natural" tool for
the job. Writing twitch games like Quake in Avalon, while possible, is not what I
would consider to be the optimal tool. But why?
Let's flash forward to a future where Avalon has shipped several versions, has a robust
API for pixel shaders, vertex shaders, 3D input, etc. In this future world we are
100% capable of writing twitch games. But, is it the right tool? I would argue that
the design center for Avalon is building Applications, Documents, and Media. We have
a control centric view of the world that relies heavily on data binding, templating,
etc. Yes, you *can* build Quake, but what unique value are you getting from Avalon?
It's with this that I believe in a portfolio of APIs. I believe that there is a big
tent of technology for presenting information to developers. HTML, and DHTML have
a place. Windows Forms and Win32 have a place. DirectX has a place. It isn't about
removing the options, but rather having a comprehensive view of the tools in the shop
and picking the right one for a job.
These debates about "AJAX" vs. Avalon, or Windows Forms vs. ASP.NET, are wrong. When
question is "when" to use each technology, not "if" you use each technology.