I use to hate Javascript. I attempted to build a large enterprise system using ExtJS... I ran into a number of problems. I then realized that I could accomplish the same task using GWT/GXT. It was successful. I still don't like Javascript, but I'm warming up to the idea of embracing it.
It seems to me that with the advent of Node.js and document oriented databases that use JSON for their document description, such as MongoDB, Javascript will become the world's most used language. I think Javascript's momentum is unstoppable.
JavaScript really doesn't seem appropriate for large software. Much of the features (like, for example, prototype inheritance) makes for small code but at the cost of some complexity. Even trying to ensure some measure of public/private data requires a lot of boilerplate code.
Probably adding the necessary features to JavaScript to make it more appropriate for these tasks would ruin it for the things it's really very good at.
I disagree, regarding JavaScript's ability to scale. It is quite easy to implement classical inheritance inside JavaScript, public and private methods really do not seem like a must have to me for code to be 'scallable'. It seems to me that these concepts are loosely enforced (or not present) in many popular web languages already.
Enforced privacy limits reuse but doesn't prevent any particular class of bugs (calling random private methods is no worse than calling random public methods; you should feel equally bad about both).
Prototype OO precludes introspection. You have "an object", and that's as much as you can ever know.
You're looking at enforced privacy from the callers perspective not the callee perspective. For the callee, the benefit is you can change or remove any private methods or private data structures and be guaranteed not to affect any callers. It's the benefit of basic encapsulation.
Although I completely agree with you about Prototype OO it doesn't necessarily preclude introspection. You can find out what kind of object it is (by looking at the constructor property) and you can iterate the methods and properties. Introspection is not a problem. But there are no guarantees -- if you find out that your object is a "bicycle" there is no guarantee it has a "pedal" method even if it had one on creation.
Yeah, for my personal website I'm about to try out node.JS with MongoDB -- I think it will be an exciting experiment. As more frameworks grow up around technologies like these, I really think server-side JavaScript makes a ton of sense -- most importantly, it can lead to a lot more sharing of application logic between the static and client-side JS parts of a site.
JS is not perfect but is good enough. It is everywhere and will be used everywhere in the future, from browsers, to servers, mobile, etc.
Maybe it will be perfected as new versions come along. We should push in that direction if we feel there are rough spots right now.
I've learned to love it. I wish there is JS hosting solutions as simple to run as php for newbies. Remember the first one giving such a service, appjet, was bought by google by millions. There is market for JS on the server.
There is market for JS on the mobile world too. APIs are wonderful, see all you can do with canvas, svg, websockets, etc. all managed thru JS and you can do wonders with them.
If the whole iPhone/iPad experience could be accessed using JS apis, it would grow the ecosystem by tenfold. I hate objective C, but I could easily build a thousand apps in javascript overnight. No kidding.
As I've said here before, it turned out to be a great stroke of luck for us all that Eich had recently read SICP when he was handed the job of making Livescript. Sure, the pieces that made it in may be mangled and half-digested, so much so that it took 10 years before people were able to even recognize them, but enough of the original greatness survives that amazing things are possible with JS. Imagine if he had been infatuated with, I don't know, Ada instead.
Edit: "it took 10 years before people were able to even recognize them" isn't quite right. It would be better to say that it took 10 years for people to reassemble the pieces that were left, like a vase from antiquity or one of those fragmented biblical codices.
Some of the server-side JavaScript stuff is really slick. APE ( http://www.ape-project.org/ ) runs JavaScript on the server-side, for instance. You basically write a client and server in JavaScript and it uses Comet to push events to the client, rather than a JavaScript client needing to constantly request updates -- a great paradigm, that could lead to much more robust multi-user JavaScript applications.
Has anyone here had experience actually using Helma? How does it compare to other general-purpose code frameworks?
I had it downloaded about a year ago and made a few toy projects, but nothing serious enough to really give it a proper workout. (And I don't have a VPS to actually launch anything on...)
I've been in love with JS ever since I started with it in '06. Learnt about closures, prototypes etc all through it. Loved the FP side of it so much that I went and read SICP as a result of that.
On a side note I recently wrote up a sliding puzzle in JS as a pre-loader for Cadmus. Might not be as complicated as the Tetris game but it was fun to write (and test).
JavaScript has probably become my all time favorite programming language (beating Common Lisp and PostScript).
I wonder if anyone has done an OS command line shell with JavaScript as the scripting language - having commands pipe JSON to each other could be rather cool.
Lots of people have. Unfortunately they all have different APIs, which we've been trying to fix with the CommonJS project: http://commonjs.org/
Personally I work on Narwhal (http://narwhaljs.org/). All of Cappuccino's (http://cappuccino.org/) build tools are written in JavaScript (and Objective-J) using CommonJS APIs now too.
Yeah - I've used PowerShell a lot and while it is a nice idea I sort of find the overall experience less good than it should be.
For a bit I was doing a fair bit of PowerShell scripting and bash scripting at the same time and I ended up concluding that I still preferred the Unix command line. Using JSON as the "standard" data format would seem to me the ideal compromise between delimited lines of text (Unix shells) and full blown objects (PowerShell).
I've completed a simular "conversion" myself recently.
After reading "JavaScript: The Good Parts" and with the arrival of things like Node.js I have come over from being a staunch "C as a first language" programmer to learning to not only accept JavaScript, but to embrace it, and the power that comes from becoming proficient in the only programming language understood by both the web browser and server.
I recently had an epiphany about JS too. I think Crockford's evangelizing and the maturing of libraries (especially jQuery) has awoken many to the fact "JS is what we got to program the client". (I just met someone today at the jQuery conference from FreshBooks.)
For all the positives of JavaScript, I still prefer Python. There are a lot of similarities, but I give Python higher marks in a few areas. The first one that jumps out immediately is the lack of requiring "var" in Python variable declarations. What I'd like to see instead I think is Python built-in to every major browser as a default language. And/or make it super easy for users to install runtime plugins for Python, Ruby, etc. that way we're not limited to a particular language in the browser client.
i can't reassign a variable in an upper context. i can mutate the object it refers to, but i can't reassign the variable right there. instead it gets instantiated at the current level.
that's why javascript has "var". it has real lexical scoping.
IIRC python 3 has the "nonlocal" keyword to "fix" this mess, but i'm not pleased by that. i read the PEP and understand their reasoning. still, it's different behavior from what other languages do (notably scheme and js). they can't even make proper lambdas, but that's because they painted themselves into a corner with the syntax.
a freeform mode for python might solve the lambda issue... but then we'd have ruby or javascript, pretty much.
what tips the scales for me (i use python most) is libraries and environment. javascript doesn't yet have a real command line scripting experience. microsoft's windows scripting host and jscript come close, but all the library documentation is scattered throughout MSDN. i much prefer python's HTML documentation. it's terse and easy to browse.
Yeah, I don't get the recent Javascript love-fest when Python and Ruby (heck, even Perl) are tremendously superior. Mainly due to lacking insane design decisions like default global scope and having standard libraries that are actually useful. I mean, did it not occur to anyone that a language heavily used for processing user input might benefit from String.trim? And you'd think a language built on key-value pairs would come with a hashtable object.
Yes I'm probably ranting; I've spent a large portion of the last 12 hours writing a bunch of Javascript that I really shouldn't have had to.
I think the only real restriction is that you can't use arbitrary objects as keys - only strings or things that easily convert to strings (such as numbers).
I bet as soon as you attempt to implement a DOM manipulation standard for Python you'd introduce all the same cross-browser incompatibilities as Java has. Also, in many ways Javascript is superior to Python. Closures are the only examples I know of off the top of my head.
Python has as much support for closures as javascript. The only significant feature in this respect that it is missing (that I am aware of) is multi-statement, in-expression lambdas.
Javascript's syntactic nicety is higher there, but on balance I think python's is far superior.
Last year my Languages instructor mentioned that there was some problem or incompleteness with closures in Python because Guido didn't want to fully implement it or something. Perhaps I'm mistaken.
It seems to me that with the advent of Node.js and document oriented databases that use JSON for their document description, such as MongoDB, Javascript will become the world's most used language. I think Javascript's momentum is unstoppable.
Time will tell.