Learning Nodeby Wojciech Adam Koszek ⋅ Apr 30, 2013 ⋅ Menlo Park, CA
My detour to understand Node more. I have a mixed feeling about this book. I feel like too many topics and frameworks have been touched in this text, so it's more of a breath read than a depth read.
Be warned – this is boring and technical thing
In between my Silicon Valley/business/MBA studies, which finally started to make me pretty tired, I decided to revert back to something people consider neat and hot and technically sexy. Something that can expand your skill-set to something better than “mere mortal”.
He also did JSLint:
Which is a neat software. Anyway:
So I was really looking for was a thing where my functions and other “stuff” could get created, and where I could make sure things work, and then move it to the browser. Basically: I was not looking for something with explicit non-blocking memory support.
First about Node I learned from the Node.js author about non-blocking I/O based on callbacks.
Couple of years ago I was a structured programming retard. Basically I would take random Java code form Beans which a friend of mine wrote and I’d criticize him using anonymous functions everywhere. How bad I was. But it was when I had too much time and less understanding of programming and the whole functional concept. In other words, it was before meeting a good friend of mine, Charles. And before I read the LISP book.
I really like the idea of anonymous functions now–they make your code more compact. Basically things look more condensed and consistent. And there’s something I started to appreciate only after I started working for The Man, where the “senior senior” contractor explained me pros and cons and his view on a need of scanning multiple files just to find simple stuff, if #define values.
Non-blocking I/O makes hard things easy and simple things hard. When you want to execute sequential block in a asynchronous block, stuff needs to be wrapped around function/data hierarchy, so that it fits the non-blocking model.
Some portions of examples are surprisingly simple and surprisingly “new” in a way makes me thing “why hasn’t this been done before”. Example:
When I think about it, it really doesn’t have to get anything better.
From the deployment perspective my understanding is that you basically have to hack around a lot to make it work, and probably even more to make it perform well, since stuff looks like something pretty primitive. It’s a pity Node.js doesn’t code with a solution letting me to run it continually, just like Apache. Basically I want a solution which will hide from me the fact that I need an external program to restart Node.js in case things go WRONG. It might be the same as it is now (using external “monitor” program to see if Node is alive), but I don’t want to be aware of it.
Unfortunately Node.js doesn’t really help with whole WWW page thingy–it’s still is some random code mixed with random HTML tags.
The whole book was just fine, however little or nearly no space (based on ratios of content) is spent on deeply explaining Node.js nature.