17 ms·

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 i

by Ygor 17y ago

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.

IgorPartola 17y ago
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.
- Periodic 17y ago
  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.
- jerf 17y ago
  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.
  - docgnome 17y ago
    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.
    - jerf 17y ago
      "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 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.)
      - bad_user 17y ago
        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 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.
CoreDumpling 17y ago
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 http://www.crockford.com/javascript/little.html
- tumult 17y ago
  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.
  - blasdel 17y ago
    Eich's original LiveScript had sexpr reader syntax before the attack of the curly braces.
    - tumult 17y ago
      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.
showerst 17y ago
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.
- mattmanser 17y ago
  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.
fnid2 17y ago
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.
- qjz 17y ago
  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?
  - Esspe 17y ago
    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.
  - nimrody 17y ago
    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.
- raganwald 17y ago
  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/difficult_distraction.md http://github.com/raganwald/homoiconic/blob/master/2010/02/d...
Maciek416 17y ago
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.
- tumult 17y ago
  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&lang=v8&lang2=luajit 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.
  - cageface 17y ago
    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.
mechanical_fish 17y ago
Here's Yegge on the topic: http://steve-yegge.blogspot.com/2007/02/next-big-language.html 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.
- swilliams 17y ago
  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 http://vodpod.com/watch/395703-steve-yegge-at-oscon-2007 (at the very end, "NBL is JavaScript 2")
  - allertonm 17y ago
    Of course, the language that is now called Javascript 2 is not the same language that Yegge was referring to.
- imd 17y ago
  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.
kowsik 17y ago
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/ http://labs.mudynamics.com/2009/01/14/js3/
pmjordan 17y ago
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.
john_lewin 17y ago
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 ...

by Ygor 17y ago

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.

IgorPartola 17y ago

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.

Periodic 17y ago
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.
jerf 17y ago
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.
- docgnome 17y ago
  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.
  - jerf 17y ago
    "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 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.)
    - bad_user 17y ago
      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 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.

CoreDumpling 17y ago

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 http://www.crockford.com/javascript/little.html

tumult 17y ago
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.
- blasdel 17y ago
  Eich's original LiveScript had sexpr reader syntax before the attack of the curly braces.
  - tumult 17y ago
    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.

showerst 17y ago

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.

mattmanser 17y ago
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.

fnid2 17y ago

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.

qjz 17y ago
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?
- Esspe 17y ago
  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.
- nimrody 17y ago
  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.
raganwald 17y ago
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/difficult_distraction.md http://github.com/raganwald/homoiconic/blob/master/2010/02/d...

Maciek416 17y ago

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.

tumult 17y ago
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&lang=v8&lang2=luajit 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.
- cageface 17y ago
  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.

mechanical_fish 17y ago

Here's Yegge on the topic: http://steve-yegge.blogspot.com/2007/02/next-big-language.html 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.

swilliams 17y ago
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 http://vodpod.com/watch/395703-steve-yegge-at-oscon-2007 (at the very end, "NBL is JavaScript 2")
- allertonm 17y ago
  Of course, the language that is now called Javascript 2 is not the same language that Yegge was referring to.
imd 17y ago
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.

kowsik 17y ago

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/ http://labs.mudynamics.com/2009/01/14/js3/

pmjordan 17y ago

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.

john_lewin 17y ago

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