Node.js and MongoDB Turning JavaScript Into a Full-Stack Language

Nerval's Lobster writes "For all its warts and headaches, JavaScript has emerged as the lingua franca of the modern Web, arguably second in adoption only to HTML itself, which obviously is just a markup standard rather than a full-fledged programming language. It's effectively impossible to launch a sophisticated Web project without making extensive use of JavaScript and AJAX dynamic loading. That's precisely why recent projects that move JavaScript beyond its usual boring domain of defining in-browser interactivity are so interesting — because it's already dominant, and growing even more so. Writer and software developer Vijith Assar argues that Node.js and MongoDB are turning JavaScript into a full-stack language. 'In the grand scheme, Node and Mongo are still quite new; for the most part, ace JavaScript developers who can write brilliant code on both sides of the request transaction have yet to emerge,' he suggests. 'But if and when they do, the things they build could be jaw-dropping.'"

Comments

Citation Needed

[casings]

In the grand scheme, Node and Mongo are still quite new; for the most part, ace JavaScript developers who can write brilliant code on both sides of the request transaction have yet to emerge, but if and when they do, the things they build could be jaw-dropping.

Can any real developer explain why having a javascript backend would be any different to any other backend in such a way where something jaw-dropping could only be the result of the javascript backend?

Re: Citation Needed

[Lunix Nutcase]

And that is "jaw dropping" how? You can already do that with several languages and nothing is remotely "jaw dropping" about it.

Re: Citation Needed

[sribe]

Can any real developer explain why having a javascript backend would be any different to any other backend in such a way where something jaw-dropping could only be the result of the javascript backend?

The quote that you referenced is pure hyperbole--in fact, it is bordering on bullshit. There's nothing a javascript backend can do that a Ruby, Python, Perl or whatever backend cannot. However, it sure would reduce cognitive load to not switch languages between browser and server ends. Personally, I've always liked Ruby (and Python before it) very much, and I like Ruby on Rails. But I'm watching node.js for this very reason--no matter how elegant RoR wraps up the process of sending dynamic javascript over to the browser for execution, it's still butt-ugly and an all-around pain to be switching between two languages, especially on such a small scale. It's not like when I switch from web dev one day (or preferably, week) to native client--sometimes it's Ruby for a minute then javascript for a minute then back to Ruby. Anybody who thinks that is not affecting their productivity is just not paying attention ;-)

Re: Citation Needed

[iggymanz]

but how are the node.js libraries in terms of maturity and completeness for most business or media or forum tasks?

Re: Citation Needed

[Spy Handler]

Having a javascript backend would allow you to create jaw-dropping UI such as cool sliding divs and flashing banners... on the server console! No more boring command line text.

Re: Citation Needed

[marsu_k]

Anecdotally (having worked with node.js for the past year or so), whenever I've needed to do something not available in the core libraries, there has been an npm for it, usually several. But - and this is a rather big but - their maturity can vary quite a bit. The biggest issue really is documentation, that can be incorrect or completely out of date. Yes, there always is the source, but that's hardly ideal.

Having said that, in general I do like node.js. It takes some time getting used to and you have grasp Javascript well in order to use it efficiently, but if you're working with JSON data (we use CouchDB) it's quite a natural fit.

Re: Citation Needed

[oh_my_080980980]

LMOL yeah there's no dependency...try the Browser engine.

Re: Citation Needed

[kwerle]

I was speaking to a friend of mine the other day, who said "Don't you find it bizarre that Javascript has become the assembly language of the web?"

And that's just it: I think javascript sucks, and I avoid it whenever possible. Instead I use CoffeeScript, which I find unobjectionable. Sure, it "compiles" into javascript - and I don't much care.

I pointed out that I never really learned assembly when I was cutting my teeth (decades ago), and so I really didn't care what was down there. It's kind of nice that I know enough Javascript to debug tricky issues when the need arrises.

I thought that coding in assembly sucked, too - still do. The higher the language, the more I tend to like it. Besides CoffeeScript, I'm keeping an eye on Dart.

So, yeah, it's bizarre that javascript has become the assembly of the web world. But it runs all over the place because it runs all over the place. Whatever. As long as there's something better to write code in than javascript, it doesn't bother me...

