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

The node.js aesthetic

substack.net

Post reply on HN
Print view View original

51–60 of 81 posts

Re: The node.js aesthetic

#51

Post by catshirt »

IsaacSchlueter wrote: post #46
catshirt wrote: post #41

Earlier quoted context omitted.

perhaps you guys are arguing semantics. i think it's fair to say javascript does not have traditional inheritance or classes. crockford seems to agree [0], perhaps i don't understand the argument. [0] http://javascript.crockford.com/javascript.html

What is a "class" in this context? Let's define it. As a rough strawman to move forward, let's say that a "Class" is a programming object consisting of: - A constructor method. - A set of properties and methods - Optionally, a parent Class from which it inherits properties and methods, which may be overridden. And that, when invoked, a "Class" returns an Object which is said to be an "instance of" that Class. The con…

i don't even know what you're arguing with to be honest- i merely suggested you and MostAwesomeDude have different definitions for class. which is exactly what your reply suggests.

classes create new types. this is precisely why MostAwesomeDude said "JavaScript is prototyped, not inherited, and doesn't permit the creation of new types". if you want to omit that from your definition of class then fine. but you're no longer talking about the same thing as MostAwesomeDude.

Re: The node.js aesthetic

#52

Post by jesusabdullah »

gbog wrote: post #2

Hmm, seems a bit hand-waving to me, but to be fair I have never tried Node.js and would probably have hard time convincing my finger to type javascript code for server things. Javascript always seemed to me a language that you used, and tried to use correctly, because you had to. On a server I have the choice, right? So my choice is currently Python so I read this article with some bias. In the section "batteries not…

numpy and scipy are poor examples because they're not core python modules. You still install them from separate people.

Re: The node.js aesthetic

#53

Post by yorick »

IsaacSchlueter wrote: post #46
catshirt wrote: post #41

Earlier quoted context omitted.

perhaps you guys are arguing semantics. i think it's fair to say javascript does not have traditional inheritance or classes. crockford seems to agree [0], perhaps i don't understand the argument. [0] http://javascript.crockford.com/javascript.html

What is a "class" in this context? Let's define it. As a rough strawman to move forward, let's say that a "Class" is a programming object consisting of: - A constructor method. - A set of properties and methods - Optionally, a parent Class from which it inherits properties and methods, which may be overridden. And that, when invoked, a "Class" returns an Object which is said to be an "instance of" that Class. The con…

We're not actually at ES5 yet, and to be honest I have not read it completely. I have read ES3 though, and I believe what they call "Classes" are the Array and the Number and the Date and the Boolean and most other globals that start with a capital, and you can find out the Class of a value by calling Object.prototype.toString on it. If you believe "Classes" to be these things, then yes, javascript has classes. It does not, however, allow you to create them yourself.

For what I have seen from ES5, which is not much, it is pushing Object.create, instead of the new X notation, which you were talking about (as the functions all being classes). According to your definition, things using Object.create are no longer classes, as they do not posess constructor functions (although you could still provide one and make it call Object.create). In this fashion, javascript is moving away from whatever classes it had, and into fully prototype-based inheritance.

Whether we think javascript has classes or not is mostly related to your definition of a 'class'. Personally, I think the "Classes" are not actually classes, just names for some native types, and the classes (which are actually classes) javascript does have (using the new X notation) should be abolished as soon as possible, as they look like a confusing attempt to make javascript less confusing for new people coming from Java or C++, by providing them with their familiar concept of classes. They merely guide people away from the powers of prototypical inheritance, instead of driving them closer.

