JavaScript Inventor Speaks Out

Anonymous Coward writes "Brendan, on his mozillazine blog talks about JavaScript 1, 2, and in between in light of DHTML and AJAX. In an informal blog entry he answers frequently asked questions such as fixing Unicode in regular expressions, multi-threading, weak numeric typing, and obfuscating code."

Comments

The difference between the language and...

[LetterJ]

The difference between the Javascript language and the browser objects themselves has become more and more clear to me as I've worked heavily with both more complex Javascript like AJAX (where you aren't spending much time directly interacting with browser objects, but rather staying "inside" Javascript), working with JScript.NET for commandline programs, JScript in WSH and HTA as well as Photoshop scripting.

Many of the things that bother me about "Javascript" turn out to be problems with IE or Mozilla's objects and not the language itself. Don't get me wrong, things like the Javascript date objects still bug me, but I'm growing to like the language itself much more than I used to.

If you've only ever used Javascript in a browser, you may not realize that much of what you're working with is really the browser's object model. All of the window., document., document.form, etc. interaction form.submit(), etc. are all browser object properties and methods.

I noticed before posting some questions about scripting outside the browser. In those environments, you just get a different set of objects instead of document.form, you get objects for the filesystem or an active image, just like in any other programming language that uses objects from outside (COM objects, .NET assemblies etc.)

Re:The difference between the language and...

[LetterJ]

It isn't only used in browsers. I used it all of the time for other things. Granted, most of my use is on Windows workstations (such is the life of a web development consultant in Fortune 500 companies) as that's what I spend most of my day on. However, there are other alternatives out there for other OS's as well.

On Windows (if you have a workstation or server), however, you probably already have the WSH accessible containers and the cscript.exe and wscript.exe interpreters. Simply making a script.js file (remember you can't use any browser objects, so search for "Javascript WSH" to get some more info) and running "cscript.exe script.js" will run your script from the command prompt.

Beyond that, you can build WSC (Windows Scripting Components) that are Windows COM DLL's written in scripting languages. HTA's (HTML Applications) are HTML files outside the browser container. Just rename an HTML file to .hta and double-click it. HTA's have gotten a bad rap as they're ofen used in virus attacks. However, so are EXE's. With power comes the potential of abuse. HTA's leave the local access restrictions behind which means your Javascript can access local files, etc. When combined with the WSH Shell object, you can run local executables to process whatever you like. I've done little scripted apps that are HTA's that collect data via a form, save the form data to a temp file, run a commandline processor (which dumps out a resulting file), read in the results and delete the temp files. What you end up with is something like the current AJAX rage without a web server and acting like a local app, all while still using Javascript/HTML.

If you're looking for more "real" applications, JScript is a full-fledged, if not well documented, language for .NET. You can compile to DLL's and EXE's directly and they are exactly the same resulting output as if they'd been written in C# or VB.NET. JScript.NET does bring some restrictions you may not be used to, including enforcing variable declarations, etc. However, it still retains a looser backward compatibility mode, resulting in many WSH scripts compiling as-is. All the tools for working with JScript.NET are free. The .NET SDK is free and contains all of the compilers. You do NOT need VisualStudio.NET to work with .NET languages.

And why not?

[Saeed al-Sahaf]

but this stinks of DRM type shit. somewhat like that amazon fiasco that prevents the same user from viewing all the pages of a book.

Honestly. Why should you be able to? Amazon SELLS books. It's not an on-line library. That's not the service they are offering.

JS is very functional

[Anonymous Coward]

Try this site to see what I mean.
http://www.masswerk.at/jsuix/

Javascript doesn't suck

[stevens]

As someone who'd only used Javascript in creating DHTML, I'd worked up a good hate against it. But what I'd hated was really the ridiculously incompatible implementations of the DOM in IE/Netscape. I also hated the embedded space itself--shitty delivery method (encoded or called from HTML, no #include, no namespaces).

Then I started writing extensions for firefox. I'm trying to show my company that (firefox + xul + js) > (ie + activex). I'm mostly successful, since we already have lots of XML over HTTP data services primed for XmlHttpRequest.

But it turns out that the language doesn't suck so bad. Sure the namespace problem is JS's fault, but the rest is the embedding. Using JS for firefox exntensions allows you to code to one platform; make more OO libraries, etc. I even generate classes from the DTDs I make the XML services from.

Who would've thunk it's really a decent language in the dynamic, lambda-toting, functional-ish area?

Re:Javascript doesn't suck

[stevens]

I just wish that FF would let us going document.element instead of force us to write document.getElementById("element") in order to reference DOM objects. the former is less typing than the latter...

That's not a feature, it's a bug. It's not FF, it's the w3c. And it's the right decision. Standards and all that, right?

The document object already has a shitload of properties, and this IE idea doesn't cooperate nicely, since the property namespace clobbers the id namespace. Bad browser-maker! No cookie!

Re:Just what I wanted!

[dwlovell]

I mostly agree, but we do need Javascript. If you look at the Strict XHTML spec, there is no target="" attribute allowed on anchor tags. So if you want to open a link in a new browser, the official way to do it requires client-script (something about targetting is a browser behavior not a document structure semantic, so it should be script, not html):

<a href="http://www.slashdot.org" onclick="window.open(this.href,'_blank');return false;">Slashdot</a>

So you can argue that XHTML blows, or that you shouldn't open links in a new window, but if you decide you want to be standards compliant, you are going to need some client script. This is not the only example.

-David

Re:It Would Be Nice...

[dwlovell]

Javascript is a scripting language that can be plugged into anything that has a script host for it. Dont confuse javascript with the DHTML DOM. Plenty of javascript code is perfectly valid and does not run inside a browser:

- Windows Scripting Host allows you to write shell scripts in many languages (Javascript, Perl, VBScript) You can install new script engines and it will host those languages as well. WSH gives you a object model to access the disk and other windows components. (COM, ActiveX, etc).
- Classic ASP used the Windows Script Host javascript engine so that js can be the language for ASP. (instead of the default of vbscript). Again, you could use any language that a script engine was installed for, including PERL. (see ActivePerl).
- I also believe some cgi scripts can be written in javascript.

Just because you aren't accessing the DHTML DOM objects (document, location, windows, etc) doesn't mean you aren't coding javascript!

-David