Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about a year ago | from the but-does-it-come-with-a-web-browser dept.

Programming 354

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

cancel ×

354 comments

Citation Needed (5, Insightful)

casings (257363) | about a year ago | (#44124539)

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

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

Javascript is now web scale (4, Insightful)

Lunix Nutcase (1092239) | about a year ago | (#44124555)

No, it's fanboy hyperbole.

Re: Citation Needed (0)

Anonymous Coward | about a year ago | (#44124621)

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?

You could code everything in one language?

Re: Citation Needed (5, Insightful)

Lunix Nutcase (1092239) | about a year ago | (#44124645)

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 (1)

LordLimecat (1103839) | about a year ago | (#44124851)

now deploy it to web users so that it can run on a wide audience with no dependencies, true "write once run everywhere", and runs in an actually functional sandbox (as opposed to the nightmares of java or activeX).

Of course Chromes NACL does that as well-- apparenly you can now get NACL games [google.com] in the chrome app store.

Re: Citation Needed (2)

oh_my_080980980 (773867) | about a year ago | (#44124981)

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

Re: Citation Needed (1)

hackula (2596247) | about a year ago | (#44125097)

Actually, most libraries will work in either client side browsers or node. See https://github.com/substack/node-browserify [github.com] 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 (1)

Lunix Nutcase (1092239) | about a year ago | (#44125091)

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

Re: Citation Needed (1)

i_ate_god (899684) | about a year ago | (#44124893)

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 (5, Informative)

sribe (304414) | about a year ago | (#44124663)

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

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

Re: Citation Needed (1)

EvanED (569694) | about a year ago | (#44124707)

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 (1)

hackula (2596247) | about a year ago | (#44125137)

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 (2)

iggymanz (596061) | about a year ago | (#44124713)

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

Re: Citation Needed (4, Interesting)

marsu_k (701360) | about a year ago | (#44124867)

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

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

Re: Citation Needed (0)

Anonymous Coward | about a year ago | (#44124971)

Popular packages are very actively maintained and high quality. There is a nice package manager called npm that eliminates nearly all the pain of handling requirements and dependencies. You can investigate what you wish here: https://npmjs.org/

Re: Citation Needed (1)

Darinbob (1142669) | about a year ago | (#44124849)

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 (0)

narcc (412956) | about a year ago | (#44124935)

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.

Re: Citation Needed (4, Interesting)

kwerle (39371) | about a year ago | (#44125015)

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 (5, Insightful)

LordThyGod (1465887) | about a year ago | (#44125031)

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

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

Re: Citation Needed (2)

hackula (2596247) | about a year ago | (#44125199)

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 (0)

Anonymous Coward | about a year ago | (#44124857)

You could just be generating HTML instead of trying to push as much workload off to browsers. Gratuitous javascript is gratuitous, and there is a lot of it.

Re: Citation Needed (1)

hackula (2596247) | about a year ago | (#44125241)

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 (3, Interesting)

Aaden42 (198257) | about a year ago | (#44125017)

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 (1)

Trepidity (597) | about a year ago | (#44125051)

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

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

Re: Citation Needed (4, Funny)

Spy Handler (822350) | about a year ago | (#44124741)

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 (1)

Kenja (541830) | about a year ago | (#44124743)

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 (1)

Anonymous Coward | about a year ago | (#44124781)

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 (1)

multi io (640409) | about a year ago | (#44124801)

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 (1)

dingen (958134) | about a year ago | (#44124967)

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 (2)

oh_my_080980980 (773867) | about a year ago | (#44125019)

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

Re: Citation Needed (5, Insightful)

hackula (2596247) | about a year ago | (#44125041)

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

If its turing complete... (0)

Anonymous Coward | about a year ago | (#44124549)

you can use any language to make an equivalent mess.

Sigh... (0)

Anonymous Coward | about a year ago | (#44124559)

No comment.

Really, I am speechless.

Full-stack (1)

Anonymous Coward | about a year ago | (#44124579)

lol

go home Nerval's Lobster, you're drunk

they won't emerge and it won't be jaw-dropping (1)

Anonymous Coward | about a year ago | (#44124583)

'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 (1)

ron_ivi (607351) | about a year ago | (#44124595)

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 (2, Insightful)

Anonymous Coward | about a year ago | (#44124731)

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 (-1)

Anonymous Coward | about a year ago | (#44124765)

You are a turkey. Fuck off back to 1987. That is all.

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

Anonymous Coward | about a year ago | (#44124785)

Wow, what a cogent response to his post. Don't have a valid argument against what he wrote?

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

Anonymous Coward | about a year ago | (#44124793)

You are also a turkey.

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

OakDragon (885217) | about a year ago | (#44124903)

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

2-factor, Suggest, Instant, Gmail, Docs, YouTube (4, Informative)

tepples (727027) | about a year ago | (#44124949)

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

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

And all it does is make pages more cluttered

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

harder to use

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

longer to load

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

takes up bandwidth

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

Google. No scripts there but immensely valuable.

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

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

Anonymous Coward | about a year ago | (#44125163)

You are 100% correct. OP is pitching something, I guess. JavaScript is antithetical to the founding premise of the web: platform independence.

Brilliant! (2)

Sparticus789 (2625955) | about a year ago | (#44124619)

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! (0)

Anonymous Coward | about a year ago | (#44124773)

You have a backend that is exploit free now? What's it called?

Re:Brilliant! (2)

Sparticus789 (2625955) | about a year ago | (#44125021)

Apple System 6 with no AppleTalk card. Exploit that!

Full Stack? (1, Interesting)

twistedcubic (577194) | about a year ago | (#44124623)

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

Re:Full Stack? (0)

Anonymous Coward | about a year ago | (#44124827)

Node-OS coming soon.

Re:Full Stack? (2)

OakDragon (885217) | about a year ago | (#44124957)

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

Re:Full Stack? (1)

OakDragon (885217) | about a year ago | (#44125001)

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? (1)

dingen (958134) | about a year ago | (#44125061)

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? (0)

Anonymous Coward | about a year ago | (#44125247)

It means that the web server, the database, the front and back end code are all javascript.

partly engineering resources put into compilers (2, Interesting)

Trepidity (597) | about a year ago | (#44124637)

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 (1)

Anonymous Coward | about a year ago | (#44124683)

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 (2)

stewsters (1406737) | about a year ago | (#44124697)

Re:partly engineering resources put into compilers (1)

Lunix Nutcase (1092239) | about a year ago | (#44124727)

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 (0)

Anonymous Coward | about a year ago | (#44124729)

This is a better one: http://www.techempower.com/benchmarks/

Re:partly engineering resources put into compilers (2)

Trepidity (597) | about a year ago | (#44125005)

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 (1)

Hentes (2461350) | about a year ago | (#44125179)

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

Javascript anywhere but the browser? No (3, Interesting)

JDG1980 (2438906) | about a year ago | (#44124639)

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

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

Re:Javascript anywhere but the browser? No (1)

Anonymous Coward | about a year ago | (#44124735)

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

Anonymous Coward | about a year ago | (#44124739)

Hmm. No typing, no pointers. So PHP doesn't have a chance in hell.

Re:Javascript anywhere but the browser? No (1)

0xdeadbeef (28836) | about a year ago | (#44124771)

Getting trounced by PHP is not a point for JavaScript.

Re:Javascript anywhere but the browser? No (0)

Anonymous Coward | about a year ago | (#44125217)

Viability as a server-side language has little to do with performance.

My point is that "better" or even "good" in terms of the parent post's criteria doesn't align with "popular."

If people can pick it up quickly and use it to get stuff done, it'll catch on.

Re:Javascript anywhere but the browser? No (4, Funny)

godrik (1287354) | about a year ago | (#44124791)

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

Lets just go all the way here for a bit... (1)

Bradley Meck (2961599) | about a year ago | (#44124815)

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

EvanED (569694) | about a year ago | (#44124863)

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

Bradley Meck (2961599) | about a year ago | (#44124941)

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

EvanED (569694) | about a year ago | (#44125193)

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

Python has pointers the way Java does (1)

tepples (727027) | about a year ago | (#44125079)

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:Javascript anywhere but the browser? No (0)

Anonymous Coward | about a year ago | (#44124885)

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

Re:Javascript anywhere but the browser? No (1)

Anonymous Coward | about a year ago | (#44125301)

> 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 (0)

Anonymous Coward | about a year ago | (#44125233)

Javascript and Mongo are like cars without seatbelts, windshields, bumpers, airbags, doors or headlights.

Sure, they go a lot faster because they're lighter.

But when they get into an accident, it's all over, baby.

Server Side Javascript (0)

Anonymous Coward | about a year ago | (#44124665)

Can you say 'trying to cram a square peg into a round hole'

Hint: If your development team can't handle using more than one language at a time, you need a much better development team.

Re:Server Side Javascript (2)

dingen (958134) | about a year ago | (#44125117)

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

Verifying equivalence of client and server code (2)

tepples (727027) | about a year ago | (#44125161)

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

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

"ace JavaScript developers who can write" (5, Funny)

tk77 (1774336) | about a year ago | (#44124671)

ace JavaScript developers who can write brilliant code

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

Re:"ace JavaScript developers who can write" (0)

Anonymous Coward | about a year ago | (#44124759)

you just aren't ace. sorry, chum.

It's web-scale, (0)

Anonymous Coward | about a year ago | (#44124695)

http://www.youtube.com/watch?v=b2F-DItXtZs

javascript for domain of in browser interactivity? (1)

Anonymous Coward | about a year ago | (#44124703)

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.

Re:javascript for domain of in browser interactivi (1)

stuporglue (1167677) | about a year ago | (#44125177)

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.

God Help Us. (0)

cfulton (543949) | about a year ago | (#44124769)

Please be more JS fanboy craziness. There is no way the Java Script can win the Language wars is there?

You mean as good a regular programmers? (1)

xxxJonBoyxxx (565205) | about a year ago | (#44124777)

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

No, node.js and mongodb are cancer (3, Interesting)

A beautiful mind (821714) | about a year ago | (#44124803)

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

  1. JS is already supported by all major browsers, modern ones with JIT
  1. asm.js - which turns anything from a LLVM intermediate representation into javascript code that runs around 2x the speed of native c/c++ code in supported browsers and as fast as any other piece of JS code in all the other browsers
  1. HTML5, WebRTC

It's an inside-out stack.

Re:No, node.js and mongodb are cancer (1)

RightSaidFred99 (874576) | about a year ago | (#44124907)

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 (0)

Anonymous Coward | about a year ago | (#44125129)

Not shit, just operating on simple objects. Firefox and Chrome recognize and optimize asm.js really well. The problem comes when C code begins using pointer arithmetic--as all good C code will, because pointers are such a powerful abstraction when manipulating data--and other constructs that don't have analogs in JavaScript.

Re:No, node.js and mongodb are cancer (0)

Anonymous Coward | about a year ago | (#44125187)

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

Re:No, node.js and mongodb are cancer (1)

Anonymous Coward | about a year ago | (#44125189)

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

The real problem (-1)

Anonymous Coward | about a year ago | (#44124841)

has to do with the inherent incapacity of the javascript language to adapt to the necessities of the internet lifestyle that so many of us have been accustomed to. Without the ability to download movies of gay child rape porn, javascript will never succeed in the real world. The simple act of forcing yourself on a young boy is so fun and delicious that only the most depraved of people would deny it to homosexuals. I hang out at grade schools just so I can take pictures of all the pretty little things that go prancing this way and that, while I stroke my penis in anticipation of the day that I will kidnap, rape, and kill them. To hear their screams as I force my cock into them, to see their tears on the pillow, and the blood that flows into the bathtub as I hang them upside down and slit their throats. All of it makes my penis so fucking hard. I am a homosexual man, and there is nothing I love more than having my way with little boys. They are my special treat. God bless America for making it socially acceptable to engage in my sexual desires.

Re:The real problem (0)

Anonymous Coward | about a year ago | (#44125139)

What does this have to do with javascript?

Also, isn't javascript from the 90's?

Lolwut? (1)

RightSaidFred99 (874576) | about a year ago | (#44124889)

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" (1)

Zedrick (764028) | about a year ago | (#44124933)

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.

might be waiting a while (0)

Anonymous Coward | about a year ago | (#44124963)

developers have yet to emerge

Real developers never emerge.

mod Up (-1, Offtopic)

Anonymous Coward | about a year ago | (#44125095)

are the important arounD return it itself. You can't more stable Non-fucking-existant. Your replies rather short of a miracle You don't need to

Re:mod Up (1)

dingen (958134) | about a year ago | (#44125157)

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

blur client-server line (1)

DrEasy (559739) | about a year ago | (#44125183)

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.

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

mat690 (2568981) | about a year ago | (#44125225)

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 (2)

jlowery (47102) | about a year ago | (#44125249)

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

..I thought he said Make Up lanaguage.. lol (0)

Anonymous Coward | about a year ago | (#44125281)

He was describing HTML and I thought he said "its just a Make Up language anyway"

Which is a double entendre since.. it can make up your webpage "face".. or it can be used to "make up" just about anything

It's The Environment, Stupid (2)

Zontar The Mindless (9002) | about a year ago | (#44125327)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...