31–40 of 93 posts
edit: It also makes me wonder how many people would give lisp, basic, and etc a second chance if those languages had the equivalent of "Wow" that jQuery provided to JS for me and others.
Earlier quoted context omitted.
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.
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?
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.
Earlier quoted context omitted.
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...
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.
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 an…
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.
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…
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);
}
}
}
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.
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.
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.
Earlier quoted context omitted.
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-base…
Earlier quoted context omitted.
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-base…
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.
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 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.)
Earlier quoted context omitted.
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-base…
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.