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."
If the "write once, run everywhere" feature was implemented. ;)
On a related note, I had an interview at Adobe a while back and the interviewer mentioned that javascript was the scripting language for a lot of their products. I drew a blank on that one since I had no idea how use javascript for an application (and, subsequently, didn't get the job). 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?
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.
Maybe because we actually know what we are talking about.
Brendan Eich worked at Netscape back when the web was pioneered.. he created Javascript while there, and wrote the entire javascript engine for the Netscape browser (version 2 or 3, can't remember).. facts are facts.. I'm sure theres more info at wikipedia.
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 ECMAscript. Name hasn't caught on yet. ECMA = European Computer Manufacturer's Association, I do believe. Mozilla used to have some bugs where you couldn't use that as the attribute value for a "script" element. Or maybe that was with SVG.
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
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.
As well as GMail, the new Google Custom Frontpage (You know you can drag those boxes around?), and hmm.. well, just disable JS in your browser and see how many websites still function. It's ubiquity is why popups exist, as the GP pointed out, but the reason popup blocking software exists is because simply turning off JS would "break the internet," in the eyes of most users.
https://www.eff.org/https-everywhere
Blah blah blah. There are situations where that's actually the most user-friendly thing to do, like when you're editing or entering information and need to display detailed instructions without losing the form, along with some other situations.
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.
somewhat like that amazon fiasco that prevents the same user from viewing all the pages of a book.
If Amazon didn't at least attempt to prevent you from accessing every page of each book, they'd be unable to offer the service at all as there's no way the publishers would agree to it. They'd essentially be providing a mechanism to get the text of the book for free.
If enough people piss about with it, Amazon *will* be forced to either withdraw the service, or just put up (say) five pages of each book and leave it at that, which would greatly reduce its usefulness.
It's official. Most of you are morons.
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
Removing all unneccesary whitespace and replacing var and function names with 1 or 2 letter replacements is also a means of compression.
Open source languages are not designed to only be used on open source projects, restricting what it can be used for goes against the whole point.
Besides, nobody has a problem with GCC producing output without embedded data to make it reversable.
I'm sorry, but this comment simply doesn't hold:
JS is not going away, so it ought to evolve. As with sharks (and relationships, see Annie Hall), a programming language is either moving forward, or it's dead.
No, when a programming language doesn't chance, it's called a standard. Look at what we've been able to do keeping html, css, and javascript a stable target for so many years! It's like Space Invaders on the Atari 2600 -- nobody who created that console, its hardware designed specifically for playing Combat and Video Olympics, expected someone to be able to slap six sprites in a row, much less have the player shoot then down one at a time. The 'standard' that was the 2600, however, gave a stable platform for programmers to learn tricks that would give the console life well beyond its creators' expectations.
We've got something like that with javascript, and we can see what happens when we compare to something like Visual Basic 6. Developers are still upset about Microsoft's decision to drop official support for VB6 in an attempt to force people to upgrade to VB.NET. Know what? Those upset programmers have found that VB6 hasn't rusted and simply continue using it to create their apps. There are more companies than you'd know (here's one) whose major apps are/were written in VB6, the 'prototyping language'. They're not quite ready to cast the baby out with the bath.
Fix bigs in javascript? Absolutely. The issue is that we've reached a point where nearly every browser anyone uses supports a 'single' flavor of javascript and we're all familiar with how to make our code work with the few quirks that remain crossplatform. There is a standard on nearly every box on the net that coders can assume will be there for them. I wouldn't want to see anyone mess this stable delivery platform up, splitting the user base into something like what we had in the Netscape 4.x/Mozilla/IE 4 & 5 days. Now *that* was an ugly time to code.
The bottom line is that evolution is an overused metaphor. You've got two choices if you'd like to propagate your genes into the future: immortality or reproduction. Immortality was a little too difficult to accomplish for living, unique individuals. Perhaps there were little organisms that could live forever, but something squashed 'em. They're gone. That's not a problem in the digital world, folk. We can make as many exact copies of an individual as we'd like. Javascript modules are not unique. They don't need to evolve. (I mean, come on, he even mentions sharks, a design that hasn't changed in millions on millions of years!)
Javascript should shoot to become an immortal standard, not another field of play and debate.
It's all 0s and 1s. Or it's not.