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

[EvanED]

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

I have heard one argument I find somewhat convincing, which is that using a single language means that if requirements change or people discover a better way to do something, it's possible to move or share code between client and server side without rewriting it. If you do something on the server side now and then say "hey, we'll get more responsiveness if we put it client-side", you can just move that function to the client side and call it.

Not being a web dev, I can't actually evaluate this claim with high confidence, but it sounds somewhat plausible at least.

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

[Kenja]

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.

Re: Citation Needed

[Anonymous Coward]

Jaw dropping is hyperbole, but there WOULD be a pretty decent advantage to just being able to write everything in one language.

As soon as you start writing ajax heavy web applications, you start to notice that you end up duplicating a lot of code. You build a page/form/view/whatever in PHP or Java (+HTML) to make sure search engines can crawl your content (and in the case of forms, provide for server side validation and related stuff), and then you end up rebuilding all of it in JS to make the front end responsive and ajaxy.

You could definitely really simplify things (and build/test a lot faster) if you could reuse the same code. You could also really cut out a lot of teamwork/communication issues - especially during rapid development phases. It also lets someone get REALLY good at one language and allows for advantages related to that.

I can definitely see a language that works on both front and back end being hugely desirable.

Re: Citation Needed

[multi io]

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: Citation Needed

[Darinbob]

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

[LordLimecat]

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 in the chrome app store.

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

[i_ate_god]

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: Citation Needed

[dingen]

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

[Trepidity]

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.

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 side via a compiler, instead of the more standard client-side language?

Re: Citation Needed

[Lunix Nutcase]

Sounds pretty mundane. My jaw is not dropping. I guess you have to be a hipster to be that impressed.

Re: Citation Needed

[hackula]

Actually, most libraries will work in either client side browsers or node. See https://github.com/substack/node-browserify for an example of how some interop is being done. The browser engine (handling the js) is V8, which also happens to be the node.js engine. Any js related to the DOM does not make sense to run server side anyway (with the exception of server side DOM testing, which works just fine with selenium, zombiejs, or phantomjs, making you double wrong).

Re: Citation Needed

[hackula]

Many prominent libraries have been ported back and forth, so this is accurate. At the same time, this is not a requirement most of the time.

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

[hackula]

This completely ignores the new real time paradigm. This is huge. Most people interested in node, are interested due to the awesome support for real time web apps. See socket.io, derby.js, etc.

Re: Citation Needed

[Anonymous Coward]

As a real developer, I reckon that a back end consisting of a mess of thousands of weakly-typed, undocumented javascript functions (as currently present in many web front ends) could well be jaw-dropping.

As in jaw-droppingly awful.

Re: Citation Needed

[Maudib]

I'm sorry but what web development can be done w/o needing to at least mix in JS on the client side?

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

[Maudib]

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 & IOC for web development combined with Javascript all the way down makes development a true joy. I've also done web development with Py, Java/Spring/Hibernate, Grails and LAMP, and can honestly say that none compare to node/mongo/angular for performance & developer productivity.

That said, Javascript can result in some terrifyingly bad code in the hands of bad developers. Certainly worse at the extremes then Py or Java.

Re: Citation Needed

[Bengie]

Or OS or hardware, while we're being pedantic.

Re: Citation Needed

[Maudib]

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

[fahrbot-bot]

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 for Mozilla and IE.

Re: Citation Needed

[kwerle]

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: Citation Needed

[Kielistic]

No, I assure you that would only generate more complaints.

Re: Citation Needed

[Splab]

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: Citation Needed

[aztracker1]

GruntJS has pretty much taken hold as the build environment for node based projects. Even in other platforms (.Net for me), I have a pre-build event in VS that will compile/minify/combine my various client-side assets. It's extremely useful. For libraries there's Bower which uses Node... It really does make web application development much nicer. The only thing that doesn't really sing to me is a good templating system that is very transparent in terms of being able to share client and server-side. There's a lot of recent work in this area though.

As far as sharing client and server-side JS, there's a lot there to support it.

Re: Citation Needed

[aztracker1]

It's worth noting that a lot of the Good Parts were around even in '98, though the DOM differences were hellish to support at that time, the language itself was always imho pretty decent (given it's rather large warts).

Re: Citation Needed

[Instine]

Event diven functional language by default with json being a rather beautifully simple transport and object description, does actually make for an excellent stack for web apps. Also the speed of high concurrency request serving on node is superb. Yes you can do all these things with damn near any language, but nothing is as easy to do all of it so scalably, fast and well. IMO.

Re: Citation Needed

[VGPowerlord]

JavaScript is kludgy?

Stop using jQuery and stop trying to force JavaScript to act like a class-based oo language. That should fix most of your JavaScript complaints.

JavaScript being kludgy is why JQuery and others like it came into existence in the first place.

Raw JavaScript is such a pain in the ass to deal with that, if I had a time machine, I wouldn't use it for world peace or to stop World War 1/2, I'd use it to go back in time and kill Brendan Eich.

Re: Citation Needed

[KingMotley]

Hmm.. You can write a silverlight app in C#, which then contacts an ASP.NET webservice that is written in C#, that calls the middle tier written in C# that calls the data access layer written in C#, that gets data from SQL Server that does a bunch of stuff that uses custom database functions written in C#.

Re: Citation Needed

[hackula]

The documentation tends to be terrific in my experience. Also, the libraries tend to be very small, by design. This allows you to simply pop open the source (usually just a single 100 line index.js file) and read away. Not for everybody, but I got sick of pouring over javadocs and msdn, so I think its great.

Re: Citation Needed

[RabidReindeer]

Yes, there always is the source, but that's hardly ideal^W readable.

... At least if it's anything like most Javascript libraries I've seen.

Re: Citation Needed

[nschubach]

If you want to you could have whatever validation (or any) script you use on the server be sent to the client to be run before they submit the data. You still have server side sanity checking and you get client side for "free".

I assume the sell is mainly part of being able to seamlessly share data via JSON (without extra parsers) and working with one language all the time. That's the main "cool" factor for me. I don't have to switch "modes" and think Ruby/.NET/PHP when working on the backend and then switch to thinking "JavaScript" on the front.

Re: Citation Needed

[hackula]

lol quite true. I think the big differences is that it took about 10 years for the Good Parts to actually catch on in the JS community.

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

[wonkey_monkey]

I'm struggling to understand how Javascript is like Assembly. One's high level, one's level low level. One's architecture specific, the other is available via several different browsers across practically every operating system running on any architecture.

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.

...which is pretty much the opposite of assembly.

Re: Citation Needed

[The Cat]

You could write a web application in C and bypass the browser entirely.

Oh, but that would require thinking.

Re: Citation Needed

[The Cat]

Sounds like a wild clusterfuck waiting to happen.

Is MongoDB written in Javascript? 'nuff said.

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

[tibit]

you start to see the power of a simple event loop and callback structure.

Kinda like all any decently performing C/C++ application would be written anyway? I mean, come on, windows and X clients had their event loops since forever, and today's async I/O on both Windows and Linux gives you async callbacks.

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?"

I can't think of any way JavaScript is at all like assembly, except that a lot of programmers hate using it...

And, frankly, that's about enough for me.

But the other - and probably more important one:
It gets compiled into.

Re: Citation Needed

[Maudib]

Very few people query mongo via rest.

However the mongo shell is v8. So all querying, aggregation and map reduce is in JS.

Re: Citation Needed

[Anonymous Coward]

I'm fairly confident that you have a non-standard definition of "terrific".

Re: Citation Needed

[sribe]

I'm undecided, though, whether Javascript on the server is the direction to go, or something-else-on-the-client.

I would much rather a better-designed language than javascript in the browser, but that's not going to happen (at least not with broad enough support), and I'm highly suspicious of the "compile-to-javascript" hacks for the browser, so javascript on the server it is. If javascript were a truly awful language, it would be different, but javascript is good enough...

Re: Citation Needed

[sribe]

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.

Re: Citation Needed

[sribe]

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

And that is exactly why I said "I'm watching node.js" as opposed to "I'm switching to node.js" ;-)

Re: Citation Needed

[aztracker1]

Fair enough.. then again, JS was really the first language I used to any large extent... far more than the scripting/macro languages I'd used before it. Mainly was doing artwork and design for web applications in the mid 90's and wanted to do a couple things... learning HTML and JS were natural extensions. I used JS for Netscape server, and even in classic ASP (JScript)... I think I was the only non-MS person using JS for ASP (all the MS projects seemed to use it). It was really nice to reuse a lot of the same include files for logic client and server-side then. Though the DOM *REALLY* sucked back then, and it wasn't until around 2003-2004 or so when it started to be manageable (with prototype, later jquery, etc).

I always loved the flexibility that it brought out... and used it to a large extent. The pain of the DOM caused me to buy in to the ASP.Net callback model, and it wasn't until the rise of "Ajax" interactions (2004-2005) that I ran away from the callback/event system that ASP.Net used. Since then I've been far more in favor of light services/rpc on the server, pretty static rendering, and heavy JS.

With JS server-side some of that can swing back to the server for constrained channels and frameworks can come out that leverage a lot of the same logic on both in a straight forward manner, supporting phones to tablets and full-fledged desktop browsers.

Re: Citation Needed

[aztracker1]

I really hate discussions like this... the browser's DOM !== JavaScript ... it's just that usage of the DOM was for a long time the primary interaction with JS... jQuery makes manipulation of the DOM easier. The language has always had a lot of nice features, and isn't very kludgy at all. I will say that string formatting and Dates are probably its' weakest points, but there are lots of languages with those problems.

Re: Citation Needed

[aztracker1]

And I (for one) used it... I also used it (JScript) with MS's classic ASP around 1996 or so. I was actually really saddened when MS dropped Managed JScript from the DLR (though they pretty much let that whole project along with IronRuby and IronPython all but die at this point). I was relatively happy to see a rise of support for NodeJS, MongoDB, etc.

Re: Citation Needed

[aztracker1]

