Should JavaScript Get More Respect?

An anonymous reader points out an article in IBM's Crossing Borders series about the language features of JavaScript, surely the Rodney Dangerfield of scripting languages. But with increasing use in such technologies as Ajax, Apache Cocoon, ActionScript, and Rhino, some industry leaders are taking a fresh look at the language. From the article: "Nearly every Web developer has cursed JavaScript at one time or another. Until recently, many developers had all but written off JavaScript as a necessary evil at best or a toy at worst... But JavaScript is becoming increasingly important, and it remains the most broadly available scripting language for Web development."

Comments

JS

[djupedal]

it remains the most broadly available scripting language for Web development.

As someone who has written applets with over 25,000 lines, I can easily agree. Out of the roughly two dozen languages (scripting, etc.) that I know, JS has been a cornerstone of both simple and solid applets and the quick & dirty prototype. Let's hope the future agrees :)

Re:JS

[Anonymous Coward]

I knew you could make Applet with Java....but with JavaScript, I just thought you could only write 'js script....'
but after 25000 lines you should be right...or did I miss something ?

Re:JS

[Schraegstrichpunkt]

And yet you don't seem to know the difference between an embedded Java applet and integrated JavaScript code.

Re:JS

[CmdrGravy]

25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????

Re:JS

[ignavus]

"25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????"

document.write('25,000 bottles of beer on the wall, 25,000 bottles of beer. Take one down and pass it around - 24,999 bottles of beer on the wall');
document.write('24,999 bottles of beer on the wall, 24,999 bottles of beer. Take one down and pass it around - 24,998 bottles of beer on the wall');
document.write('24,998 bottles of beer on the wall, 24,998 bottles of beer. Take one down and pass it around - 24,997 bottles of beer on the wall');

etc ...

Re:JS

[djupedal]

'integrated JavaScript code'

...as opposed to what? JS that isn't integrated...? I knew someone would complain. A rose by any other string of characters...

The uppercase 'A' should be enough of a hint as to why I went with that particular label :) - No? Since when is 25,000 lines small...?

For the grammar goons among us:
applet ['aplit ] noun - Computing A very small application, esp. a utility program performing one or a few simple functions.

And a utility program it was. Put up to accomplish a temporary (9 month), semi-automated process of data gathering, consolidation and PDF summary reporting via email...yes, 25k lines is nuts. Would I ever do it again? Not likely. And if you think this was crazy, you should have seen the process it replaced.

In this case it was easy enough to do, which meant we were providing the reports that senior management needed right away, giving us time to relax and build a proper & full scale SQL replacement. In the end, the recipients never knew when we migrated from the stop-gap to the final - all of the routine post-deployment feature requests went in and were tested long before it went public, with bonuses all around :) Thank you JavaScript!!!

Re:JS

[HxBro]

After writing javascript for the past 6 years on digital tv platforms, I can say I've seen EPG's, Games, Apps running on liberate based set-top boxes and various IPTV set-top boxes could be running apps of similar size at time too.

Granted you do try keep the sizes down but in some cases especially and EPG you do end up writing lots of code.

Re:JS

[mikek3332002]

document.write('25,000 bottles of beer on the wall, 25,000 bottles of beer. Take one down and pass it around - 24,999 bottles of beer on the wall');

A much better form for 25000 lines would be having, 12499 bottles of beer on the wall lines, an initlization statment, and a decremeant function after every write line. That way you can easily modify the code to start off with what ever number you want.

Re:JS

[h2g2bob]

