gihrig (2) [Avatar] Offline

I've worked up to the end of Chapter 5 and things are going well, more or less.

I'm encountering a problem, that is not directly related to the book, but is event driven Javascript in general.

How do you make sense of the code in a complex project? Even in the relatively simple chat program (as of ch5) it's basically sophisticated spaghetti to me. A good part of the problem may well be that I've been programming since the early 80's and have a lot of experience with procedural and object-orient languages, but I'm new to event driven Javascript.

The closest my experience comes to what I see in the SPA program is interrupt-driven Assembly. I handled that by creating huge charts of interrupts and the code they invoked. This was a very tedious and error prone process. It's beginning to feel like we've come full-circle and are back at the beginning again smilie

Anyway, my question is, do you guys have any recommended tools or procedures to make tracing through, and understanding event driven code practical?

Thanks for your time.


michael.mikowski (247) [Avatar] Offline
Re: Tracing the flow of event driven apps
Hi Glen:

I understand the challenge with the move from procedural to event based development. In the early 80's I did Z-80 assembly, and have a touch of experience in interrupts (Atari display list interrupts) too smilie

I think we need to step back a bit and look at computing solutions and how procedural code is used. PHP code, for example, is generally procedural, and so it is never used alone. Instead, an event-based system determines when it is executed. The event system may be an OS hosted terminal shell, an OS hosted cron job, a OS hosted desktop icon, or an Apache web server worker process. And so it goes: *all* procedural code we write today is executed instead an event-driven environment.

We can - and do - write procedural code with JavaScript. For example we write the code to fill out a web template without any interruption. The difference is that a PHP web application stops there and doesn't even try to do the "hard" stuff around that template work - Apache receives the event, invokes the PHP code, and then delivers the results back to the client. With JavaScript, it is up to us to handle the events as well.

Now how do we make it more understandable? Well, the book puts event handlers all in one place (if you use the module template), and public methods in another. Since all activities of a module should result from one of these two method types, it makes it easier to see how procedural code is invoked.

Also, I think one needs to get into the event-driven "groove" before feeling comfortable. For example, I know that when I start writing SQL again after a break, it takes me a while to get into the set-theory mode. If you stick with it, the event driven model becomes more natural after a while. And think of your JS as falling into two camps: the event-driven stuff (see event handlers and public methods), and the procedural stuff (DOM and utility methods, usually).

Cheers, Mike

Message was edited by: michael.mikowski for clarity