Hacker News new | comments | show | ask | jobs | submit login

Why do we want javascript on the server side, when we already have so many other options?

I'm not trying to imply something against this aproach, this really is a question.




Here's Yegge on the topic:

http://steve-yegge.blogspot.com/2007/02/next-big-language.ht...

... though he doesn't explicitly say he's talking about Javascript, it's pretty likely that he's talking about Javascript.

1) It's got C-like syntax.

2) It's got the dynamic- and functional-language features that make people happy.

3) We're stuck with it no matter what. Changing the world's installed base of web browsers takes about a decade; such is the lesson of IE6. The only universally-supported client-side language on web browsers is Javascript. Its successor, should it exist, hasn't even been sighted on the horizon. [1] So we're in for at least another decade in which every web developer needs to know Javascript.

4) Because of #3, lots of folks are working to make Javascript fast and reliable. There are several JS interpreter projects in active competition. That kind of focus has already paid off in spades, and is going to pay off even more over time. Those of us who remember the days when Java was considered painfully slow, to the point where people complained about how crippled it was, understand what happens when the bulk of the world's compiler wizards spend a decade optimizing a language's runtime: It tends to become better. Much better.

---

[1] The only serious challenger, Flash, is not only proprietary, widely loathed, suffering from a PR slump, and under direct attack from Apple but is also... based on ECMAscript, a.k.a. Javascript. Or so I understand. So it's more of an alternative runtime than a real alternative language.


ActionScript may be based on ECMAScript, but they look very different:

  package com.example
  {
      import flash.text.TextField;
      import flash.display.Sprite;

      public class Greeter extends Sprite
      {
          public function Greeter()
          {
              var txtHello:TextField = new TextField();
              txtHello.text = "Hello World";
              addChild(txtHello);
          }
      }
  }
Also, Flash is more than ActionScript.


The difference in appearence is because it's based on what was going to be ES4, you can actually write it like Javascript for the most part if you want to.


In a talk Yegge gave some time later he did confirm that he was talking about JavaScript. http://vodpod.com/watch/395703-steve-yegge-at-oscon-2007 (at the very end, "NBL is JavaScript 2")


Of course, the language that is now called Javascript 2 is not the same language that Yegge was referring to.


I have to completely disagree with IE 6 being the model for future browser upgrade timelines. That's a very limited data sample and the willingness to upgrade your browser is going to be significantly faster as time goes on.

IE6 continues to be a pain for sure, but the mindset behind this is changing as the web and it's users evolve.


the willingness to upgrade your browser is going to be significantly faster as time goes on.

You may be right. And then again maybe not. It's going to be fun to find out!

I would note that IE6 persisted until now not because anyone wanted it to -- Microsoft hates IE6 more than anyone, since every IE6 user is both a support timesink and a potential paid upgrade that hasn't happened yet -- but because it sits in a niche. There are people who bought old machines that haven't worn out yet. And there are businesses that built a bunch of stuff on IE6 and see no reason to upgrade.

And the nature of the universe is: Things diverge over time. (Yet another side effect of the second law of thermodynamics.) The number of niches and their diversity is growing now, and they will continue to grow. In ten years there will still be people, somewhere, running IE6. There will also be people running all sorts of other things: Old iPod Touches running obsolete versions of Mobile Safari, eleven-year-old car navigation systems, smart phones and book readers of every description, obsolete gaming hardware (have you noticed that you can still buy a brand-new Playstation 2, ten years after it launched? Have you considered the implication: There will certainly be many PS3 units in use ten years from today?)

The good news is that, thanks to ubiquitous Internet, companies are increasingly able to force customers to use the latest-and-greatest browser technology by pushing upgrades out over the net from on high. But is (e.g.) Sony really going to officially support the PS3 forever? What about the manufacturers who go bankrupt? And, if the market ends up demanding that manufacturers support multiple decades worth of their legacy hardware, is that really going to tend to encourage innovation in web standards, or is it just going to make such innovation that much more costly to implement, encouraging the tendency to embrace the status quo because it is "good enough"? We'll see.