Agreed, at my last job, roughly half my time was dedicated to NodeJS which wasn't even used for the front end web applications, though I did pretty easily add CORS & JSONP support to my web services, some didn't need authentication. It's been a great platform for data transforms and manipulation, far more straight forward than a lot of other things. Having libraries to read in an XML stream, convert it to object nodes, and manipulate it for output into another system is awesome. Creating JSON based services is a no brainer, and working with MongoDB is pretty seamless. I've honestly had far more (though relatively few) issues with NodeJS or MongoDB for that matter.

I'd be content spending most of my time on NodeJS work. Though my current job is in backend work for a large MS shop (it pays the bills, doesn't mean I think it is better).

Re: Citation Needed

[Anonymous Coward]

1/3 Insightful, 1/3 Informative, 1/3 Troll. Reduces to troll.

Re: Citation Needed

[aztracker1]

If you take a modular approach with your code NodeJS works out pretty well. There are more than a handful of test frameworks as well, and GruntJS is a really useful tool even for projects where the server code is in other platforms/languages.

Re: Citation Needed

[aztracker1]

I think the worst environment I ever worked in for language context switching was an app that used a web front end (HTML+JS+CSS), that had an embedded Flash system (FLEX + ActionScript) talking to a backend in ASP.Net (VB.Net, not C#) which then used MS-SQL (T-SQL) for storage... I spent so much time switching languages I can't even explain how bad it was. I would get asked a question by a peer, and it would take me literally half a minute just to get out of the mode I was in, have them re-ask, then get into what they were into in order to help.. then another several minutes to get back into where I was working after... It was horribly stressful.

I'd love to do full-stack all-JS development.

Re: Citation Needed

[Jane Q. Public]

"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?"

Hmmmm.... Yes! Now that I think about it, I can!

JavaScript is jaw-droppingly obtuse. It has the property that objects are represented in totally, jaw-droppingly unreadable JSON. Its syntax is jaw-droppingly primitive, full of a jaw-dropping number of unnecessary brackets and parentheses, and jaw-droppingly verbose and stubborn. I could go on, but my jaw is sore.

And contrary to what OP wrote, JavaScript has not even remotely "emerged as the lingua franca of the modern Web". It is an annoying and obnoxious holdover from the very early days of the Web.

Further, Node.js was obviously a fad, and MongoDB has already been superseded by superior products.

Re: Citation Needed

[aztracker1]

MongoDB happens to use a BSON protocol, which is kind of like protocol buffers or message-pack. That translates pretty well to JSON and other representations. The fact that the mongodb console interface uses a JS based interpreter makes this very transparent in use.

That said, NodeJS as a client to most non-sql based databases tends to be very transparent (Couch, Mongo, Redis, Raik etc)... Mongo's interface being JS based is a big advantage in Full-Stack JavaScript.

Re: Citation Needed

[aztracker1]

Not to be too pedantic, but the user can use an HTML app with only a browser (they likely already have) without a plugin (that they don't likely already have) and communicate to the server running the same language in said browser, and talk to the database, which you interact with using that same language.

MS-SQL uses T-SQL for interrogating the data, and though most interactions can be done via a GUI knowing almost nothing about the SQL language, is pretty limited without DB/SQL knowledge.

Re: Citation Needed

[taharvey]

While others here are correct in saying that there are better languages (True), and they can do many of the same things with other server side tools (True), there is one thing that client-server javascript brings to the table that is unique:

You can write a single code base that can float between client and server making it a single platform. So if you make a design change, you can run parts of your code on the serve side, or client side without a whole re-architecture or re-write of the system.

Because of the single "platform", there are whole client-server system frameworks like meteor and derby that can put you far ahead of cobbling your own pieces together.

Because of the single "platform", it empowers commercial app developers to expose the UI, but hold some code chunks back, so their proprietary code isn't exposed.

Re: Citation Needed

[KingMotley]

MS-SQL may use T-SQL for interrogating the data, programmers don't need to write it in most cases. Entity Framework will create all the T-SQL you need, including creating the actual database, tables, indexes, primary keys, and foreign keys. You can write entire applications without ever touching T-SQL.

I'll grant you that you do need to install the silverlight plug-in to get it to work on the client, but that isn't really harder than installing the browser in the first place. Millions of housewives have figured it out, just ask netflix.

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

[Concerned Onlooker]

"... At least if it's anything like most Javascript libraries I've seen."

You're not supposed to be reading the .min.js files.

Re: Citation Needed

[narcc]

Do you have any actual reasons or are you just parroting what you think "smart people" are supposed to believe?

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

[Requiem18th]

Wrong and, wrong.

Firstly, the point of MongoDB is building a NoSQL database. And it does not query via REST, CouchDB does that. MongoDB has its own querying interfase which requires external drivers. It does return JSON. But that's meaningless, JSON is analogous to Python's dicts or Ruby hashes or even to a degree to PHP arrays.

On the other hand writing web pages in Javascript sucks, specially without multiline strings. You really want a templating language. Which will render into HTML so you are also need to understand HTML. And then you need to use CSS to style the thing, except generating CSS by hand is tedious if your design is complex so you want something more powerful like SASS or LESS.

The point is making web apps easier to write not having a "full stack" language.

Re: Citation Needed

[VoidEngineer]

I'm a Meteor developer, using full-stack Javascript 100% of the time... Node.js, MongoDB, and jQuery are my stock in trade. If you're not familiar, Meteor is basically 'Javascript on Rails'. And, in my experience, everything in the article is spot on. As to the jaw-dropping abilities...

- developing in a unified language has increased my productivity 5x to 10x. I get done in a weekend what used to take me a month or more to do in PHP or C#. That's jaw dropping from a business sense, and has allowed me to completely change my business structure and approach. Frameworks like Meteor and Derby are going to win out on productivity gains alone. I can go from an initial client meeting to launching a beta of a multi-user application in a weekend.

- remember that javascript is based on actionscript, based on scheme, based on lisp. When you have your client, server, and database all using a functional language, you can start creating UI elements as monad operations on datastore elements. No objects ever on the heap. Just chained functions from database to server to client to UI. Among other things, this allows for things like reactive templates, demonstrated in the following screencast:

http://meteor.com/screencast

- besides the reactive templates, sharing of libraries between client and server makes every Meteor application theoretically capable of becoming a peer-to-peer distributed application. No PHP or Ruby or C# web application can do that. In theory, you could bundle the node.js libraries themselves into the client, and have each served client become a new peer-to-peer node.

- this allows mesh networking functionality, with monad operations defining computations between and through nodes. Think of it like routing protocols, but with computations. Lots of distributed computing possibilities here, obviously. More importantly is bandwidth usage, offline data synchronization, and the like. Instead of going to a data center to get the latest package updates, applications will be able to query neighbor nodes. Think IPv6 functionality, mesh networking, and being able to query data states from intermediary peers. The people in the Meteor dev community are actively working on things ranging from meters for smart energy grids to real-time bee pollination tracking.

Those technical details aside, the underlying reason why pure javascript can result in jaw-dropping applications is because, at it's core, javascript is a functional language, in the manner of lisp (if you know how to use the lambda calculus). It's lisp for the web (or scheme for the web, if you prefer). And putting it on both the server and client and database allows developers to do crazy monad calculations and method chaining. The monads will update and recalculate themselves in real time, as the underlying data changes. The end result is reactive templates and data-driven animations and UI elements.

If you want a better understanding how this is going to play out, check out the D3 visualization library here:

https://github.com/mbostock/d3/wiki/Gallery

Then, imagine all those visualizations used to create applications like in Processing:

http://processing.org/exhibition/

That's the direction this stuff is headed in. If you want to see some real examples in action, consider the interactives on the New York Times

http://www.nytimes.com/interactive/2012/05/17/business/dealbook/how-the-facebook-offering-compares.html?_r=0
http://www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html

Re: Citation Needed

[VoidEngineer]

Why would you deploy the back-end to the users??????

Peer-to-peer networking applications.

Re: Citation Needed

[VoidEngineer]

That's changing rapidly. Lots and lots of active development with REST libraries, and a number of packages providing that functionality becoming mature.

Re: Citation Needed

[VoidEngineer]

+1 Wish I had mod points.

Re: Citation Needed

[MisterSquid]

Only pedants mistake precision for correctness. You're using a tertiary definition of "terrific" and non-idiomatically at that. In its less common negative senses, "terrific" cannot be used as a predicate adjective, only as a predicate.

You know how to use a dictionary, sure, but you don't know shit about English grammar.

Re: Citation Needed

[arkhan_jg]

I am a Node webapp dev as a sideline with experience in a few languages over the years, and maybe it's because I'm not an 'ace' developer, but I don't think it's that incredibly revolutionary.

The main advantage of node - and mongodb - is that they're asynchronous through and through with a universal callback/event driven loop available. Which is obviously nice to work with if you're comfy with javascript already (mongodb uses javascript-style as its native syntax) and with the first class support of socket.io ala websockets means that you can largely treat the front-end browser land and server side as one large async program with a usual UI/backend split. Plus there's generally a npm module library to do whatever, though it's often wise to avoid ones that aren't maintained given the pace of change.

To be honest, I don't think there's anything really that couldn't be done with say, python twisted, or even rails. I think the universal async (and almost entirely non-blocking unless you cock it up) model is nice to work with once you grok using event handlers and/or a flow control lib like async to avoid nested callback hell, and it's obviously a good fit for web apps. But it's like any other language/toolset - pick your tools according to your needs.

Personally I've switched from mongo to couchdb as I find it easier and faster to work with, and mostly actually write code in coffeescript to get rid of the bracket cruft, but can switch back and forth to javascript as needed. It is FAR nicer to work with than PHP by any standard, but then I'm a linux/windows/esx sysadmin with an Apple-fan boss for my day job, so what do I know.

Re: Citation Needed

[Xest]

The problem is that that benefit is heavily outweighed by the fact that Javascript is fucking useless for anything non-trivial (it's OO support is fucking abysmal making it poor for server side which is normally fairly complex) and it's functional support is poorly designed (captured variable handling is badly done for example, in fact, C# did things in closures the Javascript way itself at first then fixed it as an actual language bug).

You're still better off switching languages and really it's not hard to do. I wont pretend that in a day where I was working with C#, PHP, Javascript and then XML and HTML on top that I didn't actually find it tiring, but it wasn't debilitantingly difficult and certainly working with two languages is no big deal.

It's not even like it's hard work given that serialisation/deserialisation to/from JSON in languages like C# is pretty much entirely automatic now. You don't even really have to worry about the interchange, you just have to use one language on the client and one on the server which isn't a big deal at all.

I'd rather have a server side application that's well designed, maintainable and has a good toolset behind it (especially for things like testing) rather than use a much more flawed language with worse support for writing good code and abysmal testability suites than get the single advantage of "not having to switch from it to something else server-side".

Re: Citation Needed

[Xest]

But that's the problem isn't it? Javascript got where it was by default, not because it was inherently any good.

We had a situation where there were two browser vendors who bilaterally decided to support it (though not in the most compatible of manners) one of which died meaning the only option for many years for client side scripting was Javascript (or VBScript running on the same engine, Hah.) and so everything got written in Javascript because it was the only real choice. Then when we finally get competition in the browser market it's a bit late to support anything other than Javascript.

So we are where we are, the only way we'll get something better than Javascript is if there were to be a cross-vendor effort to do exactly that, but getting Microsoft to agree with Mozilla to agree with Apple to agree with Google to agree with Opera is a lost cause.

You're right that there isn't one but that's the exact problem. We can't do much about it, but it's understandable to whinge about it, because it's a fucking shitty and unfortunate situation when the only option is a bad one.

Re: Citation Needed

[Xest]

None of that is new, and it's not real-time. Real-time has a specific meaning in computing that a system can be guaranteed to always respond within a minimal amount of time, and node.js cannot give that guarantee. To give that guarantee you tend to need specialist hardware with a specialist real time operating system.

It's just new and real-time to Javascript developers who don't know enough about computing to understand that real-time is something different, and nodes.js' method of handling requests isn't new.

It's like the "responsive design" fanboys, they seem oblivious that the term "responsiveness" was already taken with regards to Javascript and has a very different meaning and that when they say "responsive design" they normally just mean "resolution independent design" or similar. Responsiveness especially in relation to Javascript has historically been about how quickly the system responds, responsiveness in Javascript always referred to the fact that doing something client side was much more responsive than doing a page reload to do it server side. Obviously in an age of broadband where server side loads are pretty quick anyway and Javascript is less about responsiveness and more about complex client side interaction this understanding is lost on the hipsters though.

Web 2.0 amateurs need to stop redefining existing terms and start learning that the things they think they've invented have already been about for a very long time under a different name. Maybe if they did that they'd realise their new pet toy isn't actually new and could learn from the mistakes of past implementations of the idea instead of dooming themselves to repeat them, which they always do.

The worst part is I'm not even that old, I've barely broken into my 30s and I'm already annoyed by a new generation who are just making the mistakes that I learnt to avoid by learning from the generations before me who have already been there and done all this. Maybe because things change so much faster now 30 is the new 60? Oh well, get off my lawn then I guess.

Re: Citation Needed

[sjames]

On the other hand, I find that the language switch helps remind me that I am working in two entirely separate security contexts, a well trusted server and a client that may very well be a blackhat's attack program or perhaps a client browser infested with exploits. When I contemplate moving a server function to the client, it is important that I carefully consider the entire security implication. Nothing encourages that like re-writing the function in another language.

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.

Re: Citation Needed

[jeremyp]

You can do that already. For example, since 1.6, Java has had built in scripting support for Javascript.

Re: Citation Needed

[hackula]

I did not make up the term, so I am just using the definition people give it. Regardless, having a UI closely reflect data on the fly may be solved on the desktop, but that has not been the case on the web. People are working hard on the web to get similar functionality that desktop guys often take for granted. Yes, they often come up with terrible names, but who honestly gives a shit? Also, We are solving different problems and we optimize for different things, who cares? When event-driven desktop programming became the new big thing, all the backend AS400 guys rolled their eyes just like you are now and said things like "why can't we just load all the data in batch at the end of the month?". They had their own reasons for doing things in batch, desktop has good reasons for rich event driven code, and the web has its own set of emerging concerns like high concurrency, maintainable scalability, and state management. If you think these problems are easy then go into consulting and collect your zillion dollars at your convenience.

Re: Citation Needed

[Xest]

I just have a problem with people not knowing what they're on about redefining well established terms through ignorance and pretending they've invented something new.

It's like carrying a cat into the office one day and saying it's called a dog and then proclaiming you invented it and it's never been seen before.

Quite rightly you'd get a few funny looks.

I don't think you've understood my post though, you mention the desktop but I didn't mention the desktop at all. If you were mentioning the desktop in terms of real time computing then that's not what I was on about and still not what real time computing is. Real time computers are systems that have the lowest of latencies in response and can guarantee that, they may be used for example in regulating drug administration in a hospital where you can't simply have a few second spike as the OS decides to do something in the background because not regulating those levels to the closest millisecond can be the difference between life and death.

If you were referring to my comments on responsive design then again I think you've misunderstood the new definition of responsive design. The term responsive design as used by the hipsters refers to using CSS3 features and such to make a page adapt depending on the user's resolution and DPI. The reason I take issue with this is that designing a responsive website historically referred to using Javascript to limit server side callbacks, for example doing pre-validation on a form field client side and telling the user immediately that there's a problem without requiring a postback - that's what responsive design meant in the classic sense. The issue is that they've caused ambiguity because now when they say "Hey we need to build a responsive website" it's impossible to tell if they mean one that adapts to different display devices and changes it's layout to suit or whether they mean one that responds quickly to user feedback or if they just meant both. Of course, it's all also really just a natural evolution of resolution independent design at the end of the day, which is what we always used to call this sort of thing before it got more fancy with CSS3's new media tags et. al.

Things like high concurrency, maintainability, scalability and state management are as old as the web (well, older really) so are far from emerging concerns. It's as if there's a new generation of web developers that have appeared in the last 5 years who have managed to become web developers without having learnt anything whatsoever about the things that came before them and they're just repeating the mistakes everyone else that came before them made with their fancy new technologies that the people who came before them then have to come in and fix. All people like me ask of these people is can they not just learn a little bit about the history of web development so that they can expend their efforts on moving forward rather than continuously reinventing the wheel repeating and then solving problems that have already been made and solved previously and without creating contradictory terminology in the process?

FWIW I do do some consulting.

Re: Citation Needed

[kwerle]

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's a great point. It's possible it didn't occur to me because most of the 'raw' javascript libraries I've looked at seem pretty ugly already - I didn't think of compiled coffeescript as looking much worse. But it really does.

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

Since the coffeescript compiler is self-hosted and compiles to the target, at least that dependency seems like a non-issue.

Re: Citation Needed

[Maudib]

So a big part of choosing dependencies is evaluating the community that will be contributing.

A library written coffee script will have fewer possible developers available to contribute then a library written in pure js, as many JS devs won't touch coffee script. So all other things being equal, Ill choose the pure JS library.

Also as I don't plan on becoming proficient in coffee-script, I'm less likely to adopt a early stage coffee script library as I will be dependent on others to offer bug fixes. Unless I want to modify the compiled code, in which case contribution/maintenance becomes more complex.

Re: Citation Needed

[kmoser]

TFA wasn't making the case that server-side JS itself was jaw-dropping; it was making the case that an application could be jaw-dropping if it was built by a rock-star JS coder who could code for both the client and the server.

Re: Citation Needed

[shutdown -p now]

The language has always had a lot of nice features, and isn't very kludgy at all. I will say that string formatting and Dates are probably its' weakest points, but there are lots of languages with those problems.

How about weird local variable scoping (that plays really badly with closures). Strange implicit type coercion rules? Magical semicolons in a curly-brace family language that sneak up where you wouldn't expect them to? Dynamically rather than lexically scoped "this" in closures (seriously, dynamic scoping by default in a language in the 21st century? for shame).

Re: Citation Needed

[shutdown -p now]

The problem with that view is that even the "good parts" of JavaScript are generally worse than the equivalents in comparable languages. Compare syntax for closures in JS and Ruby side by side to see what I mean.

Re: Citation Needed

[shutdown -p now]

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.

On the other hand, even the remaining 0.01% of libraries constitute more useful code than the entirety of npm repository at the moment.

Re: Citation Needed

[narcc]

1) You say stop trying to use it like an OO language yet the language supports OO features badly.

No, I said to stop treating it like a class-based OO langauge. JavaScript's objects are prototype-based. Just because you don't understand it doesn't mean it's bad. Try learning the language before you complain about it.

2) If you don't prefix a previously unused variable it goes into the global scope. What. The. Fuck.

Try learning the scoping rules. It makes perfect sense.

3 try learning the language.

4 is advice given to you by someone else who doesn't understand JavaScript, and also shows clearly that you don't understand 1.

5 Possibly your only legitimate complaint. Just use semicolons all the time, problem solved. Why you don't find similar complains about optional brackets in JS, C, etc.? All the same complaints apply.

7 is unsubstantiated nonsense.

8 Perhaps you don't know what NaN means? (Hint: NaN is a value, not a type) You'll find that in Java, Python, etc. NaN==NaN returns false as well.

Need I go on?

Please don't.

despite it's prevalence one simply cannot argue that it's a "good" language

You might want to learn the language before you make such a pronouncement.

Re: Citation Needed

[Xest]

Bless. Look at the amateur trying to pretend he knows what he's on about with cries of "learn the language".

Yeah, me and even the most experienced Javascript developers on the planet, obviously we all need to learn the language. Obviously the scoping rules and handling of captured variables make perfect sense, that's why they're the number one cause of bugs in Javascript yet largely a non-issue in just about every other language.

Let us bow down to your superiority as the only person who really actually understands Javascript.

Don't worry, maybe one day you'll get a proper job where you can use well designed non-toy languages and start to learn a bit more about good language design but yeah I guess in the meantime you can pretend it's just because no one else gets the language, only you do, because of course you're awesome.

But just in case you do wake up from your rose tinted slumber that shows a complete ignorance of language design and implementation of many other languages out there that simply do it better, then might I suggest you start by recognising that your entire post has missed the point? Hint: It doesn't matter if learning the language let's you work around these things, the fact I highlighted them demonstrates precisely that I do know the language, am aware of them, and hence can work around them, but that doesn't change the underlying point which people above have been trying to make to you - that these issues are the result of bad design and kludges. It doesn't matter if you can work around them, they just wouldn't be there in the first place if the language was well designed - yes there is a technical explanation as to why NaN works the way it does for example, but that doesn't make it a good part of the language.

A good, well designed language, doesn't require you to take extra steps to "learn the language" beyond the concepts necessary to use it at a base level, Javascript does (and so do languages like PHP) and that's exactly why it's kludgy. Compare and contrast to say, Java, F#, or C# and they far more often just work exactly as you'd expect - you don't need to go and learn a plethora of warts and quirks. Why? because they're far better designed and aren't kludgy. Which is kind of the point people have been making to you but you're apparently just not smart enough or educated enough about different languages, paradigms, and design issues to get.

Re: Citation Needed

[narcc]

Hint: It doesn't matter if learning the language let's you work around these things, the fact I highlighted them demonstrates precisely that I do know the language,

As I pointed out, Your "points" 1 and 4 show that, in fact, you don't understand the language. (This statement isn't even coherent: "This is a relic of the fact that Javascript wants to be both OO and Prototype based". What other conclusion could I draw?)

Points 2 and 3 clearly shows that you don't understand the scoping rules. Once you actually learn the language it becomes clear that there are no issues to "work around". The rules are simple and clear. There are no inconsistencies. Though it looks like you want to introduce some...

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.

If you understood the very simple rules, you'd know exactly why that happens. You'd also understand why it would be "kludgy" (inconsistent) to make it work like you suggest!

A good, well designed language, doesn't require you to take extra steps to "learn the language" beyond the concepts necessary to use it at a base level, Javascript does (and so do languages like PHP) and that's exactly why it's kludgy.

Here's something fun: PHP perfectly fits your criteria for a "good, well designed language" as it "doesn't require you to take extra steps to 'learn the language' beyond the concepts necessary to use it at a base level". Why, it's even a better fit than your exemplars: Java and C#.

That's embarrassing!

Here, I'll give you a chance to redeem yourself: Following your newly revealed definition for "good, well designed language" how does JavaScript fail to meet your criteria that would not also disqualify languages that you consider well-designed like Java and C#?

Good luck.

Re: Citation Needed

[leehanxue]

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?

Not so much the Javascript backend; but the fact that node.js is highly scalable, as well as event-based and non-blocking IO features.

Re: Citation Needed

[Xest]

"This statement isn't even coherent: "This is a relic of the fact that Javascript wants to be both OO and Prototype based". What other conclusion could I draw?"

That you don't know much about language paradigms? The problem is that the three pillars of OOP are inheritance, encapsulation, and polymorphism. In Javascript you can't do inheritance without sacrificing encapsulation which is a trait of it's prototype based approach and hence precisely why it's a farce to pretend it follows a genuinely OO paradigm. It clearly does not because it cannot fulfil the basic criteria of OO.

"Points 2 and 3 clearly shows that you don't understand the scoping rules. Once you actually learn the language it becomes clear that there are no issues to "work around". The rules are simple and clear. There are no inconsistencies. Though it looks like you want to introduce some..."

Of course there are inconsistencies, hence why you have to use a rather brutal hack to pass a variable value to a binding. Again you're just highlighting your lack of knowledge of other languages here, you say it's not possible, you say it can't be done, except every other language on the planet manages to handle scoping just fine, including other prototype based languages. I know what the scoping rules are, but to pretend there's justification as to why they have to be that way displays once more complete and utter ignorance of language design.

"Here's something fun: PHP perfectly fits your criteria for a "good, well designed language" as it "doesn't require you to take extra steps to 'learn the language' beyond the concepts necessary to use it at a base level"."

No it doesn't, you're just further demonstrating what very little knowledge you have of programming languages outside Javascript. PHP has a number of quirks that are a result of bad design that you have to learn to use it properly, just like Javascript. For example, with PHP, you have to be aware that it's ternary operator works in a completely backwards when chained, it's === operator compares value and type, except when it doesn't. Languages like Java and C# have none of these problems. The base language features of PHP neither work consistently nor in a logically sound manner (i.e. == isn't transitive). The same cannot be said of C# and Java. When I talk about base language I mean your standard features like logical operations, conditional operations and so forth without more advanced functionality like lambdas and such.

