Slashdot Log In
Should JavaScript Get More Respect?
Posted by
kdawson
on Wed Dec 20, 2006 04:39 AM
from the ugly-duckling dept.
from the ugly-duckling dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
JS (Score:5, Interesting)
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 (Score:4, Insightful)
Parent
Re: (Score:3, Interesting)
The uppercase 'A' should be enough of a hint as to why I went with that particular label
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 te
Re: (Score:3, Insightful)
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
Re: (Score:3, Funny)
Re:JS (Score:5, Funny)
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
Parent
Re:JS (Score:4, Funny)
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.
Parent
Re:JS (Score:4, Funny)
Parent
Re:JS (Score:4, Funny)
Parent
Re:JS (Score:4, Funny)
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?
Parent
Re:JS (Score:5, Funny)
tellJoke();
}
catch(JokeException e)
{
printf("joke wasn't funny");
}
Parent
25000 lines: (Score:4, Funny)
Parent
Re:JS (Score:4, Informative)
Granted you do try keep the sizes down but in some cases especially and EPG you do end up writing lots of code.
Parent
Re:JS (Score:5, Informative)
Parent
Re:JS (Score:5, Informative)
Parent
Re:JS (Score:5, Funny)
1000 lines of application code, and 24,000 lines of browser compatibility code.
Parent
Dense != Good (Score:5, Insightful)
"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 (Score:5, Funny)
By that standard APL would be hard to beat.
Parent
Re:Dense != Good (Score:5, Interesting)
But Javascript is no where near 10x as "dense" as Java, http://www.theadvisors.com/langcomparison.htm [theadvisors.com] 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...
Parent
Re: (Score:3, Informative)
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", an
Re: (Score:3, Interesting)
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 co
Re: (Score:3, Insightful)
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 t
Re:Dense != Good (Score:5, Funny)
The irony of this is so elegantly compact I am concern a singularity may form around the vacinity of this article.
Parent
I love the autopointerage & hate the scope iss (Score:5, Informative)
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: firstly the reference to
sticking with arrays you can grow and shrink them with little to zero fuss: 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 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 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 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
Re:I love the autopointerage & hate the scope (Score:5, Informative)
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:
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.
Parent
Re:I love the autopointerage & hate the scope (Score:3, Interesting)
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 the
The language is fine, but it's got baggage (Score:5, Insightful)
Javascript is nice... the problem is... (Score:3, Interesting)
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.
Too Hard to unit test (Score:3, Insightful)
Me too (Score:3, Interesting)
JS is not the problem, the whole environment is. (Score:5, Interesting)
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!
Re:JS is not the problem, the whole environment is (Score:5, Interesting)
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!
Parent
Re: (Score:3, Insightful)
Dear god no. (Score:3, Insightful)
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|
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?
Daft story title... (Score:3, Insightful)
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.
Javascript might have a future, but.. (Score:3, Interesting)
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.
Server-side JavaScript (Score:5, Interesting)
Needs a Concatenation Operator (Score:5, Interesting)
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: (Score:3)
All in all, it's really a very minor issue.
Personally I think it's a pretty cool language (Score:5, Interesting)
(Browser as development platform)!=AJAX (Score:5, Insightful)
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 [chapman.edu]. 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) [lightandmatter.com]. 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.
The Download and Cache issues (Score:4, Interesting)
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.
prototype.js (Score:4, Insightful)
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:Why the pressure ? (Score:4, Informative)
Parent
Re:Why the pressure ? (Score:5, Insightful)
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.
Parent
Re:Disagree (Score:4, Insightful)
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.
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.
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.
Parent
Re:Yes, but Javascript is a bad language. (Score:5, Informative)
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:
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)
Parent
Re:Yes, but Javascript is a bad language. (Score:4, Informative)
Parent
Re:Security is a problem (Score:4, Insightful)
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.
Parent
Re:JavaScript is wonderful (Score:4, Insightful)
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.
Parent