Everything you say makes sense. Let me rephrase my statement into 2 separate statements then, as I should have initially.

1. Future browser upgrade timelines should not be based on the IE6 fiasco. It's too small a sample size to use as corroborating evidence in these predictions. It may end up being an anomaly.

2. In my own opinion I think the upgrade timeline will grow shorter. I don't have any hard evidence I can cite, it's just my impression as someone who's been involved in web development for the last 12 years or so. The points you mention are all valid, and I'm not saying there won't be new and different pains we'll enjoy ;)


I don't think people should take Yegge seriously without a grain of salt.

Yeah, he's a good writer and I've read all of its blog-posts ... but he seems like the kind of programmer that's always discontented with the status-quo, always looking for that next big language, always relentlessly looking for tools that will make programming fun again ... and that particular article seems to me a lot like wishful thinking.

And guess what ... you won't find much happiness in switching languages, unless the culture around it favors simplicity and getting things done (and your previous community didn't). That's why Lisp is almost dead.

Also, Javascript may become popular on the server-side, but that's only because browsers are stuck in the past, while becoming more and more relevant to the future.

But give developers the choice of multiple languages ... and I'm pretty sure Javascript will fade away to a niche. Incidentally, you can play with Ruby and Python in the browser right now ... it requires Silverlight/Moonlight, but it's pretty cool and gives some glimpse in what the future should look like.


I know that not a lot of people would agree with me on that one, but i'd argue that JavaScript is a better designed language than Python or Ruby on a lots of points.

It's simpler than both regarding the core language features, and is also the only one of the three to have real anonymous functions.

I'm not fond of C syntax, but i can live with it


> is also the only one of the three to have real anonymous functions

What are you talking about?


I'm talking about that :

http://news.ycombinator.com/item?id=1171471

Arguably i took a bold step regarding Ruby, which has them, but is confusing in this regard since blocks are not anonymous functions, and are the idiomatic and preferred construct in ruby. The problem is deeper than that , but Paul Canter does a much better job than me explaining why


I actually like the approach in Ruby, because the syntax for passing a single anonymous block (which corresponds to 90% of all cases) is really light and people have used it practically for adding syntax to Ruby.

What differentiates Ruby from Javascript (or Python for that matter) is that when defining a function using regular syntax, its name is not a variable referring that function in the scope it was declared ... what Python and Javascript are doing. And that's a trade-off that some people like it, because in Ruby you can call a function without parens and it doesn't really get in your way when wanting to do crazy shit with already declared functions.

On Python, it may not have anonymous functions, but it has true first-class functions and true closures. It's only a problem for async code because you want to have the declaration of a closure after you see the call-site that's using that closure, not before it. But in practice that's not so awful ... and if you really really want multi-line anonymous blocks there are hacks you can do with the "with" block.

In this regard Javascript is cleaner, but it is messier in other places. I don't like that its a loosly-typed language for instance (haven't we had enough of that?).

I don't like that it doesn't provide class-based OOP ... and while you can build it on top of prototypes, it's a PITA not having a standard. And class-based OOP is mapped better to the way we think, having a bad reputation only because a couple of popular languages have plagued us with bad implementations ... but people should really take a look at Smalltalk before throwing the baby out with the bathwater.


> it doesn't really get in your way when wanting to do crazy shit with already declared functions

That's something i don't like about ruby. You can do crazy shit but it leads to code wich is opaque for somebody that doesn't truly know ruby inside out. The language is full of tricks. But i don't want a full of tricks language. I want a simple language that doesn't get in my way, and doesn't provide 7 ways and 3 different mechanisms to do closure like constructs (numbers are not made up)

> On Python [...] if you really really want multiline anonymous blocks, there are hacks you can do with [...]

Well yeah i really really want them, and no i don't want to resort on hacks to use them.

I really have trouble understanding the rationale behind all those half baked constructs. The way Lua/Javascript/Scheme does it is the way to go IMHO : provide one mechanism that is simple and works well. You may loose some convenience or conciseness in the process (compared to ruby blocks for example), but what you gain is one consistent way to do things.

