Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: It’s Not Just for Browsers Any More

pragprog.com

Post reply on HN
Print view View original

71–80 of 93 posts

Re: JavaScript: It’s Not Just for Browsers Any More

#71

Post by simonw »

scotty79 wrote: post #52
rictic wrote: post #49

Earlier quoted context omitted.

Nope, no locks needed in Node. This is one of the little joys of javascript: no threading at all. None. With Web Workers you can have processes, but there isn't shared state; everything is done through message passing. All parallelism is cooperative in javascript, meaning that you don't have to worry about control flow switching out from under you at arbitrary points, just when you explicitly yield it by returning fr…

> Finally, to answer the grandparent question I don't event have a kid! ;-) Thank you, that was the thing I was looking for. My question now: What happens if one of the promises fails? Is a promise group disposed then? Solution offered by Periodic would wait forever.

It depends on the promise library implementation - most will let you specify an "errback" (like a callback, but called if there is an error) and will trigger that if any of their children fail. Alternatively, some may let you specify a timeout and call your errback if that time elapses without all of the children finishing.

Re: JavaScript: It’s Not Just for Browsers Any More

#72

Post by jerf »

ryah wrote: post #42
jerf wrote: post #37

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…

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 w…

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

Re: JavaScript: It’s Not Just for Browsers Any More

#73

Post by Hexstream »

jerf wrote: post #37
IgorPartola wrote: post #7

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…

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

Re: JavaScript: It’s Not Just for Browsers Any More

#74

Post by mark_l_watson »

Last night I watched most of Ryan Dahl's 1 hour video on Node, built it, and played with a few examples. I must admit that I like it much more than I thought that I would. The video is good (but too long) for understanding the motivation of event oriented processing, but if you are short on time, just spending a few minutes building Node and running some examples is informative.

Re: JavaScript: It’s Not Just for Browsers Any More

#75

Post by Hexstream »

trevelyan wrote: post #64
jerf wrote: post #39

Earlier quoted context omitted.

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

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

Re: JavaScript: It’s Not Just for Browsers Any More

#76

Post by Hexstream »

planettrash wrote: post #33
raganwald wrote: post #30

Earlier quoted context omitted.

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

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.

Re: JavaScript: It’s Not Just for Browsers Any More

#77

Post by subbu »

blasdel wrote: post #45
jerf wrote: post #37

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…

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.

Re: JavaScript: It’s Not Just for Browsers Any More

#78

Post by mechanical_fish »

rapind wrote: post #41
mechanical_fish wrote: post #14

Earlier quoted context omitted.

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…

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.

Re: JavaScript: It’s Not Just for Browsers Any More

#79

Post by cageface »

tumult wrote: post #58
Maciek416 wrote: post #13

Earlier quoted context omitted.

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 event…

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 dynam…

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.

Re: JavaScript: It’s Not Just for Browsers Any More

#80

Post by tumult »

cageface wrote: post #79
tumult wrote: post #58

Earlier quoted context omitted.

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 dynam…

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.

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