If you're not even aware of that then I can't really help you, you seem to know Javascript and nothing else so assume Javascript is the only way things can be done, which to anyone with even the slightest experience with other languages is obviously and demonstrably false.

You're one of those people whose only tool in their toolset is a plastic fisher price hammer, so you think the plastic fisher price hammer is the best thing ever invented and that every other tool must be exactly like this plastic hammer and that no other tool is possible.

Until you can discuss based on knowledge of languages other than Javascript I'm not quite sure what else can be said. The fact you believe PHP has no underlying quirks that are a result of bad language design and that must be learnt to use even the base language properly without introducing faults speaks volumes but given that you believe Javascript has no faults I'm not entirely surprised to hear that you also seem to believe PHP has no design flaws.

To answer your final question, well, I've already answered it, it's quite simple - not have poor design traits that result in inherently more buggy software at all skill levels. Javascript has all too many of those, and that's the problem.

Re: Citation Needed

[hackula]

Use coffeescript then.

Re: Citation Needed

[narcc]

That you don't know much about language paradigms? The problem is that the three pillars of OOP are inheritance, encapsulation, and polymorphism. In Javascript you can't do inheritance without sacrificing encapsulation

Umm... Inheritance is fundamentally incompatible with encapsulation. This isn't exactly a big secret. Google "inheritance breaks encapsulation".

