Node.js and MongoDB Turning JavaScript Into a Full-Stack Language 354
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.'"
Re: Citation Needed (Score:5, Informative)
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 ;-)
2-factor, Suggest, Instant, Gmail, Docs, YouTube (Score:5, Informative)
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: Citation Needed (Score:4, Informative)
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:Stop bashing JavaScript - and stop evangelising (Score:5, Informative)
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