Re: Citation Needed

[Aaden42]

However, it sure would reduce cognitive load to not switch languages between browser and server ends.

Personally, I find that cognitive load (or since we're talking about the web, perhaps a "cognitive refresh") to be a valuable thing when jumping tiers. There are things that must inherently be done differently depending on if you're on the remote client or local server. Access to data has vastly different cost, security expectations of the runtime change, consistency of the runtime environment (and thus how close to the "edge" of the environment's capacities you can target) change between a reasonably well controlled server environment and Aunt Tilly's IE6 install.

I find that needing a moment to shift gears when moving between tiers helps recalibrate my mindset about the target environment. It helps keep me from doing (as) stupid things that while standard practice on one tier (and thus in one language) are unacceptable on another tier. The difference in language is a bar to code reuse (which is a good thing with code that *shouldn't* be reused in the other environment), and it tends to reduce the frequency that I shoot myself in the foot.

Re: Citation Needed

[oh_my_080980980]

Nothing and there is/was Server Side JavaScript. Netscape developed it.

Re: Citation Needed

[LordThyGod]

But if you're going to pick a single language to be used by everyone for all purposes, then why pick something kludgy like JavaScript?

Because there isn't one? How many languages run in all web browsers, have a native database implementation that scales, and a server side language.

Re: Citation Needed

[hackula]

Totally BS. I use node.js in every production product, so do not get me wrong, I love it. However, node happening to have the same language as the front end is an outrageously bad argument for it. Also, "ace JavaScript developers who can write brilliant code on both sides of the request transaction have yet to emerge" is dead wrong. There are plenty of people using node.js as a production environment, and many of them are amazingly talented at front end development as well... just like RoR, PHP, .Net, Java, or any other server side platform. The strength of node, or any other language, is in the community that forms around it. .Net and Java would be terrible if they did not have a community of people building RAD controls, PDF manipulation libraries, and M$ integration libraries (common needs for the business community). RoR would suck if it was not for the huge community of people building start up web apps with similar infrastructure and design requirements (heroku sprang up out of this culture, I would argue). Node's community is still forming, but I would say it has a strong commitment to performance, high concurrency, and an embrace of a unix-y module system (see npm) that is clearly a reaction to giant frameworks like Rails and ASP.Net. It is not for everyone, and I recommend people all the time to check out Rails instead if it fits their needs better. For me though, node has been awesome over the past few years, and works for me and my company.

Re: Citation Needed

[hackula]

I recommend you read David Crockford's "Javascript: the Good Parts". JS nowadays is not like it was in 98. Today it feels like a flexible and powerful blend of oo and functional programming, that works really well, as long as you stay reasonable.

Re: Citation Needed

[PhrostyMcByte]

That was clearly hyperbole, though node.js does have one interesting attribute that deserves some praise: It was designed from the start to support only asynchronous I/O. Basically, it was built for maximum scalability in the embarrassingly parallel environment it is meant to service.

The form of async Node.js supports isn't anything special. It's been around in many languages for a long time, and in fact there are some far more performant implementations as well as some far better models (like C# 5.0) which make node.js look like spaghetti code. The unique part is that by emphasizing async right from the get-go, all the stuff that is built on it supports async as well. One of the most difficult things about using async in say C++ or C# is that 99.9% of the existing libraries do not properly support it. Async begins to fall apart if you block too much, and you're basically forced to unless you want to rewrite all these supporting libraries.

But, it's still Javascript. Who wants to write a complicated app in Javascript? It's a pretty terrible language. And so I won't be using Node.js for anything in production, but I suppose it does provide a quick point for web devs to jump into writing backend code without needing to learn a new language, so I can understand its popularity.

Re: Citation Needed

[Bengie]

I can transparently run C/Python/etc on MongoDB?!

The point is MongoDB is queries via REST which is native to Javascript, it returns a JSON result, which is transparently handled by the Javascript Middle-tier, when then passes it along to the client, which also runs Javascript.

No Other language(that I know of) can lay claim to a "full stack", like that.

Re: Citation Needed

[curunir]

There are a couple of advantages.

For one, the ability to run the same code on the server and client can be very useful. A number of years ago, I remember a presentation on GWT (framework for writing client-side code in Java) where the presenters mentioned that their app would benchmark the client and, when the client's DOM manipulation wasn't fast enough, would use an AJAX request to do the manipulation on the server and pass it back as HTML which was put into the document using innerHTML. In both cases, the exact same source code was executed, but they had the flexibility to run it in both contexts.

Also, using the same languages allows you to minimize the frameworks and technologies you use, making it easier for developers to know them in depth and making it easier, in general, to find developers. You also get a lot more organizational flexibility when developers can be assigned to either front-end or back-end tasks or even hybrid tasks that would otherwise require two different developers with separate skill sets to complete.

Node has been very successful thus far by making use of one important observation...the majority of applications spend most of their time waiting for things (mostly IO) to complete rather than actually doing something. This allows it to use a language that is still, by comparison, dog slow and still be faster than implementations in other languages when implementing most problems. The thing about functional languages like JavaScript is that they're ideally suited to the asynchronous style of programming where every call takes a callback and completes immediately. But functional languages don't seem to get used server-side. There is some Erlang (WebMachine and Riak are awesome at what they do), but most server-side languages are OO and make it very difficult to do this sort of asynchronous programming in a way that feels natural to the developer.

The problem with Node taking over the server side is, as mentioned, JavaScript is still dog slow. There will be times when your bottlenecks are computational and not IO. The Node answer to this is to drop to C/C++, but how many JavaScript developers can do this? Still, no matter what you think of JavaScript as a language, Node.JS is asking some very interesting questions about the nature of server-side programming and which optimizations are most important. Dismissing it because of the toy language it uses is a mistake.

Re: Citation Needed

[The Cat]

Computational Javascript code is approaching C-speed.

BULLshit.

Re: Citation Needed

[kwerle]

Some higher level, less nasty thing (C, CoffeeScript, Dart, Java, Clojure, whatever) gets compiled into something (asm, javascript, bytecode) that runs on your chosen platform (x86, ARM, web browser, node, JVM).

The assembly equivalents in this case are ASM, javascript, bytecode.

Sure, javascript is a high level language. Someone once thought of assembly as high level when compared to machine code.

It's pretty easy to think of bytecode as the assembly of the JVM. Not much of a stretch to think of javascript as the assembly of the web, if you think of it as a crappy low level language that you'd rather not deal with - which I do.

Maybe that's just my tastes and vivid imagination...

Re: Citation Needed

[lennier]

ter-rif-fic, adj.

3. Causing terror or great fear; terrifying: a terrific wail.
4. Very bad or unpleasant; frightful: a terrific headache.
Latin terrificus : terrre, to frighten + -ficus, -fic.]

The American Heritage® Dictionary of the English Language, Fourth Edition copyright ©2000 by Houghton Mifflin Company. Updated in 2009. Published by Houghton Mifflin Company. All rights reserved.

Seems perfectly standard to me.

Re: Citation Needed

[Dynedain]

You could code everything in one language?

And that is "jaw dropping" how? You can already do that with several languages and nothing is remotely "jaw dropping" about it.

What languages are those praytell? I've been doing web development for 17 years and would love your insight.

Java - requires browser plugins and runtimes. Doesn't have easy DOM manipulation
Actionscript - requires Flash plugin. Server-side doesn't really exist outside of Cold Fusion. No DOM manipulation without involving JS.
C# or VB - IE with ActionScript only, or requires Silverlight.

Running the same code (not just the same language) on both the client and server can add so much simplicity. I've been prototyping a web app using Meteor, a framework that runs on Node.JS and MongoDB. One of the coolest features about it is that automatic data syncing between the client and the server give you AJAX functionality for free. Something changes on the server, the client automatically updates, and visa versa, all without having to write a single send/receive/callback function.

As long as your visitor has a JS-enabled browser, you're set and all the dependencies have been taken care of.

Re: Citation Needed

[sjames]

Because code generated by a compiler tends not to be human readable and the instant you make even the tiniest change directly in the object code, the source becomes useless.

That doesn't make compiling bad, but it does mean that the source language and compiler becomes a dependency.

Re: Citation Needed

[Xest]

I have some reasons:

1) You say stop trying to use it like an OO language yet the language supports OO features badly. It wants to support them but then people say it has shit support, if a language has shit support for something such that people say don't use it then yes it's a shit kludgy language

2) If you don't prefix a previously unused variable it goes into the global scope. What. The. Fuck. Why in a code block like a function would you ever want a variable to become global by default? This is kludgy, it would've been better to only go global if you explicitly declare global.

3) It tries to simplify things but this often makes things harder. You have no option to pass by reference or value explicitly so when you try to do something like pass a loop variable as a parameter to a binding and want to explicitly pass by value it passes by reference and captures the variable retaining it long after it's gone out of scope naturally. You have to use the most god awful syntactically ugly kludgy hack of creating a new scope to force the variable to be copied by value.