The fact you believe PHP has no underlying quirks that are a result of bad language design and that must be learnt to use even the base language properly without introducing faults speaks volumes

Well, what are they? (Dare I ask after your failure to do the same for JavaScript?) One of the greatest strengths of PHP is that it is incredibly simple to learn and use. What are these mysterious quirks that millions of amateurs are apparently willing to slog through learning before hacking out yet another home-grown CMS?

not have poor design traits that result in inherently more buggy software at all skill levels. Javascript has all too many of those, and that's the problem.

What are these so-called "poor design traits that result in inherently more buggy software". More buggy that what?

I don't think you've thought this through.

Re: Citation Needed

[Xest]

"Umm... Inheritance is fundamentally incompatible with encapsulation. This isn't exactly a big secret. Google "inheritance breaks encapsulation"."

Wrong. In a language such as C# you can have a member set as protected, private, or public. If it's private data hiding is retained such that it's hidden from subclasses, if it's protected it's a shared property between parent and subclass, if it's public it's not hidden to anything. Nothing here breaks the principle of encapsulation as levels of data hiding are provided to cover each eventuality. Either the data shouldn't be shared, it should only be shared with inherited classes where the shared member makes sense, or it should be shared with anyone.

Contrast this to Javascript where you can't have members shared only with inherited classes they have to be made public to everyone.

If you have a Mammal class with a brain property that shouldn't be public then with C# you could create a Human and Horse subclass that retain data hiding by calling it public - both are still meant to have a brain, it makes sense. With Javascript everyone has to access the brain, or your Human and Horse don't have a brain, data hiding is broken.

You can of course produce broken designs in class based OO languages if that's what you're referring to but that's not an inherent language fault like Javascript's failure to maintain encapsulation in the face of inheritance is.

"Well, what are they?"

Um, learn to read? I provided some examples.

"One of the greatest strengths of PHP is that it is incredibly simple to learn and use. What are these mysterious quirks that millions of amateurs are apparently willing to slog through learning before hacking out yet another home-grown CMS?"

That's exactly the point, just as with Javascript they don't slog through them, they're just not even aware of them and as a result they write wrong code, buggy code, vulnerable code. The same is not true of languages like Java and C#.

"More buggy that what?"

More buggy than an equivalently skilled developer would produce with better designed languages. There's a reason most security exploits on the internet nowadays hit PHP web applications and so many sites have Javascript faults and it's certainly not because PHP is more popular given that C# and Java are erm, more popular.

Still enough is enough, you're obviously not willing to learn enough about this topic to have a rational conversation instead quoting lines from books that are now nearly 20 years old from when OO was far less common and far less well understood and (in many cases) implemented. It's obvious you're out of your depth given that, not that your inability to understand why many things in Javascript's inherent design are bad didn't make it obvious enough already.

Have fun basking in your ignorance with your Javascript and PHP with all the other low skilled web hipsters.

Re: Citation Needed

[narcc]

Wrong.

No, it's true. Inheritance breaks encapsulation. This is a indisputable fact. It's VERY well established in the literature. The problem, it seems, is that you simply don't understand what that means. Do you have an ACM DL subscription? If not, get one. You'll find plenty has been written about that very subject.

That's exactly the point, just as with Javascript they don't slog through them, they're just not even aware of them and as a result they write wrong code, buggy code, vulnerable code.

Have any evidence? Because I don't think you do. (I think you're making this up as you go along.) Where's the research? Make use of your ACM DL subscription.

That's not fair. I know you can't actually produce anything like that. How about some specific examples like I asked for in an earlier post? Surely, you have something specific in mind?

Now, I will agree that people don't use JavaScript correctly. That was the point of my first post. The problem isn't the language, of course, but people trying to use the language like it's a class-based, not prototype-based. Once you learn the language, you'll find that there's nothing wrong with it. There are no "quirks", as you like to say, it's just different. Give Scheme and Forth a go and you'll find they're just as different, but not poorly designed in any way. (The difference? You can't pretend that Scheme and Forth are just like Java and C# like you can with JavaScript. If there's any problem with JavaScript, it's that the familiar syntax makes naive developers think that there's nothing new to learn.)

More buggy than an equivalently skilled developer would produce with better designed languages

Again, what makes a language poorly designed? What makes a language "better designed"? Is there some ultimate ideal language design? I still don't think you've thought this through.

