As web application developers, we are bound by the primary
tools of our trade: (X)HTML, CSS, and Javascript. There are indeed others (Silverlight and
Flash come to mind), but these are the general underpinnings of web content
delivery. If we take a look over the
past and current offerings that Microsoft has delivered to assist in the
creation of web apps (ASP.NET specifically), they have done a tremendous job in
taking advantage of these tools to create powerful applications. Well, all but one - Javascript.
Throughout the development of ASP.NET, great effort was put
into abstracting Javascript away from the developers. Page-level API's such as those encapsulated
in the ClientScript class offer a nice "window" into this scary
world, and even allow you to mix in server-side notions and flow logic. While this is all very nice, the first
question I've had since day one is **why??**.
With the raw presentation and semantic power available from
(X)HTML and CSS, it makes no sense to me at all to abstract away the
complimentary abilities of Javascript. A
capable language on its own, it has many of the dynamic language features that
are so hip today: dynamic typing, anonymous functions, etc. It is definitely a powerful tool, and one
that can be leveraged (when appropriate, of course) to accomplish wonderful
things in the world of web content delivery.
Yet we still hide from it, and how could we not???
Microsoft goes to great lengths to continue this
"tradition", even in ASP.NET AJAX.
While the API set in ASP.NET AJAX is impressive, is it really necessary
to attempt to simulate the .NET runtime on the client? As a "nuts-and-bolts" web dev, I
would much rather have a general purpose Javascript API that I could use,
regardless of the server technology. I know there are other offerings out there
- but the question remains: Why does MS try to hide it from us??
Some quote the steep learning curve associated with
Javascript and the DOM. Not sure that's
a good enough reason to single out one language to hide though. With any language there is a learning curve -
something that any established developer is familiar with. You evaluate the language, start using it,
and grow with it, just like we all did with C#.
IMO, Javascript is no different.
It is a wonderful tool, capable of fairly complex things, and offers a
level of dynamic language features that are only now starting to become
commonplace on the server-side. Granted,
it doesn't have **true** OO constructs such as inheritance - but is this a
reason to not use it??
IMO, the real missing link here is the tooling. There are not nearly enough features built
into Visual Studio to assist in hard-core Javascript development to allow
developers to work efficiently. Features
such as Intellisense, code refactoring, and capable debugging (notice I said
capable). I would much rather see effort
placed in delivering a more complete toolset than in developing more and more
obscure API’s.
All that said, Javascript is no Silver Bullet. Like any tool, no one is a best-fit for every
situation. We have T-SQL/PL-SQL for the
DB, C#/VB/whatever-you-use for the server, and (X)HTML/CSS/JS for the
clients. Embrace them. Use them.
Learn from each of them. Create
beautiful applications. Watch users
smile - it's a great feeling.