4) Usage of new is so bad the expert advice is often just "don't use it". This is a relic of the fact that Javascript wants to be both OO and Prototype based and utterly fucking fails at the former.

5) Semi-colon use at line endings is optional, except when it's not. This causes all sorts of debate as to when you should and shouldn't use them and results in newbies having buggy code because of the utter confusion caused by what in most other languages is a pretty fucking simple rule - end your lines with a semi-colon. Again, the language trying to be smart causing more problems than it solves.

6) Javascript doesn't have real arrays, just objects. Except it's defenders keep telling us we shouldn't treat it as an OO language despite one of the most fundamental data structures in existence being implemented as an object.

7) parseInt's default radix handling is counter-intuitive and fucks people up because it parses for example numeric strings in a way people would least expect by default.

8) typeof NaN === 'number' is true, and NaN === NaN is false. Not a number is a number but Not a Number is not Not a Number. What. IsNaN is a required hack - a kludge you might say - implemented to solve the problems this can cause.

Need I go on?

Javascript is everywhere on the web, it's a necessity now and you can do some really awesome things with it, more so if you understand how to avoid it's quirks.

But despite it's prevalence one simply cannot argue that it's a "good" language, it's really not. It's probably the most warty language I've ever had the misfortune to deal with after PHP. People defending it (fanboys) initially pretend the problem doesn't exist, then when, as I have, you explain the issues they say "Well it's not a problem if you know what you're doing" but it is, you can look at the change history of any number of open source Javascript projects and you will find bugs that have been fixed that exist purely because of the warts despite the people introducing the bug being some of the most experienced Javascript developers on the planet. If there's an additional vector for bug introduction then eventually bugs will be introduced through it, and Javascript has plenty of those vectors.