instead quoting lines from books that are now nearly 20 years old

I did no such thing! (I actually had a much older paper in mind when I told you that inheritance breaks encapsulation.) You had never heard of such a thing and did a google search (as I asked), landing on Wikipedia, where you learned that the subject was mentioned in the GoF book.

you're obviously not willing to learn enough about this topic to have a rational conversation

I'm not willing to learn?!

How about answering the very basic questions about your assertions? Asking questions shows a willingness to learn, doesn't it? I've not asked any difficult questions, after all. If you want me to learn, surely you could take the time to answer them, or at least direct me to the relevant research from which I'm sure you've formed your opinions?

You're not just repeating empty platitudes, right?

Re: Citation Needed

[aztracker1]

That dynamic scoping makes for really nice unit test capabilities. I do agree with variable scoping, and usually find the coercion more useful than not (I think my biggest issue tends to be when I'm doing validation and a Zero is a valid value for my use).

Automatic Semi-Colon Insertion issues can be averted by using a linter (jslint|jshint) on your code... It's a bit of a mixed bag, and I tend to put semi colors where intended... I think this is mainly a behavioral issue with coding style and understanding the language.

Re: Citation Needed

[aztracker1]

While I linke EF a lot, I'd say it's a stretch to say you don't need to understand T-SQL to be effective with it... In many cases how you pull data out can dramatically effect performance of a given query. Wierd join statements in LINQ etc sometimes lead to very strange N+N results. And serializing your entities brings in a much bigger can of worms.

Re: Citation Needed

[KingMotley]

Use POCO objects with a DbContext and you won't have any issues with serialization nor the N+N issues. That's the default for code first anyway. Of course your code may not work as you want, but that is a bit different than having to know T-SQL. Of course some knowledge about relational databases would help in the stickier stuff, but it isn't really necessary in most cases.

Re: Citation Needed

[Xest]

Sigh, okay, I'll bite, I'll try one last time on the principle that your claim of being willing to learn is posed on good faith, but you have to do me a favour, you have to actually read what I write now, and re-read what I posted previously where relevant because claiming you're willing to learn and that I haven't answered your questions when I have actually done so doesn't strike me as the attitude of someone that's willing to learn, it strikes me as the attitude of someone that doesn't want to learn and wants to stick to his guns no matter how wrong.

"No, it's true. Inheritance breaks encapsulation. This is a indisputable fact. It's VERY well established in the literature."

No it isn't indisputable fact, and where it's "established" in literature that literate is rather old and dated, and everything else that "establishes" it does so by just parroting those dated arguments without trying to see if they still make sense.

The arguments made a bit more sense when keywords like protected weren't implemented, or were implemented poorly but afterwards the argument seems to have evolved more into what happens if you create a sub-class that's tightly bound to a parent class and you later need to change the parent class? This is literally the only argument remaining backing the claim but it's wrong, because it's premised on the idea that bad design has been used and ignores techniques that are commonplace to resolve such issues nowadays like IoC/DI.

So yes you can of course create bad hierachies and bad OOD in a class based OOP language, but that's a fault of the developer, not the language.

Compare and contrast this to the original argument that Javascript does not properly implement OO and is badly designed as a result and it's night and day - in languages like C# and Java inheritance breaking encapsulation occurs as a result of bad design by the programmer, whilst with Javascript it's broken as a necessity of bad design by the language, and that's the fundamental difference. Effectively in something like C#, bad OO design is optional, in Javascript it's a necessity because you can't ever safely inherit, you need to get that fundamental difference as to why one is far worse than the other, something you've not grasped to date.

So moving on from this point I'm going to throw it back to you, I've explained twice why inheritance doesn't inherently have to break encapsulation in well designed languages, it's now up to you to prove that it unavoidably does and then hence explain how this therefore justifies Javascripts position of requiring forced breaking of encapsulation in every case, rather than class based OO's accidently breaking in cases of poor design if you wish to persist down this route. That doesn't mean fob me off with academic papers that don't back up your position because the chances are I've read them and as I say they stem from an era when languages were very different such that their arguments are no longer valid, or instead just hinge on assuming bad design (which is a different problem).

"Have any evidence? Because I don't think you do."

Answered already. Check the web for the plethora of people citing problems with their Javascript programs that stem from the previously mentioned examples of bad language design. Because these problems are inherent only to Javascript it's a given then that it introduces more issues than other languages that don't have these problems because Javascript developers face the problems shared with those languages, and then the problems that are Javascript specific on top. Again the same is true of PHP - it results in inherently worse software because more pitfalls = more bugs.

"Once you learn the language"

You keep repeating this but miss the obvious - people have to go to much greater lengths to full learn all of Javascript's quirks than they do most other languages, and that in itself is a problem because if they have to go to greater lengths then there's a greater chance they'll miss things. Your argument can be exte

Re: Citation Needed

[narcc]

No it isn't indisputable fact, and where it's "established" in literature that literate is rather old and dated

So we should toss out relativity and quantum mechanics as well, eh? (Old doesn't mean invalid.) Put that ACM DL subscription to good use. You shouldn't have too much trouble finding more modern if that's important to you.

The arguments made a bit more sense when keywords like protected weren't implemented, or were implemented poorly

Again, you don't understand the problem. It's a fundamental problem, not something that can be fixed by adding a few language features!

Compare and contrast this to the original argument that Javascript does not properly implement OO and is badly designed as a result

A couple things: 1) There is no such thing as "proper" OOP. There is no consensus on the definition. 2) You have not established that JavaScript "does not properly implement OO" As I explained earlier, it's prototype based, not class based -- like several other languages. It's not bad simply because you don't like it.

I've explained twice why inheritance doesn't inherently have to break encapsulation in well designed languages

The problem is that your explanations don't actually address the issue at all! Again, it's fundamental -- this is very well established in the literature. It's not magically changed simply because a book you found on wikipedia and the paper I offered were older. Put that ACM DL subscription to use and find something to make your case -- you'll find that it's indisputable: Inheritance breaks encapsulation.

An example of a design flaw is PHP's === equality operator not working consistently and it's == operator not being transitive. There's not excuse for this

Assuming you're talking about the NaN thing from before, you'll find that it's a natural consequence of IEEE 754 -- and that that behavior is correct and expected in all languages. (Seriously, it's in the damn standard.) If you're speeking more generally, you'll find that PHP's == and === operators do indeed work consistently, behaving like similar dynamically typed languages. (Go ahead and try out some of the examples you found of "inconsistency" online in C, with explicit casts and you'll find the behavior is identical. Don't like C? The same will hold for Java as well.)

One language is better than another if it has less design flaws

That's not an answer to the question. What are these "design flaws"? How can they be identified?

The required additional syntax to create a new scope to make this work is nonsensical and a result of the lack of foresight in the language's design

No, the problem was that the stackoverflow posted doesn't understand closures. You'll find the EXACT same behavior in C# -- one of your exemplar languages. In fact, this confusion over closures lead Microsoft to change the behavior of foreach loops!

It's not an issue of language design, it's just how closures work. (Imagine how bizarre and unexpected the behavior of for loops would be if MS decided to change their behavior to match that of foreach!)

Surely you must at very least understand that simplified and more readable syntax to solve an identical problem is both better for developer efficiency and is better for supporting less buggy software.

Readability is important. I couldn't agree more. However, in the example you gave, C# behaves just like JavaScript. It's not a language design problem. It's not a problem at all. It's just how closures work.

I hope you can finally grasp why unnecessarily verbose code to solve simple problems resulting from lack of foresight during language

Re: Citation Needed

[Xest]

See, I told you you just didn't get it.

I provided objective facts that demonstrate the problem and you came back with misdirection and nonsense. This is perfect proof that you are not willing to learn and prefer to bask in your own ignorance.

Examples: You claim OOP isn't defined when it is, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem which I pointed out about 10 posts ago, you demonstrate you don't understand inheritance and encapsulation, you try and pretend because old books on quantum physics still have some relevance that that's somehow equivalent to old studies into OO language design are still 100% relevant - I suppose you think Russell's Principia Mathematica is 100% relevant still just because it's old even though it's wrong right?, you claim that PHP's == and === operators work as in any other languages and show that you have absolutely no knowledge of PHP or other languages given that that's well established to be false.

You're a lost cause, you have no idea what you're on about, you have pitiful knowledge of OO, you don't understand why unnecessarily verbose code leads to more bugs, and you don't understand the importance of mathematical concepts in languages like transitivity. You're an amateur, but given your depserate defence of Javascript and PHP that's not exactly surprising is it given that they're the go-to languages of amateurs. You could have at least learnt a bit about PHP before defending it though, the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.

So good luck with all that, I guess you enjoy defending your own stupidity. Do me and everyone else a favour at least though, stop pretending you're willing to learn, it's obvious you want anything but, you just want to stay stupid.

Re: Citation Needed

[narcc]

You claim OOP isn't defined when it is

No, I said that there was no consensus on the definition. That is true. Indeed, it's indisputable! You seem to like wikipedia, so you can check there. I did a quick google seach for you and found a few neat discussions that may be helpful for you.

, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem

Pay attention. Microsoft changed how foreach works, not how for works. Your example deals with for loops. You'll find that my statement is correct.

Additionally, you should consider what a similar "fix" for the non-problem in for loops would entail, and why the behavior of for remains the same.

That's all irrelevant, however, as the problem the poster had in the example you gave was a simple misunderstanding of how closures work. It's not a language design issue.

the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.