About javascript OO, i admit that it doesn't bother me as much as it seems to bother you, and that it may be linked to the uses i have had for javascript yet, but i have to say i indeed had more pleasure working with python/ruby object models than with javascript at the moment. I can't say if that is due to a superior mechanism or to familiarity with class based models though.


When was "C-Like Syntax" ever a good reason? I want something I can read naturally, like Ruby or Python.


He means that there's a critical mass of developers who will take one look at a syntax and move on if it doesn't have curly braces and semicolons. It's not that they're enamored with having a needlessly awkward syntax for function pointers, it's just that a syntax that isn't 95% of the way to Java just looks freaky weird to them, end of story.

I don't disagree that syntax matters, but C's is hardly a shining example. There's a network effect with programming languages, though (libraries, documentation, community, etc.), and there's a certain amount of realpolitik in designing with "C-Like Syntax" in mind.

I'm more worried about languages with ugly semantics. Odd syntax is only skin deep, but bad design goes straight to the bone.


Sigh. You're right and I hate it. :(


It's a nice clean language that fits the event-driven paradigm better than most. When every function is an automatic closure, things are much easier.


I'm really at a loss as to how people seem to just swallow this claim without question. What's so special about Javascript's closure support vs Perl, Python, Ruby, PHP, Lua, C#, Lisp, Erlang, or ${all other functional languages}? What's Node.js got over Twisted, POE, EventMachine, or every single thing ever written in Erlang?

Most languages used in web development have closures. A large number of them have event-based frameworks. I found quite a few other candidates poking around in the other languages but lacked the skills or time to evaluate whether they were also structured like Node.js.

I don't mind the existence of Node.js, but the people claiming it's "better than most" make me wonder if they've ever used the "most" they claim it's better than. Erlang in particular. That's something that's "better at the event-driven paradigm than most". Javascript has nothing on Erlang, Javascript's just another C-derived manually-chop-your-code-up-to-work-with-callbacks monstrosity by comparison.

