Making it easier for Javascript newbies

Yermo · 2005-02-17 20:02:49

Getting up to speed on on the javascript API's and figuring out what happens when seems to reduce down to putting alot of "alerts()" in various places ... kind of cumbersome when one doesn't know much.

Something that I do in virtually every scripting system I build is include a debugging trace facility which can be turned on or off on a per-object or per-file basis.

Then I write a "release" script that strips out all the debug messages (and optionally comments) to create a runtime version. I do all my development on the debug version. I field the runtime version.

I've put together a little _ddt() library that opens up a text area and drops messages into it. I've created a few simple functions to dump objects, HTML and straight messages into the area. It's made it much easier to see how all this stuff works together.

I'm thinking, if one of the goals of the Xinha project is to get more developers on board, having some kind of tracing system would go a long way to making it easier to "get up to speed".

How do you guys do it? Do you actually use the javascript debugger when you're working on code?

Is having a debug trace vs runtime setup something you would entertain? (It's been /extremely/ useful to me as I come up to speed in this stuff).

-- Yermo

gogo · 2005-02-17 21:08:58

Yermo wrote:

I've put together a little _ddt() library that opens up a text area and drops messages into it. I've created a few simple functions to dump objects, HTML and straight messages into the area. It's made it much easier to see how all this stuff works together.

Sounds good, you have SVN commit, so feel free to put that in, what I'd suggest is just having a config variable Config.debug (might already be one) that turns this functionality on).

How do you guys do it? Do you actually use the javascript debugger when you're working on code?

Typically, alerts, yep. When something is bveing troublesome then I'll fire up venkman and set an appropriate breakpoint somewhere so I can examine the situation at my leisure

Yermo · 2005-02-17 21:29:33

gogo wrote:

Sounds good, you have SVN commit, so feel free to put that in, what I'd suggest is just having a config variable Config.debug (might already be one) that turns this functionality on).

I tend to use alot of debug messages. I build them in as I write or work through a piece of code; so I tend to put commented out _ddtOn() calls at the top of classes to limit debug messages on a class by class basis. Turning on all debug messages at once is an option, but tends to be so verbose that it's not useful.

I'll put it together; you can always nuke it if you don't like the approach.

-- Yermo

niko · 2005-02-18 02:45:16

actually i'm not in active development on HtmlArea or Xinha - but some time ago i did....
And venkman is imho the best tool for debugging JavaScript!

a config.debug-setting is nice of course too...

Yermo · 2005-02-18 03:11:14

niko wrote:

actually i'm not in active development on HtmlArea or Xinha - but some time ago i did....
And venkman is imho the best tool for debugging JavaScript!
a config.debug-setting is nice of course too...

Agreed, once you're up to speed. A big problem with most open source projects, this one included, is they fail to realize how important making it easy for people to come up to speed is.

There are countless issues that make a project like this one particularly difficult; countless browser bugs; weird approaches to doing things; a difficult to understand API.

To offset that, it seems to me some focus should be given to making it easy for people to get started ... more comments in the code; some documentation, a debug trace infrastructure so one can quickly see what order things are done in; maybe a knowledge base of browser bugs by browser and version number that have been worked around in the code, etc. You know, all the niggling details that a newbie wouldn't know.

A bit of effort, not much, in this area would go a long way to giving people a safe entry point to the code.

For my own purposes, wanting to contribute but not being up to speed on cross browser DHTML, I'm picking the ContentMenu graphic bug ... while I'm at it I'll comment what I work on and build in the _ddt() infrastructure in the hopes it'll be a step forward in making this codebase more accessible.

Just my $0.02 worth.

admaspendent · 2013-10-26 03:09:46

Getting up to speed on on the javascript API's and figuring out what happens when seems to reduce down to putting alot of "alerts()" in various places ... kind of cumbersome when one doesn't know much.
www.admaspendent.com

Xinha Discussion Forum

Announcement

#1 2005-02-17 20:02:49

Making it easier for Javascript newbies

#2 2005-02-17 21:08:58

Re: Making it easier for Javascript newbies

#3 2005-02-17 21:29:33

Re: Making it easier for Javascript newbies

#4 2005-02-18 02:45:16

Re: Making it easier for Javascript newbies

#5 2005-02-18 03:11:14

Re: Making it easier for Javascript newbies

#6 2013-10-26 03:09:46

Re: Making it easier for Javascript newbies

Board footer