So yeah it works, yeah it's what we're stuck with, yeah amazing things can, have and will continue to be done with it, but it's still not good. Which is kind of the point most people are making when they say exactly that.

Javascript is now web scale

[Lunix Nutcase]

No, it's fanboy hyperbole.

Brilliant!

[Sparticus789]

So instead of having one portion of my stack vulnerable to hundreds of exploits, now I can have the ENTIRE stack vulnerable to hundreds of exploits. Sign me up!

Re:Brilliant!

[Sparticus789]

Apple System 6 with no AppleTalk card. Exploit that!

partly engineering resources put into compilers

[Trepidity]

I wouldn't necessarily pick Javascript on its merits as a language, but for a language as dynamic as it is, it has very good optimizing compilers, probably research state-of-the-art for this kind of language (Google's V8 engine is largely built by ex-Smalltalk researchers). That gives it some advantages over, say, Python.

Re:partly engineering resources put into compilers

[stewsters]

Or you know, you could just use java: http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/

Re:partly engineering resources put into compilers

[Trepidity]

Java's class system is quite static, compared to the runtime-modifiable classes of Smalltalk, Javascript, Lisp/CLOS, Python, etc. In some cases that doesn't matter. But if you want a highly dynamic language, V8 is a pretty solid compiler, better than anything in the Python or Ruby spheres (though perhaps some of the stuff in the Lisp world gives it a run for its money).

Javascript anywhere but the browser? No

[JDG1980]

Javascript isn't really a very good programming language (its lack of strong typing and lack of pointers are two things that often frustrate experienced coders). The only reason it's so popular is that it is a universal standard for client-side scripting in the browser. If you want to run code on the user's web browser, you have to use Javascript.

On servers, that doesn't apply. There are much better languages, no matter which platform you prefer. And MongoDB isn't particularly impressive, either; it's basically a database for people too stupid to understand SQL.

