Live data from Hacker News

Why I'm Learning Node

rdegges.com

51–60 of 65 posts

Re: Why I'm Learning Node

#51
I like the though process but I think where you may fall short is the UI Design aspect. HTML/CSS/Javascript isn't all that hard, it is creating a good looking and highly usable user interface that is challenging. Good luck!

Re: Why I'm Learning Node

#52
post #46
post #29

Earlier quoted context omitted.

The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write. I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires. > Lastly, I would like to know what y…

> I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires. This is a sign of a not-fully-adopted paradigm shift. Like, when someone first learns a new (spoken) language, they translate it to their native language in their head. Fluent speakers don't translate, they simply underst…

> Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

A minor remark from my experience with functional programming, continuation-passing style is actually something I prefer to avoid.

Re: Why I'm Learning Node

#53
Just read around two thirds of 'The Node Beginner Book'. I've only briefly played with node.js before now and I still don't really have an immediate use for it personally. I could see myself using it to whip up rough scaffolding to support prototypes of personal projects written in other languages.

I did learn something from its event-driven callback system though. Made me realize I was approaching things the wrong way in a libevent-based daemon I'm developing in C.

Re: Why I'm Learning Node

#54
post #21

Earlier quoted context omitted.

Huh? What does the statelessness of HTTP have to do with OOP, particularly on the server, but not the client?

Because most server side languages take a "throw away the world" approach to web programming; none of your objects persist in memory through requests, which means every time a request comes in you have to reload a part of the user's world from the db, service the request, and then destroy the world you've just created. For structural things like MVC, objects are great, but you really don't see much of the "object as…

Ah. But that isn't an issue of language or object-orientation. There are server-side frameworks that don't throw away the world, and client-side frameworks that do. (Notice how your javascript state is thrown away everytime you load a new page in the browser). That's a design decision that's made possible by the statelessness of HTTP, but not required by it.

Re: Why I'm Learning Node

#55
post #50
post #19

The problem with node is it decreases your productivity tremendously. The most important thing about the choice of programming tools is productivity. Node.JS does not promise you any productivity gains. Node sells itself as a solution to "slowness" caused by "blocking IO". What's the solution? All I/O is evented! This means you have to write everything with callbacks. You may see some very nice libraries/tools coming…

Or Haskell, Erlang or various other languages that have better solutions for non-blocking I/O.

Or C, C++, Java, Python or Ruby.

Every language has solutions for non-blocking I/O, even the boring ones.

Re: Why I'm Learning Node

#56
post #31
post #29

Earlier quoted context omitted.

The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write. I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires. > Lastly, I would like to know what y…

It cracks me up that you haven't tried Go but you're still recommending it, is there a web framework? Edit: Found web.go. Screw it it's a long weekend, I'll give learning Go a go.

web.go is still not compliant with the recently released Go1. I'd recommend anyone interested in Go but not in a hurry to wait a month or two until the Go1 dust settles.

Re: Why I'm Learning Node

#57
post #54

Earlier quoted context omitted.

Because most server side languages take a "throw away the world" approach to web programming; none of your objects persist in memory through requests, which means every time a request comes in you have to reload a part of the user's world from the db, service the request, and then destroy the world you've just created. For structural things like MVC, objects are great, but you really don't see much of the "object as…

Ah. But that isn't an issue of language or object-orientation. There are server-side frameworks that don't throw away the world, and client-side frameworks that do. (Notice how your javascript state is thrown away everytime you load a new page in the browser). That's a design decision that's made possible by the statelessness of HTTP, but not required by it.

Certainly, but throwing away the world is natural on server side code and it means that your carefully crafted object don't live long and many of them don't need too be objects, they are micro namespaces for a set of methods. I never tried node.js for real but one good side off it could be that you are not pushed towards objects like you are with Python, Ruby, Java, etc.

Re: Why I'm Learning Node

#58
post #19

The problem with node is it decreases your productivity tremendously. The most important thing about the choice of programming tools is productivity. Node.JS does not promise you any productivity gains. Node sells itself as a solution to "slowness" caused by "blocking IO". What's the solution? All I/O is evented! This means you have to write everything with callbacks. You may see some very nice libraries/tools coming…

I very much agree on the drop in productivity. I was just contracted to help with a Node project and just getting up to speed has been difficult. This is not all node's fault since the callbacks and such could have been handled differently.

The better examples will be in a few years when programmers have more experience with Node and the projects' code reflect that.

I won't be returning back to Node after the project though because it reminds me of earlier days writing XML with Spring.

Re: Why I'm Learning Node

#59

Not many people know this, but Javascript: The Good Parts is available online as a PDF, for free! http://www.rose-hulman.edu/Users/faculty/rickert/OldFiles/Cl...

I read through most of J:TGP, but the problem is that it doesn't really focus on the DOM at all (which I knew when I picked it up). Unfortunately, the DOM is the entire reason I'd realistically want to use Javascript anyway.

Most 'popular' languages these days are descendants of C in some form, which means that the differences between any two are very small, in the grand scheme of things. (I'm talking about programming paradigms here - I understand that things like running time and library support are real factors, but to me those define the implementation of a language, not the language itself).

Javascript may be different from most C-derived languages in that it promotes certain paradigms that others don't, but to me, it doesn't offer anything as a language that other languages that I like (and use) don't. Prototypal inheritance is familiar to me from Python (yes, you read that right), and functional paradigms (including first-class/higher-order functions and closures) are familiar to me from Scala and Lisp.

If we want to talk about actual implementation and the runtime environment, I'm still not convinced that Javascript has any real inherent advantages over other languages for most of the non-DOM tasks that people try and use it for. Maybe it promotes familiarity with a single language, but I see that as a detractor, not an asset.

So in the end, while Javascript may be 'more than just the DOM' these days, for me, that's still where its use case lies. Just because I can use it for other things doesn't mean I want to; for anything that I want to do other than manipulating the DOM, I can find an environment that suits me much better.

Re: Why I'm Learning Node

#60
post #19

The problem with node is it decreases your productivity tremendously. The most important thing about the choice of programming tools is productivity. Node.JS does not promise you any productivity gains. Node sells itself as a solution to "slowness" caused by "blocking IO". What's the solution? All I/O is evented! This means you have to write everything with callbacks. You may see some very nice libraries/tools coming…

If "This is a revolution" hadn't been patented by Apple years ago, I'd be using it right now. Hell, Node invented / brought us:

- The Reactor Pattern, a never-been-before paradigm.

- V8 and its mind-blowing speed.

- Evented I/O, a game changer.

- It also allows you to program all that with the best language known to man, Javascript, ON - THE - EFFIN - SERVER (zomg).

Hats off to the Node community though, they're getting good at emulating Rails' PR tactics of buzzwords, fluff and overblown hype.

Post reply on HN