Slashdot Mirror
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."
It's a pity JavaScript rarely gets the attention it deserves as a legitimate programming language. Most guides to C begin with teaching you how compilers work; most guides to JavaScript teach you how to swap some images.
This is unfortunate as it's quite powerful: it supports first-class functions and an excellent generic object-system, not to mention the usual suspects such as dynamic memory management.
Hopefully its apparent resurgence these days (as browser vendors get their compatibility acts together) will change this.
((lambda x ((x))) (lambda x ((x))))
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.
.NET assemblies etc.)
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,
The Glass is Too Big: My Take on Things
I'd rather use a browser configured to show me the world wide web as a bunch of hypertext documents, not as a bloated adware-infested and spyware-infested application that moves crap around inside the browser window and pops up windows.
Yes, but this is a discussion about JavaScript, not Flash.
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.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Try this site to see what I mean.
http://www.masswerk.at/jsuix/
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?
Code obfuscation isn't really a "feature" per se. I think the main problem is what you've mentioned -- that a lot of folks don't believe in the "Open Source" philosophy and yet use such scripting languages that by their very nature, are "open source." (PERL rants aside)
It's writing code and hoping nobody else can understand, modify, improve, or possibly circumvent it. To be perfectly honest, I don't think code should be more obfuscated than it already is. The simpler and easier to understand, the better.
I did run into a vbscript worm once that did something like rotX itself when transporting (with a random shift, I believe, to try to avoid AV fingerprinting), then decode and execute upon launch. I must say that was pretty neat in a sick sort of way.
I think by the time Javascript came along, Sun had pretty much lost interest in TCL. I heard stories about people trying to license the Sun implementation of Tcl/Tk and getting a runaround. It's probably not a coincidence that Ousterhout left Sun (and took Tcl with him) at about the same time as Eric Schmidt, who brought Ousterhout on board in the first place.
It's also responsible for Google Maps. That's the only big one that jumps out at me, but there are a few other uses I've seen, that I've liked. Try out greasemonkey, and make javascript work for you.
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
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
When an application uses javascript for the scripting language, does that mean a javascript parser is also implemented into the application? Or can javascript be used in a standalone environment?
A javascript parser is included in the application. The opensource ultima online server UOX3 used SpiderMonkey (Mozilla's javascript engine) to handle server-side scripting.
It's actually not that difficult to link spidermonkey into your application. I did it once for a benchmark program (it would pull a web page, and parse the javascript banners etc and time how long it took to download every piece of data required to render the page).
No web page should ever open up a new browser window when the user clicks on a link. That's rude! The world wide web is a set of documents, not an application. Web pages should not be making decisions of that sort for the user.
You can do this with CSS, and without having to call back to the server for the "help" content as another web page
Define your help notes as divs which are hidden (display:none). Then you have your "help" hyperlinks point to those divs, which can then become visible (because they have the focus a different CSS rule applies and they can get display:block or whatever).
Opening new windows is almost always a bad idea. "User-friendly" depends not just on the technique but also on the user. For some people it may work, in some circumstances, but for other people (people with visual impairments, for instance) it is never friendly.
You can be standards compliant and still use target with XHTML strict. One of the bigs things about XHTML is that it is modularized and target was just moved to a module which you can import in your documents:m l-target-1.mod
http://www.w3.org/TR/xhtml-modularization/DTD/xht
Using JavaScript for this, which people can disable or just selectively cripple, is a terrible idea and you start getting all these non-standard handlers spread around.
It never ceases to amaze me how people can do sometimes extensive work with JavaScript and still not spot what an elegant and powerful language it is. Sure, most of that work is about doing meaningless browser-related stuff and wrestling with bad APIs, but come on. I really do expect from an averagely talented real IT person to be able to separate that from the langauge, and be able to recognise the things it can do that their normal language can't. Its almost single-abstraction design that turns out to be able to do just about everything and still look nice and procedural and newbie-friendly totally rocks.
sudo ergo sum
Finally somebody who isn't a total dickhead speaks up on the Ajax craze.
..."
"With DHTML and AJAX hot (or hot again; we've been here before, and I don't like either acronym)
Bingo!
The man's right on.
We suffer more in our imagination than in reality. - Seneca