Re:Javascript anywhere but the browser? No

[godrik]

What are you talking about? We are talking about Javascript!! The new messiah of programming languages! Everything will be implemented in javascript. Even the linux kernel is being reimplemented in this highly productive language! Javascript saves baby dolphin and prevent dictators to take over. How can you not love it?

Re:Javascript anywhere but the browser? No

[Maudib]

Or for people who understand RDM just fine and know when to use it, but who also understand that Map Reduce and schema-less also have a place.

I'm not going to put financial transactions into mongo. However I will gladly do analytics in it.

"ace JavaScript developers who can write"

[tk77]

ace JavaScript developers who can write brilliant code

There are so many things wrong with that statement, my brain hurts trying to figure out where to begin

Re:It'd be neat if a JVM could run in a browser

[Anonymous Coward]

So many good JVM based languages (Scala, Closure, JRuby).

I wonder if anyone ever thought of letting a JVM run in a browser and use those for the full stack as a replacement for javascript.

(Edit: yes, I've heard of java applets before)

Oh, God no!

JavaScript has turned the web into a thick client medium.

I tried recently to use NoScript and I ended up having to turn it off for every damn website that I visit in order to just use it. I couldn't even log into my credit union or broker without it!

JavaScript has turned the web into bloatware. And all it does is make pages more cluttered, harder to use, longer to load, pages frequently lock up my browser, takes up bandwidth, etc .... JavaScript is a tool for crap. It is for advertising. It's funny, not wasn't I able to login to my credit union with NoScript, but all the ads/promotions/(shit I don't care about) didn't work.

I think I'll start a new metric or new law - the AC law:

A website's quality is inversely proportional to the amount of JavaScript.

Case in point: Google. No scripts there but immensely valuable.

Worthless Social media websites: loaded with the crap.

No, node.js and mongodb are cancer

[A beautiful mind]

The real thing that's turning javascript into the lingua franca of the web are really three things:

1. JS is already supported by all major browsers, modern ones with JIT

1. asm.js - which turns anything from a LLVM intermediate representation into javascript code that runs around 2x the speed of native c/c++ code in supported browsers and as fast as any other piece of JS code in all the other browsers

1. HTML5, WebRTC

It's an inside-out stack.

Re:No, node.js and mongodb are cancer

[uncle brad]

He was trying to say that its only twice as slow.

Re:No, node.js and mongodb are cancer

[dkf]

You might be suprised to see what benefits Just-In-Time (JIT) compilation can bring to run time.

And you might be surprised to see that C code written by someone competent still goes faster. The real advantage of working in a higher-level language is that the compiler can have more information about the operation being attempted and so use a better instruction sequence (and, for that matter, a better data structure) to implement it.

Beating bad C code isn't too hard, and most other languages have substantially higher-level operations for some key things like strings. Getting C to handle strings quickly requires substantial cleverness, and is nearly impossible with the standard string operations even those are individually compiled to optimal instruction sequences. (This isn't a paradox: other languages keep more metadata around and that can hugely accelerate most common operations.)

Re:No, node.js and mongodb are cancer

[Bill_the_Engineer]

asm.js - which turns anything from a LLVM intermediate representation into javascript code that runs around 2x the speed of native c/c++ code in supported browsers and as fast as any other piece of JS code in all the other browsers

I'm more than a little skeptical of your claim. A presentation at GDC 2013 by Alon Zakai, only claims that asm.js is faster than handwritten JavaScript. I assume you misinterpreted his "2X of native" quote as being for C/C++ and not for Javascript. Later in his presentation where he specifically talks about compiling C/C++ to JavaScript he only claims "Fast code execution, getting close to native speed".

Re:It'd be neat if a JVM could run in a browser

[OakDragon]

You're very clever, young man, very clever... but it's turkeys all the way down.

2-factor, Suggest, Instant, Gmail, Docs, YouTube

[tepples]

I couldn't even log into my credit union or broker without it!

Financial web applications probably use JavaScript to store a cookie that verifies that this browser has previously been used to access this account. This makes the browser the second factor in a two-factor authentication system.

And all it does is make pages more cluttered

Not always. JavaScript lets a web page hide a particular element until the user expresses interest in viewing it by clicking it.

harder to use

With JavaScript, a user can (for instance) click to expand help for a particular field of a form without having to navigate away from the form.

longer to load

Without JavaScript, the only way to expand or collapse an element in a document, such as an element in a tree or an aside that has been hidden, is to follow a link or submit a form that results in sending the whole page back. This whole page takes long to load.

takes up bandwidth

Updating only what has changed on a page takes up less bandwidth than having to send the whole page all over again.

Google. No scripts there but immensely valuable.

If Google Search doesn't use JavaScript, how do the Suggest (drop-down completion box below text input) and Instant (replacement when the user pauses typing) features of Google Search work? Besides, Google also produces Gmail, Google Docs, and YouTube, which use plenty of JavaScript.

Re:Full Stack?

[OakDragon]

Basically, they're saying JavaScript could be used at the OS level, the database level, and the presentation level.

Re:Server Side Javascript

[dingen]

Sharing a single code base between client and server is a huge benefit for any application. Nobody likes to write things twice.

Verifying equivalence of client and server code

[tepples]

Sometimes "a much better development team" is a larger and therefore costlier development team.

Besides, sometimes I want the code on the client and the server to do the same thing, and the easiest way to do that is to run the same code. (See Don't repeat yourself and Once and only once.) Say I want to validate input on the client for speed and offline capability and then revalidate it on the server for security. With a common language, I can reuse the same validation functions on the client and server. Without a common language, what's the standard practice to formally verify the equivalence of the client-side and server-side input validation code?

Re:Verifying equivalence of client and server code

[tepples]

I assume that Anonymous Coward was recommending that one apply the same suite of unit tests once to the validation code written in the server-side language and again to the validation code written in the client-side language, and then assume that they're equivalent if the tests return the same result for both implementations. But there's still an argument for having a single version of the truth.

Javascript is still single-threaded

[jlowery]

and recovering from an exception in node-js is next to impossible. You really have little choice but to reboot the instance.

It's The Environment, Stupid

[Zontar The Mindless]

This seems to happen every time someone confuses a language with an environment and/or implementation and/or API.

Ca. 1998-2000, I was writing these things in JavaScript:
*Web browser DOM stuff aka "Dynamic HTML"
*Server-side ASP and NS-SSJS (Remember Netscape? They used to do servers, too...)
*System apps using ScriptEase/JS on *nix and COM/ActiveWhatever/JS on Windows
*Interaction in PDFs and SVG docs
*Extensions for Macromedia (now Adobe) DreamWeaver
*Extensions for Mozilla

We didn't have Ajax or Canvas in those days. We also didn't have smartphones or Justin Bieber.

But we still used JavaScript in lots of places, we still made phone calls, and we still changed the channel or hit the Mute button when MTV started playing crap.

Please

[gtirloni]

Wake me up when this is over.

Re:blur client-server line

[dkf]

completely hide the separation between client and server

Won't work. The separation between remote and local is fundamental because you've got a whole world of additional failure modes when you go remote. You can code client and server in different languages or the same language (hey, it's been tried before with C++ and Java and C# and VB and many others) but the real issue is that you just can't hide the fact that more things can go wrong. The network can go away. Someone can try to hack things (for profit or for lulz). Traffic levels can suddenly spike massively in ways you didn't anticipate. Lots of ways to fail. Pretending that there's no client/server separation just makes the fail much harder.

I advise writing the client and server in different languages because that helps you be sure that you've not made the interface between them language-specific (and so hard to reuse). It's not a strong recommendation — if you want to do both sides in the same language it will work — but keeping the separation clean is definitely a good idea.

Re:Full Stack?

[Ranx]

In the web development world a stack is the combination of webserver, database and programming language, so you have the well known LAMP stack (Linux, Apache, MySQL and PHP) and the Java stack (Tomcat [for example], Oracle [for example] and Java) and the Microsoft stack (Windows, IIS, SQL Server and C#). Now you also have the JavaScript stack (Node.js [with build in webserver] and MongoDB).

supported how?

[waterbear]

>>But if you're going to pick a single language to be used by everyone for all purposes, then why pick something kludgy like JavaScript?

>Because it is the only language that is universally supported in browsers. Would be nice were that not the case, but it is the fact that we have to live with.

"Because it is the only language for which there are claims of universal support in browsers."

FTFY

Re:Stop bashing JavaScript - and stop evangelising

[sfcat]

JavaScript is a shit language: Fuck off.

Wow, good argument. BTW, my office mate was at Netscape when Javascript was created. The author of Javascript has since apologized for creating Javascript. In his defense, it was only ever intended to run one line bits of logic inside of a web page. Ideas like functions actually had to be added later as the idea of using Javascript for a general purpose language came after the language was designed, not before. See how this leads to problems?

Javascript isn't and shouldn't be used as a general purpose language, EVER! It has uses but very few in general and they probably all have to do with browsers and DOMs.

JavaScript is not strongly-typed: Since when did strongly-typed languages become "better"?

Um, since math has existed? Compilers double as automated code error checkers. Or maybe you like checking your code's syntax by hand?

JavaScript is insecure: You're doing it wrong.

Javascript forces clients to execute general logic. This is a security issue no matter what. I'm sure you have some solution to this issue, but I assure you that there are ways around your solution (and anyone else's solution).

Node.js is single-threaded: OK, were you planning on serving clients with a single server instance/process?

Javascript is single threaded, this is OK for writing web apps, sometimes. But not always and its a huge hole in a general purpose language.

A single language client- and server-side offers little to no benefits: Yeah, you're right. Why would I want to a single test suite for my client- and server-side code? Why would I want to (securely) share model definitions between the client- and server-side? Why would I want to optimise one code-base instead of two? Why would I want to debug one language instead of two?

You finally make a good point. +1 for you.

MongoDB is for people who can't/won't learn SQL/the relational model: I'll admit that SQL is not my area of expertise, but my naive understanding is this: in SQL databases, you normalise your data by default until you hit performance issues. In NoSQL databases, you denormalise it by default. The decision on which one to use should depend entirely on the data you want to store.

Take it from me, you know NOTHING about data persistence no matter how much you think you do. Relational Algebra is the basic math governing manipulating, querying and storing data as tuples. It governs MongoDB (and other NoSQL tools) too, just that the authors of those systems basically lopped off all the hard parts of the relational algebra and implemented just the easy bits. And they did those parts quite poorly when compared to traditional RDBMSes.

NoSQL was an attempt to re-invent a very complex wheel that 1) already worked, and 2) the often didn't let you do things that were bad ideas (even if you didn't realize they were bad ideas at the time). SQL isn't perfect, but more people know it than HTML and Javascript combined. And the systems that implement SQL have reputations (and a history) of not losing data (well, as long as the hardware works) and allowing very large datasets to be queried. And before someone says something dumb like "Web Scale", Sharded DBs store and query some very large datasets. Only when you have datasets the size of google's do you have to implement your own. And they made BigTable so fast by not implementing things that DBs need but they didn't (like data consistency and joins). It might be nice for a RDBMS to allow you to choose to not use table locks or do other things to make these trade-offs. But RDBMSes evolved in a world where throwing hardware at problems was always a valid strategy and it probably still is and will be into the foreseeabl

Re:Please top hijacking Javascript _

[spage]

No, let's keep advancing JavaScript.

Let's compare
* find web site promoting some application
* go to download link
* find it's not available for Mac/Linux/your phone/Windows XP
* or it is, but you need to download a different Qt/GTK/SDL/DotNet/JDK runtime
* but that's not available for your machine, or it's 32-bit not 64-bit
* now download, save, run installer, wait for virus checker
* now finally run the bloody thing
* (Windows-only) wonder why there's another task running, it's the %^$#! Check for updates service
* A week later. Yay, there's an update. Repeat all these steps.

vs.
* find web site promoting some application
* click link
* you're running today's build. It just works.

You have to be a clueless, blind, future-fearing Luddite, yet simultaneously have the skills to master the download-find-install-run-maintain loop to find the former preferable. The 0.1% of the world population who fit that niche all hang out on Slashdot and vote up "bloated browser" comments.

Re:MongoDB ad

[VoidEngineer]

Mongo's console is a javascript interpreter. The folks at 10gen seem to have been the first (only?) modern NoSQL development group to have the blindingly obvious realization that javascript would be the ideal interpreter language for their database. The rest has been history....