Javascript, "The Next Big Mistake" ?

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.

Hash tagging your code, but is it a good idea ?

The finished product, http://thecodebase.com/bang/ .

I started hash tagging my comments on the project I'm working on, doing things like

// Refactor this to use inheritance !charlie

// Rewrite this once we know for sure that we won't need to edit the workflow !frank

Then, to see what I had left to do, I would grep for them

grep -rin '!charlie' .

And when frank came on board to the project, he could grep for '!frank' to see what I needed help with.

I preferred this over creating tickets, mostly because I'm lazy, and I don't want to login to some website, fill out a bunch of fields.

But also because I think these things don't belong in a ticketing system. What I was tagging was very code specific, it wasn't a vague intermitent problem, it was concrete code related problems.

"I need help your help with this". "Fix this before release 1".

I finally got motivated to write a script that would parse these out, and because I was all javascript on this project ( node + extjs + mongo ), and I had another project I was using python on, I decided just to make it support both languages. The result is http://thecodebase.com/bang/ , a python script to parse them, and node+extjs to make them all pretty like.

I showed this to friends , and friends of friends, and here are some reasons why they thought it was a bad idea.

• I already have a ticket system, I don't want to look in two places
• Why is this better than //TODO that my IDE already highlights ?
• //TODO's and //FIXME's are just wrong and you shouldn't use them
• Charlie you're an idiot stop talking to me

For me, I didn't want full fledged tickets. And I didn't really use what we had anyway, its much easier for me to type 'bang' and get a list of things to do.

And this was born out of //TODO's. The problem I was having was that it was just a random list of things to do. If I was in the mood to work on 'refactoring', i'd have to go through and read all of them to get to the refactoring tasks. With bang I could categorize them. Sort them by priority. See if I could help !gnovy with his !ui stuff.

For some people "ticketing" systems is mostly a management tool, more tickets makes it look like your code sucks. And I have worked at companies like this, it's stupid, but it happens. But as a result they didn't really have a place other than //TODO's to report things that needed doing.

But the larger idea of commenting the source code to keep track of what to do being bad practice is still a question . On the one hand, I can see it being bad in that if you see a problem with the code ( a //FIXME ), you should fix it. Don't make a comment, fix it.

On the other hand, what if I just found a bug before leaving for mandatory meeting X. I don't want to go update the ticket, I don't have time. I comment it, and come back to after this worthless meeting. And there are other things besides FIXME's. For instance some of my code dealing with workflow was getting just way too complicated, but other things were still in flux, I didn't want to dedicate time at that moment to refactor it, but I knew it had to be done eventually, so I tagged it, completely intending to refactor it when decisions were finally made regarding the business logic.

And eventually I did refactor it. Because I had tagged it, and I got tired of it staring me in the face all the time.