Edit: No, if I were going to pitch Node.js, I would pitch it as "Use the same language on both the client and the server; it's adequate on the client, it's adequate on the server." OK, "adequate" isn't the best pitch but it's honest. The stupidest thing about web development today is needing to know three languages (HTML + browser quirks counts as roughly as complex as a language, client-side JS, server side not-Javascript language) just to get your foot in the door. Having the same language on client and server will probably provide some interesting capabilities, such as the thing mentioned in another comment where your comment formatting code can be run in either place (show on the client exactly what they'll get if they submit, run on the server to validate it), or validation code that is guaranteed identical on both client and server, or several other interesting things I can imagine where you can play games with exactly where something is run. Server-side Javascript just shouldn't be pitched as a "uniquely capable" language in a field full of PHP, Perl, Python, and Ruby... "uniquely capable" is Erlang or a the Seaside framework, not Yet Another (Dynamic) Algol Variant.


Something that's different, at least from POE, EventMachine, Twisted is that it is attempting non-blocking purity. You can snub your nose at this but it turns out to be very important. It ends up abstracting away a problem in a way that EventMachine or Twisted will never be able to do simply because of the existence of massive amounts of blocking Ruby and Python libraries. The programmer simply doesn't have to know what non-blocking I/O is - they don't have to know that if they do "node script.js < hugefile" - that STDIN_FILENO cannot be selected on.

Erlang is different. Node presents a different programming model than Erlang - Node handles thousands of connections per process - and keeps itself close to the metal. Erlang is it's own operating system handling one connection per processes but allowing very many processes. Is Node's model better? Well at the moment it's incomparable since Erlang is very much a solid, production ready system and Node is not more than some dude's hack. But supposing that Node becomes stable and usable at some point, a major advantage of the Node model is that for the first 10,000-1,000,000 concurrent connections the programmer doesn't have to know anything about concurrency - a single process will just handle it. There is no forking or IPC - it's just synchronous events and callbacks. In Erlang you have to think about about IPC on the first connection. The Erlang-model might turn out to be the wrong level of process granularity. Maybe the right level of process granularity is how computers are already designed: 10,000-1,000,000 connections per process, use one per core.

I also wish for less hype around the Node project but I think you're short changing it by saying it's same thing as Twisted but in Javascript instead of Python. The main selling point is not that you can run the same code on browser and server. The main selling point is that you don't have to know what you're doing, at least for the first 10,000 concurrent connections.


"There is no forking or IPC - it's just synchronous events and callbacks. In Erlang you have to think about about IPC on the first connection. The Erlang-model might turn out to be the wrong level of process granularity. Maybe the right level of process granularity is how computers are already designed: 10,000-1,000,000 connections per process, use one per core."

Also false. An Erlang "process" is not an OS process. It already works the way you say, except it can use multiple cores simultaneously. Automatically. Node.js has nothing on Erlang except a familiar syntax. Nor does IPC come up like some kind of blocker; it's baked into the core and quite natural, often all wrapped up behind a simple function call.

And let's not even talk about the baked-in clusterable Mnesia database or the OTP library, which Node.js can only dream about. (Erlang isn't just multicore, it's pretty easy to make it multi-system.) Or how Erlang has code replacement (the Node.js complaint of the day) built right in to the core, where it really has to be for it to work. And Erlang laughs at your "non-blocking purity"; in Erlang, you can call sleep and it won't block anything! No special support needed, no magic from the user, no arranging things in callbacks manually (how 1980s). Try that in Node.js.

It's actually impossible for Node.js to do some of these things because you have to start with them.

You don't understand how Erlang works. That's fine, except you started to criticize it. I refer back to my previous comment that the people hyping Node.js don't seem to have used the competition. Maybe my problem is that I have used the competition, quite extensively. Come to think of it, I've yet to hear anyone say "Gosh, I was using Erlang but Node.js is just so awesome I had to switch!:" That probably says something important.


You should read my reply again (or maybe for the first time) and comprehend. I did not say nor imply that I think Erlang's processes are OS processes. Sorry for not using quotes ('process') if that's what has confused you so deeply.


You can hardly expect me to read your mind on that point when you bury it in so many other wrong ideas about Erlang, which I note you do not challenge.


> I also wish for less hype around the Node project

I'm tremendously amused that you write this when every other poster on HN is desperately trying to generate hype for their project/company.


Yeah, Lua and Erlang in particular seem better suited to this role. Erlang's whole model is fundamentally event-driven, and Lua is remarkably similar to Javascript, only without the design errors made permanent, and with a better JIT compiler.

Javascript's already closely tied to the web, though, and it gets plenty of word-of-mouth since web developers already know it. That will probably beat any technical advantage.


Python has no true anonymous functions.

Ruby is just a mess in this regard,even if you can arguably do anything you want in the end : http://innig.net/software/ruby/closures-in-ruby.rb

On the other hand, javascript has a simple, no bullshit syntax for functions. If you want a function to be anonymous, just don't give it a name.

Erlang and Lua obviously have true anonymous functions and closure support.


JS has three epic wins going for it, that cannot be matched together by another language:

  * A shitton of people are already using it on the daily
  * All of the existing code written in it is event-driven
  * It's got prototypical inheritance, and some people
    actually use it instead of bludgeoning in classicism


* A shitton of people are already using it on the daily

This is actually a problem. Majority of that shitton use js without knowing what they are doing. It's a copy-pasted code for some client-side validation. Even the so-called framework-users (jQuery and Prototype) depend blindly on plugins for their job.


You aren't wrong, and I find Protoype.js incredibly depressing (see my third point).

But the point is that you're not going to get fired for choosing JS on the server. It has curly braces! Your boss isn't so worried about hiring.


I see where you are going. Getting a large pool to pick from isn't going to be a problem.


Your second and third points have been matched by Erlang, and for longer too.


Yeah, but it is the first point that matters, and when matched with two and three the real power comes.


1. People are forced to use javascript.

2. There are a lot of people who use erlang.


1. Good point. I was definitely forced to use it. Nowadays it's probably more like a first taste language for most new developers though.


"What's so special about Javascript's closure support vs Perl, Python, Ruby, PHP, Lua, C#, Lisp, Erlang, or ${all other functional languages}?"

Javascript has java-like syntax. Heck, it even bears half the name even if the language has almost nothing to do with Java. Did you know that the first version of Javascript was actually a scheme variant but they decided to conceal its identity so it would appeal to the masses?

It's stupid that a familiar syntax is one of the foremost considerations in the mass adoption of a language, but that's reality for you.

(PS: I'm a Common Lisp fanatic so I'm acutely aware of this syntax problem.)


Well Python's lambda's kinna suck for one. As far as I know, Python, Ruby, and PHP all suffer from the fact that all functions are not first class. Also Javascript's prototypal inheritance is pretty neat. I'm not saying js is a "great" language, it's not with out it's crufty bits, but it's a nicer language than most people give it credit for.


"Well Python's lambda's kinna suck for one."

Not really relevant in this context, as naming things isn't that big a deal. Lambdas are only needed for one-liners and they serve that purpose fine.

"As far as I know, Python, Ruby, and PHP all suffer from the fact that all functions are not first class."

Definitely false for Python, Ruby actually has multiple kinds of first-class functions (for better or for worse, I am assured that in practice it's not a problem), recently false for PHP (http://en.wikipedia.org/wiki/PHP#5.3_and_newer ), and to save time, also false for Perl, Lua, ${all functional languages} (pretty much by definition, there), and false for C# as of 3.0.

If you want to play "oh but the support is quirky", Javascript has its own quirks on the closure front:

    var i;
    var funcs = [];
    for (i = 0; i < 5; i++) {
        funcs.push(function () { alert(i) });
    }
    funcs[3]();
What does that alert?

Mind you, that's only a quirk and I wouldn't crucify the language for it, it's arguably correct and sensible once you understand it. The again, Python's scoping is arguably correct and sensible once you understand it, too, but people don't cut it much slack for that.

(The answer is 5 by the way. Compare with Perl, which can actually close on a variable created inside a scope in the function, instead of having just one function-level scope like Javascript. Compare with Python, which does what Javascript does.)


Actually you could say that functions in C# have been first-class since version 2.0.

We of course need to define what first-class is ... if it's the ability to have higher-order functions, than 2.0 fits. C# 3.0 only adds a light-weight syntax for anonymous delegates plus the really kick-ass ability to get a syntax tree of that method instead of the method's reference (on which Linq is based) ... and I really wish other languages add this capability (it was possible in Ruby 1.8.x, but it's not anymore in Ruby 2.0).

Python kicks ass in regard to first-class functions ... and it leverages that ability with decorators. People using other languages go through great pain to have AOP capabilities (for example), but in Python it only takes like 10 minutes to add a couple of utilities to do whatever you want.

The only frustration I have with it is the lack of multi-line anonymous blocks, but Python is so flexible you can add that using "with" block hacks, like described here ... http://billmill.org/multi_line_lambdas.html

Also, once you understand dynamic-scoping ... it's really not that big of a deal to deal with the situation described above. It's just different.

I like the lexical-scoping in Perl as it prevents all kinds of errors ... but in Python I have real exception-handling, and a kick-ass debugger console just by adding "import ipdb; ipdb.set_trace()" anywhere I want.


Erm. Yeah I know for a fact that not ALL PHP functions are first class. Which was all I was saying. PHP does have lambda, but not EVERY function is a lambda.


Can someone explain to me why the answer is five? Appreciated.


There are two ways a for loop like that implemented:

The first way, which I prefer, is to make the binding of i to its value inside the loop body, this way you get a nice fresh binding on each loop iteration, so if you iterate the loop 5 time you get 5 bindings.

The other way, which I loathe but is still an arguably "correct" way to do it, is to make one binding of i outside of the loop and then modify it on each loop iteration, so no matter how many iterations of the loop you have, there's only one binding.

As far as I'm concerned, the first implementation is obviously the better one because the instances where this benefits you come often while the instances where the second implementation benefits you is very rare and unidiomatic. I think the second implementation is used for better performance but that's a mistake.

I had this problem of perceptions when I switched from Common Lisp's Loop to Iterate. Loop, for all its many big shortcomings, had the decency of making a fresh binding on each new iteration, though IIRC the standard specifies that bindings can be established outside or inside the loop context. When I want to make a closure based on the value of an iterated variable with Iterate I have to do an explicit binding...


i is a mutable variable declared in the enclosing scope. The for loop mutates it, and each anonymous function closes over i. After the loop is finished (when func[3]() is called, i is equal to 5.

I'm not sure what makes this a "quirk" since this is exactly what closures should do: they maintain a reference to the variable from the enclosing scope. This is also the behavior of a fairly classical example of closures in scheme.


I still remember when Javascript was a fairly ugly language that felt like the PHP of client-side programming.

I revisited Javascript a few years ago and I was pleasantly surprised. It's come a long way, and it does make event-based programming easy.


I'm excited about this idea because:

1) This approach lets me put together a quick server without a big, complex container to configure (No Apache, Tomcat, Rails, (Insert Python Framework Here), etc).

2) Javascript really is a nice language to program in. First class functions lead to some neat tricks, and aside from a few minor quirks (scoping issues, overloading the "+" operator) it lacks nasty gotchas like Java and PHP, at least so far.

3) Lots of programmers have JS experience and web experience, so there's a large potential pool of users (Subjectively, this may or may not be a good thing, see PHP. But there's demand)