How about Mozilla firefox (or any of it's extensions).

Re:JS

[Anonymous Coward]

Dude, you failed it and no buzzword is going to make his comment invalid.

Re:JS

[Anonymous Coward]

Also, it's a good idea to Write and Save your JavaScript a Word document (eg in an editor like Notepad), not scrawled in Paintbrush and saved as a Bitmap File. It's funny how the Internet can't compile my Paintbrush Javascripts lol! My fried says thats how all the best programmers do it, but I can't get it work. maybe I don't get something? something vital? I think that must be it

Re:JS

[datadriven]

for (i=25000;i=1;i--) {
    document.write((i + ' bottles of beer on the wall,' + i + ' bottles of beer. Take one down and pass it around ' + (i-1) + ' bottles of beer on the wall\n');
}

I only had 3 lines.

Re:JS

[pla]

In this case it was easy enough to do, which meant we were providing the reports that senior management needed right away, giving us time to relax and build a proper & full scale SQL replacement.

It strains credibility to claim that, after producing something functional, management would give you the time to replace it with something such that, "the recipients never knew when we migrated from the stop-gap to the final".

And I don't mean that as a typical geek management-slam - If they can't tell the difference, why should they approve the team spending twice as long on the cleanup as on the prototype? Yeah, the engineers might know the difference, but the aesthetics of the underlying code rarely counts as making for a better a business case.

Re:JS

[Schraegstrichpunkt]

'integrated JavaScript code'
...as opposed to what? JS that isn't integrated...?

Perhaps I chose my phrasing poorly. The JavaScript interpreter is integrated into the browser, and has direct access to the web page's content. As opposed to Java applets, which are mostly isolated from the browser and the surrounding page content.

For the grammar goons among us:
applet ['aplit ] noun - Computing A very small application, esp. a utility program performing one or a few simple functions.

I don't get my computing vocabulary from some unnamed dictionary. I get it from usage, and I've never heard anyone who isn't confused use "applet" in reference to JavaScript code. You wouldn't use it either, if you actually cared to communicate your thoughts clearly.

Re:JS

[Anonymous Coward]

for (i=25000;i=1;i--) document.write((i + ' bottles of beer on the wall,' + i + ' bottles of beer. Take one down and pass it around ' + (i-1) + ' bottles of beer on the wall\n');

Get rid of unnecessary braces and you're down to one line. (Yes, I know you could still write it on one line with the braces, but the point was that they were unnecessary.)

Re:JS

[Anonymous Coward]

applet ['aplit ] noun - Computing A very small application, esp. a utility program performing one or a few simple functions.

The only thing JS and applets have in common is that they run on client side.

Applets are Java bytecode (rarely used anymore) and Flash files.

JS is a script language which has to be interpreted by the (more or less conformant) JS engine embedded in the Browser before it does anything.

25.000 lines of JS script as you claim would mean at least 25.000 line-feeds which would mean at least 25k bandwidth per connection which means your shit sucks. You can do a LOT with server side includes these days. Please use JS only for rendering.

I suggest you go back to start and, this time, stay away from buzzwords when you learn everything again.

Re:JS

[Anonymous Coward]

My sarcasm detector exploded. ow.

Re:JS

[VernonNemitz]

I kind-of like JavaScript, probably because of its basic similarity to C, while it-seems-to-me being simpler than C++ I definitely like how a complete and completely functional program (however ugly it may LOOK), can be embedded in a Web page. I even like the way such a program can be client-side-only, needing no interaction with the server. In this day of phishing and other scams, it's nice to be able to offer something harmless to the masses. Here, for example: http://www.nemitz.net/vernon/SuDoKuHelp.htm

Re:JS

[walt-sjc]

25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????

1000 lines of application code, and 24,000 lines of browser compatibility code.

Re:JS

[TheNinjaroach]

Maybe you could write a few more to catch the joke for you as well. =)

Re:JS

[orasio]

Cut the guy some slack.
Only because Sun trademarked "Applet" it doesn't mean they invented it, or that they own it.
An applet is a small app. More often, it's a web, client side app. Much more often, it's a "Sun Java Applet".
In the context of this discussion, the second meaning was obvious. All of your responses were too pedant. There _are_ applets that are not "Sun Java Applets". In the context of _this_ discussion, it was clear what he was talking about.

Re:JS

[Anonymous Coward]

Dictionaries get their definitions from usage too, but thankfully they have a wider experience than you. I was going to quote the OED at you, but its definition is identical to the one the OP posted, so it's no longer an "unnamed dictionary". If that's not enough for you, try Wikipedia

Re:JS

[jozeph78]

"25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????"

document.write('25,000 bottles of beer on the wall, 25,000 bottles of beer. Take one down and pass it around - 24,999 bottles of beer on the wall');
document.write('24,999 bottles of beer on the wall, 24,999 bottles of beer. Take one down and pass it around - 24,998 bottles of beer on the wall');
document.write('24,998 bottles of beer on the wall, 24,998 bottles of beer. Take one down and pass it around - 24,997 bottles of beer on the wall');

etc ...

My goodness!

for (var x = 1 ; x <= 25000 ; x++ )<br>
{<br>
document.write( x + ' bottles of beer on the wall, ' + x + ' bottles of beer. Take one down and pass it around - ' + x + ' bottles of beer on the wall');<br>
}

Efficient, but perhaps less effective.

Re:JS

[Gr8Apes]

No no no!!!!

You write a single loop to dynamically generate 'x' lines of write output. Then you have folks download the saved file! That's how it's done in JS land!!!

Re:JS

[Anonymous Coward]

Super, that will loop forever printing out i as 1 ;)

Re:JS

[julesh]

A CMS with a relatively advanced JS UI that my company's currently working on has around 7,000 lines of JS. That's not a particularly complex application, either. I could easily imagine something like a webmail system reaching five times that.

Re:JS

[Bandman]

Really, because reading (and rereading) the original post, it looks like the author has confused javascript and java, which many people do quite frequently.

It's probably best to avoid the term "applet" when referencing the Java and javascript languages unless you are actually referring to a "java applet", in order to avoid sounding like an idiot (even if you arn't one).

Re:JS

[CastrTroy]

try{
tellJoke();
}
catch(JokeException e)
{
printf("joke wasn't funny");
}

Re:JS

[rjshields]

In the context of _this_ discussion, it was clear what he was talking about.

It might be clear to you but it's not clear to me whether he's written 25k lines of Java or JavaScript. Although this topic is based on JavaScript, he's talking about applets and processing PDF files and XML, things that are more commonly associated with Java. Perhaps you can enlighten the rest of us as to what he is talking about, I don't have the energy to try to decipher his muddled post.

Re:JS

[T-Ranger]

On the other hand, in a discussion at a place "For Nerds", it possible that one might give the person who claimed to write some 25k of code for one project (which is a lot, for anyone, in any language) the benefit of the doubt as to them understanding the True Meaning Of Technical Terms. You know, the point of this season[1].

[1] Or something.

Re:JS

[foniksonik]

How about Dreamweaver? Have you ever looked at it's WYSIWYG code? All Javascript. In fact the entire UI is 90% Javascript.... you can customize the whole app by editing, you guessed it Javascript.

Re:JS

[hobo sapiens]

I only had 3 lines.

Yeah, 3 lines and an endless loop. You meant:

for(var i=25000;i>0;i--)
document.write((i + ' bottles of beer on the wall,' + i + ' bottles of beer. Take one down and pass it around ' + (i-1) + ' bottles of beer on the wall\n');

Dude, this is slashdot. You can't be posting endless loops like that, that could be dangerous! Have you any idea how many geeks will be frozen in front of their computers until they involuntarily fall asleep?

Re:JS

[hkgroove]

So, that's why it's so horrible to work with!

Re:JS

[computational super]

That's not fair to the user - you're wasting his computing time by doing it that way. Instead, you should do that on the server side, like this:

<%
out.println( "<script language=\"javascript\">" );
for ( int i = 25000; i > 0; i++ )
{
out.println( "document.write(( " + i + " + ' bottles of beer on the wall,' + " + i + " + ' bottles of beer. Take one down and pass it around ' + " + (i-1) + " + ' bottles of beer on the wall\n');" );
}
out.println( "</script>" );
=>

Re:JS

[computational super]

Actually, I thought his post made perfect sense... back when Java applets were the motivating hype behind Java, the demos basically looked a lot like what we use JavaScript (or Flash) to do today (that is, present an interactive application in a web browser). What I'm hearing him say is: "I've implemented equivalent functionality as both Java Applets and as JavaScript, and I found JavaScript to be a better fit for the problem at hand."

Re:JS

[orasio]

In the context of _this_ discussion, it was clear what he was talking about.

It might be clear to you but it's not clear to me whether he's written 25k lines of Java or JavaScript. Although this topic is based on JavaScript, he's talking about applets and processing PDF files and XML, things that are more commonly associated with Java. Perhaps you can enlighten the rest of us as to what he is talking about, I don't have the energy to try to decipher his muddled post. Ok, here it goes (the full text of his post):

As someone who has written applets with over 25,000 lines, I can easily agree. Out of the roughly two dozen languages (scripting, etc.) that I know, JS has been a cornerstone of both simple and solid applets and the quick & dirty prototype. Let's hope the future agrees :) The topic is JS. He talks about applets. He says he knows "roughly two dozen languages", and that "JS has been a cornerstone of both simple and solid applets and the quick and dirty prototype".

He means "JS applets". Nobody talked about Java.

The only reason some people thought about Sun Java Applets is that Sun promoted that term a lot back in the day. As someone else said, this is supposed to be "news for marketdroids", it's news for nerds, and nerds are supposed to know the difference between a JS powered applet, and a Sun Java Applet.

I know he was not clear, and could have chosen better words, but I insist that it is a wrong correction to make, telling a guy that all applets are Sun Java Applets.

Re:JS

[dlim]

dude. you're putting the bottles back on the wall. that makes no sense at all...

Re:JS

[Anonymous Coward]

uhm... why not just use a for loop?

for (var i=25000, i>0, i--) {
document.write(i+" bottles of beer on the wall, "+i+" bottles of beer. Take one down and pass it around - "+(i-1)+" bottles of beer on the wall");
}

am I missing something? O_o

Re:JS

[jgc7]

Depending on how you create new lines, the Google Maps API javascript is about 12,000 lines. See the class reference

I can't image a javascript application being much larger than that.

Re:JS

[budgenator]

From what I've seen, 25, 000 lines of javascript has only one linefeed :-)

Re:JS

[Anonymous Coward]

Did you remember to include the ocr object into your workspace before attempting to compile?

Re:JS

[AaronCampbell]

If they can't tell the difference, why should they approve the team spending twice as long on the cleanup as on the prototype?

Well, I can't speak for this specific case, but often if you tell them something along the lines of "it will look and feel the same, but it will last for years rather than months" they tend to be sufficiently motivated. Especially the upper management that thinks (correctly or incorrectly) that the business would instantly go bankrupt if they did not read these reports.

Re:JS

[jc42]

I definitely like how a complete and completely functional program (however ugly it may LOOK), can be embedded in a Web page.

Well, that's why I keep both java and javascript turned off, except for short-term enabling when they're needed. If a browser won't let me do this, I simply don't use it for anything other than testing my own pages.

I have plenty of respect for JS. I've written a fair amount of code for it. That's why I understand that it's a Bad Idea to enable anything that lets a remote stranger download code to my machine and run it.

(I also have a few demos of some nasty things that can be done via JS, for the benefit of people who don't understand or believe the potential problems. But this is a geek/nerd form, so surely I don't need to provide links and risk a slashdotting. ;-)

Re:JS

[rjshields]

The only reason some people thought about Sun Java Applets is that Sun promoted that term a lot back in the day. As someone else said, this is supposed to be "news for marketdroids", it's news for nerds, and nerds are supposed to know the difference between a JS powered applet, and a Sun Java Applet.

Of course everyone should know that Sun didn't invent the term "applet", no one is disputing that. However, when you start talking about applets in the context of web pages and web development, it's only logical to assume you're talking about Java applets, and certainly not bits of JavaScript. You don't use the term "applet" to describe bits of JavaScript unless you're very confused. To quote wikipedia :-

An applet is a software component that runs in the context of another program, for example a web browser...An applet is written in a language that is different from the scripting or HTML language which invokes it. The applet is written in a compiled language, while the scripting language of the container is an interpreted language, hence the greater performance or functionality of the applet.

I'm sure you can see why confusion should arise over incorrect use of the term "applet".

Re:JS

[Anonymous Coward]

If your writing an entire front end web gui in javascript you'll hit that number easily! one of my clients is writing a huge application in EJB3 on the backend and the front end is all javascript manipulating the DOM and making ajax calls to the EJB junk on the backend.

well over 150,000 lines of javascript code...

Re:JS

[xornor]

What is a JavaScript applet?

Re:JS

[ShieldW0lf]

I've always liked using JScript on the server when I'm working in IIS, easier to remember the syntax when you're jumping around from client to server.

JavaScript client code is like ninjas on an away team mission. They're not bound to their environment, you write them to intelligently investigate it before they act. Fun stuff to build.

Re:JS

[fleck_99_99]

Check your boundary conditions. Your code will incorrectly process output for the case where i==1 or i==2.

Re:JS

[ClassMyAss]

25.000 lines of JS script as you claim would mean at least 25.000 line-feeds which would mean at least 25k bandwidth per connection which means your shit sucks. You can do a LOT with server side includes these days. Please use JS only for rendering.

I'm sorry, but this is just bad advice. Yes, I'll admit that 25,000 lines of JS is a lot, but depending on the calculation that's being performed, the frequency of updates, and the number of users expected to access that script during a given period, putting the processing load on the client can be more than worth a once-per-pageload 25k cost (besides, these days, most web sites push far more than 25k in title graphics alone!).

Your "Please use JS only for rendering." is likely to get you in trouble if followed dogmatically, especially in situations like stock data feeds where you might be getting one piece of data from the server every 10 seconds and calculating several customized indicators based on that data. It would be foolish (in most cases) to do the complex math on the server's end, because it would tie up the server while it could be pushing out data to other customers. I think a better rule is to be aware of your constraints, and choose the tools appropriate to the job. Spread out the processing power and bandwidth if at all possible, and you'll likely be fine.

Re:JS

[fredrik70]

argh! document.write() is *bad*!! of course he should write:

var txt = document.createTextNode("25,000 bottles of beer on the wall, 25,000 bottles of beer. Take one down and pass it around - 24,999 bottles of beer on the wall");
document.appendChild(txt);
var txt = document.createTextNode("24,999 bottles of beer on the wall, 24,999 bottles of beer. Take one down and pass it around - 24,998 bottles of beer on the wall");
document.appendChild(txt);
etc...

Re:JS

[mortenmo]

So instead of sending a roughly ~100 byte script that might waste some client cycles, you want to send a ~2MB of text/html data over the internet? Yeah, that sounds like a great idea and not at all a waste of the clients bandwidth! I hope he doesn't have a modem :)

Re:JS

[lysdexia]

*snizx* Mwhah? Where did this luxuriant white beard come from? And who are these little men a-bowling `neath my desk? By my faith! Is that process still running?

Re:JS

[TeknoHog]

25,000 bottles of Ajax on the wall.

Re:JS

[Anonymous Coward]

Your way only needs half the bottles. And actually it should then go from 12,499 bottles.

Re:JS

[VernonNemitz]

Heh, I'm somewhat behind-the-times with respect to the more modern features of JavaScript. The documentation I have is for version 1.3 or so, and it does not include any way that I know of to modify any files on the client machine, other than cookies. That's if the v1.3 JS code is written to function without crashing, of course. I might assume that if it crashed the browser, then some exploit might become possible. But personally, I prefer to write programs that don't include crashing as a "function". Given that Microsoft's ActiveX stuff so-easily lets malware mess up a computer, I'd say that to whatever extent they "enhanced" JavaScript to enable greater control of a computer, I'd say I prefer the older restricted way. It gives me a reason to brag about writing embedded JS that is actually safe to enable!

Re:JS

[hobo sapiens]

Thanks. And it's good that you got some time away from your job as a javascript interpreter!

Re:JS

[jboker]

other than the obvious error of i=1 on there, there's also a syntax error, missing the closing parentheses in the document.write call.
again, this is slashdot and you cant get away with errors like this.

Re:JS

[TuringTest]

No no no no no! You got it all wrong!

If you can catch the joke, it must be a funny one!

Re:JS

[Anonymous Coward]

As techno-nerds you should know how to avoid embarrassing yourselves... the word "applet" is not confined to Java nor did it originate there. Heck, even Microsoft call their control panel utilities "applets". Read up on something before slating someone else for misdiagnosed ignorance. Try this to start you off:

An applet is a software component that runs in the context of another program, for example a web browser. An applet usually performs a very narrow function that has no independent use. Hence, it is an application -let. The term was introduced in AppleScript in 1993. An applet is distinguished from "subroutine" by several features. First, it executes only on the "client" platform environment of a system, as contrasted from "servlet."

Re:JS

[Anonymous Coward]

This thread makes me sad, but it does seem to provide an answer to the question of whether or not JavaScript programmers should get more respect.

Re:JS

[Anonymous Coward]

Writing 25,000 lines of interpreted code is easy. Maintaining it is the bitch whore from hell no one is mentioning on this thread.

Re:JS

[Tablizer]

1000 lines of application code, and 24,000 lines of browser compatibility code.

Amen, Bro!

Re:JS

[Raenex]

If they can't tell the difference, why should they approve the team spending twice as long on the cleanup as on the prototype?

They should approve it after you explain that when they want new features or a bug fixed, it will be faster to add with fewer problems. You explain that if all projects were left in prototype stage as soon as something was working, eventually you'll end up with a big ball of mud.

Re:JS

[Schraegstrichpunkt]

We're still dealing with huge codebases that have tons of SQL injection and obvious buffer overflow vulnerabilities. There's no reason to assume that programmers who write a lot of code, in general, actually know what they're doing.

Re:JS

[Schraegstrichpunkt]

Dictionaries describe usage in general terms. That doesn't make the word choice correct. If you say that you write web pages in SGML, people are going to assume something like DocBook, even though HTML is an SGML dialect. If you start talking about writing SGML pages with JavaScript applets, you would still be correct according to any dictionary definition, but people would be right to assume you're confused, and you would be wrong to describe your work that way.

Likewise, if you put "ASP" on your resume, and the company that hires you finds out that you don't know a thing about VBScript---that your "ASP" experience was actually only with Python/ASP---no dictionary would prevent you from being fired with just cause.

Re:JS

[wonderidiot]

I have to agree, I have been using JS for the last few years and nothing compares to the way I can control an entire form to apply for twelve different products using a single parameter to control everything from fields, links, css, validations and form actions all on the fly in less than 1000 lines of code (including the HTML). Sure you could do this using all sorts of languages, but for the simplest and most compatible plain forms for web use - there is no other way for me!! Frustrating as JS may be sometimes, especially in browser compatibility (which has become infinitely better in the last few years), I still believe in having a challenge when I'm coding, otherwise what's the point of being in this career?? JS has solved many problems, opened opportunities and taken my coding to a whole new level. Even as I enter a new chapter of my development career, I'm sure JS will be a prominent feature in my applications. Here's to JS getting a revival........and the recognition it deserves. LONG LIVE THE SCRIPT

Re:JS

[orasio]

You don't use the term "applet" to describe bits of JavaScript unless you're very confused. To quote wikipedia :-

An applet is a software component that runs in the context of another program, for example a web browser...An applet is written in a language that is different from the scripting or HTML language which invokes it. The applet is written in a compiled language, while the scripting language of the container is an interpreted language, hence the greater performance or functionality of the applet.

I'm sure you can see why confusion should arise over incorrect use of the term "applet".

I see what the wikipedia says. It's wrong.
First, the idea of the applet being written in a compiled language is completely arbitrary, and probably comes from the nineties, when you couldn't easily write a web component just with JavaScript.

Right now, JavaScript has the power to implement a big part of the behaviors that Java Applets originally provided (e.g.:drag and drop, image manipulation and stuff).

There is a bit in the Wikipedia about applets being compiled, so it was fast, as opposed to interpreted languages. It might have been argued to be true some time, but right now that is just not an issue.

I think the wikipedia article is about the reality of eight years ago. Right now, javascript is ok to make applets. You can watch OpenLaszlo. One of the targets they generate for clients is flash, that would be an applet, and another is JavaScript+DOM, and by the definition of wikipedia it would not be an applet, although it is functionally indistinguishible from the other.

Re:JS

[rjshields]

I take your point. I think you're right that the definition of term "applet" hasn't yet caught up with the technology. To my mind an applet is something that is compiled, which is as it was back in the 90s.

Re:JS

[Anonymous Coward]

How many other kinds of applet do know in common use in web pages? If you talk about applets in the context of web page, people assume you are talking about Java applets, you fucking knob jockey. To use the term to talk about JS code makes no sense at all.

Re:JS

[hobo sapiens]

Spoken like a true VB luser. Good show, AC!

Re:JS

[Anonymous Coward]

i hate it when the difference smacks me in the face.

Is this a dupe from a few months ago?

[Schraegstrichpunkt]

It looks awfully familiar.

Re:Is this a dupe from a few months ago?

[Opportunist]

Your post looks awefully familiar to one I've read about 2 hours earlier, too.

Re:Is this a dupe from a few months ago?

[MPHellwig]

hmmm I thouhgt I've read your post before too

Re:Is this a dupe from a few months ago?

[Opportunist]

A deja vu.

An no exit in sight...

Re:Is this a dupe from a few months ago?

[Anonymous Coward]

hmm. I thought I've read your post before too.

Dense != Good

[Marcus Green]

According to the article

"My friend and colleague Stuart Halloway, one of the foremost experts on Ajax, begins a JavaScript class with a provocative statement: "By 2011, we will recognize JavaScript as a language with a better set of features for developing modern applications." He then says that JavaScript programs are often 10 times as dense as similar Java programs and goes on to show the language features that make it so."

The author seems to equate dense with good, not an association I make

Re:Dense != Good

[MichaelSmith]

The author seems to equate dense with good, not an association I make

By that standard APL would be hard to beat.

Re:Dense != Good

[Anonymous Coward]

He then says that JavaScript programs are often 10 times as dense as similar Java programs

So are the javascript developers in my experience. I kid, I kid...

I agree with parent poster that there seems that a lot of people take lines of code as the only measure of how good a language is. Something like 80% of developer time for an average project is spent on maintenance, and often there are new developers doing it. So in my opinion clarity is at least as important.

I admit that fewer lines of code can make code more readable, but brevity does not automatically mean clarity. Witness many perl based apps, especially those that make heavy use of regexp. I have also seen some pretty unreadable Ruby code where the programmer was clearly in love with all the clever things you can do. Metaprogramming, activerecord magic, method_missing stuff, runtime changes of objects where it was just more convenient than thinking through the model, and so on. Probably fun to write, nightmare to maintain.

Re:Dense != Good

[MemoryDragon]

I would not call javascript more dense, scripting languages usually have a denser syntax due to shortcuts and introspection on language level. Javascript is one of the weakest scripting languages thanks to missing namespaces and prototype handling in those aspects. I would not even call it denser the missing namespaces result in overly long class and function names. Actually javascript has good concepts, but its execution is missing the vital 5% of namespaces, and good object syntax constructs. If you want to see javascript done right check out groovy for instance, same idea as javascript in language design, but way better in execution.

Re:Dense != Good

[sholden]

Since developers seem to code about the same number of lines of code/statement per unit time, regardless of language. 10 times as dense means the developers are 10 times as productive. Since programmers are reasonably expensive needing 1/10th as many is a good thing.

But Javascript is no where near 10x as "dense" as Java, http://www.theadvisors.com/langcomparison.htm while flawed in many many ways puts Perl at 2.5 times as "dense" as Java. There is no way in the world that Javascript is four times as "dense" Perl...

Re:Dense != Good

[D-Cypell]

The author seems to equate dense with good

The irony of this is so elegantly compact I am concern a singularity may form around the vacinity of this article.

Re:Dense != Good

[Eivind Eklund]

I consider the numbers in that comparison so deeply flawed that they can't be used for comparing density of two languages like this.

In my experience, Ruby is about twice as dense as Perl *in direct translation* (I have taken Perl libraries and translated directly to Ruby). It is even more dense when the code is idiomatic Ruby - that might be up to 10x. Idiomatic Common Lisp is about as dense as Ruby.

Yet, Perl comes out at 15 and Common Lisp comes out at 5 in that "programming languages comparison", and Java comes out above Common Lisp at 6. These results are completely ridicilous. They probably have some statistical correlation with reality for some kinds of programming with some kind of developers - they're just far from exact enough to be useful for specific language comparison, like you do above. (They're also a decade out of date.)

Eivind.

Re:Dense != Good

[Anonymous Coward]

$_ is the devils variable

Using it puts your soul in peril - yet it is amazingly powerful if obscure and occasioanlly considered black magic

Re:Dense != Good

[CaymanIslandCarpedie]

10 times as dense means the developers are 10 times as productive. Since programmers are reasonably expensive needing 1/10th as many is a good thing.

That sounds great for little one-off scripts. However, if you are working on an application with any decent expected lifespan, well than that is just wrong. Say your average application will be in production use for 5 years (I'd think this is a pretty low estimate). In that case I'd guess your intial development costs would be a fraction of your support costs over the life of the product.

By your logic whenever designing a database you should always just name tables as A, B, C, D, E, ... and the columns within those tables as a, b, c, d, etc. Also, any comments in code are just a frivilous waste of money.

As much of a pain as writing verbose code can seem at times, it certainly does have its merits.

Re:Dense != Good

[Anonymous Coward]

Since developers seem to code about the same number of lines of code/statement per unit time, regardless of language.

It could be argued that they are correlated but one doesn't cause the other. After all, Perl can express anything in a single line :)

If a programmer was twice as capable, they could write a program in half the time, and with twice the density (for example due to greater confidence with inline increments and suchlike). That is, 10 lines in 10 minutes instead of 20 lines in 20 minutes.

However, this doesn't mean speed is dictated by density.

That said, with Perl I can apply a regexp with =~ whereas with JavaScript you need to go off creating a new RegExp object with more verbose and hence hard-to-remember syntax...

Re:Dense != Good

[Ricardo Lima]

Sorry to disagree, but dense can be good. I mean "select employee_name from employee where employee_id = ?" is much more denser than a similar code in C. Sometimes expressiveness can be bad, I admit, but dense languages mean that I can say more with less words. If density was so bad, we would still be programming in assembly.

Re:Dense != Good

[rjshields]

Since the current purpose is for light scripting of other applications, the lack of namespaces is not really too important. If it was to become a standalone scripting language it would need to have namespaces and some kind of standard library added.

Re:Dense != Good

[ajs318]

Namespaces? We don't need no steenking namespaces! If you can't use totally unique variable names in every single program you write, you shouldn't be programming!

Re:Dense != Good

[bensch128]

That said, with Perl I can apply a regexp with =~ whereas with JavaScript you need to go off creating a new RegExp object with more verbose and hence hard-to-remember syntax...

So, what does =~ mean? I mean, unless you memorize Perl's 1001 operators, you're pretty much up shit cheek. Where as OO languages only have a small number of operators and a very large library.

Perl is the worst were it has way too many operators and it also has a huge library. So you have to memorize both to make sure you understand the language. Plus the compiler and interperter must be complex and inefficent to handle all of the extraneous operators.

Give me new RegExp() anyday...

Cheers
Ben

Re:Dense != Good

[marcosdumay]

"Since developers seem to code about the same number of lines of code/statement per unit time, regardless of language. 10 times as dense means the developers are 10 times as productive. Since programmers are reasonably expensive needing 1/10th as many is a good thing."

Maybe, but writting the program is fast. What is slow is writting a program that works.

Now, How does Javascript helps you to wite code that works at the first try, or maintanable code, or code that is easier to debug? Well, the answer is that without sane objects, a workable type system, some rules that prohibit bad patterns of code, and most of the other things that make Java verbhose Javascript simply doesn't help you.

Re:Dense != Good

[ajs318]

You don't need to keep creating new RegExp objects. You can use something like
if (foo.match(/cat/i)) {
.....
}
for a quick match, or
bar = bar.replace(/cat/, "dog");
for a quick replace (note that unlike Perl, a replace returns a value which you must assign back to the variable. If you evaluate it in a void context, it doesn't change anything). If you used round brackets to pull out bits, you can access them later as RegExp.$1, RegExp.$2 and so forth. (Still not as cool as Perl; Perl lets you evaluate a regexp with round brackets in a list context, e.g.
($year, $month, $dofm) = ($sql_date =~ /(\d{4})-(\d{2})-(\d{2})/)
and get what would ordinarily have been $1, $2 &c. right there in the list to which you assigned. Well, it's good if you have a nice wide terminal window ..... it can get hairy when extracting many fields with a complex regexp.) You can also use $1, $2 &c. in replacements in JavaScript:
foo = foo.replace(/^\s*(\S.*)\s*$/, "$1");

Re:Dense != Good

[Rufty]

Dense *is* good. Suck all the bugs out of your code, you just need a perl regex with an event horizon.

Re:Dense != Good

[umghhh]

When you write: They probably have some statistical correlation with reality for some kinds of programming with some kind of developers you very rigth. The point is that any language being different from all others have specific features that are better suited for certain tasks and/or people than other. Comments, documentation and program structure is the key unless of course the appl being written is, on complexity scale, rather close to famous "f.k the world" program.

But that is so obvious that majority of us will not notice anyway and indulge in language comparisons just for the sake of argument.

Re:Dense != Good

[x2A]

Absolutely. Everytime I need a new variable, I use the md5 checksum of the file at its current point. If I ever forget a variable name, I simple undo until the first time I put the variable in (I keep vim open ALL the time, and never exit) and run md5 on it again. Simple.

Re:Dense != Good

[SharpFang]

10 times as dense also means 10 times lower probability of a mistake. Apples to apples, oranges to oranges, a badly-commented C code will be just as hard to maintain 'per line of code' as badly-commented javascript, correctly written will be just as easy - a screenful of good C will be as hard to debug as a screenful of well written Javascript, but C will do in that screenful what javascript does in two lines. Meaning C program will be 10 times longer and take 10 times as much work to maintain. Costing ten times that much in maintenance costs.

Re:Dense != Good

[dwarfking]

Of course this is a humorous post, but I have to ask, what does a namespace construct provide that you don't have with JavaScript already?

to quote Wikipedia a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allows disambiguation of items having the same name (residing in different namespaces)

Couldn't you achieve the same thing by grouping variables (or functions) as attributes of an object prototype since JavaScript allows dynamically adding variables (or functions) to objects?

Wouldn't something like

namespace TopLevel {
int count = 0;
};
int count = 5;
TopLevel::count = 1;
cout << TopLevel::count << " is not " << count << eol;

be equivalent to

TopLevel = new function() {
this.count = 0;
}
count = 5;
TopLevel.count = 1;
alert(' ' + TopLevel.count + ' is not ' + count);

Now granted, a namespace usually exists only once in a running context where as a JavaScript object can have multiple instantiations, but nothing would prevent the program from only creating and using one copy of the object to simulate the same environment.

Basically all this is syntactic sugar anyway. Object Orientation, Namespaces, Classes vs Prototypes, just different high level means of segregating data and grouping functions which are byte arrays in memory.

Re:Dense != Good

[MemoryDragon]

i sum it up simple and easy, namespaces provide constructs that you do not end up with functions looking like that org_slashdot_module1_submodule2_classname_function name

ok given that you can embed functions in functions you at least can block these names on definition level of the subfunctions, but you cannot on the root level of the function.

Sorry to say that, but the problem really is there, and it is severe, someone mentioned you do not need this stuff because javascript scripts are small and not application level. I do a lot of web2 stuff and I can assure you there are huge code libraries which heavily utilize javascript and some of them go wild hoops to add the namespacing to avoid this problem (and also to simplify the crude prototype inheritance constructs)

the classic example of this would be the dojo toolkit www.dojotoolkit.org. We are already in javascript at codesizes of middle size applications, if you run that stuff on a serious interactive level.

Re:Dense != Good

[MemoryDragon]

one word check out the dojo toolkit www.dojotoolkit.org, then you can see which codesizes we are already dealing with. The dojo toolkit is not the only javascript codebase of significant size already outside in the wild, the more interactive the applications become the more you see toolkits of that size becoming the norm not the exception.

Re:Dense != Good

[multi io]

The author seems to equate dense with good, not an association I make

As long as you don't deliberately try to write cryptic or code, the association holds.

Re:Dense != Good

[Richard Asbridge]

It reads better like this: "...JavaScript programers are often 10 times as dense as similar Java programers..."

Re:Dense != Good

[rjshields]

=~ is easier to remember than new RegExp()... or was that new RegEx() or new RegExp("blah") or new RegExp("blah", "blah")... I forget. Then once you've created it, what are the methods? Was it match() or find() or search()...

Re:Dense != Good

[rjshields]

Perl lets you evaluate a regexp with round brackets in a list context, e.g.

($year, $month, $dofm) = ($sql_date =~ /(\d{4})-(\d{2})-(\d{2})/)

That is an awesome feature, would love to see what the equivalent JavaScript is...

Re:Dense != Good

[raddan]

One reason to equate density with goodness is that the number of bugs per line (I don't recall the exact number) has been shown to be relatively constant. Therefore, if your programming language allows you to get more work done in fewer lines of code, you will have fewer bugs for a given application, and you can spend more time refining the application rather than bug-hunting. Obviously, there are other factors at work here, but it is an important factor, and it's why things like server-side web applications tend to be done in PHP/ASP/Perl/yadayada as opposed to C. C will happily run your server-side applications, but do you really want to reimplement the libraries and tools that web programming languages give you for free? Time is money.

Re:Dense != Good

[DragonWriter]

The author seems to equate dense with good, not an association I make

All other things being equal, I think dense -> good is pretty valid. The problem is that often, a programming language that allows a more dense expression does so at the expense of clarity, which becomes a problem for maintainability and debugging. (There may be other tradeoffs, as well.)

Re:Dense != Good

[Rob Riggs]

I agree with parent poster that there seems that a lot of people take lines of code as the only measure of how good a language is. Something like 80% of developer time for an average project is spent on maintenance, and often there are new developers doing it. So in my opinion clarity is at least as important.

The author's comment on "density" is a contrast in brevity and verbosity, and not about clarity. A language such as JavaScript (and Python to name another) communicates the same amount of information with greater clarity in far less space than "high-level" languages such as C++ and Java. The cost of maintaining applications with the same feature goes down as the density of the language increases. Greater density results in fewer lines of code, resulting in less development and maintenance costs.

Re:Dense != Good

[null etc.]

I'm sorry, but there's no way that Perl is only 2.5 times as dense as Java. It's at least 150 times as dense.

Re:Dense != Good

[bckrispi]

=~ is easier to remember than new RegExp()...

We're all entitled to our opinions, I suppose.

Then once you've created it, what are the methods? Was it match() or find() or search()...

I don't need to remember. Using a good IDE like Eclipse, it's simply a matter of pressing CTRL+SPACEBAR to see possible (documented) completions.

Re:Dense != Good

[sholden]

That sounds great for little one-off scripts. However, if you are working on an application with any decent expected lifespan, well than that is just wrong. Say your average application will be in production use for 5 years (I'd think this is a pretty low estimate). In that case I'd guess your intial development costs would be a fraction of your support costs over the life of the product.

Sure an application might be 20% development, and 80% non-development costs. Then saving 90% on development costs only saves you 18% of total costs - but that's significant in most places. Of course in reality things interact and it's hard to split costs exactly (for example, crappy development results in more support costs - so saving development costs by employing monkeys can increase support costs and be a net negative).

By your logic whenever designing a database you should always just name tables as A, B, C, D, E, ... and the columns within those tables as a, b, c, d, etc. Also, any comments in code are just a frivilous waste of money.

That's just being silly:

select a.c, b.b from a,b where a.b=b.a and a.d='blah';

if exactly the same (from a LOC/statements view point as):

select person.name, group.name from person, group where person.groupid=group.id and person.something='blah';

comments also don't count in any sane LOC/statements count. There's a reason I included the word statements, after all:

a+=2;b+=3;c+=4

if the same (by this metric) as

a+=2;
b+=3;
c+=4;

or

a = a + 2;
b = b + 3;
c = c + 4;

but better than (in some non-existent stack assembly language):

PUSH A
PUSH 2
ADD
POP A
PUSH B
PUSH 3
ADD
POP B
PUSH C
PUSH 4
ADD
POP C

Of course adding numbers isn't where it matters - but the principal remains. Of course the usual price for this is that the program runs slower (not always but that's the usual trade off). CPU is cheaper than developers in most cases (again not all cases) so that's often a good trade.

There have been studies that show that an assembler produces about the same LOC/statements output per day as a C programmer. If C is more expressive, which is what I interpreted "dense" to mean since it was said as a positive, then a single LOC/statement in C will do the equivalent of multiple statements in assembler and hence the C programmer is more productive.

Javascript is more expressive than Java (well I'm trusting the article on that), but it's far from the peak. Most functional languages, plus the perl/python/ruby crowd are "denser" still.

Re:Dense != Good

[Anonymous Coward]

Choose your tools acording to the job at hand.

General purpose languages such as C++ and Java (well, at least Java was originally supposed to be general purpose) will always be less "dense" than more focused languages such as JavaScript.

Trying to compare C++ or Java with JavaScript is comparing apples with oranges.

This subject is a non-starter for anyone that has studied CS (formally or informally) and has a number of years of real world experience under their belt.

Re:Dense != Good

[rjshields]

We're all entitled to our opinions, I suppose.

It's not just opinion, the =~, // and s/// syntax is very easy to remember and to type.

I use eclipse as well. Yes, code completion is valuable but I didn't realise it supported JavaScript code completion.

Re:Dense != Good

[iluvcapra]

Well.... just an observation:

Inside your function "TopLevel" block, you still have to qualify your variable assignment of "count" as being a member of "self." In a language with a proper namespace, this qualification is automatic if you use a variable name that is not declared in any parent namespace.

Also, languages with namespaces almost always have a way of "importing" a namespace permanently into the top scope, so you can say:

using namespace TopLevel;
count = 1;

Thus, TopLevel::count is assigned, and if you wanted to keep a separate one in the top namespace, you do main::count (er words to that effect, I am not a C++ coder). If you wanted to declare a buncha functions in a scope, using your technique, you'd have to state them in long form every time you wanted to use them, which is equivalent to just giving them a long prefix-name.

You're absolutely right, it's syntactic sugar, and namespaces and objects and execution contexts are similar things, but programmers use them in different ways, and syntax should fit use hand-in-glove.

Re:Dense != Good

[rjshields]

Hey MD, dojotoolkit looks very cool. I will check it out. Thanks, Rob

Re:Dense != Good

[Anonymous Coward]

that was a lot more than one word.

Re:Dense != Good

[Myen]

Well, if you're using JavaScript 1.7 (i.e. Firefox 2 or later... but nobody else):

[, year, month, dofm] = /(\d{4})-(\d{2})-(\d{2})/.exec(sql_date)

reference - and yes, that comma at the start is deliberate since the first item in the array is the full matched text.

Re:Dense != Good

[mattwarden]

There are so many things wrong with that analysis, it's not even funny. Your assumption that developers write a constant number of lines per unit time is flat out wrong. Number of lines is a horrible measure for almost everything. You see it often because it's the best objective measure we have, really, and in your mind you assume that must mean it's a good measure. It's not. It's horrible and have very low correlation with complexity, difficulty, and even file size.

If I asked you to measure the complexity of a programming solution, and you give me a count of the number of carriage returns in the file, you'd get a pretty strange look from me.

If you need proof, look at a perl program.

And that leads into my next point: you aren't considering maintenance costs, which are the biggest costs in the software development life cycle. "Dense" languages typically cost more to maintain, because the code is less verbose and less self-documenting.

Again, if you need proof, look at a perl program.

Re:Dense != Good

[Lord Ender]

Wow, Perl must be the best language. *gag*

Dense = complex.
Complex = bad.

Re:Dense != Good

[Raenex]

A language such as JavaScript (and Python to name another) communicates the same amount of information with greater clarity in far less space than "high-level" languages such as C++ and Java.

As these language wars do, it often comes down to dynamic vs static typing. A dynamic language like Python gains some of its succinctness by omitting types, which has the effect of reducing communication. Looking at the types of parameters and return values is an extremely valuable tool, and becomes more important as projects get larger in size.

Then there's languages like Perl, which gains much of it's brevity via hidden magic and cryptic constructs. It's great if you live and breath the language, but not so great otherwise.

Re:Dense != Good

[Enahs]

Heh, and I think your .sig sums it up well on Perl. :->

And you may have hit the nail on the head on the state of software development.

Re:Dense != Good

[Anonymous Coward]

Dense isn't necessarily good, but when comparing Java to anything (other than perhaps COBOL or Ada), Java usually ends up looking bad because of its unnecessarily verbose way of expressing things.

Yes, but Javascript is a bad language.

[Anonymous Coward]

- It is not possible to have two methods with the same name and different parameters (only one of those will ever be called).

- On the other hand methods behave like objects. One can have arrays of methods and then call mymethods[2](param);!

This is just plain weird.

Re:Yes, but Javascript is a bad language.

[Schraegstrichpunkt]

Weird? Does JavaScript support something like varargs? If so, then this is no different from Perl, Python, C, probably Ruby, bash, and basically every other language I've used except C++ and Java.

Re:Yes, but Javascript is a bad language.

[Myen]

Every function has a variable number of arguments. You can access it via the keyword arguments - it's an array. So yes.

function foo() {
  alert(arguments[0])
}

Re:Yes, but Javascript is a bad language.

[masklinn]

It is not possible to have two methods with the same name and different parameters (only one of those will ever be called).

Because Javascript has no ways of dispatching: all functions (remember that Javascript methods are exactly like functions) use varags, and the arguments you ask for are but pointers to vararg cells.

Example:

1. function foo(a, b, c) {
2. return [a, b, c, arguments]; // `arguments` holds every single argument of your function no matter what
3. }
4. foo() // -> [null, null, null, []]
5. foo(1) // -> [1, null, null, [1]]
6. foo("foo","bar","baz","buzz","bon") // -> ["foo","bar","baz",["foo","bar","baz","buzz","bon" ]]

On the other hand methods behave like objects. One can have arrays of methods and then call mymethods[2](param);!

It's not that JS functions "behave" like objects, JS function are objects, period. Callable objects maybe, but objects nonetheless, they're no different from strings, integers or lists in that aspect.

And this is one of the nicest features of the language (along with lexical scoping and complete closures)

Re:Yes, but Javascript is a bad language.

[Anonymous Coward]

Java 5 has vargargs.

Re:Yes, but Javascript is a bad language.

[bensch128]

I would consider Ruby to be the correct direction that Javascript should evolve towards.

The way it it allows you to easily add properties and it's reflexiviness is extremely similar to javascript.
It has a bunch of other freatures I'd love to see in JS one day, like hiding instance variables, class+module concepts instead of having to using function() to initialize members, and continuations.

Otherwise, I think that JS is a perfect lowlevel scripting language.

Cheers
Ben

Re:Yes, but Javascript is a bad language.

[rjshields]

- It is not possible to have two methods with the same name and different parameters (only one of those will ever be called).

That's because a function is an object. You can't have two objects with the same scope in most languages.

- On the other hand methods behave like objects. One can have arrays of methods and then call mymethods[2](param);! This is just plain weird.

Yes they do, because they *are* objects. No it's not.

Re:Yes, but Javascript is a bad language.

[Anonymous Coward]

This is just plain weird.

Is that weird? Both of the things you mention are also true of C. Arrays of function pointers are very useful things. If you have a case statement that handles many cases, you might be able to accomplish the same task more efficiently and more readably by using an array of functions.

And function overloading is bad because it makes it harder to understand the meaning of code.

Re:Yes, but Javascript is a bad language.

[mad.frog]

It is not possible to have two methods with the same name and different parameters

That's not a bug -- it's a feature.

(Did we charge you for the deluxe version?)

Re:Yes, but Javascript is a bad language.

[masklinn]

I would consider Ruby to be the correct direction that Javascript should evolve towards.

Javascript is currently evolving towards Python, which I consider much more fit to what JS currently is and its past history.

It's also acquiring features from much more functional languages (such as JS 1.7' let structure for dynamic scope generation)

It has a bunch of other freatures I'd love to see in JS one day, like hiding instance variables

You can already get "private" variables easily, and JS has properties too, I don't see anything missing

class+module concepts

That's in the work for Javascript 2.0... maybe.

instead of having to using function() to initialize members

I sujest that you look up the notion of Prototype-based Object Oriented Programming

The initial function on which you use new is merely a constructor, the only thing that would be gotten from a more regular class syntax in that point would be... well... nothing at all.

Class-based POO has other advantages, but this is not one of them.

continuations

There are great many things that should be fixed in Javascript before implementing continuations.

Re:Yes, but Javascript is a bad language.

[siegesama]

And this [functions as objects] is one of the nicest features of the language (along with lexical scoping and complete closures)

I'm surprised that none of the +3 comments make any mention of how close JavaScript is to Scheme (or any Lisp 2, I suppose) with the features you've noted.

Re:Yes, but Javascript is a bad language.

[mabinogi]

Just because you don't understand it doesn't mean it's bad.

It sounds to me like you need to spend some time studying languages like Lisp, Smalltalk and Self.

Re:Yes, but Javascript is a bad language.

[bensch128]

Javascript is currently evolving towards Python, which I consider much more fit to what JS currently is and its past history.

Please, please don't tell me that JS will lose it's braces and go for whitespace scoping... not going to happen because of the need to put js code into event handlers. otherwise, I hope it doesn't get OOP tacked on the way python has it. (explicitly having to declare self as a param in every method? WTF?)
I see it more like ruby because of the open/closed nature of ruby classes, which is closely mirrored in JS's prototype lookup system. Compare how ruby finds the correct method to execute vs JS. Its the same bloody thing. (i haven't read how python does it though...)

The initial function on which you use new is merely a constructor, the only thing that would be gotten from a more regular class syntax in that point would be... well... nothing at all.
Grrrr, this is both freeing and extremely scarely. I really live js for quick and dirty app development but without serious considerations for coding standards, I doubt its possible to build large multi-person projects in it. And I think that the language itself should enforce 99% of the coding standard. So by allowing arbitrary structure into your class declaration/prototype function, you really need to be careful.
I guess js is just one of those languages which you can't live with and can't live without.

Why the pressure ?

[unity100]

Lately it is like as if some circles are almost pressuring the developer community to pay more attention to java, javascript and affiliated stuff. Every now and then someone pops up and says something to that effect and chaos ensues.

I just dont get why ?

Theres something called freedom. If something is useful for developers, they like it and they use it, and they think good of it, they pay it respect. If something does not catch their attention, or they think its not to their liking, they just ignore it.

I just dont get why are we being pressured to look into matters java, javascript. If they are respect-worthy, they will earn the respect by themselves good enough. If not, noone can make developers to respect something by propaganda or by coercion.

Re:Why the pressure ?

[tpwch]

Java and Javascript? Why would anyone do that, since those two are not related other than the name. Sun developed Java, and Netscape developed Javascript. Totally independent of each other. I'm starting to get tired of people thinking that they have something to do with each other.

Re:Why the pressure ?

[unity100]

whats the rush to conclude that someone thinks they are the same ?

in case you have noticed i said that there have been a lot of debates ensuing from various articles that are bent on java AND javascript are underrated. not java/javascript. It might as well be apples and liquid cooled rockets.

actually there is one debate that is in a few day older articles that is still not cooled down, about java this time.

Re:Why the pressure ?

[Anonymous Coward]

Respect?

How many web developers respect IE, relative to how many make their pages IE compatible?

In the case of javascript, if you were developing a browser you would have to include javascript support or be marginalized. So while those developers have the choice not to implement it, realistically, they have to.

Same with developing for Windows, working with it in some cases can be a pain in the ass. But that is where the market is. Thus programmer time can be wasted working with a beast while greener pastures are available, but not commercially viable.

Standards can be forced on people, even if they are bad.

Re:Why the pressure ?

[Aqua OS X]

Developing interactive content for the web is a lot like building a house out of crap you find at the junk yard. None of the materials are great, you'll be forced to use a lot of jankie things you'd rather not use, and you may need to substitute sheet-rock for side panels from an '82 Corolla.

In the case of anything involved in web development, I use tools because they're the best thing for the job. Unfortunately, "best" for web dev tools usually means "only" or "no one will be able to view your page if you develop with something else."

Java Script / J Script is the devil. Development is a sloppy crap shoot, but we use it because it's there. It's now being used for ridiculous things that it was never really designed for.

On one hand, web 2.0 AJAX sites are cool, on the other hand, AJAX makes me throw-up a little bit in my mouth every time I type it's name.

Re:Why the pressure ?

[Aladrin]

Because the discussion was about javascript and you just threw java in there, and even suggested it was related: "java, javascript and affiliated stuff"

You might as well have thrown cobol in, since they are just as much 'affiliated' as javascript and java are.

Re:Why the pressure ?

[Bastard of Subhumani]

whats the rush to conclude that someone thinks they are the same ?

This guy sure seems to have them confused - he writes javascript applets, apparently.

I won't even mention HR departments.

Re:Why the pressure ?

[slide-rule]

Actually it just got worse: Java now has a facility called "Java Script"... included is the Rhino engine, so you can now run "Javascript" inside of "Java Script".

Re:Why the pressure ?

[GeckoX]

A decade later and you're still getting your panties in a bundle over it?

Don't sweat the small stuff.

Oh, and btw, it's all small stuff ;)

Re:Why the pressure ?

[GeckoX]

Tell me this, what languages can you use to render content within a browser, on the client?

It is completely obvious that THAT is why a few people have mentioned Java and JavaScript in the same sentence throughout the course of this thread. They are related, in that they are a subset of a small list of viable browser client languages. Actually, there really are only 3: Java, JavaScript, and Flash. Few consider Flash to be a language per se, thus we're left with Java and JavaScript.

Re:Why the pressure ?

[Shaper_pmp]

"Java Script / J Script is the devil. Development is a sloppy crap shoot, but we use it because it's there. It's now being used for ridiculous things that it was never really designed for."

What exactly is wrong with the javascript language? Everything you're ranting about is the fault of browser manufacturers and faulty/incomplete/deliberately broken implementations of javascript. The DOM support of various browsers sucks

Some news: Lisp would be shit if there were three or four wildly-divergent implementations, each claiming to be "the" lisp. And especially if the dominant version was a bastardised Microsoft Lisp-alike which everyone who didn't know better coded-to.

Javascript the language is actually quite compact, elegant and usable.

Re:Why the pressure ?

[saltydogdesign]

I disagree vehemently. If you spend enough time getting to know it, you'll find that Javascript is a very elegant language. It's true that the various implementations are a weak spot, but there are plenty of good frameworks (prototype and dojo in particular) that insulate you from a lot of that nonsense. I've been developing JS since around 1997, and I can tell you it has blossomed in the last couple of years. JS is now an absolute pleasure to develop, and if I had my druthers, I'd toss my PHP and Perl out the window.

Still waiting on server-side compiled JS...

Re:Why the pressure ?

[FishWithAHammer]

Lisp is shit anyway, but for different reasons. And there ARE implementations of it (or bastardizations of it) that diverge pretty wildly: Scheme, Common Lisp, Emacs Lisp...

Re:Why the pressure ?

[Aladrin]

I completely disagree. Obviously, Flash is not a language any more than JPG or PNG is a language. It's a container. ActionScript is the language that Flash uses.

As for Java, that's like writing a plugin for a browser for COBOL and then claiming it's one of the few languages that can render directly in a browser.

Javascript is native to the browser. Java is not.

Re:Why the pressure ?

[Anonymous Coward]

alert('You are right! Also, it really is time that people learned there is a difference between Java and Javascript. Mind you, poor naming decisions led us here...');

Re:Why the pressure ?

[GeckoX]

Holy pedantic batman.

Tell me, what are the most common technologies used for programming web pages?

Right. JavaScript, Java, and Flash.

Did I say anywhere that Java == JavaScript? No, I did not. Did I mention COBOL? No I didn't. Just because it can be done doesn't mean people do.

Both Java and JavaScript are HEAVILY used to provide rich client functionality. These are the technologies that web developers actually use, regularly. God forbid they come up in the same conversation.

That's all that I was getting at. Just because someone mentions Java and JavaScript in the same conversation does NOT mean that they don't know the difference between them as a number of people, including yourself, like to assume. Even when it is quite obvious that that is not the case.

Arguing for the sake of arguing...got nothing better to do today?

Re:Why the pressure ?

[rjshields]

Lately it is like as if some circles are almost pressuring the developer community to pay more attention to java, javascript and affiliated stuff. Every now and then someone pops up and says something to that effect and chaos ensues.

No one is pressuring you into anything. Did someone handcuff you and force you to read the article and comments? I think not. Perhaps the fact that these languages are very popular makes it hard not to notice that people are talking about them. As for being "pressured" into paying more attention, I think your tinfoil hat needs adjusting.

Theres something called freedom. If something is useful for developers, they like it and they use it, and they think good of it, they pay it respect. If something does not catch their attention, or they think its not to their liking, they just ignore it.

"They just ignore it"... it sounds to me like you might want to listen to your own advice!

Re:Why the pressure ?

[bentcd]

I have done a great deal of Java programming over the years and some months back, I found it necessary to do some JavaScript (actually ECMAscript) programming. I found that this was quite easy once I adopted the philosophy that "JavaScript is like Java on acid" (*). They really are quite similar, and I expect this was an important design consideration when JavaScript was first created.

* - I eagerly await ad from Sun in which they first show you a snippet of Java code with a voiceover "This is your programming language", then show you a JavaScript snippet with the voiceover "This is your programming language on drugs" :-)

Re:Why the pressure ?

[rjshields]

JS is now an absolute pleasure to develop

I agree with you, it's a cracking little language. It's funny how the people who criticise it haven't use it much or don't even understand the difference between the language and the implementations of it, the DOM, etc.

if I had my druthers, I'd toss my PHP and Perl out the window

PHP should be archived in /dev/null, but my ideal scripting language would be JavaScript with the regex and various other neat syntactic features of Perl, combined with a library like CPAN.

Re:Why the pressure ?

[Aladrin]

"Arguing for the sake of arguing...got nothing better to do today?"

One could say the same for you, since you didn't bother to read the original context in which 'java' and 'javascript' were mentioned. I'll save you the trouble. It says "java, javascript and affiliated stuff", as if java and javascript are affiliated to each other. If they weren't, it would be hard to have 'affiliated stuff' with the pair of them.

Re:Why the pressure ?

[DragonWriter]

Tell me this, what languages can you use to render content within a browser, on the client?

That I can think of off the top of my head? JavaScript, Flash, anything that compiles to Java bytecode (which is considerably more than "Java"), anything you can use to create Windows Forms controls (obviously, IE-only), and REBOL.

I'm sure I'm missing a few.

Re:Why the pressure ?

[Aladrin]

If it was only JS and Java that were that close, I could agree with you. But you can take the same philosophy and program C, PHP, and other languages, too. The syntax is similar because C proved it worked well, and the others used it also. Java and Javascript are only alike in that they were designed by people who had experienced C.

I'm sure C was influenced by previous languages as well. (Other than the obvious predecessors, of course.)

Re:Why the pressure ?

[GeckoX]

Java, JavaScript, CSS, HTML and affiliated stuff.

There, does that make it better for you?

I damned well did get the context, it is YOU that insists it means something that it clearly did not. Especially since the author of that post clarified that themselves as well.

Re:Why the pressure ?

[Fahrenheit 450]

Scheme is not Lisp, Scheme is Scheme.
Yes, it has it's roots in Lisp, and it looks a lot like Lisp, bit Scheme is no more Lisp than C# is C.

Re:Why the pressure ?

[bentcd]

While there are definite similarities between C, C++ and Java, my experience with JavaScript suggests that it was created with Java in mind for more than just the PR bandwagon effect. As an example, it also has direct facilities for calling Java code from within JavaScript and use Java object references directly from within JavaScript etc. I expect this is largely intended for easy interaction with Java applets. I found good use for this when writing JavaScript test suites that could use Java-based libraries directly without much fuss. It really did, at times, give me the feeling of being a scripting language for Java but that's probably because I don't know JavaScript and so would call into Java libraries to get the difficult stuff done (not knowing how you're _actually_ supposed to do it with JavaScript) :-)
I would say that JavaScript has something to do with Java, but Java doesn't have anything to do with JavaScript.

Re:Why the pressure ?

[unity100]

You are still saying the same thing.

im quoting my earlier message :

whats the rush to conclude that someone thinks they are the same ?

in case you have noticed i said that there have been a lot of debates ensuing from various articles that are bent on java AND javascript are underrated. not java/javascript. It might as well be apples and liquid cooled rockets.

actually there is one debate that is in a few day older articles that is still not cooled down, about java this time.

apparently you did not read further than the first sentence.

Re:Why the pressure ?

[Anonymous Coward]

Scheme is a lisp dialect. Lispers and Schemers both agree on this. I'll take their word over your ranting.

Re:Why the pressure ?

[Anonymous Coward]

Quote from yourself, above:

Arguing for the sake of arguing...got nothing better to do today?

Amen to that. GET YOUR FUCKING PANTIES UNTWISTED GECKOX!!!!!11ONEHUNDREDANDONE

Re:Why the pressure ?

[freezin fat guy]

> On one hand, web 2.0 AJAX sites are cool, on the other hand, AJAX makes me throw-up a little bit in my mouth every time I type it's name.

You are my new hero... (I couldn't agree more)

Re:Why the pressure ?

[Myen]

You also use C++ things from JavaScript all the time. Does that mean JS was created with C++ in mind?
(Browser don't implement the DOM in JavaScript... so anything that interacts with the page, at all, is talking to C++. Whether through XPCOM (Mozilla) or COM (IE).)

Re:Why the pressure ?

[Myen]

I think whitebeam is supposed to be some sort of server-side apache module for running JS. It uses Mozilla's JS engine (SpiderMonkey) at least. Their page is just confusing though, and I've never used it so I can't vouch for its sanity... And as far as I can tell it's not compiled either.

Re:Why the pressure ?

[bentcd]

I must take this to mean that we are dropping any attempts at rationality and going for extreme pedantry instead. If so, I really must point out that JavaScript does not interact with C++ at all - it "interacts with" machine code instructions the exact nature of which are dependant upon the architecture you are running the various pieces of software on. I am not currently aware of any hardware architectures that run native C++.
It would seem that this debate has evolved in a direction that doesn't hold much interest for me so unless you can come up with something else worthy of discussion, I expect I'll be bowing out at about this time.

Re:Why the pressure ?

[Shaper_pmp]

Fair point, but not all those Lisp interpreters claim to "support" the same standard.

Ok, how about:

"You might as well say C/C++/C# are shit because Windows and Linux don't support exactly the same libraries".

Better?

Should JavaScript Get More Respect?

[Anonymous Coward]

In the opionion of a retired Windows cleaner: NO!

Feared? YES

Re:Should JavaScript Get More Respect?

[polar red]

retired MS-Windows cleaner ? or retired glass-thingies-you-put-in-walls-cleaner ?

Re:Should JavaScript Get More Respect?

[Anonymous Coward]

Between ActiveX and JavaScript auto-installs used by malware distributors, trojans included in free as in trap bait software and with Windows as the distributed with the majority of new computers OS, "computer repair" is generally cleaning Windows. A Linux user friend even brought me a copy of a Red Hat distro several years ago that he had clearly labeled "Squeegee".

Security is a problem

[Anonymous Coward]

Hey guys. I'm an online gamemaker, so 'toy' languages are right up my alley.

The main problem with writing games with some of the most applicable web tools out there (Javascript, Flash) is that once it hits the web anyone with access to the View Source command can steal your work and throw it on their own site as theirs. This is highly discouraging.

Nowadays I do use Javascript and Flash extensively, but the most significant part of any game machinery is always on the backend somewhere, usually in PHP.

Re:Security is a problem

[Abasher]

Yes, the main problem is security, but not in the way you mean. Just have a look at how many remote exploits through javascript have been found this year. On one who's concerned about security (and doesn't trust every webserver he/she goes to 100%) has javascript turned on. It's not a big hassle to allow in in NoScript, but still.

Re:Security is a problem

[pubjames]

Surely there are many things you can do to make the Javascript delivered to the client practically unmodifiable.

why don't you use PHP to deliver the Javascript, and have the PHP obfuscate it?

Re:Security is a problem

[vadim_t]

Oh, bullshit.

No obfuscation will make it very different from what it is. A code indenter, a variable name replacement, and it'll be already understandable to pretty much any programmer.

Re:Security is a problem

[tacocat]

That may be true but there are still a lot of people out there who are willing to write applications in other languages that can also be "stolen" from the web. I've looked at some javascript in the past that I wanted to steal and the canned libraries that are available to day.

In the long run, stealing someone else javascript is not going to be that prolific. Good thing you aren't a musician, eh?

Javascript could become a language to actually use, if it actually worked as a language and not a conglomerate of many language influences that are all fighting for the same space. Some call this software platform dependency. I call it the death of javascript.

Re:Security is a problem

[DrSkwid]

If only you;d know that when you started ... oh wait ...

Re:Security is a problem

[ajs318]

No, the problem is that you are confusing sharing with stealing. If somebody shares your code, you still have it -- all of it. If somebody steals your car, you no longer have it. Understand the difference now?

That's the way the world is; and if you can't get used to it, I suggest you stop writing code and do something different. You could use a compiled language instead -- I'd reckon you've got about ten years left before decompilers are good enough that even compiled code will be readable.

Re:Security is a problem

[Anonymous Coward]

oh fuck off, hippy

Re:Security is a problem

[uradu]

> anyone with access to the View Source command can steal your work and throw it on their own site as theirs

Don't flatter yourself. As any halfway experienced developer will realize, that would only be true of the most trivial code, or perhaps some fancy algorithm that calculates the meaning of life in five lines of code or less. Most larger real world applications that do something useful are more tedium than brilliance, and are so problem domain specific that code "stolen" from them would be all but useless to most people or projects. You're welcome to all the thousands of lines of JS code our company produces, where would you like me to mail it to?

Re:Security is a problem

[Cragen]

I would recommend you mailing all that JS code to our webmaster, but he might pick that day to consider something besides ASP2. Sigh... Cragen

Re:Security is a problem

[Almahtar]

I think that really depends on the size of your code and the flexibility of the language syntax though, wouldn't it?

Large programs are hard enough for most programmers to comprehend even when written with descriptive variable names. I don't know how much of this is possible in JavaScript, but if you replaced all the strings with ASCII character codes(possible?), replaced semicolons with commas (??), that'd make some stuff pretty darn hard to read, and it'd probably fool an indenter. At very least though an intelligent obfuscater can inject multiple intermediate variables that go through strange arithmetic for a statement like "i = i + 1", change the variable "numberOfKittens" to "akr1189Rnej_orp14n2jjjf__", and the function name "translateToTurkish()" to "k()". It could replace hardcoded numeric values with lengthy boolean computations that produce the same result, and replace a single function call to multiple calls through functions that contain strange if() and else statements that it knows won't get executed and meaningless computations that will.

Sure, some of this stuff is very reasonably reversible (someone could pretty easily script something to compute all those weird equations that can be reduced to constant values), but the reverse obfuscation is likely to be a more buggy process than the obfuscation, and that'd make it error-prone and unreliable.

One irreversible loss of information would be the variable and function names, though. No amount of intelligence in anti-obfuscation could really determine the roles of the symbols except in a few really simple cases.

I'm not trying to say you're wrong, I'm just saying obfuscation can be more formidable than you made it sound if you include logic obfuscation. The obfuscater knows what the code is supposed to do, but anyone (or anything) trying to reverse-obfuscate it has to try and read a very deranged mind.

Re:Security is a problem

[chudnall]

You're welcome to all the thousands of lines of JS code our company produces, where would you like me to mail it to? darlmcbryde@sco.com

Re:Security is a problem

[hereticia]

You should see what can be done with a good js obfuscator, like the one made by stunnix. We do some similar things to our js code where I work, and I can honestly say that if we lost our un-obfuscated code, I would find it easier to rewrite it than to try to translate it back from the obfuscated version.

Re:Security is a problem

[vadim_t]

All of which is still ultimately futile.

Yes, for you it's easier to rewrite it, because you know what it was. For the attacker the only option is to break it. Which is doable enough, with indenters, name replacement and venkman. They don't need to decode all of it either, just the interesting parts. And functions can be used as a black box.

If somebody determined enough wants to do it, they will. The MS Word format was reverse engineered with no documentation. So was NTFS, SMB and many other things. Consoles were reverse engineered as well. It only takes skill and determination, and there are plenty programmers out there.

I love the autopointerage & hate the scope iss

[cyclomedia]

Would be nice to have everything my way, the sheer built in extensibility of the language is in my opinion nothing short of beautiful, and something other languages could do well to imitate (check out D, for example).

allow me to elaborate, suppose you want to know if the version of the language on your platform supports an intrinsic array push function, and if not, attatch your own:

if( !Array.push )
  Array.prototype.push = function( item ){ ... }

firstly the reference to .push in the if has no brackets, so it becomes a pointer to the function within the intrinsic Array class. you can then create a function and assign it to that pointer. Sheer magic and gorgeously intuitive.

sticking with arrays you can grow and shrink them with little to zero fuss:

function array_push( arr , item )
  arr[arr.length] = item;

magically the array is one index longer. you can just set arr.length and it will append or delete indexes for you.

you can also use this to assign functions to other object's handlers, most notibly events

someObject.onclick = myFunction

But this has brought up the thing that really really needs fixing, suppose i want that onclick function to pass some info to myFunction when i call it i have to do this

someObject.onclick = function(){ myFunction( this.someAttribute ) }

so instead i've created a function inline to hold my custom function, firstly it's not immediatley obvious to what object the "this" applies. if i'm running this code in a class does the this mean the class or someObject, one hopes it means the someObject.

next is the scope issue i've talked about suppose i'm dynamically creating objects on the fly and want the callback to reflect the id thus

for( i=0 ; i<10 ; i++ )
{
  someObject[i] = new SomeObject();
  someObject[i].onclick = function(){ myFunction( i ) }
}

every single object will pass the value of 10 to myFunction, because after the function has finished the instance of i in memory that was used is still sat there and every myFunction has been given a pointer to it, not the value it was when it was initialised!

so some oversights still exist, if only there were ways you could explicitly state "pointer to" or "value of" like in, oh, every other language including visual basic

LCD

[ComaVN]

the most broadly available scripting language for Web development

The expression you're looking for is Lowest Common Denominator

What a piece of shit that language is.

Re:LCD

[zoftie]

I do agree, it is for small hacks, and it hasn't improved too muvch on fundamentals since 2002 when i have used it. You can get alot of funding for ajax related stuff, but that doesn't mean that it is useful for masses at its foundation. Diversity of browser behaviours will make sure of that. And it isn't about languages too, for the other half, but about behaviours, inconsistent and broken alot of times. You really have to do a balancing act. See how trivial application of google maps, doesn't work the same on all browsers. Until there is a rigid standard about ECMA script, akin to Java ones, one can't talk about proper interoperability and usefulness of such language.

Many projects incorporate python as a scripting language of choice.

Why do I think replacement of Java/ECMA script with python is good in terms of browser language? Because it is fast. It mandates proper and consistent tabulation. It eradicates puctuation in many, and un-necessary cases. It is also very very fast, if precomplied codes are used. Also I takes alot of C/Java programmer design, without making you feel like a downgraded programmer, who is allowed to use a knife only with safety blade that can't cut skin or meat. As well it has very clear way to lay out code in clear ideas. Proto-currying is built in, which is useful and full real currying in 2.5 is very usable with libraries. Sort of functional onto generic procedural programming.

Yes I am one of those python people.
2c

Re:LCD

[giuntag]

As far as I'm concerned, PHP would also be a good contender for "ideal scripting language in the browser".

Advantages over js:
- using the same lang both server and client side is easier on the coder (applies to python too, and might apply to js, if it ever becomes widespread server side)
- huge set of functions in the interpreter core: I really miss a lot of them when coding in javascript
- the object model, albeit more restrictive than the prototype based model, makes a lot more sense to people used to C++, java, php et al

Re:LCD

[Anonymous Coward]

Flamebait, perhaps, but troll? hardly.

Look at this and tell me javascript is not an ugly language

WTF is that about.

Re:LCD

[afd8856]

The huge set of functions is only needed because of the craziness of the whole language.

Learn python, you'll see the difference between a "huge set of functions" and rich builtin objects and extensions modules.

Re:LCD

[ajs318]

I've done something similar myself, in a corporate intranet environment. It was Perl both ends, not PHP, but it'd work with PHP. It relied on installing some scripts on the client workstations, but you can certainly serve up something like <form action="http://localhost/cgi-bin/stuff"> and/or mix images and iframes from the client and server with wild abandon.

But this requires a webserver (needn't be Apache, even hibachi [link is to old, PD version] will do) and your favourite interpreter on every client machine. Easy to do in the office; probably much harder to do in the big world.

Re:LCD

[arevos]

- using the same lang both server and client side is easier on the coder (applies to python too, and might apply to js, if it ever becomes widespread server side) The majority of developers (or, at the very least, a large proportion), do not use PHP. They'd receive no benefit from it, and would have the disadvantage of learning a new language.

- huge set of functions in the interpreter core: I really miss a lot of them when coding in javascript Why not just extend the existing standard library in Javascript?

- the object model, albeit more restrictive than the prototype based model, makes a lot more sense to people used to C++, java, php et al I'm not so sure. Compare:

class Foo {
  public function __construct($name) {
      $this->name = $name;
  }
  public greet() {
      return "Hello " . $name;
  }
}

To this:

Foo = Class.create()
 
Foo.prototype = {
  initialize: function(name) {
      this.name = name
  },
  greet: function() {
      return "Hello " + name
  }
}

I'm not really sure there's too much difference in practise, except, as you say, the prototype model is somewhat more flexible (and more difficult to optimize).

Re:LCD

[Anonymous Coward]

People are really bending over backwards to agree with you, ehh. If you'd used JavaScript for any length of time you'd know that it's a neat little language with lots of useful features like regular expressions, dynamic collections, closures, function objects, etc. Certainly not the piece of shit you think it is.

The language is fine, but it's got baggage

[Radium Eyes]

JavaScript/ECMAScript really is an interesting language; the way objects work takes some getting used to, but it's powerful, and definitely definitely not a toy language. It's when you bring the HTML DOM and browser inconsistencies into the equation that things start to get painful.

Re:The language is fine, but it's got baggage

[ChrisZermatt]

Take a look at qooxdoo.org - a very slick framework that irons out the DOM hassles of different browsers for us developers.

Re:The language is fine, but it's got baggage

[kestasjk]

Browser inconsistencies really are the worst thing about JavaScript. If all HTML was XHTML compliant, and there were no differences between browsers, AJAX would be so much simpler. Depending on what you're coding it can often take far less time to write it for one browser than to get it to work on the four common browsers.

Re:The language is fine, but it's got baggage

[FooAtWFU]

You remind me of comments I first saw at JavaScript: The World's Most Misunderstood Programming Language.

Despite its popularity, few know that JavaScript is a very nice dynamic object-oriented general-purpose programming language. How can this be a secret? Why is this language so misunderstood? ...

JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedural language. This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens. ...

It also has some speculation on why the language is typecast in the manner it often is, some of the design errors, bad implementations / books / standards, and the amateur JavaScript-hugging non-programmers putting shiny things together for their webpage.

Re:The language is fine, but it's got baggage

[GeckoX]

FUD, plain and simple. This is what I do for a living, and that is just pure bull crap, period.

I have one single JavaScript abstraction file, ~100 lines of code, that attaches and manipulates certain attachment points from JavaScript to the browser via prototyping etc to get the less compliant browsers to support the same code as the compliant ones.

Then I write my code. And surprise! It works on all of them. And I'm not talking one little feature here. Dynamic positioning, content creation, form manipulation, response handling etc etc etc.

It's NEVER the javascript that is the problem getting it all to work on all the big browsers. It's ALWAYS tweaking the CSS and layout to be consistent across the browsers.

JavaScript is perfect for it's designed and intended purpose. Please, learn how to use it instead of bashing it out of hand. You really don't know what you're talking about.

Re:The language is fine, but it's got baggage

[anomalous cohort]

There's a lot more to object orientation than simulating a vtable with an associative array. How can you have encapsulation without persistence or visibility modifiers?

Most of the dynamic language evangelists claim that the ability to add or modify methods at run time is a good thing. I believe this to be the part that takes getting used to. I can see the value of adding or modifying methods but feel that this should be done declaratively (e.g. Ruby or .NET 2) instead of by manipulating the associative array directly in code. I am okay with aspects and method interception even though some implementations use a dynamic approach. The developer experience is still declarative.

I agree that the DOM and browser disparities are an issue, however, those issues are mitigated by modern libraries such as prototype.

One big advantage to java scipt's associative array is an object approach is that is what allows JSON to work. JSON is a very easy way to serialize in arbitrarily complex object hierarchies into java script which is a good thing for complex AJAX apps. The down side to this approach is increased exposure to man-in-the-middle attacks that can run arbitrary code client side.

JavaScript is wonderful

[Anonymous Coward]

JavaScript is an absolutely great language marred by the fact that people can't distinguish a language from its library. When most people say "JavaScript sucks!" they are really saying "DHTML/the DOM object model/HTML/CSS sucks!".

What I don't get is why developers use PHP, which looks like it was thrown up after a frat party. JavaScript would fill the bill as a decent language with a C-based syntax much better.

Re:JavaScript is wonderful

[killjoe]

To be fair you use the library as much if not more then you use the language. If I can't interact with databases, if I can't download a library that scrapes web sites, connect to SOAP services easily, authenticate against a LDAP server then no matter how beautiful the language is I can't use it.

One lesson ruby learned early was that you don't get anywhere till you build your own version of CPAN (still the king!). Build your library, build a way to install, uninstall and upgrade your libraries smoothly and your language will take off.

In conclusion. It's the library stupid.

Re:JavaScript is wonderful

[rjshields]

Exactly. There's little wrong with Javascript that wouldn't be fixed by adding a decent library, since the only things you get string and array classes and a few other bits and bobs. You would need at least a decent I/O library, namespaces and the ability to include other code files.

Re:JavaScript is wonderful

[Anonymous Coward]

When most people say that, it's because they don't really know the language and they are frustrated with trying to stitch together snippets of js that they copied from some "free scripts" site.

Re:JavaScript is wonderful

[illuminatedwax]

The reason people use PHP is because it has good documentation, unlike Javascript. It also has a single, uniform implementation that is much saner than any current Javascript implementation nowadays (as sad as that is).

Re:JavaScript is wonderful

[filet0fish]

The point is that the javascript language and syntax can be used with other languages very well. Once example of this is JSFL, the implementation of Javascript to script the flash authoring environment. Same syntax as the familiar browser javascript, just built for automating flash authoring instead of controlling the browser.

Javascript was built as a way for developers to be able to control the user's browser. That inherently makes javascript on a webpage platform dependent on the browser. That's bad for web standards and developer sanity, but it's not because of a flaw in the language.

So to answer the question in the title, yes, it should get more respect. I think the respect will come in time once more applications start using javascript for non-web usage instead of proprietary languages.

Re:JavaScript is wonderful

[Achoi77]

What Wikipedia says on javascript. Here's an excerpt that may interest some:

The standardization effort for JavaScript also needed to avoid trademark issues, so the ECMA 262 standard calls the language ECMAScript, three editions of which have been published since the work started in November 1996. The object model of browser-based JavaScript, the Document Object Model (DOM), is not part of the ECMAScript standard. It is defined in a set of separate standards developed by the W3C, and is applicable to the access and manipulation of HTML and XML documents in many computer languages and platforms.

if you look up ECMA, you will see a lot of browsers listed supporting the ECMA262 standard.

Here is a pdf on the ECMA262 spec. Warning: it's a big long winded, but it's pretty detailed. Good spec.

Re:JavaScript is wonderful

[Smallest]

i've used server-side JScript on nearly every web project i've been on. it's one of the nicer capabilities of IIS, from a developer's perspective.

Re:JavaScript is wonderful

[Anonymous Coward]

dojotoolkit.org has all that and so much more.

Re:JavaScript is wonderful

[leptons]

I use JScript on the server-side too, and it is also very easy to compile .net EXE and DLLs written in JScript. Application programming in JScript is not a bad idea, though some people claim it is. I'm still wishing Microsoft would support JScript more in Visual Studio 2005, but I'm still learing that environment - i still prefer to hand-code everything. Using JavaScript for both front-end and back-end code has been a real boost to my productivity, since I don't need to have two or more languages involved in a solution, I can spend all my time mastering JavaScript and my development cycles get shorter and shorter because of it.

Re:JavaScript is wonderful

[rjshields]

What I don't get is why developers use PHP, which looks like it was thrown up after a frat party. JavaScript would fill the bill as a decent language with a C-based syntax much better.

I agree with you whole heartedly, but teh only half decent server side JavaScript implementation that doesn't involve Microsoft .Net is their legacy ASP with JScript. If we were to create a JavaScript module for Apache, it would probably be very popular. However, limitations in the JavaScript language and lack of a standard library prevent this from happening currently.

Re:JavaScript is wonderful

[illuminatedwax]

Exactly. A long-winded technical spec and poor documentation of the DOM and built-in functions of browsers. That is why people hate Javascript. If Javascript had the documentation that PHP had and the focus behind it that Zend puts behind PHP, then Javascript would be popular. A programming language is just like any other piece of software: its inherent quality has very little to do with its popularity.

Re:JavaScript is wonderful

[Achoi77]

DOM has nothing to do with javascript itself, other than the fact that a lot of browsers have their own implementation how to interface the DOM via. If there is anybody to blame on the poor DOM documentation, you should be pointing fingers at the browsers' lack of standardization. Coupled with the fact that different browsers have different levels of support for different version of the DOM, that becomes a headache.

For the actual javascript implementation across all browsers itself, you cannot deny that it's pretty solid across the board. How the different browsers decide to interface the DOM with it - aside from that level of support for the dom itself, that's been largely ignored up untill even a year ago. As we see more widespread support for it and start seeing bigger and badder web-based apps for it is when js will start getting some real popularity.

Like Visual Basic ...

[Anonymous Coward]

... it's not because you have to use it, that it makes it a good language.

Only reason people are using it, is because it's the only thing that let you manipulate a web page and will work more or less for 99% of the people out on the internet. Would all browsers ship with only COBOL people would be using it. Would I have the coice between JS and let's say Python or Ruby, I wouldn't even have a look at it.

Re:Like Visual Basic ...

[vtcodger]

***Only reason people are using it, is because it's the only thing that let you manipulate a web page and will work more or less for 99% of the people out on the internet.***

Nothing against Javascript, but I think that's a very large misestimate of the number of people who have Javascript turned off in their browser. A lot of folks -- me included -- think that allowing websites to download and run programs on their PC is roughtly equivalent to putting up a sign in the front yard that says "Out of town until the 27th. Valubles mostly in the master bedroom. Please use the side door, clean up the broken glass, and wipe your feet ... thanks." Many of those folks are system administrators who control the settings on a lot of machines

Yes, I'll turn on Javascript to work with a useful site that I trust and believe actually like NEEDS Javascript, like Google Maps. But in general, if you ship me Javascript, it won't get run. If it's needed to make your site work, I'll go find a competitor whose web folks have more common sense ... and I won't be back.

Yes I know that Javascrip-t runs in a sandbox and can't be used to attack my PC. Just like I know that all politicians and software mongers are dead honest and have only my best interest at heart. Google gave me 862,000 hits on a search for 'javascript vulnerabilities'. Eight of the first ten hits look to be real problems. Clearly, there aren't 800,000 known vulnerabilities in Javascript, but I sure wouldn't bet on there not being hundreds and on some of them being serious and unpatched.

What interpreters are available?

[Myen]

Sadly, when Javascript gets mentioned most people think of browser scripting. That's like thinking of MFC every time C++ gets mentioned... :(

What sorts of shells interpret JS? I know of Mozilla's js shell, and they also have a xpcshell (which adds XPCOM things to make it fully Mozilla-y). Sadly js shell has no built-in file access (it's a compile-time option you have to jump through hoops to enable, and buggy), and xpcshell has lots of XPCOM baggage.

Are there any others using different engines? Anything from Adobe (ActionScript) maybe?

Re:What interpreters are available?

[bensch128]

There's also M$ jscript inside IIS.
On a project awhile ago, I had the choice of working with VBscript or JScript.
Of course I went with JScript and was Incrediably happy that I had done so. There's some weird problems in IIS's implementation but in comparsion to VBScript, it was heavenly....

Additionality, it allowed me to share cope between the backend (in JScript) and the flash frontend (in ActionScript). Maybe a bit bizarre but it worked!

Ben

Re:What interpreters are available?

[Anonymous Coward]

check out jsdb at jsdb.or. it has database access and XML.

Re:What interpreters are available?

[hughperkins]

Windows Scripting Host provides a javascript engine.

Re:What interpreters are available?

[madsdyd]

Wikipedia to the rescue: http://en.wikipedia.org/wiki/List_of_JavaScript_en gines

kjscmd is a shell with a nice KDE/Qt integration, actually.

http://www.sourcextreme.com/presentations/KJSEmbed /building_applications.html

Re:What interpreters are available?

[Anonymous Coward]

DigitalMars has an implementation that's available for download in D and C++ flavors.

http://www.digitalmars.com/dscript/index.html

It is licence-encumbered for commercial purposes, but otherwise, it's pretty good for general hacking.

Re:What interpreters are available?

[mhall119]

Mozilla also provides the Rhino Javascript engine for integration into Java apps. Adobe has donated their Actionscript virtual machine to Mozilla, so it will be getting better soon.

Re:What interpreters are available?

[HeroreV]

I created an HTML page that is basically 3 text boxes: script, text in, and text out. There are many times where I want to quickly code up a little something for whatever reason, and JavaScript is a great quick-and-dirty language. Over the last couple of years I've written hundreds of simple throwaway scripts. It's really valuable when you want to reformat a big blob of text, such as changing every line from

* item

to

<li>item</li>

It counts for at least 90% of all my regular expression usage.

Javascript is nice... the problem is...

[vhogemann]

The inconsistence between the two major implementations, Mozilla and IE. And the huge amount of annoying bugs that IE has.

I don't hate JS, its a rather nice language, but I tend to keep minimal use of it on my applications because I really hate to lost one entire day fighting against IE.

Re:Javascript is nice... the problem is...

[Carewolf]

And the amount of annoying bugs Firefox has.

Re:Javascript is nice... the problem is...

[GeckoX]

Do you mean JavaScript, or do you mean the differences between IE and Mozilla...particularly with respect to DOM, css etc etc?

Or do you know where JavaScript ends and the browser starts?

This is a very important distinction that just about NO one around here bothers to acknowledge.

Let me put it to you this way: If I write a lovely little piece of code in C++ on windows, it does some nice file manipulation things, very handy. And now I try to run it on Linux...Oh, wait...better compile it for Linux first...oh wait, that lib I was using doesn't exist for Linux...

Is it C++ that is the problem? Um, no, not hardly.

Starting to see the problem here? I really do hope so.

Re:Javascript is nice... the problem is...

[drew]

Thanks. Glad to see I;m not the only one who gets this. JavaScript really is a great language. It's too bad that when most people think of JavaScript, they can't get past the DOM incompatibilities, which have very little to do with JavaScript... and also, BTW, aren't even that bad any more. With a small handful of simple wrappers (mostly to account for attachEvent vs. addEventListener, and the different ways of instantiating an xmlHttpRequest) the differences between the IE, Gecko, and other browser DOMs are almost unnoticeable. IMO, the only serious compatibility problem in modern web development is IE's awful CSS support (and lack of any way to perform event capturing in IE, but I've mostly accepted that I just have to be willing to live without it.) which has pretty much nothing at all to do with JavaScript.

Re:Javascript is nice... the problem is...

[GeckoX]

Man is it nice to hear from someone else that actually gets it. Keep up the good work :)

Re:Javascript is nice... the problem is...

[fredrik70]

check out the JS framworks out there, they take care of the browser stuff for you, use MochiKit if yuou like python, otherwise check out Dojo or YUI (Yahoo's JS framework)

return false;

[davygrvy]

can you say DOM compliant?

Re:I love the autopointerage & hate the scope

[rucs_hack]

You may well be right, but

"It's multiparadigm: supporting imperative, object oriented, and template metaprogramming styles"

Is just too geeky for me before my second cup of coffee.

Too Hard to unit test

[Anonymous Coward]

javascript is too hard to unittest but most of that has to do with the web browser container . javascript is a victim of its environment.

Re:Too Hard to unit test

[Zardoz44]

How so?

25000 lines:

[hummassa]

Any serious Ajax application.

Re:25000 lines:

[captain random]

Arg! Twice in 1 week. Sorry. I really wish there was some sort of confirmation for moderation.

Re:25000 lines:

[jmrives]

Not necessarily. With good use of JSON and reliance on well written third party Javascript libraries, it is possible to write serious AJAX and dynamic HTML applications with far less lines of code.

Re:25000 lines:

[rjshields]

Any serious Ajax application.

Surely that is an oxymoron ;)

Re:25000 lines:

[Loki_1929]

Ajax - n. A regifted, decade-old technology reproducing functionality available in the mid-90s that a new generation of clueless MBAs can use to impress clueless clients with MBAs.

Me too

[Jens de Smit]

I am one of those people that cursed JavaScript (after being enthusiastic about it when I was 14). I am just now beginning to turn around and think "well, it IS pretty nice". One of the things that has changed is that it does not "[mutate] faster than a fruit fly in an X-ray machine" (bonus points if you know who wrote this) anymore, with support becoming more standard over different interpreters, and incompatibilities becoming better documented and workaround libraries that unify the differences all over the place. Debuggers also become more widely available, helping the people when they exclaim "WHY the HECK doesn't it work this time!". It's still easy to shoot yourself in the foot with it, but hey, the same goes for C. At least it generally does not blow your leg up like C++. This behaviour is caused by the extreme felxibility of the language, which also allows for interesting constructions, as long as you're careful as a programmer. In other words: you have to know what you're doing to keep the code organized and understanable, something that is lacking with most starting web developers. Still, the availability and functionalty of JavaScript allows rich, interactive web applications to be developed, which is a good thing if you ask me.

Re:Me too

[julesh]

if (!document.getElementById) { alert("You can't shoot yourself in the foot without the DOM. Try shooting yourself in the head instead."); return; }
var foot=document.getElementById("foot");
var gun=document.getElementById("gun");
gun.onload = function() { gun.shoot(foot); }

Re:I love the autopointerage & hate the scope

[Shano]

That isn't really an oversight, it's the way closures work. Most functional languages let you create closures explicitly so the problem doesn't arise. Javascript does it automatically, and usually when you don't expect it. In Javascript, you can do:

someObject[i].onClick = function(i) { return function() { myFunction(i) } } (i);

That creates a closure for each handler, with its own copy of i, so they will all get the values you want. I have no doubt there are other ways to do it, but this works for me.

Re:I love the autopointerage & hate the scope

[Anonymous Coward]

Parent wrote:

for( i=0 ; i<10 ; i++ )
{
  someObject[i] = new SomeObject();
  someObject[i].onclick = function(){ myFunction( i ) }
}

every single object will pass the value of 10 to myFunction

Well if you don't like that, then just make a function that its arguments by lexical closure:

make_function = function (n) function() { myFunction( n ) };
for( i=0 ; i<10 ; i++ )
{
  someObject[i] = new SomeObject();
  someObject[i].onclick = make_function (i);
}

XSS Attacks

[Anonymous Coward]

JavaScript should get more respect, XSS-holes are one of the most prevalent and useful attacks against websites there are.

Overlord

[Dude163299]

I for one Hate our new Javascript writing overlords.

And for the record im suppose to be writing various Javascript programs at this moment.

JS is not the problem, the whole environment is.

[master_p]

Javascript is a fine language with elements from functional and object-oriented programming. The problem with web development is the whole environment:

1) the coupling of the UI with the code that actually does stuff.
2) the non-efficient and error-prone methods of communication between client and server.
3) the non-existent security regarding JS code; anyone can see it.
4) the mixing of a tagged document language with a programming language.

Ideally, web applications should only consist of source code in one language which is clever enough to be able to provide all the necessary abstractions. In reality, such a language does not yet exist, making web applications development 10 times more difficult than what they should be: the minimum number of languages to use for a web app is 5: 1) html, 2) css, 3) javascript, 4) java/php/ruby/python/perl/whatever, 5) XML...and let's not count the various XML schemas required for various domains of the back end, because the number of 'languages' one needs to know will grow exponentially!

Dear god no.

[el_womble]

My wish for web 3.0 is that Javascript is replaced entirely. The ONLY thing that Javascript has going for it is ubiquity (which I guess is down to its ease of implementation). Its not all Javascripts fault, in general, as in most things webby I blame Microsoft, but hte language itself seems to make everything you write look lke a dogs dinner.

Wouldn't the web be a nicer place if you could script the browser using Ruby or Python? Can you imagine the fun you could have working with constructs like:

@page.findById( "myID" ).each do |ajaxReturn| ... end

The web could be beautiful. Next on my hit list is an improved HTML / CSS. Should rounding corners, or drawing shapes / shadows really be done with gif/pngs?

Re:Dear god no.

[Crayon Kid]

I don't see why you'd want JavaScript replaced by Python or Ruby. As a programming language, it is more powerful than both. By powerful I mean simplicity and power of the language itself, not comparing sets of features.

For proof, [re]read Revenge of the Nerds. Search for "Appendix: Power" on the page, look at the problem. Try doing that in Python, Ruby, PHP, Java, C of any kind.

Re:Dear god no.

[el_womble]

Ruby: def foo n Proc.new {|i| n += i } end or with the lambda synonym def foo n lambda {|i| n += i } end Looks pretty neat to me.

Re:Dear god no.

[greyc]

Python:
class foo:
      def __init__(self, n):
              self.n = n
      def __call__(self, i):
              self.n =+ i
              return i

That's too long/complicated for you?

Re:Dear god no.

[greyc]

Blargh. I should take a bit more time to think before posting. What I meant was:

class foo:
      def __init__(self, n):
              self.n = n
      def __call__(self, i):
              self.n += i
              return self.n

Re:Dear god no.

[onosendai]

You've not met RJS then I assume

page.insert_html :bottom, 'list', content_tag("li", "Fox")
page.visual_effect :highlight, 'list', :duration => 3
page.replace_html 'header', 'RJS Template Test Complete!'

Re:Dear god no.

[el_womble]

You just made me fall in love with Rails all over again.

Re:Dear god no.

[arevos]

Wouldn't the web be a nicer place if you could script the browser using Ruby or Python? Can you imagine the fun you could have working with constructs like:

@page.findById( "myID" ).each do |ajaxReturn| ... end You underestimate how flexible Javascript is. Whilst not as concise as Ruby, it has similar capabilities when backed up with a library like prototype. For instance, take the following Ruby code fragment:

a = (1..10).select { |x| x % 2 == 0 }.collect { |x| x * x }

And the equivalent Javascript:

a = $R(1, 10, false).select(function (x) { return x % 2 == 0 }).collect(function(x) { return x * x })

Not really that different, is it? Ruby has some syntactic sugar to make things more concise, but the two statements are extremely similar. Javascript is far more powerful than most people think.

Re:Dear god no.

[arevos]

For proof, [re]read Revenge of the Nerds. Search for "Appendix: Power" on the page, look at the problem. Try doing that in Python, Ruby, PHP, Java, C of any kind. Okay. In Javascript:

function foo(n) { return function (i) { return n += i } }

In Ruby:

def foo(n) lambda { |i| n += i } end

I'm not sure how that qualifies as proof Javascript is superior. If anything, it's somewhat more verbose.

Re:Dear god no.

[Chris Rathman]

If we are talking about embeddable scripting languages and Lisp is the point of comparison, I'd prefer Lua over JavaScript, Python and Ruby. Of these four languages, only Lua has tail-call-optimization (though JavaScript 2.0 is slated to have TCO). For a direct comparison to Lisp, I've translated the first chapter of SICP in these scripting languages (as well as some other FP languages): SICP in other PLs

Thanks,
Chris

Re:Dear god no.

[trimbo]

For both points, I think you're looking for what XAML offers. C# as the scripting language, rounded corners / shapes with real primitives. XAML intro

BTW, Javascript only recently became this "beloved" language when Google started using it. People did not take it seriously before then, it was mostly a language just to embed another applet or provide a little bit of verification. Certainly people weren't writing 25,000 lines of Javascript code before this. As others have said, the only thing JS has going for it is ubiquity. It will be ditched at the earliest convenient time, making it the COBOL of this generation.

Re:Dear god no.

[arevos]

As others have said, the only thing JS has going for it is ubiquity.

And it's flexibility. Most people, yourself included I suspect, don't realise just how flexible and extensible the Javascript syntax actually is. It's also one of the few languages that bases an object system around prototyping, which is interesting in itself.

Re:Dear god no.

[Anonymous Coward]

With prototype.js it works pretty much the way you describe:

$('myID').childNodes.each(ajaxReturn);

(I assume you meant that the each should iterate over child nodes, since findByID can only return at most one item right?)

Re:Dear god no.

[franl]

For both points, I think you're looking for what XAML offers. C# as the scripting language, rounded corners / shapes with real primitives. XAML intro

The page your link points to says this about XAML:

XAML is a new descriptive programming language developed by Microsoft. The purpose of XAML to build user interfaces for next-generation Windows operating system.

XAML is proprietary MS technology (and Windows-specific to boot). I'm not blindly bashing MS here, but we want Web standards, and MS hardly has a good track record for innovating those. If the W3C or ECMA were to back XAML as an open standard, then fine, but that hasn't happened (AFAIK). And despite Mono's ability to make C# available on multiple OSes, C# effectively suffers from the same reputation as XAML. Yes, C# an ECMA standard, but I don't see the W3C getting behind C# in the near future.

Re:Dear god no.

[trimbo]

Microsoft is pushing on having at least some of this work cross platform (horribly flawed at the moment, but it is a start): WPF/E

I agree it's a problem that it is proprietary, but there's no reason an open source effort can't take the ideas behind it and run with it. Mono is a pretty darn good CLR/C# implementation for Linux. It doesn't cover the entire .NET Framework, but the language features are there. IronPython runs on it, etc. Many OSS people can't comprehend the idea of taking Microsoft's APIs and running with them, but it seems like taking XAML to the next level on OSS would be a worthwhile effort.

Daft story title...

[Aphrika]

Respect is earned, not given. As far as I'm concerned, AJAX has given JavaScript a new lease of life. Without it, there would be no Gmail, no Google Maps, or at least not in the way we've come to admire them. When you see the fantastic stuff Google (and Windows Live for that matter) produce, XMLHTTP was the catalyst that made that possible, but all the donkey work is done by JavaScript.

Thus I have a lot of respect for it as a client scripting language, in most cases it's the only way of getting something done in a browser.

Re:Daft story title...

[smurfsurf]

"Respect is earned, not given." So if you do not know someone, you have no respect for him initially? How about you start with respect, which can be lost through bad action?

Re:Dense != Good ==Wrong: It's not dense

[Gavin86]

Javascript is anything but dense. The most impressive part about the various flexible agents is that they are easily understandable programming patterns. That makes it very easy to make an assessment for which methodology you will employ.

simple (and obvious) question:

[wzzzzrd]

yes

Is this a dupe from a few months ago?

[aussie_a]

It looks awfully familiar to me.

Javascript might have a future, but..

[tacocat]

Look at the history of Javascript. It's not the history of a programming language. It's the history of a marketing battleground.

Programming Languages have a few key elements that Javascript lacks. For one, everyone who writes Perl, Ruby, Java, Python, even Bash expect it to have consistent behaviour where ever it might be. And for that behaviour to be well documented, reliable, and owned by the language itself.

Javascript has an evil dependency to run based on the Operating System and Browser that you are using. Mozilla on Windows works differently than Mozilla on Linux. Mozilla on anything works different than Opera or MSIE. MSIE6 works differently than MSie7. And some of these differences in javascript behaviour isn't really javascript. It's javascript trying to do CSS/DHTML stuff.

If you were to have something similar under a real programming language there would be an active development team working to resolve the differences and get consistency in the language. The finest example of this is the Java JVM. It tries to be write once run anywhere. I don't know that it actually accomplishes that -- but it's closer than javascript.

javascript has no such activities. I don't do much with Javascript but when you pull a 10 year old book off the shelf you find 1/2 of it is talking about MSIE vs Netscape in how to work around code differences. Then you get a new Javascript book and it's still talking about many of the same problems a decade later. That's a dead language lacking any real development.

AJAX is cute because Microsoft went ahead and implimented something on their own and didn't bother telling anyone about it. I'll assume that Mozilla implimented the exact same thing but under a different name because they were afraid of getting sued. Why they did it doesn't matter. The fact that they implimented the exact same thing under a different name is why Javascript must fail. It's not a real language. You won't find a language the does the exact same thing in two different commands and those two different commands only work on distinctly different machines.

If someone takes Javascript away from the companies and starts to impliment there own version of it there's no chance. Javascript needs a replacement.

Re:Javascript might have a future, but..

[Jens de Smit]

You are seriously confusing "language" with "library". One main problem with JavaScript as a programming environment is indeed that library support for it differs hugely among environments, with good examples indeed being the XMLHTTPRequest object, implemented with roughly the same interface by two completely different browsers, but accesible in different ways (because of the difference in library). What Sun does with Java is delivering the JRE (Java Runtime Environment), of which in important part is of course the JVM, which translates bytecode instructions into operating system and platform specific instructions. However, another very important aspect of the JRE is the Java API, which is also (almost) universally consistent amongst the different JRE's. That is what makes Java "compile once, run anywhere". Also, this is not entirely true. Many cell phones and other mobile devices nowadays are equipped with a JVM, but not with a full J2SE API. Therefore, a lot of those "compile once, run anywhere" Java programs will do nothing but generate errors on such a device.

Re:Javascript might have a future, but..

[Anonymous Coward]

You're missing the point. None of your complaints have squat to do with the javascript language. They're all focused on the environment that it runs in.

You do, sort of, make a good point about about marketing though -- the reasons that so many people have completely misunderstood JS for so long are:

1) It came out at the height of the 1st browser war when everyone was focused on trying to differentiate via browser capabilities.

2) The DOM and CSS were brand new and had not yet been grokked. One could argue that they still aren't well understood. Especially by those who insist that JavaScript is a toy.

3) To work around the above problems the idea of "browser detects" was widely promoted and a whole lot of very bad code got created by people who didn't know any better and weren't being taught differently.

4) None the less the vision of DHTML continued to appeal. But the whole round trip thing made life miserable and kept the scope of client side programming pretty limited.

Then Microsoft decided to create Outlook On The Web. Naturally they wanted to make it IE-only so they came up with the XMLHttpRequest ActiveX. It took people a while to catch on but this eliminated the round trip problem and fueled a very significant expansion of client side code size and capabilities.

Mozilla, Opera et al realized that XMLHttpRequest was significant but also knew that ActiveX was evil and unnecessary for this task. So they added it to their browsers.

People finally realized that browser detects are the wrong approach and that "feature detects" are superior. Eyes started to open that JS is, actually, a surprisingly powerful language that happens to have the misfortune of being known for being embedded in the world's worst environment.

Key point for Evil Overlord Resistance Fighters -- Microsoft has made two serious errors in their quest for world domination 1) putting JS in IE. 2) introducing XMLHttpRequest. These two errors make DHTML a serious contender and have enabled the whole Web 2.0 thing. Without them Microsoft's desktop productivity lock-in would be safe for another 20 years. With them? It may just be a tiny exhaust shaft of opportunity but it's something...

Re:Javascript might have a future, but..

[julesh]

You won't find a language the does the exact same thing in two different commands and those two different commands only work on distinctly different machines.

When I write C code to open a named pipe, if I'm going to run the program on windows, I write CreateNamedPipe("name", [some other stuff I can't remember]) but on linux I write mknod("name", S_FIFO|S_IRUSER|S_IWUSER, 0). It does the same thing, at least as similarly as new ActiveXObject("Microsoft.XMLHTTP") and new XMLHttpRequest do.

Re:Javascript might have a future, but..

[GeckoX]

You don't know what you are talking about. JavaScript itself is VERY consistent across implementations.

You even said it yourself, it's where JavaScript attaches to the browser that inconsistencies arise...ahh, but this is the fault of JavaScript apparently. How so?

Learn how to use the tools at hand. JavaScript is actually very simple to write compliant, consistent and reliable code that just works on all the major browsers, WITHOUT code forks. That is a fact, period. This is what I do for a living.

Man, the number of people that have been modded up for slamming FUD about JavaScript around is mind boggling...and invariably what I'm seeing rather is blatant statements of lack of knowledge and incompetence.

If you smash your thumb with a hammer, does that mean the hammer is flawed? No, it doesn't.

Please, learn the tools of your trade, or kindly shut up about it. You're not helping anyone here.

Re:Javascript might have a future, but..

[tacocat]

I was afraid someone would find an exception like this.

I guess we just have to stop using Windows in both cases (C and Javascript)!

Re:I love the autopointerage & hate the scope

[Anonymous Brave Guy]

While I agree that some of the concepts you mention could be useful, I don't see that Javascript's implementations are particularly powerful or elegant.

It's hard to comment on the function-attaching example you gave, since obviously any real implementation of most languages already has functions such as those you describe. In general, however, I've found these dynamic features to be overhyped, and usually no substitute for having a decent design in the first place. I don't miss them in languages where they aren't there.

As for the scoping and closure stuff, IMHO having first class functions in a language is a big plus. Javascript's version always seems a bit like Functional Programming Lite, though: in real functional programming languages, the rules on scoping and such tend to be absolutely clear, and the syntax clean and powerful. So-called scripting languages tend to try but fail on this count here; Javascript is certainly not alone in the field.

easy in Ruby

[ComaVN]

def foo(n)
    n.method('+')
end

You were saying?

Re:easy in Ruby

[rycamor]

forgive my Ruby newbiage, but exactly how would you call this function? In the Javascript and Python versions you can do foo(4)(4) which returns 8, but when I try that in the Ruby code above, I get

SyntaxError: compile error
(irb):20: parse error, unexpected '(', expecting $
foo(4)(4)
      ^

Re:easy in Ruby

[ComaVN]

foo(4).call(4)

Re:JS is not the problem, the whole environment is

[AlXtreme]

3) the non-existent security regarding JS code; anyone can see it.

Repeat after me: Obscurity is not the same as Security

If you are sending information to the browser that you don't want to be known, then you're doing something wrong. This is the case for JS, as well as for AJAX, Flash or Java applets. Or client-side code in general.

Seriously, I've seen students faces turn white when I mention that I could log into and mess up their remote SQL database, thanks to them putting their (administrator!) username/password combinations in client-side Java bytecode. They would then try to obscure their passwords somehow, which leads to an arms-race with other teams trying to break in. Security can be loads of fun!

JavaScript is #1

[Anonymous Coward]

I've been a web developer since summer 1998 and not once have I ever thought JavaScript was a "necessary evil", I have in fact said many times that JavaScript is God's gift for web developers. It's my fav language and I have used it to create many unique web experiances.

Re:JS is not the problem, the whole environment is

[Mopatop]

Wrong, you do not need to know XML. I write "AJAX" applications at work all the time and haven't used XML for months. Look up JSON and make your life better.

Remember that with XMLHTTPRequest you are restricted to your own domain, so more often than not you are in charge of the message encapsulation language. You only have to make it as complicated as you want to.

On a slightly weaker note, some people are lucky enough to drop CSS from that list as well. Frequently I work with a designer who takes care of all the CSS for me - all I deal in is IDs and classes.

Server-side JavaScript

[sveinb]

I've been using PHP and Perl server-side and, reluctantly, JavaScript client-side for years before I actually bothered learning JavaScript. When I finally did, I discovered a language which was similar to PHP and Perl in that it supported most, if not all of their language constructs and which in many ways was more elegant (IMHO). So my dream was to use JavaScript both server- and clientside. That can be done in .net/mono, I guess, but I prefer the lightweight nature of PHP, Perl, Python etc. So I started http://www.sf.net/projects/jsext - check it out! The plan is to support C libraries (done on Linux, Windows version under construction) and Python modules (not done). There are other, similar projects, too: http://en.wikipedia.org/wiki/Server-side_JavaScrip t

Re:Server-side JavaScript

[Tarwn]

Javascript can also be used as the scripting language for class ASP pages. has been a choice since before .Net made it onto the scene.

Re:Server-side JavaScript

[drew]

Actually, JScript has been pretty much abandoned as a supported language in ASP.NET. I work for a company that uses ASP / JScript as the server side platform, and while we've been looking at .NET for a long time, one of the things that has caused us to put off the transition for a very long time is that the lack of JScript as a (usable) language in ASP.NET will require us to completely retrain almost all of our current web developers. For a while we were looking into PHP as an upgrade path because it was more similar to ASP, and because a lot of developers here (myself included) have previous PHP experience. Fortunately (IMO, at least) that plan got shot down because we could never get PHP on IIS stable enough to consider it a valid option.

Re:Server-side JavaScript

[Zepalesque]

If you can stand to build on the MS platform, classic ASP pages can be tooled to use server-side JScript instead of vbscript. The difference between these two scripting languages is vast - Javascript is soooo much more capable.

In the past, to reduce the number of languages team members had to learn, we chose to roll with server-side Javascript ASP pages. It improved ramp up time and gave a ton more power and flexibility to the server-side code.

Re:Server-side JavaScript

[Lord Ender]

Server-side Javascript, you say? It's so deliciously low, so horribly dirty!
</henry higgins>

Javascript gets enough respect

[bakana]

Javascript has been used to do so many things, I dare say most web developers have used it with great success to complete a wide variety of projects. But until further improvements are made to it there is no need to give it "more" respect.

Re:Javascript gets enough respect

[Anonymous Coward]

Hey, your comment reminds me of PHP. Speaking of which, as long as PHP will be called a language, why get excited about Javascript? Lesser of two evils...

Re:Javascript gets enough respect

[mencial]

PHP gets executed in the server, JavaScript gets executed in the client. Very big difference. For PHP to get input from the user, this input must travel between client and server (which means a page load unless you are using Ajax, which means JavaScript, or an specialized client). Javascript can act on input right in the client.

JavaScript is such a good idea with such a poor execution... The spec is unreadable and ambiguous. The implementations have so many quirks and incompatibilities. I wish we could just kill it and start over.

Re:Javascript gets enough respect

[Anonymous Coward]

To make a bit clearer what I meant with my previous comment:

PHP is such a good idea with sucha poor execution... The spec doesn't exist. The implementation has so many quirks and brainfarts. I wish we could just kill it and start over.

RESPECT js?

[timmarhy]

in a word, NO. JS is slow, cumbersome and i can't stand it.

Re:RESPECT js?

[arevos]

Cumbersome? In what way?

Re:RESPECT js?

[Anonymous Coward]

I agree completely. I hate javascript and keep it turned off. I avoid web sites that use it, and put the initials "js" beside their url in the bookmark.

The "js" means I may have to download 256kbytes of js code to view a 10k page. In most cases, javascript is used in places where ordinary html would work fine. So my time is wasted. That is sin.

I view javascript as a plague to be avoided.

Fortunately, the web gives enough alternative sites that don't use js. And those are the ones I go to.

Regards,

Mike Monett

Let me see...

[rbanffy]

C-like ugly syntax...
weak typing...

No. No respect.

I may use it, but respect it? Nah...

Re:Let me see...

[TerranFury]

>I may use it, but respect it? Nah...

What's her name?

Re:Let me see...

[Anonymous Coward]

C-like ugly syntax...
weak typing...

Are we talking about perl or ruby?

Re:Let me see...

[rbanffy]

I like Perl's "do or die" construct, but that's about it. I used to love the language support for rich data types and the "magic" operator, but since that time, Python conquered my heart with much of the same expressive power with a much more readable syntax. Perl programs can easily become write-only programs.

I never used Ruby much, but I intend to learn more about it. The syntax is still a little confusing for me, but maybe I can get used to it and love it. I like the Lisp-ish way it treats closures.

One must not confuse dynamic/static-typing with strong/weak-typing. While both Python, Java and C are strongly typed, Java and C are static-typed (all types are resolved on compile-time) while Python is dynamically-typed and solves type issues during runtime, but does not go out of its way to convert incompatible types. JavaScript converts incompatible types (you can add null with a string) and this tends to harbor some remarkably elusive bugs.

JavaScript prototype-based OOP is interesting, but it does not outweight its other shortcomings.

Re:I love the autopointerage & hate the scope

[cyclomedia]

i'm aware of closure and that solution but deliberatley avoided bringing it up, but wouldn't it be nicer to just:

someObject[i].onClick = &myFunction(*i)

or introduce a friendlier concept from, of all places, VB : byRef and byVal

Re:JS is not the problem, the whole environment is

[ageforce_]

such language exist and become more and more common.
Google already released their gwt (http://code.google.com/webtoolkit/) but there are also other languages like HOP (http://hop.inria.fr/) or Links (http://groups.inf.ed.ac.uk/links/)

Re:JS is not the problem, the whole environment is

[Tim C]

I used to hang out on the , and questions about encrypting Java bytecode came up with surprising regularity. The number of people who simply didn't understand that what they wanted - to make it impossible to decompile the bytecode back to Java source - was impossible was quite staggering. All sorts of plausible-sounding solutions were mooted, but they are all ultimately worthless. As long as I control the hardware, there's nothing you can do to prevent me from seeing data processed by it, all you can do is try to make it difficult.

Higher order functions? Whats the big deal?

[Viol8]

Can someone explain these to me since I'm confused. The article states:

"This example shows that I can treat a function just as I treat any other variable. C developers think of this concept as a function pointer, but JavaScript's notion of higher-order functions is much more powerful...
[snip]
Using a function as a function argument, or returning a function as a value, elevates this abstraction into the realm of higher-order functions. "

Whats so new and powerful about this? Using the C example you can easily return function pointers as arguments from functions and pass them too functions as well. So why is javascripts method so much more powerful that C's? Using a standard C compiler you could also pass to the same piece of code function pointers to functions with variable arguments(though I suspect a C++ compiler might complain about this).

Not sure what his point is.

Re:Higher order functions? Whats the big deal?

[Anonymous Coward]

Javascript doesn't just do function pointers. Javascript has closures, which makes it possible to generate variations on functions without using eval():

function get_it(start) {
  var s = start * 100;
  return function() { return s++ };
}

var it1 = get_it(1);
var it2 = get_it(2);

it1(); // returns 100
it1(); // returns 101

it2(); // returns 200
it3(); // returns 201

Re:Higher order functions? Whats the big deal?

[ChrisWong]

C's functions are totally context-free. You can't work with them as you would methods of related objects, where behavior is married to some presumed context. JS's functions are more OOPy, in that function calls are always associated with some object. A JS function can both retain context (through closures) and gain new context simultaneously when you reassign it to another object.

An illustration: you can change functions on an existing object, and functions receive the context in which they reside. So when you assign a function to an object:

var object = { x:1, y:2, sum:0, }; // assign function here
object.f = function(z) {
      sum = this.x + this.y + z;
}

that function sees the properties of the object to which it is assigned via "this".

Another difference is that you cannot readily change behavior in C by assigning functions. Because of the pointer/function distinction, you can only use function pointers with code that was written from the beginning to accept and execute functions via pointers. In JS, functions are a standard data type: all functions in all objects can be changed, and changing those functions will change the objects' behavior.

hris

Other reasons

[LucidBeast]

I did it for the money...

No printf in javascript ?

[herve_masson]

Beside the lack of a good way to debug your javascript code (using traces, not the infamous alert method), I really miss printf like functions. Why was this not available in the base language is beyond my understanding.

Anyway, if you're like me, you can use my own implementation of printf functions here.

Needs a Concatenation Operator

[ajs318]

JavaScript has one really, really nasty flaw. It "recycles" the + operator (which usually is used for adding numbers) to concatenate strings. In some languages (e.g. BASIC), which treat numbers and strings as distinct data types, this is not a problem. But JavaScript is dynamically-typed -- in other words, you don't have to tell it what is a number and what is a string; it tries to work that out for itself. And this is the source of the error. When you innocently write
document.theform.hours.value += 1;
in a bit of form-munging code, what happens is that a figure "1" gets appended onto the end of the value in the "hours" box. If you want to increment it by one, you have to use something like
document.theform.hours.value -= -1;
which is mathematically sound, but looks very weird.

JavaScript really needs a dedicated string concatenation operator, in recognition of the fact that numeric addition and string concatenation are different operations. Unfortunately, the "dot", which would be the most obvious choice as it's already used for the concatenation operator in other languages, is already very much in use -- not to mention that changing an operator in this fashion is likely to break things. And the breakage will be even worse than register_globals in PHP, since JavaScript runs on the client side -- meaning no webmaster can ever know for sure what JavaScript engine is in use.

Re:Needs a Concatenation Operator

[shutdown -p now]

Plenty of other mainstream languages reuse + for string concatenation (C++, C#, Java), including dynamic ones (Python, Ruby). I haven't really observed any problems with that so far, but if you're really worried, you can always declare something like: function strcat(s1, s2) { s1.toString() + s2.toString(); } And use that throughout your code.

All in all, it's really a very minor issue.

Re:Needs a Concatenation Operator

[ajs318]

It's not a "very minor" issue. It's fundamentally broken. Essentially, everytime you want to add numbers, you end up having to subtract a negative number instead, or use ParseInt() / ParseFloat() to force things to be numeric (concatenating strings seems to be the default behaviour of +). This just looks messy (and coming from someone who uses Perl, that's a damning indictment indeed).

Your strcat() example is nice, but it can only ever concatenate two strings -- a limitation of the language. (JavaScript insists for every function to have an exact number of parameters; Perl functions can take as many or as few parameters as you like). So it soon gets unwieldy; you need separate functions to concatenate three or four strings. Or, more likely, to add different numbers of numbers:
function sum2(n1, n2) { return (n1 - (-n2)); }
function sum3(n1, n2, n3) { return (n1 - (-n2-n3)); }
and so forth.

I think awk has the best syntax for string concatenation .....

Re:Needs a Concatenation Operator

[Bitsy Boffin]

JavaScript insists for every function to have an exact number of parameters;

Guess you havn't used Javascript in a while.

"Using the arguments object, you can call a function with more arguments than it is formally declared to accept. This is often useful if you don't know in advance how many arguments will be passed to the function. You can use arguments.length to determine the number of arguments actually passed to the function, and then treat each argument using the arguments object."

http://developer.mozilla.org/en/docs/Core_JavaScri pt_1.5_Guide:Using_the_arguments_object

I agree that string concatenation should have a separate operator though.

Re:Needs a Concatenation Operator

[ajs318]

Ooooh! I must admit, I didn't know that. I will have to go away and find a use for it right now!

Re:Needs a Concatenation Operator

[shutdown -p now]

It's not a "very minor" issue. It's fundamentally broken. Essentially, everytime you want to add numbers, you end up having to subtract a negative number instead, or use ParseInt() / ParseFloat() to force things to be numeric (concatenating strings seems to be the default behaviour of +).

This is precisely how things are in most (all?) statically-typed languages which overload + for string concatenation. If anything, I'd say it's an advantage - your average C# or Java programmer immediately knows how to handle string concatenation in JS properly. Which is one thing that I think is a conscious design decision in JS (or maybe not, but good nonetheless) - for being a dynamic language with closures and object prototyping and other tasty things, it looks and feels mostly familiar to C#/Java programmers (of which, especially the latter, there are a majority) on the surface... and from there, it's not all that hard to learn the "differences".

Re:Needs a Concatenation Operator

[GayBliss]

Essentially, everytime you want to add numbers, you end up having to subtract a negative number instead, or use ParseInt() / ParseFloat() to force things to be numeric (concatenating strings seems to be the default behaviour of +).

This is not true. If you add two numbers, you get a number as a result. If you add a number and a String, you get a String as a result. You can typecast the string to a number to convert it to a number. For example:

var a = 2;
var b = 3;
var c = "4";
alert(a + b); // displays "5"
alert(b + c); // displays "34"
alert(b + Number(c)); // displays "7"

Re:Needs a Concatenation Operator

[Tim C]

It "recycles" the + operator (which usually is used for adding numbers) to concatenate strings.

The technical term for that is "overloads".

JavaScript runs on the client side -- meaning no webmaster can ever know for sure what JavaScript engine is in use.

There are some tricks that you can perform to try to work it out. You could also do something server-side by sniffing the user-agent header and comparing it to a list to take an educated guess at the likely level of support.

Of course, given that (according to the linked page) not all browsers respect the language attribute and of course user-agent headers can be faked or missing, you can't rely on it. The usual method to ensure compliance is simply to test against a specified subset of browsers and support only them; that doesn't necessarily mean locking out all other browsers, but you should at least make users aware that they may experience some turbulence...

Re:Needs a Concatenation Operator

[iONiUM]

I believe you can just do eval(document.theform.hours.value + 1) if you want to get a number. I think the eval function is extremely powerful in JavaScript.

Re:Needs a Concatenation Operator

[fossa]

Kitten is a subclass of Flesh which mixes in Water. Water responds to microwave by heating. When its temperature parameter is sufficiently increased, Flesh cooks.

Re:Needs a Concatenation Operator

[ucblockhead]

This is less of an issue with typed languages like C++ or Java. If you try to add an integer to a string on one of those languages, you get an error. In Javascript, it changes the integer to a string. (Python also errors out if you try to add a string to an integer.)

Re:Needs a Concatenation Operator

[Scarblac]

Python and Ruby may be "dynamic" in some sense, but in both of them string += int will cause an exception. They're strictly typed, just with dynamic binding. Javascript really is a bit odd in allowing += for both addition and concatenation, and giving no warnings if you mix types. That's the sort of fuzzy thing that you'd only expect in PHP.

Re:Needs a Concatenation Operator

[drew]

You can always use Number()/String() to force typing:

document.theform.hours.value = Number(document.theform.hours.value) + 1;

Unfortunately, I don't think you can use the '+=' with that form, because Number() returns a new Number object. Still, I'd say that's a little easier to look at and understand than your version, even if it is a little longer to type. It was a hard learned lesson for me way back when I first ran into this "bug", but it's pretty much just habit now. Any time I am dealing with a variable that has the remotest possibility of not being a Number, I always throw Number() around it before I use it.

That said, I do agree with you that the language designers really had a serious brain fart when they didn't make a separate concatenation operator, but it's far too late to add one now, and I don't think it will ever happen. Besides, even if one was added, Internet Explorer would take ten years to add support for it, so it would be essentially useless anyway. (Hey Microsoft, when are we going to see JavaScript 1.5 in IE, huh?)

Re:Needs a Concatenation Operator

[Anonymous Coward]

Plenty of other mainstream languages reuse + for string concatenation (C++, C#, Java)

That doesn't mean it's a good idea, especially for a language where conversions from strings to numbers and back are done automatically.

In C++, string + int doesn't concatenate the int onto the string. If you're lucky it's an error. If you're not lucky, it converts the int into a character and appends that character. If it's a string literal rather than a std::string, even worse. Reusing << would have been a better choice than + in C++.

if you're really worried, you can always declare something like: function strcat

Which doesn't solve the grandparent's problem, because it doesn't remove the functionality from +

Re:Needs a Concatenation Operator

[mandelbr0t]

Meh. Caveat Programmer. If you work in a dynamically-typed language, you should know what the gotchas are. Perl has exactly the same problems (although it does have a dot operator to clarify some things). You always have to coerce the type by a construct like "" + 1 or the like in any dynamically typed language where the result is dependent on string type versus numeric type.

mandelbr0t

Re:Needs a Concatenation Operator

[Anonymous Coward]

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

Re:Needs a Concatenation Operator

[Anonymous Coward]

(Hey Microsoft, when are we going to see JavaScript 1.5 in IE, huh?)

Umm... 1999? Seriously, what are you talking about?

Re:Needs a Concatenation Operator

[zobier]

When you innocently write
document.theform.hours.value += 1;

Like others have said that isn't an innocent mistake. It's a dynamically typed language you should typecast your String to a Number first. Having said that in your simplistic example you could get away with a double plus, no good if you want to increment by greater than a unit but x='1'; ++x == 2.

Re:Needs a Concatenation Operator

[Falesh]

That's the sort of fuzzy thing that you'd only expect in PHP
Apart from the fact that PHP is very solid with regards to concat, it uses a dot.

Re:Needs a Concatenation Operator

[drew]

I'm talking about version 1.5 of the JavaScript language, a.k.a. ECMA-262 3rd edition. I don't know what browser Microsoft released in 1999 that supports it, but Internet Explorer 5.5, 6.0, and 7.0 do not.

Re:I love the autopointerage & hate the scope

[ageforce_]

next is the scope issue i've talked about suppose i'm dynamically creating objects on the fly and want the callback to reflect the id thus
for( i=0 ; i&lt;10 ; i++ )
{
someObject[i] = new SomeObject();
someObject[i].onclick = function(){ myFunction( i ) }
}
every single object will pass the value of 10 to myFunction, because after the function has finished the instance of i in memory that was used is still sat there and every myFunction has been given a pointer to it, not the value it was when it was initialised!

That has been fixed in JavaScript 1.7. A new keyword (let) allows to limit the scope of a variable, which is exactly what you would need here.

Re:JS is not the problem, the whole environment is

[Tim C]

Ooh, nice unclosed anchor tag there. Teach me to not use the preview button - and to get 3 hours sleep...

Re:JS is not the problem, the whole environment is

[herve_masson]

I agree that javascript is not *the* problem of web development, but it has itw own bag of oddities.

Here is one: variable scope:

function MyFunc()
{
    var i=0;
    {
          var i=20;
    }
   
// Did you really expect the 'i' variable to contain 20 here ?
}

simplicity and power

[TapeCutter]

Call me old fashioned but K&R will always be my definition of simplicity and power in programming.

The thing that makes it messy in C is C's strong typing, you would have to pass and return everything as strings, but this is to be expected since the problem is contrived to demonstrate the brevity possible with weak-typing. The trade off is that you don't know exactly what your dealing with. In well written scripts that's no big deal, in a system with thousands of source files written by dozens of programmers it will quickly turn your brain to mush.

It used to be that weak typing in a language was a BadThing(TM), now it's a "feature".

Re:simplicity and power

[arevos]

The thing that makes it messy in C is C's strong typing, you would have to pass and return everything as strings, but this is to be expected since the problem is contrived to demonstrate the brevity possible with weak-typing. The trade off is that you don't know exactly what your dealing with. In well written scripts that's no big deal, in a system with thousands of source files written by dozens of programmers it will quickly turn your brain to mush.

It used to be that weak typing in a language was a BadThing(TM), now it's a "feature".

You're confusing weak typing with dynamic typing. C is not strongly typed; it has static weak typing. Languages like Java have static strong typing, Python and Ruby have dynamic strong typing, and PHP and Javascript have dynamic weak typing.

Re:simplicity and power

[pclminion]

Just to clarify the parent's comment, DYNAMIC/STATIC refers to the ability or inability of an lvalue to change its type during the course of execution. STRONG/WEAK refers to restrictions the compiler places on which kind of operations can be applied to which types. The two concepts are pretty much orthogonal.

In C, for instance, typing is static because a variable is declared as a specific type and that type cannot change. The typing is also WEAK because the C compiler does not impose very many restrictions on operations between types -- you can assign an unsigned char to an int with no complaints, or cast a pointer into another type of pointer, or pass an integer to a function which expects a float (and the compiler will automatically do the type conversion).

The disadvantage of a dynamically typed language is that you cannot know, without using reflection mechanisms, what type an lvalue actually contains. The disadvantage to weakly typed languages is that you cannot easily know which implicit type conversions the compiler is performing. But working in a statically, strongly typed language can feel very constraining and idiomatic. I think C strikes a fairly reasonable compromise. JavaScript on the other hand confuses the hell out of me.

Re:simplicity and power

[arevos]

But working in a statically, strongly typed language can feel very constraining and idiomatic. I think C strikes a fairly reasonable compromise.

I can see why some people prefer static typing, and others dynamic; however, I can't think of many benefits to weak typing over strong typing, aside from improving efficiency by cutting down runtime overhead. Could you enlighten me as to why you prefer a weak/static language like C over a strong/static language?

Re:simplicity and power

[pclminion]

For me it is purely a matter of convenience. Because of my experience with C, I have all the implicit type conversion rules built into my head, and I take advantage of them all the time. For a beginner in C, these rules can make it seem impossible to predict exactly what operation will actually occur. As an example consider the expression 1.0f + 5 - 'a' -- what types do the temporary expressions have, what is the ultimate type of the final expression, in what order to type promotions occur, etc? To me it is apparent, to someone inexperienced it is a mystery. I don't deny that coding in C and actually enjoying it is quickly becoming old-school and even a little crusty.

Re:simplicity and power

[TapeCutter]

My bad, I should have said "stronger" rather than "strong".

A great Javascript debugger...

[Anonymous Coward]

Beside the lack of a good way to debug your javascript code

Ahem.
FireBug.

Re:A great Javascript debugger...

[herve_masson]

yes, you're right, we now have something great ... in firefox. It just won't help you to troubleshoot cross browser issues, which to date takes a hell of js programmer's time. But that's a fantastic help for common JS coding.

Re:A great Javascript debugger...

[ChrisWong]

Ahem.

http://www.getfirebug.com/lite.html

Works with IE, Opera, Safari.

There is also a fairly powerful script debugger for IE that comes with Office.

Chris

javascript object model

[Anonymous Coward]

It is a pity that someone not very informed writes an article on the JavaScript object model. The JavaScript object model is a copy of the object model of the Self language developed in the 80s. There still a link to the Self language to the Sun web site. There was a reason to create Self language object model and it is not bad at all if features such dynamic binding are needed. Whether a generic purpose browser script language needs such a model is another matter. Nevertheless, most of the developers use a minimum of the features available, and once a while someone seems to rediscover it - come on this object model model is more than 20 years old - and JavaScript has been for around 10 years now with this very model. The original JavaScript documentation by Netscape had an entire chapter on JavaScript objects, that is still the best tutorial available for the Self object model.

Yo, Rodney!

[niktemadur]

JavaScript, surely the Rodney Dangerfield of scripting languages.

I don't get no respect, you know, the other day I told a friend that I wanted to try out the online dating scene, and he set me up to use Outlook Express on Usenet!

Even Java6 considers JavaScript important

[Anonymous Coward]

I never touched JavaScript myself (well, to open and close a window, which is only an example I grabbed from a website) yet have been annoyed at people who didn't even manage to seperate Java from JavaScript. When it comes to web programming I've only used Java thus far through jsp or full servlets. Still, JavaScript is absolutely an important issue. It allows for server-side scripting without the hassle of a full container (in my case java container; tomcat or glassfish).

Still, what company knows best about JavaScript than Sun themselves? Recently the latest version of Java (Java SE 6) has been released and guess what one of its keyfeatures is? An API to support scripting languages. Right now the so called scripting engine only supports JavaScript, read about it here. For those really interested, here is the API documentation (javadoc).

I know I'm biased but heck; if people still don't realize the possibilities of JavaScript I'm pretty convinced that the combination of Java and JavaScript will enhance some of it. Java SE6 is pretty extensive, and with the addition of JavaScript even more flexible.

Re:JS is not the problem, the whole environment is

[Anonymous Coward]

The problem is not the environment, it is your inexperience. HTML and CSS are for markup, the interface. Javascript is for behaviour. The back-end language is for the controller and the model. Stick to well known paradigms and you'll do well.

This degree of seperation is beautiful. I wish it was that easy for client applications too.

Lets all do binary

[YeeHaW_Jelte]

As we all know, programmers are most productive in assembly, which is by nature many times denser than any programming language.

Oh wait! Never mind assembly, lets just do binary.

Re:Lets all do binary

[SharpFang]

actually, assembly (non-macro) is more efficient because it converts 1:1 to binary and you don't need to do all the remembering of addresses and so on. Essentially assembly is not really a separate language than binary but just a symbollic representation of it. Not once I was counting cycles of an interrupt routine or seeking where to save that one byte to fit the whole routine before the next interrupt vector instead of making an unnecessary jump, saving at least 3 cycles.

Re:Lets all do binary

[OhHellWithIt]

As we all know, programmers are most productive in assembly

I would mod your comment Funny, but I'm afraid you might be serious. I think I've managed to write many more bugs using higher level languages, and Python is my favorite current tool for writing bugs that really bugger things up. If anything is the Anti-Assembler, it's Python.

But your comment also makes me think of another use for vector bosons. Maybe we should try blasting them at all these applications we have now that require us to have gigabytes of memory and terabytes of disk space.

No it's pants

[matt me]

And Ajax is worse. Now I can be writing an email in gmail, hit back to check something, and bye bye everything.

Re:No it's pants

[Lord Faust]

Check your Drafts folder.

Disagree

[arevos]

Java Script / J Script is the devil. Development is a sloppy crap shoot, but we use it because it's there. It's now being used for ridiculous things that it was never really designed for.

I agree that there are sometimes compatibility issues with complex Javascript, but I think you overexaggerate Javascript's flaws.

As a language, Javascript is simple, but has a very rich featureset. The standard libraries allow it to interface with the DOM of a HTML page. The only significant problem I can think of is Javascript's lack of thread control structures, which may prove problematic for applications that handle complicated asynchronous events.

I'm not sure why you think Javascript is "being used for ridiculous things that it was never really designed for", as it's a rather generic scripting language, and its standard library is small and to the point. Could you give an example of some of Javascript's perceived shortfalls?

Re:Disagree

[masklinn]

As a language, Javascript is simple, but has a very rich featureset. The standard libraries allow it to interface with the DOM of a HTML page.

In what bizarro world do you live where having a DOM interface means "a very reach featureset"?

I do like Javascript, but come on, javascript has barely any "featureset" to speak of and no standard library whatsoever apart from the DOM.

The only significant problem I can think of is Javascript's lack of thread control structures, which may prove problematic for applications that handle complicated asynchronous events.

Javascript has no threads, the lack of thread control structure therefore doesn't matter much.

its standard library is small and to the point

I strongly disagree: Javascript has no standard library. As far as the shortcomings of regular JS, check the improvements to javascript in JS1.6, JS1.7, E4X, and the various Javascript 2.0 propositions.

Re:Disagree

[arevos]

In what bizarro world do you live where having a DOM interface means "a very reach featureset"?

I said, "As a language". Javascript's standard library is small, but the functionality the language itself supports is quite advanced. Closures, prototyping, mutable objects, and consistent OO (i.e. everything is an object), make Javascript rather flexible; just look at the additions Prototype has added in.

Javascript has no threads, the lack of thread control structure therefore doesn't matter much.

Ah, you're quite correct; Javascript is singled threaded. However, considering the amount of asynchronous callbacks from setTimeout, setInterval and XMLHttpRequest, one has to wonder whether the very lack of threading could not be construed as a disadvantage on its own. Since each Javascript function is axiomic, one would have to split up complex functionality to run across several functions.

I strongly disagree: Javascript has no standard library.

What do you mean by "Javascript"? Are you referring to the ECMAScript dialect (which, so far as I'm aware, does have a standard library), or are you using "Javascript" to mean "Any ECMAScript browser implementation" (in which case you are technically correct)?

Regardless, the standard libraries of JScript and Javascript overlap considerably, so although you can point out, quite correctly, that ECMAScript does not define a standard library per se (so far as I am aware), from a practical standpoint the major browsers have a number of EMCAScript objects in common, which mounts to the same thing as a standard library in practise.

Re:Disagree

[rjshields]

I strongly disagree: Javascript has no standard library.

You could argue that things like String, Array and Math form the standard library. You could also argue that they are part of the language. I'm not sure which is correct.

Ignoring this point, which is largely academic, there are still a shedload of features missing to make it useful as a standalone scripting language, e.g. I/O, filesystem access, networking/sockets. The ability to include other code files and namespaces would also be very useful.

JS has respect, and ....

[joe_n_bloe]

JavaScript is a developing and well-defined standard - ECMAScript. It's no less standardized than, say, CSS, and as a practical matter, JavaScript is generally less variable and more predictable across platforms than is CSS.

Nor is JavaScript necessarily slow. In fact, it's quite fast in many cases when you consider what it's doing. If all you do in JavaScript is time loops, you should be using a different language.

Google has demonstrated that JavaScript can be translated (compiled) into other languages, Java in the case of GWT.

There are JavaScript shells that you can use as a means of writing command-line applications in JavaScript (more or less).

Now, what I'd like to do with JavaScript is be able to write client-side applications with it. I want to be able to do file i/o (and so forth) locally, without running a local web server. Make it a full featured "normal" programming language with access to local resources except that it is, of course, running via a browser and/or able to manipulate a browser's DOM. Having to use a mini-web server running locally, or *cough* XUL, or whatever, to do this is so 20th century.

JavaScript is a nice language with unique abilities and applications, and it is the only language with a well-known and widely used interface to the DOM. If you dismiss it out of hand, you are dismissing it out of ignorance.

Re:JS has respect, and ....

[crush]

I want to be able to do file i/o (and so forth) locally, without running a local web server.
You can. You just have to have a webbrowser interpreting the javascript. It differs of course between IE (Scripting.FileSystemObject) and Moz (Components.classes["@mozilla.org/file/local] and Components.classes["@mozilla.org/network/file-outp ut-stream;]) and away you go (after you've taken care of security privileges.

Re:JS has respect, and ....

[DrEasy]

Google has demonstrated that JavaScript can be translated (compiled) into other languages, Java in the case of GWT.

Just a nitpick, I think it's the other way around.

Re:JS has respect, and ....

[joe_n_bloe]

D'oh!

Re:I love the autopointerage & hate the scope

[Johnny deBris]

> if( !Array.push )
> Array.prototype.push = function( item ){ ... }

Yes, this sounds nice, but it's a large pitfall too. It's very tempting to start extending 'basic datatypes' with all kinds of stuff, which can result in awful clashes with other libraries that do the same. Ruby on Rails' 'Prototype' library is a good example of how _not_ to use this.

> someObject.onclick = function(){ myFunction( this.someAttribute ) }

Horrible indeed. The idea of allowing to call a method with a different 'this' is already scary, and useful only for nasty hacks, but I think actually using this feature in very commonly used functionality* was a big mistake (perhaps not so obvious when 'object oriented' programming (yes, the prototype stuff, i know it's not strictly oo) wasn't very common, but nowadays it's one of the first walls JS developers bump into).

> function array_push( arr , item )
> arr[arr.length] = item;

Nothing new here I think... There's more (intepreted) languages that can do this. And most other languages actually _do_ implement push() (or something similar) on all platforms. ;)

> someObject.onclick = myFunction

Nothing new here either. Try Python for instance, which is a lot more dynamic than JavaScript... :)

Yes, I understand that JS has certain very nice features when you're used to more static ones like C or Java or whatnot, but I think compared to certain others (note that most of JS' features are in some way stolen from other languages) its awful implementation, lack of basic functionality (no String.strip() while there is a String.blink()?!?), sheer unintuitiveness (it's for instance not at all clear what notation to use for 'OO', there's a billion ways to define objects and prototypes and such, and the differences are subtle) and strange quirks (like the nested scopes example you mention, but there's plenty more examples) are reason enough to still see it as 'necessary evil' rather than 'an enlightening experience'... ;)

(Do note that I'm a bit biased, as I'm (not deeply, but a bit) involved in the PyPy project, which works on (among a lot of other things) a Python to JavaScript compiler... ;)

* most notably event handlers: when registering an event handler in certain ways 'this' points to the event, or the element on which the event is defined, or something, and not to the object, making that you need to use closures to actually have a reference to the object the method is defined on, from the method :|

JavaScript Shell

[markus_baertschi]

I'd like a JavaScript based shell for my shell programming tasks. At the moment I'm confined to either bsh/ksh or perl. The shells [bk]sh are just too limited for many tasks, perl just has a too wierd syntax for many things.

The obvious answer is 'just do it', but this need time and between work and famliy there is not much left...

Markus

Re:I love the autopointerage & hate the scope

[arevos]

But this has brought up the thing that really really needs fixing, suppose i want that onclick function to pass some info to myFunction when i call it i have to do this

someObject.onclick = function(){ myFunction( this.someAttribute ) }

The Prototype library introduces a function called "bind" that allows you to get around this:

someObject.onclick = (function(){ myFunction( this.someAttribute ) }).bind(this);

This makes 'this' refer to the object that created the function, rather than the object the function is attached to.

next is the scope issue i've talked about suppose i'm dynamically creating objects on the fly and want the callback to reflect the id thus

for( i=0 ; i<10 ; i++ )
{
  someObject[i] = new SomeObject();
  someObject[i].onclick = function(){ myFunction( i ) }
}

This doesn't have a neat solution. However, there are various ways to get around the problem you descript. For instance, under prototype, one could write:

someObject = $R(0, 10).collect(function(i) {
  return Object.extend(new SomeObject(), { onclick: function() { myFunction(i); } });
});

It's the clients stupid

[bhmit1]

The best and worst part of javascript is the client side scripting. Unlike just about every other language, you don't get to pick the best implemented compiler or interpreter or platform for your program. Rather, whatever web browser happens to pull up your page today with a half implemented javascript spec is what you get. You can't just test every piece of code you write, you have to test every piece of code with every platform and browser you plan on supporting. And as bad as that is, there just aren't any better options for cross platform/browser support for client side scripting that are built in.

Re:It's the clients stupid

[jdbartlett]

I agree with your first couple of statements. I love working with JavaScript (yes, even with prototypal inheritance). I tend to get around the specific problem you describe (which has a name: Internet Explorer) by encapsulating commonly problematic functions (such as addEventListener). In doing so, I can write modern standards compliant JavaScript (which doesn't make it ECMAScript, that would be a bloody stupid name) without sacrificing cross-browser compatibility.

However, there's another issue in the client: speed. I am extremely dissatisfied with the speed at which JavaScript is interpreted. It's a real bottleneck. Because I like working with JavaScript so much, I've started designing a JavaScript-only widget library which uses modern W3C & ECMA compliant DOM methods to create widgets. The purpose was twofold: cut out the middleman (HTML) in developing web "2.0" apps, and introduce a method of developing web apps that allows us to completely separate our server-side code from our client (as opposed to the coupling that exists w/current toolkits). It's an interesting study, but has some obvious drawbacks: it's not downgradable, not accessible for screenreaders, and draws widgets ridiculously slowly compared to a page with the equivalent HTML elements. The last of these three drawbacks is out of my control: the only workaround I have found is to forgo compliance in favor of using innerHTML. No thanks.

Re:I love the autopointerage & hate the scope

[RAMMS EIN]

``

someObject.onclick = function(){ myFunction( this.someAttribute ) }

so instead i've created a function inline to hold my custom function, firstly it's not immediatley obvious to what object the "this" applies. if i'm running this code in a class does the this mean the class or someObject, one hopes it means the someObject.''

Maybe you hope so, but I don't. The "this" is lexically inside whatever environment the whole line of code is in, so it should refer to whatever object "this" refers to in that environment. At least, that's what lexical scoping dictates and what makes the most sense to me.

Re:I love the autopointerage & hate the scope

[Zardoz44]

You can introduce your own friendlier concepts. That's the power of it.

Javascript Closures: has a nice tutorial. In this case specifically, you can follow the event-handler system he's created. You could also look at the prototype.js library, specifically the "bind" function (function extension).

foo.onclick = this.DoSomething.bind(this, arg1, agr2);

Now onclick executes "DoSomething" using the current "this" as the context, and stores the args. Not only is this very useful, but it avoids the memory leaks in IE caused by combining inline functions, DOM elements, and closures.

ECMAScript

[arevos]

It sounds like you want a standardized version of Javascript. There is one; it's called ECMAScript. Where the problem lies is that different browsers may have different standard libraries, so a standard function in IE, may not exist in Firefox and vice versa.

However, as far as I know, most browsers adhere to the EMCAScript spec fairly closely in terms of syntax, even in IE. So the language is a fixed standard, and certain libraries (such as the W3C DOM model) are standards, but that doesn't stop individual browsers either extending the standard libraries, or screwing up the implementation of the libraries they support.

Personally I think it's a pretty cool language

[CTho9305]

You can do some pretty fun things with it, such as a true 3d engine, a raytracer, games (careful, robots is addicting!), out-of-order CPU simulators, and other stupid things without any plugins - all the user needs is a halfway decent browser.

Re:Personally I think it's a pretty cool language

[Anonymous Coward]

Those are cool, but this is just useful:

Javascript vector graphic library
http://www.walterzorn.com/jsgraphics/jsgraphics_e. htm

Re:I love the autopointerage & hate the scope

[julesh]

It's hard to comment on the function-attaching example you gave, since obviously any real implementation of most languages already has functions such as those you describe.

A real world example you may find more enlightening: There's a framework out there somewhere that extends the standard Javascript classes with methods that are API-compatible with the standard methods of equivalent Ruby classes, meaning that simple Ruby programs can often be run with few or no modifications.

Another thing you can do with this capability is use it on your own classes. Consider plugins that directly add new features to existing objects.

Memory Leak Problems?

[eatergator]

I really like JavaScript, however when I did complicated things with it, I ran into a some problems with Memory Leaks in IE. Getting rid of which was not that easy in some case, thankfully there are tools like Drip http://outofhanwell.com/ieleak/index.php?title=Mai n_Page I guess some of these things were fixed with IE 7...but you know it was not fun.

Language bloat

[Colin Smith]

I've noticed it with Perl, Python, Ruby, Pascal, C, C++, Java. Well pretty much every single language I've ever come across except for the Unix shell.

They start off as small, fast, flexible, perhaps even elegant languages and evolve into massive bloated, and unweildy oil tankers which are too large to fix. So we start from scratch with a whizzy new better language which just needs a little tweak here or there to make it perfect.

JavaScript is great

[ubergenius]

Programmers don't really hate JavaScript, we just yell at it like we do any other programming language when we can't easily do something that we want done easily, like searching substrings. In truth, JavaScript is a great tool that allows the ability to create powerful webapps that have the look and feel of traditional standalone apps, and anyone who says the genuinely hate it is either lying due to anger at something related to it, or don't use it enough to understand its usefulness.

Javascript is also the heart of the Sphere engine

[xxxJonBoyxxx]

Javascript is also the heart of the Sphere gaming engine. http://aegisknight.org/sphere

Re:JS is not the problem, the whole environment is

[SolitaryMan]

Repeat after me: Obscurity is not the same as Security If you are sending information to the browser that you don't want to be known, then you're doing something wrong. This is the case for JS, as well as for AJAX, Flash or Java applets. Or client-side code in general.

Argh! Where is the mod point when you need one!

I even remember some people telling me that POST request is more secure than GET since client can see contents of GET request in URL. These people worked for serious web company, btw. I'm afraid that Security through Obscurity is still the way most people see it...

It's not the best.... but it's not bad, either.

[Randolpho]

Javascript has some amazingly powerful functional features that make it rival some of the great languages. That said, it is hampered by a lack of true object orientation. There are syntactic hacks that allow you to *fake*
It strikes me, however, that one of the best scripting languages out there, python, took a similar path. Once python had no object orientation, and people faked it with syntactic hacks. Then the syntax changed slightly and it was slowly added over the years, even as compatibility was kept with previous versions.

Javascript could take such a route. It's not a bad languages; it could get better.

Re:It's not the best.... but it's not bad, either.

[Randolpho]

It helps to actually preview your posts. Here's the fixed version: Javascript has some amazingly powerful functional features that make it rival some of the great languages. That said, it is hampered by a lack of true object orientation. There are syntactic hacks that allow you to *fake* private methods/properties and inheritance, but they are not really features of the language.

It strikes me, however, that one of the best scripting languages out there, python, took a similar path. Once python had no object orientation, and people faked it with syntactic hacks. Then the syntax changed slightly and it was slowly added over the years, even as compatibility was kept with previous versions.

Javascript could take such a route. It's not a bad languages; it could get better.

Re:It's not the best.... but it's not bad, either.

[ggpauly]

I like the laid-back objects that JS provides. Just reference an attribute and it exists. Simple as can be. You can be informal or rigorous as you like. Closures, functions as arguments, all with a very small vocabulary.

If JS had an integer type I'd consider using it for server-side scripting.

Re:JS is not the problem, the whole environment is

[Anonymous Coward]

That's an oddity?

The only people for whom nested variable scoping is an oddity are those whose main language is BASIC.

Have you used APL?

[Anonymous Coward]

> 10 times as dense means the developers are 10 times as productive.

Not really. Have you ever used APL?
http://en.wikipedia.org/wiki/APL_(programming_lang uage)

It's extremely dense but if you discover a problem with your code a week after writing it, good luck trying to debug it.

Re:Have you used APL?

[sholden]

Nope, though the report I linked to puts it as between java and perl in the "denseness" stakes...

This is fixed in 1.7 (let keyword)

[Ayanami Rei]

function MyFunc()
{
        var i=0;
        {
                    let i=i+1;
                    alert(i);
        }

      alert(i);
}

You would see "1", then "0"

lexical scoping in ecmascript is very simple, to support the construction of closures, as it is primarily an event handling language. The let keyword would provide a built-in way to introduce a blocking scope (it is possible now, but it involves defining an anonymous object and using a method scope, IIRC)

That being said, the cases where you need such a construction are fewer than you would imagine, as it can make code intent unclear.

Tools...Options...

[Anonymous Coward]

What's this?

Tools...Options...Content...Un-Check "Enable JavaScript".

or

Tools...Internet Options...Security...Internet...Custom level...Active Scripting - Disable.

Oh my, all my JavaScript applications I spent hundreds of hours developing no longer work! What will I do? How can I force my users to enable JavaScript? Oh, you mean I can't? Well I guess those hundreds of development hours are wasted aren't they?

If it must work, then it must be done serverside which is under your control. Client-side scripting is strictly for completely non-essential frills.

Not to mention that the whole memory and sluggishness issues of Firefox are due to the absurd reliance on JavaScript.

Until browsers no longer allow JavaScript to be disabled (I rue the day) then it is useless as a reliable tool for web application development.

Now were someone to release their own browser where JavaScript cannot be disabled and their server will only recognise this browser, then it would be useful, but we all know what happens when you try and force a particular browser on users...

I've come to this conclusion also.

[YoungHack]

I've decided in the last year that JavaScript is the unsung hero of computer languages. The biggest reason I feel this way is: JavaScript lowers the bar for program distribution. If you write a program in Java, the bar is high because they have to have a Java interpreter. Same for Perl, Python, Ruby, Flash, etc. If you write in a lower level language like C, C++, etc. you still have to get the program installed, and you have to tailor for their architecture.

I'm a math teacher, and I considered once writing a web article for folks about a topic that would require solving an equation (and not a simple one that could be done with algebra). The obvious support program for the article would be a program that could apply the secant method and approximate the answer, because close is good enough.

I considered writing a little CGI equation solver, but this was unsatisfactory to me. I'd have to take care because I'm letting other people run code on my server. Then it occurred to me that I could write it in JavaScript, and it would run on their computer.

If your program can be done in JavaScript, there is no simpler software distribution model. Click the link and it's going. Nothing to install. It doesn't get any easier than that.

Re:Verbose != Readable

[Bastian]

Verbosity and density really aren't all that closely related to readability and maintainability. I submit as evidence the fillowing: assembly language, C, Perl, and Haskell.

My sense is that, if two languages are about equally readable, the one that is more dense ("expressive") will produce more maintainable code simply because there's less to read and keep track of.

JavaScript = Security Risk!

[Anonymous Coward]

Like all active content, JavaScript is a severe threat to security.
Web Developers need to be aware of the risk. Do the right thing, do not use JavaScript to protect your website's visitors.

Re:JavaScript = Security Risk!

[arevos]

Like all active content, JavaScript is a severe threat to security.

Only if implemented incorrectly; but then you could say the same thing about any piece of code.

Re:JS is not the problem, the whole environment is

[Anonymous Coward]

Java Applets did all this, but Microsoft got their grubby little hands on it and destroyed it.

Sun nailed the concepts with Applets. It's very unfortunate that they got such a bad name in the beginning.

Dude. DUDE

[Ayanami Rei]

I've been trying to put something like this together for ages. It has been a perverse dream of mine to do system management from javascript for the longest time. This totally rocks. And with dynamic binding? GLEE

I problem I never figured out (and which always kept me from getting anywhere) was how to reconcile threading/forking with the spidermonkey engine in a way that could be manipulated cleanly from the scripts themselves.

Any thoughts on this?

I don't get no respect

[pantalanaga11]

...surely the Rodney Dangerfield of scripting languages.

If one couples this statement with the more general Axiom #7 of Programming Languages (A7PL*), it follows that JavaScript could be interpreted as little more than a dancing gopher. Therefore, JavaScript "don't get no respect".


*Axiom #7 of Programming Lanaguages (A7PL) states that scripting languages are the Chevy Chase of programming languages in general.

newbie thoughts

[harryk]

As someone who just finished writing my first javascript app, and a simple one at that, I can tell you that I appreciated the simplistic language. I've got roots with BASIC, Turbo Pascal, and have dabbled a little along the way, and I have to say it was intuitive.

I'm not a web-dev guy, and the script I wrote won't even touch a http server, as its only meant to work locally, but I liked it.

just me rambling

harryk

i like javascript

[jaimz22]

Personally, I feel that javascript is a wonderful well thought out language. It's easy for starters, yet it has the power that professionals want and need. Alot of people talk down about javascript because browsers don't all integrate it the same, or correctly. but javascript give you to tools to get around the short comings of the browsers.

I think the problem is your mental model

[MarkusQ]

I think the problem here is your mental model, rather than the language. Specifically, you are thinking that the value of form field, which is a string, should be treated as an integer any time you want it to be. Admittedly, JavaScript does a pretty good job of doing this sort of implicit type conversion for you, but it can't always guess correctly. And, when it doesn't (or when you suspect that it might not) you should do the conversion explicitly.

Keep in mind that the example you cited (adding an integer to a string) would not work at all in most languages. While JavaScript makes a good guess at what you want, you really should be checking the value for validity (the user might have left it blank or typed in "Bob slept here" instead of giving the integer you were expecting), converting it to an integer with parseInt(document.theform.hours.value,10), and incrementing that.

--MarkusQ

short answer: no

[coaxial]

Javascript will forever be the bastard stepchild as long as there's all the incompatabilities between platforms. Hell, even the standard APIs have different semantics. Until you don't have to code up three version of every function, JS will linger on the edge of respectability.

JavaScript revisted . . . with gladness

[RealSalmon]

I've recently started tooling around with creating some in-house Firefox extensions. They don't really do anything to extend Firefox so much as they are applications in and of themselves. As a result, I've had the opportunity to dive back into JavaScript. I must say, I've been able to get quit a number of things done rather quickly, and the results are easily distributable in a cross-platform format.

With applications such as XULRunner, distribution of JavaScript based applications could get even easier.

One of the things that's greatly lacking for non-web applications though is database connectivity. The things I've worked on so far have had to connect to a web server in order to get anything done with SQL. It still works great, but it would really be nice not to have that extra layer of complexity.

Re:JS is not the problem, the whole environment is

[master_p]

Markup is programming as well.

In order to fully comprehend how a web application works, you need to know all its subsystems, including markup.

Re:JS is not the problem, the whole environment is

[drooling-dog]

Ouch. In a thread about web development, too...

Javascript is the BB gun of Christmas Toys.

[Twixter]

Man is it fun; and useful! But sooner or later, you end up shooting your eye out.

//Create new Human
var human = new Object();
var ass = new Object();
var head = new Object();

//Assign properties to human
human.ass = ass;
human.head = head;

//Elect human to office.
human.ass.head = head;

Perfectly valid in Javascript, and in the real world.

The most amazing thing about JavaScript

[Anonymous Coward]

The most amazing thing about JavaScript is the number of people who don't really use it, but have very strong opinions on the subject.

JavaScript is a very powerful, flexible language. Like any other powerful language, you can get into trouble if you're not careful. Bottom line is, if you can't write good code in JavaScript, YOU can't write good code. It has nothing to do with the language.

Standards?

[Dorceon]

Considering the differences between the implementations, you could say that JavaScript is the most important half-dozen or so almost identical languages on the web.

(Browser as development platform)!=AJAX

[bcrowell]

I have a hard time understanding why I hear so many people complaining about JS as a language. I think a lot of Java programmers don't like it because it's not Java (not strongly typed, ...), and a lot of C++ programmers don't like it because it's not C++.

The truth is that you can do some pretty amazing stuff with JavaScript. My favorite demo is here. It's a web-based calculator, and if your browser has MathML set up correctly, it'll display your equation on the fly, as you type it, in standard math notation. For instance, if you type 1/(2+pi), it displays a fraction bar, with 1 on top, and 2+pi on the bottom (pi rendered as a Greek letter). (I think recent versions of Firefox have MathML and its fonts set up correctly by default, but if not, you can download the necessary fonts (instructions). For IE, you need to install MathPlayer.) What I think this calculator app demonstrates pretty dramatically is how powerful a development platform the web browser can be, without messing with the ugliness of AJAX at all. WYSIWYG mathematics typesetting is the kind of application that people used to pay $100 for ca. 1995, and now it's not only free, it's open-source, and it's an app that you can just run in your browser, without having to install anything.

Re:(Browser as development platform)!=AJAX

[mandelbr0t]

WYSIWYG mathematics typesetting is the kind of application that people used to pay $100 for ca. 1995, and now it's not only free, it's open-source, and it's an app that you can just run in your browser, without having to install anything.

LaTeX + a WYSIWYG front-end whose name escapes me was free and available ca. 1996. It did a very good job with mathematical expressions, as I recall. Of course, that's because LaTeX does a very good job with mathematical expressions. The final product is typically a GIF file showing the equation. LaTeX may be obscure, but there are some good front-ends for it, and there's no desktop publishing app that can even come close today, IMO.

/me worships Knuth

mandelbr0t

Re:(Browser as development platform)!=AJAX

[bcrowell]

LaTeX + a WYSIWYG front-end whose name escapes me was free and available ca. 1996.
Are you thinking of LyX? They call it "what you see is what you mean" rather than WYSIWYG, but you're right, in terms of math editing it does do something pretty similar to the JS program I linked to. Your comment prompted me to download the latest LyX and try it -- I haven't messed with it in a long time. One pretty spectacular difference: downloading LyX via Debian apt-get resulted in 33 Mb of new software being installed on my machine, whereas the Javascript thing for math typesetting has zero footprint on my hard disk, and the size of the JS code is 0.042 Mb. It's not even such an apples-and-oranges comparison as it might seem, because I already had latex installed, so the 33 Mb was just the GUI layer. Another nice thing about the JS approach is that you can use it on a Windows machine, or on a machine where you don't have privileges to install software.

As a programming language,comparable to Python

[Animats]

Javascript really isn't that bad as a language. It's fairly close to Python in capabilities. With a little bit of work, Javascript could grow up to be Python. It wouldn't be a bad thing if the client and the server spoke the same language. Flash and Firefox now have just-in-time compilers for Javascript. Open source, even. Actual machine code gets generated. So performance isn't that bad any more. Javascript's object model, which is borrowed from Self, is rather clunky. On the other hand, variable declaration and scope is better than in Python. Javascript could use Python-like tuples. But it's close enough that, in a future rev, it could catch up with Python.

The Download and Cache issues

[bryanbrunton]

While developing an Ajax application called Grand Strategy, an implementation of the board game Risk, I have found one of my main gripes with Javascript to be the download times involved with using large amounts of it. There are things that you can do to mitigate: gzip compression, displaying progress bars, use short variable and function names, and then caching. There are ways to do dynamic downloading of portions of a library; you can see these in Dojo. However, these dictate that you radically structure your code to support it.

It would be very nice if the whole browser based development environment had mechanisms to deal with the dynamic loading of javascript.

Next we come to the next major javascript issue: the unreliable browser cache. Users of my game will occasionally not be able to log in, or a portion of the game becomes unusable, even after having played the game for weeks on end. Inevitably, some javascript in their browser's cache will have become corrupted, or seemingly partially downloaded.

Re:The Download and Cache issues

[Anonymous Coward]

if your app has a lot of tags to load the js then it will take a while to load as each of these needs a seperate http request to download. i've had the same problem before so I made an ant task to inline all of the javascript in page and download speeds where fine after that.

also an idea to load script dynamicaly would be to request it ajax style from the server and then eval the result. i haven't tried this but can't think off the top of my head why it wouldn't work.

Re:I love the autopointerage & hate the scope

[scotch]

(note that most of JS' features are in some way stolen from other languages)

Wow, that's too bad. Hopefully those other languages can have the police help them get the features back. Or maybe these languages can get replacement features from their insurance company while they wait for the trial? I know that I won't use those other languages until Javascript gives them those features back, so this is truly a tragic day for all those other languages. I speak from personal experience here, when a language steals features from you, you really feel violated and vulnerable. You want to lash out and kill those other languages. Cool heads should prevail though: with proper rehabilitation, Javascript can be made to stop its theiving ways and become an upstanding, productive member of the language society.

Javascript is stupid and...

[Anonymous Coward]

all you ajax people out there thinking this is cool are a bunch of retards. The fact is that this "technology" is just hacked together crap.

I repeat myself again. Javascript and the entire web development stack is seriously broken. Just look at how long it takes to put together a decent, functional website and you will understand. The interaction between all of the components is seriously chaotic at best. The whole OOP in magical web land is more of an OOPS

Re:Javascript is stupid and...

[arevos]

I repeat myself again. Javascript and the entire web development stack is seriously broken. Just look at how long it takes to put together a decent, functional website and you will understand. The interaction between all of the components is seriously chaotic at best.

Perhaps you could give an example of this?

Java Applets == Crapplets

[Anonymous Coward]

Title says it all. A toy programming language used to create a bloody crapplet. That is a crappy, buggy application. All java is good for is as one poster so beautifully stated: quick and dirty prototypes, my emphasis on quick and dirty.

I'm tired of having to download a 150Mb set of libraries, and having to set some bloddy CLASSPATH environment variable. Code should just damn statically link, or have it's libraries in common places. (I'm looking @ you TomCat).

Now I know not many of these points apply to JavaScript, the braindead, hacked-up cousin, suitable for script kiddies testing their mad skillz.

Re:JS is not the problem, the whole environment is

[drew]

Actually, the minimum is 3.
1) HTML
2) CSS
3) JavaScript

JavaScript makes a good^W decent server side language as well. Sure, it's not the greatest language available, but on the other hand it's nice be able to use all of the same libraries/conventions on the server side as you do on the client side, which for some applications may outweigh the benefits of using an otherwise superior language.

As for XML (and the various associated schemas), yuck. I suppose if you were a masochist you would do it that way. Personally, the only time I ever deal with XML is when a client explicitly requests an XML web service. Otherwise I just use JavaScript (a.k.a. JSON) as the transport language as well. Really, though, it doesn't matter one bit what your transport is. All you have to do is write serialize/deserialize functions for both the client and server that agree on a common format, whether it be JSON, XML, or brainf*ck. Beyond that, you never have to look at it again.

And finally, others have pointed this out as well, but I just want to say it again:

3) the non-existent security regarding JS code; anyone can see it.

You have two separate sentences here, and they have nothing at all to do with each other. (Unless by security you are referring to preventing people from stealing and reusing your JavaScript code and not security of the application code, but that's a completely different animal.)

Terminology generation gap, anyone?

[aeoneal]

In the context of this article, which clearly discusses how JavaScript can provide denser code than Java, and compares JavaScript with Java for applications "more commonly associated with Java," his response makes perfect sense.

And just a comment on the "all applets are Java" remark higher in the thread. Really? I was writing applets for PCs, sans any intent for web use, years before Java even existed. I think what we may have here is a terminology generation gap.

Re:Terminology generation gap, anyone?

[rjshields]

In the context of this article, which clearly discusses how JavaScript can provide denser code than Java, and compares JavaScript with Java for applications "more commonly associated with Java," his response makes perfect sense.

It would make perfect sense but for the incorrect use of the term "applet".

You know you're on Slashdot when....

[Bugs42]

...Someone makes a joke like this:

"25,000 lines of Javascript ? What could you possibly be doing which requires that level of Javascript interaction ?????"
document.write('25,000 bottles of beer on the wall, 25,000 bottles of beer. Take one down and pass it around - 24,999 bottles of beer on the wall');
document.write('24,999 bottles of beer on the wall, 24,999 bottles of beer. Take one down and pass it around - 24,998 bottles of beer on the wall');
document.write('24,998 bottles of beer on the wall, 24,998 bottles of beer. Take one down and pass it around - 24,997 bottles of beer on the wall');

And you get a half-dozen responses showing the proper way to accomplish that, completely ignoring the fact that it was in fact a joke.

Re:You know you're on Slashdot when....

[Anonymous Coward]

People with autistic spectrum disorders have difficulty with jokes, cues and social context. You must be new here ;)

Re:You know you're on Slashdot when....

[ignavus]

For the humour-challenged on this thread, there is a whole site devoted to ways of programming '99 bottles of beer': http://www.99-bottles-of-beer.net/

Re:You know you're on Slashdot when....

[Raenex]

The people responding know it's a joke.

prototype.js

[Lothar]

I have one word for all of you: "prototype.js" ( http://prototype.conio.net/ ). The day I discovered prototype.js I stopped hating javascript. It also made me appretiate the really cool ways javascript lets you do inheritance etc + reading the prototype.js code really gets you learning.

If you also use Firebug (make sure you get the latest beta) for debugging then programming web and javascript becomes fun!

With prototype.js the javascript code becomes probably 30-70% smaller. No self respecting javascript programmer should be without prototype.js. It rocks!

Re:prototype.js

[MemoryDragon]

prototype while being cool, has been kicked out of some projects already again, due to the stance of the developers of hijacking language features and important keyword sequences for their own use. it is not funny to have a lib which hijacks the dollar sign or extends a base object of javascript in several ways.

Namespaces will be in ECMA4

[mad.frog]

Namespaces will be present in ECMAScript 4, along with lots of other goodies.

You can track the ECMAScript 4 standards proposals here: http://developer.mozilla.org/es4/

And Namespaces specifically: http://developer.mozilla.org/es4/spec/chapter_12_n amespaces.html

You can try out namespaces right now in ActionScript 3, which was modeled after earlier (incomplete) ECMA4 proposals.

what a pain

[singingjim]

Xerox is developing entire interactive websites consisting entirely of Javascript and my company has been unlucky enough to have to use one of them to access our book cover PDF proofs for approval on a printer's web site. I'm sure they had good intentions, but man, it's such a royal pain in the ass to use. I'm sure they think it's making our job easier, but I for one don't like it. Just let me click a link to download the proof and check a box to send an automated approval email. Waiting for pages to load because they are so unwieldy is not my idea of a good time, or efficient use of my good time either.

Built an entire business application platform...

[holophrastic]

...solely on JScript. 800K of JScript, to be exact. It's not as fast as C, and it's not as fun as Perl, but you get a free rendering engine, free networking engine, and free interface engine out of it. So now, new business applications can be built, from scratch, within a few days: copmletely custom for the client -- layout, navigation, business logic, features, functionality, and security.

But hey, when it comes to JScript, I've found some pretty obscure language bugs.

You can hide instance variables in JavaScript

[Stealth Potato]

You definitely can hide instance variables in JavaScript. You have to employ JS's lexical closures, and it might seem a little odd to someone who's not used to it, but such as it is:

// Constructor for Pie object
function Pie()
{
...// Create an instance variable inaccessible to the outside world
...var flavor = "blueberry";

...// A method of Pie which accesses the hidden instance variable
...this.getFlavor = function()
...{
......// We can access 'flavor' because getFlavor is closed over its environment of definition
......return flavor;
...}
}

var mypie = new Pie();
var str = "I like " + mypie.getFlavor() + " pie!";

(Note: Give me a break, Slashdot! Why no "pre" formatting in code blocks???)

As for classes, it should be noted that JavaScript is prototype-based, which is really a very nice way of approaching OO once you get used to it. There is something of an effort to make ECMAScript more class-based, though, and the next version of JavaScript from the Mozilla guys will include support for classes.

Continuations are not supported as such, but Mozilla's JS 1.7 does include support for generators, which are very nice and can be used to do some of the things you could do with continuations.

developing for a moving target

[freezin fat guy]

The problem with developing Javascript code is that you are shooting at a moving target.

Unless the use is restricted to a highly controlled intranet setting it will be executed on an indeterminate set of runtime environments. Different browser vendors, different versions, different sub-builds... where does the madness end?

Unless you are doing something trivial you can wind up with several times the code necessary to get the job done on any one Javascript runtime. And bug testing? Well that takes far longer than it should for exactly the same reason.

I don't have a problem with the language itself. Or any one interpretation of the language to be more precise. But give me some solid footing.

Beef #2 - is your Javascript accessible to disabled users? Standard response: "F*** the disabled; they're a minority and we all know minorities deserve to be shot and pissed on." As I lack the Satanic vitriol necessary to punish people for unfortunate circumstances I find myself at odds with the Web 2.0 community.

Re:developing for a moving target

[Anonymous Coward]

alert("Got Here");

Well said!

[Anonymous Coward]

This is the first post so far providing the real reasons why JavaScript sucks to program. JavaScript, while (potentially) useful in other environments, is almost always utilized in the web browser environment. In this area, JavaScript is a hack to try to make web pages function like an app. It's a nasty language (or at least I prefer something strongly typed and readable), hard to debug, unit test, and browser implementations vary (probably the worst part). I stay away from JavaScript at all costs, yet I have to use it all the time.

Slow?

[porneL]

If you think JS is slow, you haven't tested Opera's implementation.

Hell No!

[h4ck7h3p14n37]

Hell no Javascript doesn't deserve more respect. Unlike, say Java applets, there's no security sandbox so rogue Javascript code can connect to the network and leak information from the client system.

Re:Hell No!

[franl]

Can you supply some references describing how Javascript code can access the client filesystem? The language has no file I/O constructs, so it must be the browser-supplied library that's allowing that particular security violation to happen, right?

Re:JS is not the problem, the whole environment is

[raynet]

Actually, the minimum is 2. (for dynamic content or user interaction)
1) HTML
2) some programming language

Or you could do with just HTML, eg. writing an adventure game with only HTML isn't that difficult :)

(I still sometimes have to write some webapps for Netscape 3.x *sigh*)

JavaScript is actually pretty good

[SanityInAnarchy]

If there's anything wrong with JavaScript, it's the speed of execution. As far as I know, we still don't have a decent bytecode engine for it, making it at least as slow as Ruby.

Combined with HTML/CSS, it's worse. But actually, XHTML/CSS is the best we've got. Don't get me wrong, I wish we had something better...

And we do have something for rounded corners, drop shadows, and the like. It's called SVG. But I'm not convinced SVG is really any better than XHTML/CSS with transparent PNGs. (Yes, I know what vector graphics is, I'm talking about confusing standards/implementations.)

Re:JavaScript and .Net

[James X L]

I like the fact that JavaScript can be easily integrated with .Net applications. You can practically open a JavaScript interface for your .Net application for free. The only thing you have to do is attaching some application specifical objects. Unfortunately, I have heard that Microsoft will replace JavaScript engine in .Net with their proprietary scripting language. I hope they will not let this happen. JavaScript is not only useful as embedded language in browsers, it is also very useful as a general purpose language as a clean replacement for other scripting language (e.g. those with syntax like $#&{ref}->* etc.).

Of course it should!

[ErGalvao]

Nearly every Web developer has cursed JavaScript at one time or another.

Not me, no, sir... JavaScript, weather people like it or not, is the de facto standard for client-side code execution. It's also what makes AJAX so interesting. Take off the "J" in AJAX and you'll have nothing. Take off the "X" and you'll still be able to work with plain text. It's also important to notice that AJAX wouldn't be so hot without JavaScript's ability to manipulate the DOM of a HTML document.

JavaScript has lots of respect.

[Qbertino]

JavaScript has lots of respect. It has allways been a very modern scripting language, even back in the day when Perl was the only free thing running on the server side and others where still building webapps in VB4 and flash was little more than an extended gif animator or something.
It's the browser DOM frustration that puts people of and takes the wind out of JavaScripts big multi-plattform asset. It allways has. If for once the browserbuilders could get that in line JS would be adopted instantly everywhere. Until that happens we'll have the festering broswerwars constantly breaking JS consitency and pushing off people to Flash/AS, Java and whatever other plugin stuff people decide to toy with. Ajax hasn't changed that. Building neat stuff with JS (aka "Ajax") has allways sucked - even back in the nineties - and will continue to suck for quite some time. Growing JS ("Ajax") Frameworks that try to tackle incompatabilites with sheer truckloads of code only work as far as the JS engines don't buckle under the load. Open a few tabs and start a egroupware or some Google RIA app in another one to see what I mean.
Unless we finally get some OSS RIA capable plugin (XULRunner, Gnash or whatever) JavaScript won't be able to show it's full potential. I don't see MS teaming up with Mozilla to build a unified JS engine anytime soon. ... Now that Java is fully open sourced I'm not holding my breath anyway. Could be that Java finally takes on in the RIA ballpark and causes Flash and Co. some real heat. Would make things interesting again.

Re:JS is not the problem, the whole environment is

[Anonymous Coward]

Realizing is half of the solution, and I agree fully with all your remarks.

The solution is within reach. Try echo2 (java) or Wt (c++) and you will find what you seek: one language that is clever enough to make abstraction of all the web idiocracies tolet you create web applications like any other GUI application (with a little more effort to have proper client-side event handling if you care about latency -- like stateless slot implementations in Wt).

Re:JS is not the problem, the whole environment is

[Anonymous Coward]

I even remember some people telling me that POST request is more secure than GET since client can see contents of GET request in URL. These people worked for serious web company, btw. I'm afraid that Security through Obscurity is still the way most people see it...

Wrong rationale, wrong attacker, but their conclusion is right - POST is more secure than GET. Consider sites that put a session ID as a query string parameter, and consider a user pasting a URL into a message board. Nothing sensitive should ever be in the URL.

Of course, from their flawed rationale, I'm sure they're doing something else horribly wrong. If the user seeing the parameter is a problem, then maybe they should be sending it to him...

Javascript is like Basic.

[liftphreaker]

Javascript is like Basic - they both do the job in a quick and dirty way, and both encourage bad programming practices.

Re:JS is not the problem, the whole environment is

[smellotron]

I even remember some people telling me that POST request is more secure than GET since client can see contents of GET request in URL

POST is more secure than GET, but not for that reason. The reason is because POSTed data does not get logged. Imagine a perfectly secure website that accepted credit card numbers. If those numbers were recorded on the server side as "GET /form?card=4111111111111111&exp=0909&cvv=211", then all of that security can be defeated by anyone who can access a logfile.

This is similar to "cookieless session" capability of PHP, to inject "PHPSESSID=092348sdf0923ksjdk" or whatever into forms and hyperlinks, so that GET parameter would save a session. It's bad because it puts sensitive data in the URI.

Yes, I know you can configure servers to log POST data, but it's generally a bad practice (because of the privacy concern) and certainly is not on by default on any web servers I've seen.

Comment removed

[account_deleted]

Comment removed based on user account deletion

javascript should be buried deep, asap

[Anonymous Coward]

It's essentially a Microsoft mechanism to make Internet IE-only. It has no other valid purpose and no-one should use it for anything. Ever.

It should be buried into deepest pit in Hell and anybody who invented it with it.

Lisp called. It wants its closures back.

[SimHacker]

Yes, it's tragic. After JavaScript stole C's syntax, all my CPP macros stopped working. And Lisp has been an extremely weak and difficult language to use, ever since JavaScript stole its closures. But at least Lisp still has its macros and parens left.

-Don

I swear to all the dieties that

[Tablizer]

....JavaScript has only one error message: "Invalid Object". No matter what error you or anybody makes, it is always this.

Re:For simple page stuff, it's hard to beat

[cortana]

If you come from a standards point of view, call it ECMAScript. That's the language's official name; JavaScript is the name of Netscape/Sun's implementation and JScript is the name of Microsoft's.

If you come from a historical point of view, call it JavaScript because that is the original language created by Sun and Netscape; they later submitted a subset of the lanugage to ECMA to create the ECMAScript standard, and Microsoft embraced and extended JavaScript to create JScript.

Re:JS is not the problem, the whole environment is

[orclevegam]

Your count is a little off on the languages. First off, HTML, CSS, and XML are not programming languages, they are markup languages (that's what the M in HTML and XML stands for). Secondly, HTML is a subset of XML (or at least XHTML is), so really XML/HTML should be expressed as XHTML, however as previously mentioned these arn't programming languages, so they can't be lumped into the same category as ECMAScript (or JScript/JavaScript is you prefer). The breakout of XHTML, CSS, and ECMAScript is actually just right, as this lends itself perfectly to a MVC model, in which the XHTML is your model, CSS is your view, and ECMAScript is the controller. Now, this is of course all on the client side, when you go to the server side there's another issue, but this is a advantage not a problem. If you wish to use only ECMAScript for development, that is of course perfectly possible, all you need to do is install one of the ECMAScript based application frameworks such as Cocoon (which admitedly also uses XSLT, but for most things the default XSLT files should suffice). So to summarize you really need to know 2 markup languages, and 1 programming language in order to write a web-based application, plus the associated APIs for any libraries or environments you wish to write in. You need to know, XML, CSS, and ECMAScript, with the XHTML and DOM APIs as well as the IE and W3C APIs. On the server side you have a ton of possibilities, and the choice is really more of personal preference. In my case, I'm a Java developer, so I tend to lean towards Java. However even in that I don't do pure Java as I usually use the Spring framework, so I also need to use XML for my dependency injection, and the property file format for my configuration constants.

Huh ?

[Kitallis]

Hell no JavaScript doesn't deserve more respect. Unlike, say Java applets, there's no security sandbox so rogue JavaScript code can connect to the network and leak information from the client system. JavaScript is only a scripting language, for the Host environment dude. You want a scripting language to steal network information ?!! Laughs

Links

[Anonymous Coward]

Here're some really good links about JavaScript:

http://www.crockford.com/javascript/

http://javascript.crockford.com/javascript.html

Clubbing server-side Java and client-side JavaScript is also something interesting:

http://getahead.ltd.uk/dwr/