21–30 of 65 posts
As noted somewhere else learning node is not learning front-end. Something that bothered me recently is that on the back-end we are used to big oop frameworks when in fact the stateless nature of http do not match oop so well. On the front end however we have a gui so oop is a good paradigm.
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 disagree. Firstly, CoffeScript is not confined to the client-side. Besides, there are some modules like socket.io for which you will hardly find any substitues in other eco-systems.
You're also discounting the effects of context shifts between two separate languages - one on the client side, and the other on the server side.
Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.
If the point is to learn front-end development, it seems like you're still sticking to your strengths instead of challenging yourself and delving into actual front-end DOM manipulation stuff.
Agree. It seems the OP is just moving from one language to another rather than from one domain (back-end) to another (front-end). If you're learning JavaScript to get familiar with front-end and UI, Node.js is just a distraction. Instead, my advice is to learn raw HTML/CSS/JS without frameworks. You know those cheesy web-based "OSes"/Desktops that no one really uses? Building one is actually quite helpful to developi…
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...
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 think you have the wrong link there. It goes to a paper about Self.
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…
As noted somewhere else learning node is not learning front-end. Something that bothered me recently is that on the back-end we are used to big oop frameworks when in fact the stateless nature of http do not match oop so well. On the front end however we have a gui so oop is a good paradigm.
Huh? What does the statelessness of HTTP have to do with OOP, particularly on the server, but not the client?
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…
You may see some very nice libraries/tools coming out around node.js, like jade, coffeescript, and stylus. These are all nice and good, and they do increase your productivity, but, only on the client side. I disagree. Firstly, CoffeScript is not confined to the client-side. Besides, there are some modules like socket.io for which you will hardly find any substitues in other eco-systems. You're also discounting the ef…
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 you find productive about Go, that's not the case with either CS/JS on Node.
Not having to write everything asynchronously?
I haven't actually used go, but the way goroutines communicate (and synchronize) with channels suggests to me (from what I've read/seen) that this callback spaghetti problem is non-existent in Go.
After reading so many negative things about nodejs, I'm completely surprised to report that it is actually pretty damn cool. Most of these negative things were (are being?) written by people who target Node's shortcomings without giving due concern to the areas it shines in. Good Parts is definitely a good read. If anyone is looking for more reading materials on JavaScript, I had written a post about it recently: htt…