This post originated from an RSS feed registered with Python Buzz
by charlie s.
Original Post: Javascript, "The Next Big Mistake" ?
Feed Title: Ignorant Views on Software and Other Things
Feed URL: http://ovsot.blogspot.com/feeds/posts/default
Feed Description: My stupid views on programming you probably dont want to hear and shouldn't listen to anyway.
I've heard tons of buzz lately on how Javascript is going to replace every programming language ever written , how server side javascript is going to be the next big thing, how NoSQL is going to forever change the world.
After working in a pure javascript stack for the last 8 months, using MongoDB ( javascript scripted / json document storage ), NodeJS ( server side javascript using the V8 engine ) , and ExtJS ( client side UI library ), I pray they are wrong.
It's not any one of these technologies in itself are bad ( NodeJS is actually blazingly fast, outperforms .NET by factors of 10 on an amazon EC2 instance with [ seriously ] 256K of memory ), but take a bunch of bleeding edge software technologies and tie them together with possibly the worse scripting language ever written and what you get are headaches.
Take for example a bug I hit recently, where I call from Node ( which uses V8 as it's interpeter ), into Mongo ( which uses Spider Monkey ), calling what is the equivelant of a stored procedure , passing it a callback that executes within Node ( back to V8 ), and my this pointer completely vanishes. I have lost all scope besides global.
Node is very proud of it's asynch approach to programming, and at times it feels very nice. At other times it's a horrible blight on the world.
Most of the problems revolve around asynch functions and recursion. Or for loops, those are also a pain. The recursion problem is actually not so bad because there is an agreed upon way of handling it, albeit an ugly one, involving a counter that increments everytime the function is called, and decrementing the counter after the function call, and when the counter returns to 0 you call the callback function.
But the ugliest by far is the for loop with asynchronisity. Let's say you have to loop over a collection, call an asynch function that modifies the element in the collection, then after all the asynch calls have finished, respond to the client. As far as I have found there is no agreed upon paradigm, mostly it revolves a forever loop that waits for some condition ( count == finalList.length , where count gets incremented before the asynch call ), and then when the condition is met, call your user passed in callback.
Is Javascript going to take over the world ? You better hope not.