It's probably not the be-all-end-all, but there are some positive reasons to see work in this space. I'm curious to see how the language implementations evolve as people start doing more complex server side things with JS.


The scoping issue is a minor quirk? okkkkkkkkkkkkkk. Javascript is an ugly language, always will be. == or ===? Man.

My biggest issue is that as far as I know there are no decent tools for it yet. Notepad, hey, sod that crap.

TBH I was hoping it was going to die a death with flash/silverlight, but alas with apple hating flash and the g man sponsoring it, it seems destined to stay.

It honestly feels like a step back.


Because it's actually a decent language when you take away the DOM cruft?

It's actually remarkably similar to Scheme [1] with very flexible arrays and real first-class functions.

[1] http://www.crockford.com/javascript/little.html


JavaScript programmers who have never used Scheme frequently repeat this patently false claim. Scheme has nothing in common with JavaScript other than that JavaScript has first-class functions.


Eich's original LiveScript had sexpr reader syntax before the attack of the curly braces.


Eich's original LiveScript.

We have something else, JavaScript. It does not have sexprs. It doesn't have continuations. It doesn't have tail call optimization. It has mutable array operations, but immutable string operations (got it backwards.) There are no macros, hygienic or otherwise.

The only thing it has in common with Scheme are first-class functions. If you want anything else, you must implement it yourself out of the Turing Tarpit, and it will perform badly, because optimizing JavaScript is difficult due to its mistaken specification.

