Should JavaScript Get More Respect? 439
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."
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: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...
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.
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 (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 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
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.
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 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.
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!
Server-side JavaScript (Score:5, Interesting)
Re:Dense != Good (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 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,
As much of a pain as writing verbose code can seem at times, it certainly does have its merits.
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:JS is not the problem, the whole environment is (Score:1, Interesting)
This degree of seperation is beautiful. I wish it was that easy for client applications too.
Personally I think it's a pretty cool language (Score:5, Interesting)
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.
what a pain (Score:1, Interesting)
Re:Dense != Good (Score:3, Interesting)
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:
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.
Built an entire business application platform... (Score:2, Interesting)
But hey, when it comes to JScript, I've found some pretty obscure language bugs.
Hell No! (Score:3, Interesting)
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.