Pray tell, then. What are the problems? (I've explained why NaN!=NaN already. See IEEE 754 if you forgot) If you're talking about things like intransitive equality, you're just confused. You'll find identical behavior in virtually every other language. Not just those with dynamic typing -- recreate the examples you found in some blog post in Java or C, applying relevant type casts. Look at that! The behavior is the same!

Now, you're welcome to list which type conversions you find irrational, though once you look, you'll find they're all perfectly sane. It behaves exactly as you would expect from experience with your exemplar languages.

you don't understand why unnecessarily verbose code leads to more bugs

Check my post again. I agreed with that specifically. I also challenged you on Java (one of your exemplars) as it is unnecessarily verbose! JavaScript and PHP are positively terse in comparison.

I will offer, for your consideration, that unnecessarily terse code also is less readable, often leading to more bugs and making maintenance difficult.

Moving on. I find it odd that in response to evidence that directly contradicts your claims, and which support my own, you offer only bold assertion.

I asked you some very simple questions so that you could make a stronger case. (Well, to let you actually make a case!) If I'm wrong about something, I like to know. I'm disappointed that you'd rather insult me than actually discuss the issues.

This whole dialog started with your objection to some simple advice I offered another user: don't use JavaScript like it's a class-based OO language. I still don't know why you found that unreasonable, as JavaScript is prototype-based. (There's a paper you might find instructive here: D. Ungar & R. B. Smith (1987) "Self: The Power of Simplicity", OOPSLA '87 Conference Proceedings, pp. 227-241)

Anyhow, with this post I've left you with some reading and experimenting to do. Give it a go and let me know the results. I expect that you'll be unpleasantly surprised.

Re: Citation Needed

[Bengie]

But that is not 100% transparent. It requires defining objects in C#.The point isn't that it's "little work", the point is that it's 100% transparent, as in your treat it no differently than you would treat something else. In C#, you still treat them differently, even if it is simple.

Re: Citation Needed

[KingMotley]

And how is this less transparent than the proposed javascript stack? Are you suggesting that it wouldn't "require defining objects"? I seriously doubt you understand what you are talking about.

Javascript is now web scale

[Lunix Nutcase]

No, it's fanboy hyperbole.

Re:Javascript is now web scale

[fustakrakich]

It's a trap!

Re:Javascript is now web scale

[Anonymous Coward]

Plus, everything old is new again.

TL;DR: Netscape had server-side Javascript in 1994. It didn't take off.

Re:Javascript is now web scale

[Requiem18th]

Because people have never found out that relying in a proprietary web app has shortcomings...

Re:Javascript is now web scale

[Wootery]

Not always, which was part of his point: he's discussing obfuscated JavaScript.

From the GPL 3.0:

The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

In other words: just because JavaScript is deployed in the same language as it's written doesn't mean that what your browser receives is the source code. JavaScript obfuscators/compressors/optimisers introduce a source/'object' distinction comparable to what we see in C.

Also there are JavaScript development frameworks which translate some other programming language into JavaScript. GWT does this. Again, what your browser receives is certainly not the source.

Re:Javascript is now web scale

[yenic]

It is kind of fanboy hyperbole. But what no one has noted is that as work is shifted from the server to the browser, JS is in a unique position in that regard. Everyone keeps saying how someday we'll be charged by CPU time in "the cloud". If so, work can be dynamically pushed to the client or server side dynamically much more efficiently than a Ruby backend to JS frontend. If that would even be a feasible task to attempt at all.

Full-stack

[Anonymous Coward]

lol

go home Nerval's Lobster, you're drunk

they won't emerge and it won't be jaw-dropping

[Anonymous Coward]

'But if and when they do [emerge], the things they build could be jaw-dropping.'

These mythical ace developers who are brilliant at browser and server javascript will never emerge in large numbers. "full stack" javascript will not produce anything any more jaw-dropping than any other stack is already doing.

I've been using node.js and while javascript is become passable as a browser language, it still sucks as a server language.

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

[ron_ivi]

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

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.

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

[Maudib]

There is shit loads of javascript on google.com

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!

Full Stack?

[twistedcubic]

What does full-stack mean? Is this akin to a "fully-loaded" car?

Re:Full Stack?

[OakDragon]

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

Re:Full Stack?

[OakDragon]

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:Full Stack?

[dingen]

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:Full Stack?

[Anonymous Coward]

Traditionally, Javascript has been used only as a client language, running in your browser

Yes, that was the "tradition" before Netscape's Server-side Javascript support.

Re:Full Stack?

[hackula]

I will fight smartassery with more smartassery by leaving this here for you http://appjs.org/

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

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

[Anonymous Coward]

Because, you know, Python doesn't really need that. Since it isn't designed to be a scripting language run in a browser and then tortured into running "natively."

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

[Lunix Nutcase]

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

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

Re:partly engineering resources put into compilers

[Hentes]

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

Re:partly engineering resources put into compilers

[Maudib]

(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 both Vert.x and node.js only read the file once using this:

https://gist.github.com/2652991

Then node.js ends up performing substantially better than Vert.x. I changed both Vert.x and node.js apps to match so it would be apples to apples comparison.

The results I got had node.js outperforming Vert.x by 50%."

Re:partly engineering resources put into compilers

[hackula]

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.

Re:partly engineering resources put into compilers

[MostAwesomeDude]

You picked a poor example, as PyPy is also state-of-the-art, PhD-powered, and loaded with just as much performance-enhancing optimizing code as V8. Additionally, JavaScript can easily be rejected on the demerits of being a poor language.

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

[Anonymous Coward]

...And MongoDB isn't particularly impressive, either; it's basically a database for people too stupid to understand SQL.

Or relational theory.

Re:Javascript anywhere but the browser? No

[0xdeadbeef]

Getting trounced by PHP is not a point for JavaScript.

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

[Anonymous Coward]

> And MongoDB isn't particularly impressive, either; it's basically a database for people too stupid to understand SQL
> (Score:5, Interesting)

You people really are the bottom of the barrel.

Perhaps.

Or maybe we've experienced the joy of non-relational data in mission-critical applications.

"Oh, look, it's a string, anything can be anything now! It's so easy to code! $100 can be $1000!"

Re:Javascript anywhere but the browser? No

[Laxori666]

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.

Re:Javascript anywhere but the browser? No

[hackula]

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.

Re:Javascript anywhere but the browser? No

[Zof]

Tada! JSLinux: http://bellard.org/jslinux/

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.

Re:Javascript anywhere but the browser? No

[VoidEngineer]

Overrated. Most use cases don't need proper relational theory. Convergence to consistency is sufficient for most people's needs. Denormalized DRY data is less important now that memory is plentiful. Speaking as somebody who was an SQL admin for 10+ years, and am happy to have made the leap to Map/Reduce and won't ever be looking back.

Re:Javascript anywhere but the browser? No

[VoidEngineer]

Some people like riding a chopper. :)

In all seriousness, this is an insightful comment. I tend to make the analogy that LAMP stacks are like prop propeller airplanes, whereas Javascript/Mongo frameworks (like Meteor) are akin to Jet Turbines. If you want to break the sound barrier, a propeller airplane simply won't do the job. But a jet can.

Re:Javascript anywhere but the browser? No

[VoidEngineer]

Word. +1

"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:"ace JavaScript developers who can write"

[Anonymous Coward]

Most of the ace JavaScript developers that I've met have backends that are anything but jawdropping

javascript for domain of in browser interactivity?

[Anonymous Coward]

As noted on slashdot a whole back Fabrice Bellard has written an x86 emulator out of javascript... and made a whole linux system in a browser: http://bellard.org/jslinux/

With other technologies, (gwt etc) javascript can be thought of as a compiler end result language. Yet, even a 'primitive' or difficult language is just another means of expressing a concept that is in the programmers head. There have been programs coded in assembly language that were amazing, fantastic and clear. Others were so efficient that they were an obfuscated mess to the casual observer, and only understandable after knowing the hardware and assembly language intimately.

Javascript is just a language, leveraging frameworks can make it more 'sophisticated' but.. .it is just a way for the programmer to communicate with the hardware to make it all happen.... A good programmer knows how to make hardware happen.... the language is just a different vocabulary.

You mean as good a regular programmers?

[xxxJonBoyxxx]

>> 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:You mean as good a regular programmers?

[hackula]

As as node.js dev.... **cringe**


That quote made me want to barf.

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

[RightSaidFred99]

Lolbullshit. It does not run around 2X the speed of native C/C++ code unless that native C/C++ code is shit.

Re:No, node.js and mongodb are cancer

[Anonymous Coward]

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

Why would any kind of JavaScript compiler be able to generate object code which is magically faster than another language such as C++?

Do you understand how a compiler works? Do you realize that if a JavaScript compiler was able to generate a particular pattern of instructions which implements a particular computation expressed in JavaScript, that there are no fundamental laws of nature which would prevent a compiler in any other language for generating the same pattern of instructions?

What next? JavaScript that runs in a browser with 3x the speed of the equivilient machine code? Will you tell me that Java or C# are slow because they are "interpreted"?

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:No, node.js and mongodb are cancer

[vilanye]

Do you understand that there are certain things that are only knoawable during runtime which a static compiler can not optimize for but a JIT compiler can?

Admittedly, JIT on client-side JS isn't as useful as JIT on long running server processes(JIT it is why C and C++ can always smoke Java in short running processes but the tables get turned when the process runs for hours, days, weeks, etc) but there is some advantage on the client side.

Lets just go all the way here for a bit...

[bradley.meck]

Python, Ruby, Lua, PHP, Lisp, Perl, Awk, etc. are bad : they lack pointers and strong types. Oh and lets not forget type coercive language in respect to strings (or pointers since that was brought up) ...

Re:Lets just go all the way here for a bit...

[EvanED]

I would say that Python and Lisp at least are both reasonably strongly-typed (just because they're dynamic doesn't mean they can't be strong). PHP and Perl are both definitely weakly typed. The others I don't know well enough to evaluate.

But at this point I honestly don't know what people really mean when they complain that X language doesn't have pointers. Because basically everything out there offers something like Java references. Are people really missing pointer arithmetic? How often do you need that?

Re:Lets just go all the way here for a bit...

[bradley.meck]

Bundled in the dynamic languages here but anything that doesn't have pointers fails the OP's test... which is a lot these days.

Re:Lets just go all the way here for a bit...

[EvanED]

...anything that doesn't have pointers fails the OP's test... which is a lot these days.

And my point is that it's a dumb test. (Granted, I did say it in response to you. :-))

Re:Lets just go all the way here for a bit...

[XcepticZP]

Python is a strongly typed, but not statically typed language. This is a common misconception that I see in almost every discussion on the merits of python vs more traditional, compiled languages.

Here is a linkie that explains it rather simply, in case you want to research it further.

Btw, javascript is not strongly typed.

Re:Lets just go all the way here for a bit...

[styrotech]

Python, Ruby, Lua, PHP, Lisp, Perl, Awk, etc. are bad : they lack pointers and strong types.

So what reasonably popular actually useful languages aren't bad?

I would've though C++ and Ada could fit your requirements for pointers AND strong typing, but they don't really seem all that useful for the purposes of the topic at hand (webapps).

Re:Lets just go all the way here for a bit...

[styrotech]

I forgot about Go? Is that it?

Re:Lets just go all the way here for a bit...

[vilanye]

Python, Ruby and Lisp are all strongly typed. C is not strongly typed, why didn't it make your list? Perhaps you meant statically typed?

Lolwut?

[RightSaidFred99]

Javascript is a terrible language for back-end development. It's a terrible language for _front end_ development but it's all we've got. Microsoft tried something very cool with Silverlight (.NET in the client) but it crashed and burned. So why would one want to use Javascript when C# or Java (or other shitty but still better than javascript scripting languages people seem to be into, I guess) are available on the back-end?

"But if and when".... "then"

[Zedrick]

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.

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.

Python has pointers the way Java does

[tepples]

Python has pointers in the same way that Java has pointers: objects are passed as references. Besides, there's a difference between strong typing (automatic coercion) and static typing (variables can hold references only to a particular type and types that extend or implement it). Python has strong types (1 + "2" raises TypeError) but, like JavaScript and PHP, lacks static typing apart from a few specialized numeric containers (such as array.array).

Re:Python has pointers the way Java does

[Laxori666]

Actually, Python doesn't pass objects as references. It's call by object. It might take a few read-throughs to grok it but it's well worth it.

Re:Python has pointers the way Java does

[XcepticZP]

The linked page is painful to read. Do you perhaps have a better link on the topic? I tried searching, but it didn't yield much except for one rather empty SO question.

Re:Python has pointers the way Java does

[tepples]

By that definition, Java and JS are call-by-object too, correct?

Re:Python has pointers the way Java does

[Hentes]

Those are different from C pointers. Let me show you an example:
//in C++
int x=1;
int* y=&x;
x=2;
cout<<*y; //outputs 2

#in Python
x=[1] #we're using an object
y=x #x and y now reference the same object. If we were to modify x, y would also change.
x=[2] #that link, however, is broken on assignment
print(y) #outputs [1]

Re:Python has pointers the way Java does

[Bill_the_Engineer]

The link you just gave says " The most accurate description is CLU’s “call by object” or “call by sharing“. Or, if you prefer, “call by object reference“.

In other words, it IS call by reference. The author is trying to be clever.

Re:Python has pointers the way Java does

[shutdown -p now]

Simply put, Python (and Java, JS etc) pass object references by value. This is different from the traditional call-by-reference, because references in those languages are first-class values; they don't only exist as a parameter modifier, but your variables also store references, and you can rebind a variable (including function parameters) to hold a reference to a different object.

This gets more complicated when the language also has true call-by-reference, as e.g. C# does with "ref". Then you get things such as object references passed by reference, and people get confused.

Re:Python has pointers the way Java does

[shutdown -p now]

No, it is call by value, where the value being passed is a reference. By your definition, any C function call involving a pointer would also be "call by reference".

Re:Python has pointers the way Java does

[shutdown -p now]

Can you give an example of a pointer-typed function argument in C being used to 1) pass something by reference, and 2) pass something not by reference?