By your definition, javascript is full of classes, but most of them are not intended to be classes, and they probably should not have been. (ever tried forgetting new when instantiating a class? that clobbers your global object massively, unless you use a detection-method to prevent it, further explained on the top answer at http://stackoverflow.com/questions/383402/is-javascript-s-ne... )

Re: The node.js aesthetic

#54

Post by YuriNiyazov »

yorick wrote: post #53
IsaacSchlueter wrote: post #46

Earlier quoted context omitted.

What is a "class" in this context? Let's define it. As a rough strawman to move forward, let's say that a "Class" is a programming object consisting of: - A constructor method. - A set of properties and methods - Optionally, a parent Class from which it inherits properties and methods, which may be overridden. And that, when invoked, a "Class" returns an Object which is said to be an "instance of" that Class. The con…

We're not actually at ES5 yet, and to be honest I have not read it completely. I have read ES3 though, and I believe what they call "Classes" are the Array and the Number and the Date and the Boolean and most other globals that start with a capital, and you can find out the Class of a value by calling Object.prototype.toString on it. If you believe "Classes" to be these things, then yes, javascript has classes. It do…

What's a "detection-method" ? I Googled, didn't come up with much.

Re: The node.js aesthetic

#55

Post by koen »

zzzeek wrote: post #32
substack wrote: post #30

Earlier quoted context omitted.

The asynchronous aspects were a very small piece of the article for a reason. Node is doing a lot of very interesting, important, and novel things that aren't related to asynchronous events at all. Twisted in particular suffers from too much exposed surface area and having to manage the reactor yourself, which hurts reusability a lot.

I'd prefer to see a detailed article about that. Also I'd like to see more detail on why exactly writing custom servers is so profoundly important all the sudden. I hardly see the advantage of even nginx over apache, though that's a different issue.

WebSockets probably. None of the traditional server-side web frameworks (Ruby on Rails, Django, Java Servlets, ...) can deal with them because you need to maintain open connections with each client. That also makes asynchronous I/O important (a feature of nginx over apache).

Most WebSockets solutions are clumsy at best, because you need to run something independent from the rest of your web stack. Unless you use solutions like Wt (http://www.webtoolkit.eu/wt).

Re: The node.js aesthetic

#56

Post by virmundi »

koen wrote: post #13

> A big part of what empowers node to make these kinds of interfaces possible is its asynchronous nature. No longer do you have statelessness imposed from on high by the likes of apache or rails. You can keep intermediate state around in memory just like in any ordinary program. Should that not be: A big part of what empowers node to make these kinds of interfaces possible is its "statefull" nature. ... Really, that…

I think the sessions in Node/Express are helpful when pair properly. For example, Express can use Redis as its session store. This has the benefit of making the session cross-cluster populated, while still being fast. Add to this the fact that almost everything in JS is serializable as itself and you get a pretty good replication mechanism.

Re: The node.js aesthetic

#57

Post by bretthoerner »

koen wrote: post #55
zzzeek wrote: post #32

Earlier quoted context omitted.

I'd prefer to see a detailed article about that. Also I'd like to see more detail on why exactly writing custom servers is so profoundly important all the sudden. I hardly see the advantage of even nginx over apache, though that's a different issue.

WebSockets probably. None of the traditional server-side web frameworks (Ruby on Rails, Django, Java Servlets, ...) can deal with them because you need to maintain open connections with each client. That also makes asynchronous I/O important (a feature of nginx over apache). Most WebSockets solutions are clumsy at best, because you need to run something independent from the rest of your web stack. Unless you use solu…

What do you mean when you say "independent of your stack"?

memcached, postgres, rabbit, etc aren't written in the language I use, but they're very much a part of my stack.

Using an external application to hold the WebSocket connections and be the middleman between your app code and the user is not automatically clumsy. Clumsy would be re-writing your app in JavaScript because you believe it's the only language suited to WebSockets.

Re: The node.js aesthetic

#58

Post by bretthoerner »

bradleymeck wrote: post #35
zzzeek wrote: post #5

>You don't need to reason about multiple instruction pointers or mutexes or re-entrant, interruptible execution because all the javascript you write just lives in a single thread. I see....on the other hand, when I write request-handling code using (any web framework ever on any platform), you're suggesting that we do worry about mutexes and reentrance (not to mention, handling a single request uses multiple threads?…

When working with requests that share resources via web frameworks that deal with threads, the large consensus is to put the resource into an external managed resource. This external resource such as a database will manage the locking for you to prevent write conflicts, however, when caching values for complex interaction beyond CRUD you may have update conflicts where a new request has an in memory copy of an outdat…

Wait, how does Node solve this where others don't?

Re: The node.js aesthetic

#59

Post by benatkin »

munificent wrote: post #25

> So if a module "foo" was tested against and depends on "baz@0.1.x" and a module "bar" depends on "baz@0.2.x", then when you go to use both "foo" and "bar" in your own program, "foo" and "bar" will both use the version of "baz" that they were tested and depend against! That sounds like a recipe for disaster if I get an object from "bar" that came from "baz@0.2.x" and try to give it to "foo" which then gives it to "b…

The Law of Demeter applies here, even if traditional objects aren't being used. If the library that uses it encapsulates everything about it, or at least documents things that aren't encapsulated, it tends to work out just fine.

http://en.wikipedia.org/wiki/Law_of_Demeter

Re: The node.js aesthetic

#60

Post by MostAwesomeDude »

substack wrote: post #39
MostAwesomeDude wrote: post #34

I find the spinning in this article to be incredible . The "limited surface area" is all well and fine in JS, because there is no object inheritance in JavaScript . The author tries to emphasize usability over extensibility, which is a false dilemma in my book since it's possible to code to an interface in other languages. You define a usable interface, and then everybody codes things that fit that interface. You don…

> Let's go ahead and compare with Twisted, shall we? Oh goodness, yes. How about an echo server. This one is from the twisted home page, so I am not knocking down a strawman. from twisted.internet import protocol, reactor class Echo(protocol.Protocol): def dataReceived(self, data): self.transport.write(data) class EchoFactory(protocol.Factory): def buildProtocol(self, addr): return Echo() reactor.listenTCP(1234, Echo…

The reactor is explicit. "Explicit is better than implicit." You don't have to always be in the reactor, if you don't want to. It lets people use Twisted to build GUIs and other things, without always being in the reactor's context. Twisted is a general-purpose networking library, not a tiny-web-servers-only networking library.

An example used to illustrate and educate does not necessarily result in the shortest code sample. That sample does not use twisted.protocols.wire.Echo, because it was decided that things should be explicit and obvious in the samples on the front page.

The reason for separating protocols and factories is simple: Sometimes you need to store per-connection state, sometimes you need to store per-server state. The separation permits developers to store things in factories instead of in global objects. Node doesn't have this distinction, and as a result, things like tracking all connections currently made on a server are cumbersome.

Another thing is testing. How should a person test the Node example? Every bit of the Twisted example is trivially instrumentable; I can access the protocol, the factory, the reactor. I could, if I wanted, replace the reactor with something mocked. There's no place to do that in the Node example.

I was gonna type out an IRC bot, the favorite exercise of novice coders, but I felt that would be petty, since there's no IRC library included in Node.

Post reply on HN