By any of these metrics, Python, Ruby, Perl, and C# all have more in common with Scheme than JavaScript. I think the people claiming 'JavaScript is like Scheme but with a different syntax' are mistaken from lack of experience.


For me it is about consistency. With javascript on the client and the server, it's easier to write code once and move it around. Compared to having to write perl, java, php, whatever on the server side and javascript on the front.

It reduces the learning curve for new developers because they only have to learn javascript, not javascript plus something else.


I run into this all the time. The most common case is form validation. If you want to do some validation on the client side, why are you forced to repeat yourself by writing it once in Java/Ruby/Python/Perl/PHP on the server and then write it again on the client using Javascript/Underscore/JQuery/whatever?

http://github.com/raganwald/homoiconic/blob/master/2010/02/d...


Could it be that your form validation example is merely a symptom of not working at a high enough level of abstraction?

In the rails world, for example, if you've done your validates_* declarations on an ActiveRecord model, it shouldn't be too difficult to generate the javascript required for client-side validation.

Actually found a project that goes a long way towards achieving just that: http://github.com/grimen/validatious-on-rails

But I guess you're referring to complex validations, expressed as code instead of validates_* declarations. It seems like you would prefer either an all-JS approach or an automated translation to JS, as per the blog post you linked. To me, it boils down to whether such a complicated validation is really appropriate for client-side validation and whether it blurs the lines between form validation and business logic to such an extent that it's better off just living on the server.