My logic is pretty simple: it's only pass-by-reference if the function parameter itself becomes an alias for another value in the caller. In other words, you should not need any special syntax to access or modify the reference value; the fact that it's an alias is completely transparent to you. Examples of language features that work this way are C++ references (&), Pascal "var" (and, in Delphi, "const") parameters, BASIC "BYREF", and C# "ref" and "out". Examples of language features that do not qualify are C pointers, because you need to explicitly dereference them via * or -> to access the value; if you do not do that, then you're operating on the pointer itself. In other words, you do have a pointer that is passed by value, and that can coincidentally be dereferenced.

The reason why Python does not qualify is a bit more subtle. There's no special syntax involved, but the value of the argument inside the function is a new reference (which is itself a value) to an existing object. This is obvious once you try to mutate the argument inside the function, or to observe a mutation performed by outside code. In true pass-by-ref, you'll see the change. For example, in C++:

int x;
void foo() { ++x; }
void bar(int& y) {
  foo();
  cout << y;
  ++y;
  cout << x;
}
bar(x);

This is true pass-by-ref: y is an alias for x, any changes made to x are immediately seen through y, and any changes made to y are immediately applied to x. In contrast, in Python:

x = 0
def foo(): x += 1
def bar(y):
  foo()
  print y
  y += 1
  print x
bar(x)

Argument y is not an alias for x. Initially, it is bound to a copy of an object reference that is stored in x - so both variables hold identical (reference-typed) values, which refer to the same object: int 0. However, when foo changes the value of x, that change is not reflected by y - the variables now hold two different (reference-typed) values: one is still a reference to int 0, the other one is a reference to int 1. Further changes reinforce the point that variables themselves are not tied in any way.

