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.'"
Citation Needed (Score:5, Insightful)
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?
Javascript is now web scale (Score:5, Insightful)
No, it's fanboy hyperbole.
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 ;-)
Re: (Score:3)
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)
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.
Re: (Score:2)
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 .
Re: (Score:3)
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: (Score:2)
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)
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: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:3)
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: (Score:3)
Computational Javascript code is approaching C-speed.
BULLshit.
Re: Citation Needed (Score:4, Insightful)
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 (Score:5, Insightful)
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: (Score:3)
Re: (Score:2)
Re: (Score:3)
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, i
supported how? (Score:3)
>>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: Citation Needed (Score:4, Interesting)
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: (Score:2)
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
One language to compile them all... (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: Citation Needed (Score:5, Funny)
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: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: Citation Needed (Score:5, Insightful)
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: (Score:2)
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)
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 (Score:5, Insightful)
And that is "jaw dropping" how? You can already do that with several languages and nothing is remotely "jaw dropping" about it.
Re: (Score:2)
now deploy it to web users so that it can run on a wide audience with no dependencies, true "write once run everywhere", and runs in an actually functional sandbox (as opposed to the nightmares of java or activeX).
Of course Chromes NACL does that as well-- apparenly you can now get NACL games [google.com] in the chrome app store.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Sounds pretty mundane. My jaw is not dropping. I guess you have to be a hipster to be that impressed.
Re: (Score:2)
You can't run any other language than JS in the browser (practically anyways), so if you want a one-language-to-rule-them-all, you really need to code in one language knowing it will be translated into a different language, which is always uncomfortable.
Re: (Score:2)
You can't run any other language than JS in the browser (practically anyways),
That's more a function of browsers bundling Javascript support than of the language itself. You could substitute Tcl/Tk, (or Perl, Python, etc...). Presently, there's a Tcl/Tk plugin [www.tcl.tk] for Mozilla and IE.
Re: (Score:2)
I'm sorry but what web development can be done w/o needing to at least mix in JS on the client side?
Re: (Score:3)
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: (Score:3)
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
It'd be neat if a JVM could run in a browser (Score:2)
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)
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
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: (Score:2)
There is shit loads of javascript on google.com
Re: (Score:3)
Brilliant! (Score:3)
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: (Score:3)
Apple System 6 with no AppleTalk card. Exploit that!
Full Stack? (Score:2, Interesting)
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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).
partly engineering resources put into compilers (Score:3, Interesting)
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: (Score:3)
Re: (Score:2)
But how would that appeal to the hipsters looking to jump on the newest fad language/framework? Java is old and stodgy.
Re: (Score:3)
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).
Re: (Score:2)
(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
Re: (Score:2)
Re: (Score:2)
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.
Javascript anywhere but the browser? No (Score:4, Interesting)
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 (Score:5, Funny)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Getting trounced by PHP is not a point for JavaScript.
Python has pointers the way Java does (Score:2)
Re: (Score:2)
Re: (Score:3)
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" (Score:5, Funny)
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
You mean as good a regular programmers? (Score:2)
>> 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.)
Re: (Score:2)
That quote made me want to barf.
No, node.js and mongodb are cancer (Score:4, Interesting)
The real thing that's turning javascript into the lingua franca of the web are really three things:
It's an inside-out stack.
Re: (Score:3)
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
Re:No, node.js and mongodb are cancer (Score:5, Interesting)
Re: (Score:3)
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
"But if and when".... "then" (Score:2)
Just get better at coding / learn to master the tanks you already have. There are no shortcuts.
blur client-server line (Score:2)
Re: (Score:2)
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
Re: (Score:3)
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
Javascript is still single-threaded (Score:3)
and recovering from an exception in node-js is next to impossible. You really have little choice but to reboot the instance.
Re: (Score:2)
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.
Re: (Score:2)
been using it for nearly a year now. Currently supports the company's website of over 400 pages.
It's The Environment, Stupid (Score:3)
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.
MongoDB ad (Score:2)
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.
Re: (Score:3)
Please (Score:3)
Re: (Score:3)
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 (Score:3)
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 [wikipedia.org] and Once and only once [c2.com].) 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. W
Re: (Score:2)
What does unit testing have to do with validating user input?
Re: (Score:3)
Re: (Score:2)
Nothing.
But it has a lot to do with this:
what's the standard practice to formally verify the equivalence of the client-side and server-side input validation code?
Re: (Score:2)
Besides, if I have written a program and want to run it in two environments, w
Re: (Score:2)
This one won't beat the Turing test yet, but keep trying!
Re: (Score:2)
Fabrice Bellard could make an x86 emulator out of a paperclip, some spare change and a couple of matchsticks.
Just because you can do something doesn't mean it should be used as a production product.
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
Re:Please top hijacking Javascript _ (Score:5, Insightful)
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.