But I'd love to hear your further thoughts on the matter.


A concern might be that you expose your server side code. Though many os projects do this by design.


Not necessarily, you can make a really high-level DSL to express validation rules, that encompasses both client-side and server-side logic, and then you generate the client-side-only validations from this model while not including the server-side, "secret" validation code.


Innocent question: Won't the server and client side code tend to be so different, they'll appear to be mutually exclusive? I understand that you're referring to basic concepts and syntax, but surely a lot of server side code simply won't execute in a browser's sandbox, correct?


When writing code for both client and server, it's difficult to mentally "switch". E.g. after writing some code in client, I'm starting placing curly braces in python's code :)

It would be nice to write both client and server in one language.


Someone once gave an example of a 'preview' feature on the client side (like preview the formatting of blog comments) -- then the same code is used on the server to generate the actual view.

I think this was briancarper.net where - since he's using clojure on the server - ended up running a javascript interpreter (rhino) on the server so that the same formatting code could run on the client and server.


Primary reason is, especially when used with something like CouchDB is absolutely no data transformation. What's in the DB is exactly what jQuery gets on the front end. See this:

http://labs.mudynamics.com/2009/01/14/js3/


Like others are mentioning, Javascript is clean, familiar, easy, and has some compelling language features to boot (closures, JSON, etc).

Cultural norms and design patterns in Javascript Land increasingly orbit around projects like jQuery. This sort of influence works out spectacularly-well if you've spent the last several years working countless hours on browser-side code and suddenly stumble on nodejs and its evented/closure style of programming. Perhaps this doesn't describe you, but from my vantage point, this describes a vast number of programmers. There are a lot of people in that demographic who want to be able to rapidly write out web apps in the same frame of mind client and server side and not have to switch to thinking in Python or Ruby.

The fact that V8's engine is competitively fast isn't hurting these efforts either.


The people who claim JavaScript is fast because of V8 have probably never used a fast language and platform in a situation where speed is important. V8 is fast compared to other JavaScript engines. It's very slow compared to most other languages. PLT Scheme, a non-fast Scheme platform, averages half the time of V8 in the flawed benchmarks game (single core, JavaScript cannot multithread.) Lua, a fast non-broken dynamic language with first-class functions averages between 3x and 100x as fast as V8, the fastest JavaScript engine.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

By definition they are flawed benchmarks, but you will have a hard time writing faster JavaScript code than equivalent code in most other platforms. In the case of Lua (and Python, and Perl, and many many others) the equivalent JavaScript code will also be as long or longer, and not as clean.

I'm not going to get mad at anyone for their choice to use JavaScript, but the uncritical repetition of sentences like "Thanks to V8 and other modern engines, JavaScript has become fast compared to optimized language/platform X" or "JavaScript offers these N features you won't find anywhere else" will not fly.


I think you're reading the shootout wrong. V8 is faster in most cases than Lua in those benchmarks. Often by a fairly large margin. The gap between V8 and Ruby and Python is even larger.


Compare LuaJIT, PLT, V8, Lua, JRuby, Python 3, Ruby 1.8, Perl, PHP -

http://shootout.alioth.debian.org/u32/which-programming-lang...


Look again -- V8 is faster than the regular Lua interpreter, not the Lua JIT, which is much faster than V8.


Currently, JavaScript is the only thing I can actually convince customers to use in place of PHP, which has various weaknesses that make it a terrible choice for certain apps. The killer argument is that there are lots of people who already know JavaScript.


Good question. As a server programming language its newish, and all the growing pains (bugs, security holes, standardizations of processes, training documentation) have yet to be realized. Meanwhile mature languages are pushing the envelope in distributed and multi-core programming ...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: