This review was written about a week ago when I was first into my learning curve of javascript, html, dom and webGL. Well, its a week later and I think that what I was really responding to is / was different than what I thought it was. Its not about WebGL, its about expectations. See note at the end of the post.
This is a review on the process of
learning Javascript and WebGL. The two are very interconnected and
we will start with Javascript and then move to WebGL.
Note, I am not far enough along to have
a real opinion about how well WebGL works, because I am spending all
my time getting through the learning curve of getting a picture up on
the screen. It shows promise, when things work it almost seems
magical.
But when you first are learning WebGL
you have to get through Javascript so we will start there.
Although Javascript is a little weird,
it does grow on you, and there are clever even possibly reasonable
solutions to various flaws in the language which, once you get used
to their weird syntax, seem to be OK. For example, I am using a
variation on the "module" pattern in Javascript and it
seems to be working out for me in terms of hiding and keeping
internal state of various parts of the program. Furthermore,
javascript reminds me a bit of Lisp in its devil-may-care attitude to
dynamic memory and its JSON equivalent of an S-Expression. Although
initially dealing with Javascript is a problem, in time the
problems fade into the background.
The problem is that learning Javascript
is something of a pain in the ass, and for the following reasons:
1. Javascript has a specification and a
bunch of tutorials, but no serious reference manual or best practices
documentation. You are expected to get all that "out on the
Internet". Ha.
2. The problem is that each of these
tutorials is written by a different person with wildly different
skill sets, styles and talent. They are not Kernighan and Ritchie.
They are not comprehensive. They are occasionally helpful, they are
more often then not incomplete or inaccurate. They are in no way a
substitute for a good reference manual.
3. Each of these tutorials by helpful
unpaid volunteers uses a different style, and a different set of
support packages, all of which are completely incompatible with each
other. There is no equivalent to "stdio" in Javascript.
One person uses Ajax, another uses Jquery, still another uses
something else. These different packages all seem to be useful, ad
hoc, mutually incompatible and of wildly varying quality and utility.
4. Learning Javascript is usually
intertwined with learning some combination of DOM and HTML, each of
which exists in its own versions, varying implementations, and
without documentation. Repeat problems of learning Javascript for
each of these.
5. Unless you have someone with the
knowledge and the time to guide you through this morass, you can
count on a very frustrating period and a very time-inefficient
process. Its nothing that anyone involved should be proud of. Just
because they made a billion dollars at it, does not mean that they
did a good job.
But the good news is that, so far at
least, in conjunction with a nearly Lisp-like level of interactivity,
one can pretty quickly get through the learning curve and onto
whatever it is you wanted to do with the language.
But then you get to WebGL and you run
into a series of problems which are very related to the ones just
mentioned but with a few additional ones to make it all better. Not
only is there no reference manual, nor anything close to minimally
acceptable reference documentation (a specification is not a
reference manual, by the way), but one more time we have the morass
of internet tutorials that vary from useful to not, and each of them
uses their own support packages for matrix operations and so forth.
But unlike Javascript, with WebGL and
all modern graphics APIs, you have to do an awful lot correctly
before you can put a cube on the screen. And if you do one of those
30 or 40 things incorrectly, then you will not see a cube on the
screen. But each of those 30 or 40 things is badly documented since
there is no reference manual, so you are reliant on Internet based
tutorials which brings us full-circle on the discussion.
The only way I have found to proceed is
to divide and conquer. Which is to work your way through the
creation of a working program one module and WebGL call at a time,
reverse engineer what the documentation should have been, and then
move on.
That takes time.
I am not all that impressed, to tell
you the truth.
So now it is a week or so since I wrote the above post. And I think I was being a little harsh. Once you get through the learning curve, and get a handle on what documentation that there is, one can become productive. There are still unsolved riddles but I am able to move around them. I think that the real problem here, however badly expressed, is one of incorrect expectations. I expected things to be better, for us to go forward with the best, and not to have to deal with things that are no better designed or documented than what we had 20 years ago. It is perhaps a let down that we have not come very far in certain ways and that is what I think I was expressing above, without knowing it. As for the rest, Html, Dom, and even WebGL is fine, if a little weird now and then.