Simply put, object references in Python (and Java, and C# etc) behave exactly like C pointers (and not like C++ references), except that there is an implicit dereference on every member access - so Java's foo.bar() would be C++ foo->bar() - and no pointer arithmetics. However, there's no implicit dereference on assignment or comparison. Also, for languages with explicit typing, indirection is always implied in type declarations for reference types - so "Foo a" is effectively "Foo* a".

As a side note, while I do happen to be a Python enthusiast, it is but one of a dozen programming languages that I know well enough. As it happens, study of PL history and design is my hobby. So I do understand the difference between "pass by value" and "pass by reference" (and "pass by name" etc) just fine, thank you.

Re:Python has pointers the way Java does

[Laxori666]

Hmm, according to the Wikipedia, Java is indeed call-by-object for object parameters, and I think it must be call by value for primitives.

Re:Python has pointers the way Java does

[Laxori666]

Yea check out this Wikipedia article. It seems a lot of the confusion is that people use the terms call-by-value and call-by-reference inconsistently. It might be more a matter of vocabulary instead of actual confusion of what happens.

Re:Python has pointers the way Java does

[vilanye]

Java is pass by value, with no exceptions.

It uses the exact same passing mechanism as C.

In Java the value being passed is either a primitive value(int, float, etc) or an integral value that points to the object.

Why so many people get confused over a basic concept is something I will never understand.

You know how math dumbs down the defintion of a function as the vertical line test? Well, here is a dumbed down test for pass by value vs pass by reference:

If you can swap values in an array like this:

swap(Type arg1, Type arg2) { Type temp = arg1; arg1 = arg2; arg2 = temp; }

the language, at the very least, supports pass by reference. If it can't, it is pass by value.

Everyone confused about passing semantics should read this: http://javadude.com/articles/passbyvalue.htm

Re:Python has pointers the way Java does

[Laxori666]

It's certainly not pass by reference. However, it is "call by sharing" for objects. You've demonstrated your ignorance by not reading the Wikipedia article, which even says: "However, the term "call by sharing" is not in common use; the terminology is inconsistent across different sources. For example, in the Java community, they say that Java is pass-by-value [...] Call-by-sharing implies that values in the language are based on objects rather than primitive types."

The distinction is this: although you could certainly implement Java's passing scheme by passing pointers (memory addresses) by value, the language itself doesn't deal with pointers at all. The semantics are such that both the caller and the callee have variables that point to/refer to the same object - i.e. they share the same object. Thus you could describe it "as call-by-value, where the value is implied to be a reference to the object.", or you could describe it as "call by sharing", which is simpler. Note that with "call-by-value" you have to specify that the value isn't the object itself but rather a reference to the object.

Either way we're describing the same behavior. It's just a matter of the words we're using.

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.

Re:mod Up

[dingen]

This one won't beat the Turing test yet, but keep trying!

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

[dingen]

What does unit testing have to do with validating user input?

Re:Verifying equivalence of client and server code

[tepples]

From Limitations of unit testing

Testing will not catch every error in the program, since it cannot evaluate every execution path in any but the most trivial programs. [...] In order to guarantee correct behavior for every execution path and every possible input, and ensure the absence of errors, other techniques are required, namely the application of formal methods to proving that a software component has no unexpected behavior.

Besides, if I have written a program and want to run it in two environments, why should I have to write it twice? Why shouldn't I be able to write it and then have the computer write the other one?

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.

Re:Verifying equivalence of client and server code

[bmk67]

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:javascript for domain of in browser interactivi

[stuporglue]

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.

blur client-server line

[DrEasy]

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

Re:blur client-server line

[gauauu]

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 perfect by any means, but it's the closest thing I've found to what you're talking about)

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:blur client-server line

[XcepticZP]

Congrats to them, they've just reinvented web forms from asp.net, which we've had for years if not a decade.

You can't polish a turd but you can roll it in gli

[mat690]

All they need to do now is shoehorn PHP and MySQL in there somewhere, code it all in notepad and you have the development stack from hell.

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.

Re:Javascript is still single-threaded

[dingen]

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:Javascript is still single-threaded

[jlowery]

been using it for nearly a year now. Currently supports the company's website of over 400 pages.

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.

One language to compile them all...

[TiggertheMad]

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 detail to learn as learning several languages (where 'learn' means have a good understanding of API, objects, methods, etc. and not just a rudimentary comprehension of syntax).

MongoDB ad

[Animats]

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:MongoDB ad

[aztracker1]

I think the biggest advantage MongoDB has over other DBs in this respect is the console interaction for MongoDB is based on a JS REPL interpreter... that said, it really depends on your needs. If you need caching of data there's Memcached, if you want that with persistence and pub-sub there's Redis, if you care more about bigger storage there's Couch, if you want some hybrid SQL-like functionality there's MongoDB and RethinkDB... there's even column-based dbs and a lot of others.

MongoDB is probably the most natural fit for NodeJS for the most broad of use cases. It's isn't a one-size fits all problem solver, and neither is any SQL solution depending on your needs.

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

ZERO JS and proud of it!

[arfonrg]

"It's effectively impossible to launch a sophisticated Web project without making extensive use of JavaScript and AJAX dynamic loading."

Yeah, that's why my (extensive) web infrastructure has ZERO javascript in it....

Please

[gtirloni]

Wake me up when this is over.

no ffi

[MetalOne]

Until Javascript has a standard foreign function interface, and people being writing bindings to C/C++ libraries, and there exists some sort of packaging system to install these bindings and libraries, Javascript will be severely lacking capabilities present in several other languages.

Re:no ffi

[Maudib]

(1) NPM works just find for package management.
(2) https://github.com/rbranson/node-ffi

I guess we are good now.

carbon footprint?

[opencity]

It seems to me (normal career newb disclaimer here) that node is going to burn less juice than PHP under Apache. Disregarding for a moment my general dislike of php (except the paychecks) and my general dislike of the Drupal/WP/Joomla ... uh ... paradigm my experiences with node/mongo have been very refreshing. Async is a cool way to work with once you get your head around it (my head maybe 90 degrees so far ...) and Mongo / document storage is way more natural for certain kinds of relatively big data issues than mysql (which I have no hatred for)

But back to the top. Hey server guys and gals: Wouldn't node draw less electric, like way less. So if my webbloging socialnetworking ecommercing socialgaming buzzwordcompliant client blows up they'd need less of a web armada ... right? And they'd be helping the environment by not using Wordpress or Drupal.

Stop bashing JavaScript - and stop evangelising it

[Anonymous Coward]

Briefly, I work at a company that produces your stereotypical "web app": a minimal index.html which pulls everything in via JavaScript. We deploy to ~12,000 physically separate production environments every few months. Prior to my current gig, I helped build Node.js daemons / WebSocket functionality in a FTSE 100 company on a site that receives so many millions of hits per-day I can't remember the numbers. TL;DR I'm not just sitting in my bedroom writing Node.js "Hello World!" apps.

All the arguments I've read above have some serious issues:

JavaScript is a shit language: Fuck off.

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

JavaScript is insecure: You're doing it wrong.

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

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?

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.

I could go on, but I'm tired of dissecting your attempts at a debate. For a damn good overview, see this StackOverflow discussion.

Lastly, has anybody considered why JavaScript is becoming a "lingua franca"? Every language since assembly languages has focussed on abstracting stuff away from the programmer when it isn't necessary. When I'm writing a web app, I don't give two hoots whether how big your address space is, what network interface you're using, how big your monitor is, or anything else below the level of the browser. I care about drawing stuff on the screen with minimal effort.

Different problems require different solutions. In some cases, JavaScript all the way through might be a good fit. Most of the time, it won't be.

Re:PHP runs in IE

[wonkey_monkey]

Great! Now all we need to do is get everyone else to do that (and to switch to IE) and we'll have a competitor to Javascript.

no benefit

[sribe]

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 detail to learn as learning several languages (where 'learn' means have a good understanding of API, objects, methods, etc. and not just a rudimentary comprehension of syntax).

I work constantly in C, Objective-C, C++, Ruby, bash, and javascript. I have worked in Common Lisp, Pascal, various assemblers, Python, Dylan, various nasty proprietary "4GL" languages, AppleScript, Visual BASIC, C#, Java...

There is no benefit to flipping between high-level scripting languages throughout the day; it is a complete waste of cognitive effort.

Please top hijacking Javascript _

[Anonymous Coward]

I'm sorry, I don't know or care what "full stack" means in this context, but please stop extending the Javascript language to do things it was not supposed to do, and just making it horribly more complex than necessary.

There's the C++/Java people who keep trying to turn Javascript into a class'd OOP language, which it isn't, and should never be.
There's the Media people who can't standardize on an Audio API, let alone an Audio or video container or codec, so web browsers and javascript are left having to bit fiddle
There's the OpenGL games people who keep trying to turn Javascript into a WebGL game platform, which isn't ever going to work. Look at Polycraft, the game basically is only capable of PSX (yes playstation 1) level of graphics, and even that is unable to take advantage of multiple cores, so it's never going to be able to do anything better. WebGL was meant for previewing models, not playing games. If we want to use WebGL for playing games, a higher level API is going to be required, because a low-level API is horribly slow.
Then there's the DRM people who want to protect their media despite there being NO STANDARDIZED VIDEO TO BEGIN WITH.
And of course there's the absolute lack of being able to use multithreading in any shipping browser.

The "web" platform, is not for games, and not for media. That is clear. That has been clear since Flash has been doing these things since Flash 9. The elephant in the room is that both WebGL and Canvas are solutions for a problem they created. Canvas has it's uses, but it's pretty much a non-starter for anything HD, let alone anything more complicated than a super nintendo game level of graphics. Game consoles have a fixed level of performance, games belong on them. Web browsers do not have a fixed level of performance, therefor they are best suited for applications where latency and processing speed only make it take longer to complete a task. Highly responsive games are not going to happen on the "web" platform, and anyone who's developed a flash game can tell you that.

We all need to step away from using web browsers and javascript as a be-all-end-all because really what is the difference between programming against SDL (which can be ported to everything) in C, and the web browser? The SDL game can actually run at native performance, where as the web browser adds no less than three additional layers (The browser, DOM and Javascript) into the mix.

There are games that can be written in javascript, but they largely are of the farmville and P&C Adventure variety.

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:Please top hijacking Javascript _

[The Cat]

Wins the FUCKING THREAD

Go the fuck home. Discussion over.

Re:Please top hijacking Javascript _

[Xest]

I don't think GP was arguing against the ideas you suggest, just pointing out that Javascript isn't a language well designed to do it.

It's design flaws limit it's scalability and suitability as a general purpose language.

It's not a question of advancing Javascript, it's a question of replacing it (and in fact just building a new stack designed for web applications rather than attempting and failing to mangle a stack designed largely for static content to do it) to reach the future you propose.

Re:Please top hijacking Javascript _

[Bill_the_Engineer]

A much better solution will be to make a better language standard in all browsers.

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:AJAX Please go already.

[Zontar The Mindless]

HTML that's not XML is SGML.

SGML leads to pain and misery.

Just wait until you have to use an SGML parser for something, much less try to write one.

Re:No

[Smithy66]

Couldn't agree more...

``stack language''

[Luna Argenteus]

I actually thought ``Forth'' the moment I saw the title.

What could go wrong?

[manu0601]

The nice thing with having the same language on client and server is that it helps a lot for code injection...

Re:God Help Us.

[VoidEngineer]

I think there's a good chance it will. Just remember that Javascript is based on Actionscript, based on Scheme, based on Lisp. It's actually got a a much better pedigree than most people realize. It implements the lambda calculus wherever there is a web browser. That's pretty much exactly what it needs to do to 'win the wars'. Be ubiquitous and support the lambda calculus. Everything else is just syntax.

The very definition of the web is different langs

[zakkudo]

If you are a true web developer, I hope you don't put your css styles in camelCase. Between, html, xhtml, css, javascript and your backend server language, things will only improve so much for you. I feel like all web developers try to turn everything into C#. In they try to turn everything into C# (or Java before it.)

Re:2-factor, Suggest, Instant, Gmail, Docs, YouTub

[tepples]

And you *need* javascript to store cookies, how?

I haven't thoroughly debugged the scripts on Chase.com, but let me offer a few guesses. Only script can store cookies in localStorage or IndexedDB. Only script can generate a keypair that the server and the browser will use for challenges and responses, and only script can respond to the server's challenges.

And all it does is make pages more cluttered

JavaScript lets a web page hide a particular element until the user expresses interest in viewing it

Requiring extra clicks to read content I could've been reading right away, taking my attention off the act of reading and onto the act of finding what silly tab to click.

Are you familiar with the concepts of "information overload" and "progressive disclosure"? Please look them up on DuckDuckGo before proceeding. The gist is that if a document presents far more information at a time than the user is expecting, the user will find it difficult to find the desired information in the document. An alternate model is to present the entire web site as a single document and use the web browser to navigate in that document, but that's the same model that PDF uses for navigation, and a lot of Slashdot users have voiced their hatred of various things about PDF.

Does it now? Have you measured that, down to the extra handshakes?

It doesn't matter. One handshake to start a download of the 4 kilobytes of information that has can changed and one handshake to start a redownload of the entire page are each one handshake. One of them just transfers less data afterward. Besides, HTTP/1.1 allows a web browser to hold a connection open, resulting in fewer TCP handshakes overall. I myself have not measured that down to the extra handshake, but operators of large web applications have. There are white papers on the Web about on how Yahoo! and Google optimized their web applications to require fewer requests.

It already starts out bad with sometimes huge background images and avatars and all sorts of other crap that you're supposed to be interested in

Which would be sent with or without script. In fact, without script, more things would have to be sent and re-sent.

Re:God Help Us.

[unapersson]

Actionscript is based on Javascript rather than the other way around.

how does better language happen

[spage]

Sure, everyone thinks they know what that better language is. There is no consensus, there never will be, and other browser makers will resist attempts like Dart and NaCl and pNaCl by one vendor to impose a new language or runtime. So realistically, how will it occur? Every web site has been free to send <script type="text/python" src="foo.py"> or <script type="bin/mybytecode_x64" src="foo.llvm"> pages for close to 15 years now, but no one does because it's a complete non-starter to require end-users to install a special browser or hack in support for a new language module.

Meanwhile in the real world JavaScript (+ HTML + CSS + Canvas + SVG + WebGL + audio processing + sensor support + notifications + real-time communications + ...) keeps improving, despite calls to "stop hijacking" it and to "stay off my lawn".

Re:how does better language happen

[Bill_the_Engineer]

To take advantage of the new features in HTML5 the user had to update to the latest browser. Nothing prevents a different scripting language from being introduced to the browser environment, since the new language would live alongside Javascript and people would update to the latest version of their browser software to view content using the new language.

Eventually the browsers would evolve from "Javascript built in / NewLang plugin" to "Javascript built in / NewLang built in" and ultimately to "NewLang built in / Javascript plugin".