Forgot your password?
typodupeerror
Programming Databases

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

Posted by timothy
from the but-does-it-come-with-a-web-browser dept.
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.'"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Citation Needed (Score:5, Insightful)

    by casings (257363) on Thursday June 27, 2013 @01:28PM (#44124539)

    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?

    • by Lunix Nutcase (1092239) on Thursday June 27, 2013 @01:30PM (#44124555)

      No, it's fanboy hyperbole.

    • Re: Citation Needed (Score:5, Informative)

      by sribe (304414) on Thursday June 27, 2013 @01:40PM (#44124663)

      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 ;-)

      • by iggymanz (596061)

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

        • Re: Citation Needed (Score:5, Interesting)

          by marsu_k (701360) on Thursday June 27, 2013 @02:03PM (#44124867)

          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 [npmjs.org] 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.

          • by Splab (574204)

            The documentation sucks big time, but a far bigger problem is the lack of standard build environments - and a huge disconnect between supported components.

            It's extremely difficult to share code between client and server and headless testing of front-end has a long way to go .

      • by Darinbob (1142669)

        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?

        • Re: Citation Needed (Score:5, Interesting)

          by kwerle (39371) <kurt@CircleW.org> on Thursday June 27, 2013 @02:14PM (#44125015) Homepage Journal

          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...

          • by Maudib (223520)

            Funny, I really can't stand coffeescript. Its good that developers have a choice, but I tend to avoid coffeescript projects as dependencies as the community will by definition be smaller.

            • by kwerle (39371)

              I understand not liking coffeescript - to each their own.

              But I don't understand the dependency thing. coffeescript compiles 100% to javascript. Why do you care what it was written in?

              • by sjames (1099)

                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.

        • by LordThyGod (1465887) on Thursday June 27, 2013 @02:15PM (#44125031)

          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.

        • by hackula (2596247)
          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 (Score:4, Interesting)

        by Aaden42 (198257) on Thursday June 27, 2013 @02:14PM (#44125017) Homepage

        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.

      • by Trepidity (597)

        I agree there are cases when you'd like to be able to write in the same language on the client and server sides. I'm undecided, though, whether Javascript on the server is the direction to go, or something-else-on-the-client. For example, you can now write both sides of the stack in Ocaml, and deploy the client side via Js_of_ocaml [ocsigen.org].

        I guess it comes down to which ends up being less awkward: using JS on the server side instead of a more mature server-side language, or using something like Ocaml on the client

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

        I don't know, I don't think having to know several languages is that much of a chore. I kind of prefer languages to be specialized for specific purposes, because you can't be the best at everything. I don't know how much sense it would make to use SQL syntax for geometry shaders, or for asm to be used as a HTML dom manipulation. When you write a language to support everything, it is just as much detai
    • by Spy Handler (822350) on Thursday June 27, 2013 @01:48PM (#44124741) Homepage Journal

      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.

    • by Kenja (541830)
      Main thing I can think of is being able to dynamically decide where the code processing should happen depending on client requirements. For example, if you have some complex computations that would take up a lot of server CPU time for 10,000 users you can push that to the client in javascript. However, if a smaller number of your users are on mobile devices with limited CPU power, you could run the same javascript code on the backend servers for just those mobile users.
    • by multi io (640409)

      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?

      Not "jaw-dropping", but it may enable you to share code (e.g. domain objects, validation, "business code") between server and client.

      • by dingen (958134)

        A full-stack Javascript web app will have the ability to predict behavior in the client without having to ask the server first. This means you can present a user with something meaningful which is probably right, meanwhile check on the server with the data present there and update the client if needed afterwards. This could be a huge usability improvement for many applications and games.

    • Nothing and there is/was Server Side JavaScript. Netscape developed it.
    • by hackula (2596247) on Thursday June 27, 2013 @02:16PM (#44125041)
      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 (Score:4, Informative)

      by PhrostyMcByte (589271) <phrosty@gmail.com> on Thursday June 27, 2013 @02:54PM (#44125549) Homepage

      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.

    • by Maudib (223520)

      It does make some things much simpler.

      One example of being quite nice, though admittedly niche. I was writing some complex map reduce stuff for mongo. Multiple steps, lots of data, etc. I really wanted unit tests of the map-reduce scripts, but couldn't see a great way to do this in Mongo. So I wrote a node application that emulated the Mongo map-reduce environment and could then use mocha to do my testing.

      I think the really mind blowing stack for web development is node.js + redis + angular. The power of DI

    • Re: Citation Needed (Score:4, Interesting)

      by curunir (98273) * on Thursday June 27, 2013 @04:33PM (#44126835) Homepage Journal

      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.

  • 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)

    • Re: (Score:2, Insightful)

      by 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 fu

      • 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.

      • by Maudib (223520)

        There is shit loads of javascript on google.com

  • by Sparticus789 (2625955) on Thursday June 27, 2013 @01:35PM (#44124619) Journal

    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!

  • Full Stack? (Score:2, Interesting)

    by twistedcubic (577194)
    What does full-stack mean? Is this akin to a "fully-loaded" car?
    • by OakDragon (885217)
      Basically, they're saying JavaScript could be used at the OS level, the database level, and the presentation level.
      • by OakDragon (885217)

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

        Er, meant to say "server level", not "OS level". Possibly, when looking for a "full stack developer", you would also want someone knowledgeable in networking, too.

    • by dingen (958134)

      It means both both server and client. Traditionally, Javascript has been used only as a client language, running in your browser. With Javascript moving to the server with node.js and MongoDB, it enables a developer to write a complete server/client web application entirely in Javascript and share code between the two.

    • by Ranx (28829)

      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).

  • 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.

      • But how would that appeal to the hipsters looking to jump on the newest fad language/framework? Java is old and stodgy.

      • by Trepidity (597)

        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).

      • by Maudib (223520)

        (A) That is a year old, and node has had something like 6 releases since then
        (B) Did you bother to read the substance of the test? His test was flawed. Each request he was doing file io in node, but not in vert.

        "In your benchmarks nodejs is reading off the disk for every request. That’s the reason for the dramatic performance difference. Monitoring disk ops you can see this as well. Seems the JVM is doing some caching that v8 isn’t for reading the same file.

        Also making a small change so that bot

      • by hackula (2596247)
        Most people in the dynamic space are not looking for a static language. The real market share competitors are Ruby and Python. People who do choose node tend to choose it over those two for the enormous performance advantages, while remaining dynamic.
    • by Hentes (2461350)

      Common Lisp is faster [debian.org], and at least as dynamic as Javascript. Not that JS compilers aren't good, but they are not the leading edge.

  • by JDG1980 (2438906) on Thursday June 27, 2013 @01:37PM (#44124639)

    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.

    • by godrik (1287354) on Thursday June 27, 2013 @01:55PM (#44124791)

      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?

    • by Laxori666 (748529)
      Pointers - you don't need them in Javascript. what's a situation where you'd like to use a pointer but can't, and it makes the code significantly more complex? No points to you if you give the `swap(int *a, int *b);` example.
    • by hackula (2596247)
      Your criticisms apply to any dynamic language, which is one of the oldest flamebait comments around. Dismissing the MANY talented and experienced programmers across multiple dynamic platforms really shows your ignorance.
  • by tk77 (1774336) on Thursday June 27, 2013 @01:40PM (#44124671)

    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

  • >> 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.

    You mean they would be as good as real programmers? (i.e., People who use Javascript on the client side and something meatier for the server app.)

  • by A beautiful mind (821714) on Thursday June 27, 2013 @01:56PM (#44124803)

    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.

    • 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

  • Reminds me of the below-average players in World of Tanks, always grinding for the Next Tier Perfect Tank that will get their winrate in the black for sure.

    Just get better at coding / learn to master the tanks you already have. There are no shortcuts.
  • One advantage I could see in having JavaScript used on both client and server sides is that ultimately we could imagine new frameworks that would completely hide the separation between client and server. After all, we're using MVC anyway, might as well have all components in the same language so that the glue part is as seamless as possible. Wouldn't it be nice if you could have an IDE that gives you the impression that you're programming a regular desktop application, but that would take care of the deploy
    • by gauauu (649169)

      Wouldn't it be nice if you could have an IDE that gives you the impression that you're programming a regular desktop application, but that would take care of the deployment aspects? And once you get there, you can imagine higher level, languages that would generate the JavaScript for you if you're not a fan.

      Getting slightly offtopic, but you might want to check out Vaadin. It's a java framework that attempts to do what you're talking about -- you write everything in java in a fashion similar to a desktop application (with a widget toolkit that's similar to other desktop widget toolkits), and it takes care of building the html and javascript, and managing the ajax connections. You can run and debug it in an IDE and almost pretend you're not dealing with all the nastiness of the web. (I say "almost" -- it's not

    • by dkf (304284)

      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 massivel

  • by jlowery (47102) on Thursday June 27, 2013 @02:31PM (#44125249)

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

    • by dingen (958134)

      Single threaded is not a problem for web services as long as the threads aren't blocking. Once you have threads waiting for something (I/O typically), then you are delaying the system. But that's not really necessary with Javascript. Just finish as quickly as possible and fire an event when something you have to wait on is finished. Another thread will pick it up and resume later, and the system will process other requests in the meantime.

  • 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.

  • This sounds like a MongoDB ad. There's no particular reason that server-side Javascript should use MongoDB. There's "node.js" support for most databases.

    • 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....
  • by gtirloni (1531285) on Thursday June 27, 2013 @03:04PM (#44125687)
    Wake me up when this is over.

As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"

Working...