JavaScript Editors ( Give me a text editor and a good book )

[Java script Dude]

I have still yet to see a JavaScript Editor that comes close to
reading a good JS book, learing it and using it with a text editor.

Anyway, here my recipe for build successfull DHTML Applications:

If you want to support only M$ IE stop here and do the following:
1) Install blindfold
2) Repeat the phrase - I love my cage

Buy the Book: Buy O'Reilly's JavaScript The Definitive Guide
~ The best damn JS guide & reference period, end of story, finito

Get a good Text Editor with Syntax Highlighting support
~ Real programmers don't use WYSIWYG tools
~ You will never learn with these tools
~ Code is always inefficient
~ Apps to Use:
~ OSX - BBEdit - Powerful but no MDI support
~ Win32 - UltraEdit - Low cost, high power, competent
yntax Highlighting
~ ^nix - Kate or KDevelop - Well written but needs KDE (big)
~ Does not work with OSX's X11 Client :[ - ('+' key
doesn't work)

Browser Development Platform
~ Mozilla (1.3+) (FireFox release suggested)
~ Why Moz?
~ Mozilla based development works in:
~ IE 95% of the time
~ Konquorer (KDE/Apple...), Opera 99%+ of the time
~ Why not IE?
~ IE based development works in standards based
browsers only 50% of the time
~ IE black hole methods (non standards based) causes
people to ignore standards based DHTML objects,
properties and methods.
~ Browser Support Baseline
~ IE 5.5sp2+
~ This is the first (reasonably) stable
version of IE for advanced JS coding.
~ When ever I experience weird bugs from users I have them
them upgrade to IE5.5sp2+ and it goes away.
~ Netscape 6.n+
~ Netscape 4.7 should not be supported!
~ Opera ? (I plead ignorance here)
~ Konquorer/Safari ? (I plead ignorance here)

Debugging Methodology:
~ Use JS Console (Moz)
~ Put try/catches at all error prone functions / methods
~ Because of IE's error stupidity, you should get as
close to the source as possible.
~ Read stack property of error in Mozilla to
read stack of error (powerful)
~ Install JavaScript Console Status in Mozilla
~ Use window.onerror handler
~ In IE, read arguments.callee.caller... to read stack
~ Goes only to last error throw point ! not error source
point :[
~ Note: at this time, there is no way to to get to
the Error object in Mozilla from this handler.
Therefore no stack in Moz. Use Try/Catch instead

Add the following code to every page:
_w=window
function getElem(s){return document.getElementById(s)}
function getEvent(e){ return is.ie?_w.event:e }

Event Declaration
~ Avoid using inline javascript declarations (In HTML Tags)
~ Inline declarations is where you call a function or
run code from the html elements definition
(onclick="<RunSomeCode>")
~ This technique will not allow you to access
the event argument in Mozilla...
~ Instead use getElem("<Element ID>").onclick=<function name>
~ Declare handlers like:
function mySlickFunction(e){e=getEvent(e)...
~ This will ensure you always have Event Object
~ If you want to get fancy you could normalize the Event
at getEvent()
~ Method Declaration
~ Declare <obj>.<meth>=function <obj_acro>_<event>(args){
~ Example: myObj.smile=function MO_smile(args){...
~ Why? - When you build you're stack in the debug
you get the method names!

Other Stuff:
~ Use JSON (www.json.org) as much as possible to nest data
structures (for more complex programming).
~ JSON is fast (primitively supported), stable easy to read.

Could anybody else add to this list?

If people are interested, I can make a document and add other stuff
like JS debugging libraries, Consoles and other slick JS Debugging
stuff.

Happy coding!

Java (script) Dude

 

[Michael Winter]

On 23 Apr 2004 16:53:46 -0700, Java script Dude <[email protected]>
wrote:

[snip]

Buy the Book: Buy O'Reilly's JavaScript The Definitive Guide
~ The best damn JS guide & reference period, end of story, finito

I personally prefer Netscape's JavaScript references and ECMA-262. I've
never bought or read a JavaScript book (and I can't say I ever intend to

[snip]

Debugging Methodology:
~ Use JS Console (Moz)

Opera's JavaScript console is also very helpful and automatically includes
a stack trace (although I wish "Clear" permanently cleared the list).

[snip]

Add the following code to every page:
_w=window
function getElem(s){return document.getElementById(s)}
function getEvent(e){ return is.ie?_w.event:e }

That would imply browser detection, which is a bad idea (simple
alternative below).

Event Declaration
~ Avoid using inline javascript declarations (In HTML Tags)
~ Inline declarations is where you call a function or
run code from the html elements definition
(onclick="<RunSomeCode>")
~ This technique will not allow you to access
the event argument in Mozilla...

Wrong. This isn't explained explicitly by Netscape, but there is an
example provided:

The following example uses the event object to provide the type of
event to the alert message.

<A HREF="http://home.netscape.com"
onClick='alert("Link got an event: " + event.type)'

Click for link event</A>

The event object appears to be passed as an implicit argument.

~ Instead use getElem("<Element ID>").onclick=<function name>
~ Declare handlers like:
function mySlickFunction(e){e=getEvent(e)...

The same can be achieved whilst avoiding your (possible) browser detection:

e = e || window.event;

~ This will ensure you always have Event Object

So should the above, as long as all browsers follow either the Netscape or
IE event model.

[snip]

Mike

 

[Java script Dude]

I personally prefer Netscape's JavaScript references and ECMA-262. I've

never bought or read a JavaScript book (and I can't say I ever intend to

I would think that the ECMA-262 would be the best first bet from a
technical perspective. But being a technical document, it probably
would not be a good starting point for first time developers.

The O'Reilly's book is extremely well written and it's reference
structure allows for rapid resolution of syntax, objects, properties
and methods.

Opera's JavaScript console is also very helpful and automatically includes
a stack trace (although I wish "Clear" permanently cleared the list).

Now a stack dump in the console sounds sweet. Currently, I need to be
able to handle the error in moz and then dump with error.stack. If I
could have it in the console, my life would be much easier. Hmmm.
sounds like a suggestion for Moz.

[snip]
The same can be achieved whilst avoiding your (possible) browser detection:

e = e || window.event;

I stand corrected.

However, it would be a good idea to avoid putting complex JavaScript
inside of the inline handlers. It becomes difficult to read and debug
as the code gets more complex. If the handlers were put into a
separate JS file, the page size could also be reduced.

<div id="divTest" onclick="divTest_click(window.event|event)">Click
me</div>
<script>
// Handlers
function divTest_click(e){...}
...
</script>

Thanks for the input Mike!

Tim

 

[Richard Cornford]

Java script Dude wrote:

[snip]
The same can be achieved whilst avoiding your (possible) browser
detection:

e = e || window.event;

I stand corrected.

However, it would be a good idea to avoid putting complex JavaScript
inside of the inline handlers. It becomes difficult to read and debug
as the code gets more complex. If the handlers were put into a
separate JS file, the page size could also be reduced.

<div id="divTest" onclick="divTest_click(window.event|event)">

<<snip> ^
You should be using logical OR rather than bitwise OR (which will result
in zero).

The code provided as the string values for event handling attributes is
the one place where you don't need to normalise the event object because
the implementations that provide an event object as an argument for the
internally generated event handling function use the identifier -
event - as the parameter name. So the unqualified identifier - event -
will resolve as a reference to the event parameter on browsers that pass
an event object to the function, while on browsers that have a global
event object the same identifier will be scope resolved as a property of
the global object - window.event.

So:-

onclick="divTest_click(event);"

- will pass the event object on to the - div_Test_click - function from
the event handling function in either case.

Richard.