10 ms·

Farewell Node.js

357 points by beltex 12y ago

bsiddiqui 12y ago
convinced he represents an org of devs http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
anonfunction 12y ago
For those that don't know TJ Holowaychuk, he's the guy behind express and commander.js (and a lot more) which are two of the most popular node.js packages.
- waitingkuo 12y ago
  My favorites are jade and stylus, which are also hot!
  - couchand 12y ago
    Mocha is the only JavaScript testing framework that works on the server and the browser and is simply beautiful. Superagent is likewise a simple and obvious API that works identically in both environments. TJ has done quite a bit to advance the state of the art in JavaScript development, it will be interesting to see what he does with Go.
    - notduncansmith 12y ago
      Jasmine works on the server and the browser. http://jasmine.github.io/1.3/introduction.html http://jasmine.github.io/1.3/introduction.html
- beltex 12y ago
  "First, lets admit the facts: as of today, it is possible to produce a competitive Node application whose entire stack will comfortably rest on various frameworks, tools and libraries developed exclusively by TJ. If you are doing things with Node, you will not escape TJ. He is omnipresent." http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
- deleted 12y ago
  [deleted]
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
aroman 12y ago
This is as significant a loss for the Node community as the loss of _why was to the Ruby community. Maybe even more so.
nadaviv 12y ago
I've been using his libraries since I started out with node, and there isn't a single project that I'm working on today that doesn't have at least 2 or 3 of his libraries as dependencies. He has contributed a lot to the nodejs ecosystem (around 600 packages! [1]), and it saddens me to see him go. The Go guys should be very excited to have him on board! [1] https://www.npmjs.org/~tjholowaychuk https://www.npmjs.org/~tjholowaychuk
- tdumitrescu 12y ago
  Yeah, it's absolutely crazy how much that dude put out there over the last years, totally impossible to do JS web dev work without using at least a few of his libraries like Express, Jade, Mocha, Co. and then one day it's like "alright done with that." If I could be even 1/2 that productive...
  - Jonovono 12y ago
    Maybe this will make you feel better :p http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-.... Speculation he is actually a Pen name.
    - smoe 12y ago
      Or maybe Google is behind this. They created an icon within an emerging community where all the cool kids go, in the hope they will follow once he publicly converts to golangism
      - deleted 12y ago
        [deleted]
      - ansimionescu 12y ago
        Yep, that's exactly the kind of thing Googlers spend their time on. /s
    - ulisesrmzroche 12y ago
olegp 12y ago
Couldn't agree more with this post. Node has always had a problem with favoring performance over robustness, coupled with an overly zealous, polarized community that exists in a bubble. This resulted in synchronous libraries like fibers being shot down without proper consideration. At StartHQ (https://starthq.com https://starthq.com) we've abstracted away all async code with a sync layer using fibers and that has served us well over the past year, but I can totally see how trying to mix the two would have been a recipe for disaster. Here is a video of a talk we gave on this: http://www.youtube.com/watch?v=pmyDJnEza6A http://www.youtube.com/watch?v=pmyDJnEza6A and here are the slides: http://www.slideshare.net/olegp/start-hq-server-side http://www.slideshare.net/olegp/start-hq-server-side
- bhauer 12y ago
  > Node has always had a problem with favoring performance over robustness I don't disagree with the gist of what you're saying, and I think you're correct. But the premise of Node being high-performance is perhaps more reputation than actual fact. I think it gets that reputation because it is higher-performance than some more popular options, but in the big scheme of things, it's but a medium-performance platform [1]. [1] http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=json http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...
  - olegp 12y ago
    Agreed. I benchmarked Node/V8 vs. the JVM and while Node has lower memory usage, Java is as performant while being more reliable, with less variance in HTTP response times, due to the better garbage collector. http://www.slideshare.net/olegp/server-side-javascript-going-all-the-way http://www.slideshare.net/olegp/server-side-javascript-going... - there are some graphs from slide 46 onwards.
- jeswin 12y ago
  There is no guarantee that a custom fork with fibers will be maintained and patched in the long term. Generators are a safer, forwards-compatible choice for doing async work. That's why there is little support in the community for adopting fibers. The big issue with generators is making sense of stack traces while debugging. And due to the nature of how generators work we'll probably need an fairly creative solution here. I'm fine with generators today, but it would be better if await sugar landed sooner.
thiago_fm 12y ago
The hype of writing javascript everywhere is over long time.
deepakkapoor 12y ago
http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
- oknoorap 12y ago
  he is genius boy from 21st century
- mburst 12y ago
  That was a pretty cool read. The theory definitely makes sense
  - deepakkapoor 12y ago
    If I was in Canada then I would go to Vision Media's office just to meet or rather verify the assertion. It would be a win win in either case.
    - gkoberger 12y ago
      visionmedia is his screen name, not the company where he works. He worked at a company called LearnBoost (https://www.learnboost.com/blog/welcome-aaron-and-tj/ https://www.learnboost.com/blog/welcome-aaron-and-tj/), which I can only assume is some sort of mob-style front for laundering JavaScript code. (Look at their employee list and GitHub repo) Now, I've heard he works for Segement.io (in SOMA), but does so remotely.
cnp 12y ago
Always, always loved his attitude towards stuff. Seriously. And when its time to go, its time! Good luck TJ and thank you so much for everything.
archgeek 12y ago
Maybe Golang is great for developing frameworks, but as someone who build websites i prefer Node because Go's typing makes development slower and more expensive.
- notduncansmith 12y ago
  I used to feel similarly about most static type systems, but Go's feels unusually light and I rarely feel encumbered by it.
  - codexon 12y ago
    I still found it more awkward to do things like access JSON in Go.
    - skuwamoto 12y ago
      Can't you just unmarshal into interface{}?
      - notduncansmith 12y ago
        You can, but the properties need to be string pointers, not strings (this one stumped me for hours).
- ragesh 12y ago
  Dynamic typing was very cool when I started out with Node, too. It lets you get things wired up very quickly and come up with a very functional app with almost no friction. But in my experience, once the app reaches a point where I no longer remember every single line of code that was written in it, I start to miss what a type system could tell you. Hmm, do I pass a string in the first parameter, or was it the second? What does that funciton return? Am I really getting a number in this parameter? Of course, you can get around that confusion by adding more unit tests and parameter validation but with strong typing I'd get all that for free.
  - 12y ago
nemothekid 12y ago
We're a pretty heavy Go production shop, but today I decided that we would move our dumb rails codebase (we were really only using the asset pipeline) to nodejs+mincer (mainly to get rid ruby). Hope the departure of an incredibly js developer doesn't impact the community too badly.
derengel 12y ago
I guess the important lesson from him here (which he mentions) is to get out of your comfort zone and learn new stuff, as to be able to tackle problems with a wider view of things and solve them with the most adequate tools.
shadowmint 12y ago
I was suprised to see the comment that tooling for Node wasn't great; I thought the node tooling (npm, gulp, grunt, etc.) was significantly superior to the primitive (ie. relatively low level) tooling go provides. ...but I see that's a very specific comment: the tooling Go provides for profiling and debugging is great... Ah, that makes more sense. This is definitely an area where node applications are really troublesome to work with (live debugging).
- notduncansmith 12y ago
  I was surprised as well, until I saw that. The npm/gulp/bower/less/node stack is pretty awesome for full-stack web development. All in one language, all open source, easy-breezy package management. If Go had that sort of complete stack (and for God's sake a package manager to rival npm), I'd probably be pushing Go as hard as possible at work. As it stands, there's way too much friction and it would cost a LOT of money to invest in Go. There's a good chance that the ecosystem may not evolve to Node's level for years - and worst of all, if you want to build competitive web apps, you still can't avoid Javascript.
mambodog 12y ago
One (very arbitrary) metric of TJ's position in the node community: https://github.com/substack/npmtop https://github.com/substack/npmtop running it today tells us that he's still number one: rank percent packages author ---- ------- -------- ------ 1 0.60 % 548 tjholowaychuk 2 0.44 % 401 substack 3 0.41 % 379 jongleberry 4 0.40 % 367 dominictarr 5 0.37 % 341 jonschlinkert 6 0.37 % 337 sindresorhus 7 0.36 % 331 juliangruber 8 0.34 % 317 mikolalysenko 9 0.31 % 289 raynos 10 0.28 % 260 mathias 11 0.28 % 257 hughsk 12 0.28 % 255 forbeslindesay 13 0.26 % 239 tootallnate 14 0.23 % 216 clewfirst 15 0.23 % 208 azer
deleted 12y ago
[deleted]
throwaway41597 12y ago
> We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there I wish more people realized this. Generators seem to be billed (ironically by TJ amongst others with his Koa project) as the solution to callback hell but, having tried Go, I got the same felling that actors are much easier to reason about and debug (although concurrency is still hard). On the client side, web workers allow parallelism but the API is inconvenient to use: you need to have a file for each web worker whereas Go's `go` routines are akin to a function call. In addition to this standardized conundrum, you have browsers discrepancies with the APIs available inside a worker varying between vendors [1]. On node, you have the cluster API, which allows managing several processes so it's even further from light threads. On the bright side, most (all?) APIs have both a sync and async version. As a result, there's nothing you can use for multithreading in a module without coordinating with the whole project. I think JavaScript needs language support for light threads, not APIs for multiprocessing. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers https://developer.mozilla.org/en-US/docs/Web/API/Worker/Func...
- iambase 12y ago
  Rather than cluster API, I guess you meant child process API but otherwise I agree 100%.
- aikah 12y ago
  Nodejs could have workers,it's not really a javascript.Node maintainers just didnt implement that stuff. I personnally dont like generators for concurrency.It's the wrong solution to the problem.For now I stick with promises,and I hope JS gets async/await keywords quickly.
  - throwaway41597 12y ago
    > Nodejs could have workers Agreed, but what I meant is that the API (running a file in a worker) is inconvenient, first because there is no closure. Go allows the go routine to read variables in scope and has a race detector to tell you when your accesses are unsafe. There's also the issue of managing workers: is a web worker an OS thread or a light thread [1]? how many can you spawn? which worker should you send work to? These problems are solved by Go. I think it would be very hard to obtain the same reliably and performance with today's web workers. Other languages solve this with a language construct, not an API to run another file. > I hope JS gets async/await keywords quickly It would be a step up. But most of the time you want to express a linear list of tasks. Javascript should support this by having a synchronous variant of its APIs and having light threads. My hope is more that some language having such features will compile to asm.js [1]: it's either a thread, a process or an "equivalent construct" http://dev.w3.org/html5/workers/#processing-model http://dev.w3.org/html5/workers/#processing-model
ilaksh 12y ago
I wonder if people are picking Go over Nimrod mainly because Go is more popular.
- woah 12y ago
  It's certainly one of the best reasons to pick a language. Popular = Ecosystem .
- deleted 12y ago
  [deleted]
_greim_ 12y ago
This post really resonates with me. I'm not as prolific and don't have the ability to breeze into a new language on a whim, but seeing so many other languages gaining momentum nowadays really makes me feel restless. All the best of luck to him, and I certainly hope I'm not stuck in the same rut the next ten years.
sriku 12y ago
Server side dev folks have always enjoyed choice of language/system when it comes to building. You can simply choose the thing that works best for you, that you're more comfortable with, is most performant for your app, etc. On the client side, we have ... javascript. While JS is pretty fast these days everywhere and we can cross compile with emscripten and all, I'm almost tempted to say that the true web standard for programmability on both client-side and server side ought to be some kind of a byte-code .. a concept the Java guys had right way back. If you consider that we have PNaCl compiling llvm-bitcode to native within the browser, Emscripten cross compiling llvm-bitcode to asm.js (which Firefox's engine converts to native), Safari's engine compiling js itself to llvm-bitcode, I'm thinking why not make llvm-bitcode an open web standard? That way, any language that compiles to llvm-bitcode would be equally usable on the server side and on the client side. The biggest potential downside to that would probably be educational. I learn a lot by looking at source code and the web was always open in that way, though with minified JS these days that's not so possible any more. However, it might make it easier to distribute source code in any language, since a module can then compile and run such code right in the browser. edit: These thoughts came up when I was thinking about how TJ won't be able to take his work with him as he moves to Go. Well, I suppose he wants to do new kind of work for which Go is better suited, but is then all of the prior work just a brief view along the journey?
pjmlp 12y ago
Another I left <dynamic language> for <strong typed language> when faced with performance/large codebase/tooling issues post. Additionally we are now past Rails wave, Node.js wave and into Go wave.
- adamors 12y ago
  > Additionally we are now past Rails wave, Node.js wave and into Go wave. And the narrative is similar as well: starting a new project with the shiny new thing is cool but maintaining it is boring and awful and to quote the OP "I need maintainers!". Part of the problem is the language of course. Maintaining even a medium sized codebase written in a dynamic language is a challenge. But the other part is the mantra that "coding is easy" and "everyone should do it". And now there's an entire generation of developers whose idea of software development is "writing an app in Node in a weekend". Which of course doesn't require years of maintenance, complicated tooling or even adherence to common best practice.
- drdaeman 12y ago
  Erm. If you meant "static", not "strong", then Go is as statically typed as, say, C - fine in theory, but not so much in real world practice.
kolev 12y ago
Reminds me of Zed Shaw leaving Ruby... Honestly, Node.js has done a lot, but, come on, it's still JavaScript in the core. The selling point that you can run the same code both on the client and on the server doesn't really hold up to the reality check. I'm not so excited about Go, I honestly find Rust better. Dart also seems promising - especially having dart2js and Google backing it, too, but it doesn't seem to be picking hype as fast as Ruby and then Node.js did. To me, having a powerful package manager seems to be the common theme and they key to success. I still can't believe with all the ego, Python is still relying on a joke like pip. Although I agree it would be challenging, I think the world will be a better place if there's a cross-language package manager, with language-specific plugins. At the end of the day, maybe 75% of the logic is shared and is around downloading things, installing symlinks, checking dependencies, and so on. Package that with a cross-language pyenv/rbenv/nodeenv, etc., and you would have a killer.
- sriku 12y ago
  > I'm not so excited about Go, I honestly find Rust better. Same here, but Go has productive libraries that can help you hit the ground running. Just with the packaged standard libraries, you can do things like have a useful webserver going. I prefer Rust though and might stick with JS until I exhaust it .. or until Rust matures enough to put into production and then jump fully on to Rust. Rust compiles to llvm-bitcode, unlike Go, so that's a win for me. edit: I stand corrected - https://github.com/go-llvm/llgo https://github.com/go-llvm/llgo
  - kolev 12y ago
    I've seen that, but just noticed that the project is led by a Canonical developer, which I find interesting.
- boothead 12y ago
  Try Nix(Os) https://nixos.org/wiki/Howto_develop_software_on_nixos https://nixos.org/wiki/Howto_develop_software_on_nixos We use it at work for both packaging and deployment and it's awesome!
mike-- 12y ago
Wait a couple of years and author finds erlang or scala...
- th0br0 12y ago
  ... or Rust, given that the language should have matured by then. But other than that, I'm also waiting for people to eventually discard Go and move on to one of those languages...
davidw 12y ago
Pity he didn't have a look at Erlang. It's not likely to be the "next big thing", but it's really good at what it does.
- brickcap 12y ago
  He did give erlang a try and tweeted about it 4 years back. I think judging from some of this other comments on disqus(I can't find them at the moment) he did not like it very much. https://twitter.com/tjholowaychuk/status/16988926506 https://twitter.com/tjholowaychuk/status/16988926506
bipin-nag 12y ago
He is one of the topmost contributors to the node.js ecosystem if not the most. He has given a plenty of good libraries. Besides the reasons he gave to leave node.js, I feel that he was under-appreciated and over-worked many times. With components he tried to create a toolchain, wrote express and koa for server, jade for templating, mocha for debugging etc. He tried to do a lot many things single-handedly. Which is why he needs a lot of maintainers. I don't blame him for overloading and stressing out. That is the way how it goes in node.js. Working in node.js is like battling a multi-headed beast. The core javascript keeps evolving, node.js isn't even in version 1.0, API changes a lot. There are lot of blanks to fill and too much time goes into boilerplate stuff and managing existing code. It is just not rewarding and fulfilling to contribute to node.js. On top of that he faced a lot of friction from other contributors. He had some really difficult times, like express-connect conflict, bower-components conflict. Having handled conflicts too many, some people also consider him as being rude and too self-centered. Besides he is young and is probably one of the first things he has done he is serious about. Many times before I asked to myself how does this guy do it. In a community where to contribute even a little one has to put in a lot of effort, his contributions are gigantic. I hope he continues to work, although not at too many projects . His experiences will definitely be handy.
- enome 12y ago
  On top of that I remember the first nodeup podcasts and on twitter some key member from the community would bitch about express all the time. Ranging from express is bloated to middleware is a shitty abstraction to you don't need a framework in Node.js. It was really weird because express was (is?) one of the most used framework in the Node.js community and here you have people that other people follow and listen to tell you that it's crap.
  - tjholowaychuk 12y ago
    Haha yup, I wont lie I have been an asshole at times, mostly because you sort of have to defend yourself when you're surrounded by people who attack your work, but after a while I realized it wasn't worth it so I just sort of detached (no longer on IRC, the mailing list etc). Defending your work isn't worth becoming rude yourself. Communities always form cliques that's just how it is. The core node community was very unreceptive to change since the very beginning, to be honest Ryan and Isaac were some of the few humble people in the bunch. I've always been a "threat" to "the node way" of doing things, whatever that means. The elitism gets a little old.
develop7 12y ago
despite Go isn't actually an answer, good for him anyway
spasquali 12y ago
Go is a great language, and I'm looking forward to see what TJ does with it. He's bored, and moving on. That's it. He's trying to justify what must be a painful decision by making a bunch of abstract claims about how Node isn't a production-ready language. The elephant in the room: how is it that TJ was able to build so many things, over so many years, that are used -- in production -- in so many places, in a language that is "difficult to debug, refactor and develop."? Is he a masochist? I think he's hit a personal wall. It seems he has a beef with the way the core is being developed. And Go is indeed fun, and exciting. This isn't surprising. People get burned out.
- tjholowaychuk 12y ago
  Not at all, my claims of node not being production ready are 100% legit, and based on real-world applications. The thing that is enjoyable Go is that it IS production ready, if I could say the same about node I would still be using it. Like I mentioned in my post, I decided to rewrite an application that I had been working on for the last month with Go. I decided that if I could do it in a week, and if it went well that I would ditch node. It went even better than I had hoped, and is much less frail. Node has many design flaws down to its very roots. I'm not saying those are due to terrible engineering or anything, but they were choices that were made and Node is stuck with them for the foreseeable future until breaking changes can be made. That is if the core people can admit that it's not great to work with :) I think the main problem is often people working on the depths of some system forget to really use it. It's so easy to get caught up in the details but if you don't step back and use your own product you're screwed!
  - spasquali 12y ago
    Your experiences moving a Node app to Go would make for a great study. You're extremely influential, and it may be better to give concrete examples of how Node can be improved. I wonder about this "enjoyable" criteria. I'm assuming you're not claiming to be the only person who has written large Node systems, or that nobody has ever written larger, more highly trafficked, more complex Node applications than you have. So the point seems to be: for you, Go is more fun than Node at scale. As a well known contributor, that's a valuable perspective. I'd like to know more about how your personal experience could be translated into general truths all developers could understand. It seems to me that Node is used rather extensively by the core contributors. I don't get the impression that they have never actually used the product, based on their repos etc. Thanks for all your work. I'm sure the Go community will similarly benefit from your efforts.
alecco 12y ago
Hilarious/sad how this has 210 points in 9hrs and it's 2nd page.
wesbos 12y ago
TJ did a lot for this community, sad to see him go but really happy that he did contributed so many library that we will continue to learn.
ericff 12y ago
I really want to know why he chose golang instead of X or Y (Elixir, Erlang, Scala, ClojureScript). Have he said anything about that in other blog? Or anyone of you have sent him email about that? I use node.js (0.3 to now) quite a long time. I also feel the smell of node.js, forever, express and socket.io. Recently, I am considering switch to Elixir. But I am afraid now. From day one in node.js to now, we know that node.js is not prefect and not fastest. But it is so popular and some many great guys, like TJ, contributed many packages into the eco-system. Go is not prefect too. But once it get more popular and more packages. Better vm like Erlang or X or Y may be just ignored by devs.
- ericff 12y ago
  TJ replied my email, he said: Hey! Mostly Go because it suits what I pictures as my ideal language pretty well. It's simple, C-like, great concurrency primitives, great standard library. I've had bad experienced with anything JVM so I'd stay away from Clojure, and Erlang has some legacy baggage but I'd still like to give it a better look some day! Elixir is cool but too Ruby for me
novaleaf 12y ago
I guess I'm a little late to the party, but can someone comment on the issues TJ mentions? Specifically, I've never seen problems with callbacks being double-executed. Under what conditions would it occur?
disputin 12y ago
Moving from Node to Go? From a platform to a language? And what's with the one size fits all - moving? And if moving a project from Node to Go, was Node the correct choice initially, for that project - more one size fits all?

357 points by beltex 12y ago

convinced he represents an org of devs http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...

anonfunction 12y ago

For those that don't know TJ Holowaychuk, he's the guy behind express and commander.js (and a lot more) which are two of the most popular node.js packages.

waitingkuo 12y ago
My favorites are jade and stylus, which are also hot!
- couchand 12y ago
  Mocha is the only JavaScript testing framework that works on the server and the browser and is simply beautiful. Superagent is likewise a simple and obvious API that works identically in both environments. TJ has done quite a bit to advance the state of the art in JavaScript development, it will be interesting to see what he does with Go.
  - notduncansmith 12y ago
    Jasmine works on the server and the browser. http://jasmine.github.io/1.3/introduction.html http://jasmine.github.io/1.3/introduction.html
beltex 12y ago
"First, lets admit the facts: as of today, it is possible to produce a competitive Node application whose entire stack will comfortably rest on various frameworks, tools and libraries developed exclusively by TJ. If you are doing things with Node, you will not escape TJ. He is omnipresent." http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
deleted 12y ago
[deleted]

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

aroman 12y ago

This is as significant a loss for the Node community as the loss of _why was to the Ruby community. Maybe even more so.

nadaviv 12y ago

I've been using his libraries since I started out with node, and there isn't a single project that I'm working on today that doesn't have at least 2 or 3 of his libraries as dependencies. He has contributed a lot to the nodejs ecosystem (around 600 packages! [1]), and it saddens me to see him go. The Go guys should be very excited to have him on board! [1] https://www.npmjs.org/~tjholowaychuk https://www.npmjs.org/~tjholowaychuk

tdumitrescu 12y ago
Yeah, it's absolutely crazy how much that dude put out there over the last years, totally impossible to do JS web dev work without using at least a few of his libraries like Express, Jade, Mocha, Co. and then one day it's like "alright done with that." If I could be even 1/2 that productive...
- Jonovono 12y ago
  Maybe this will make you feel better :p http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-.... Speculation he is actually a Pen name.
  - smoe 12y ago
    Or maybe Google is behind this. They created an icon within an emerging community where all the cool kids go, in the hope they will follow once he publicly converts to golangism
    - deleted 12y ago
      [deleted]
    - ansimionescu 12y ago
      Yep, that's exactly the kind of thing Googlers spend their time on. /s
  - ulisesrmzroche 12y ago

olegp 12y ago

Couldn't agree more with this post. Node has always had a problem with favoring performance over robustness, coupled with an overly zealous, polarized community that exists in a bubble. This resulted in synchronous libraries like fibers being shot down without proper consideration. At StartHQ (https://starthq.com https://starthq.com) we've abstracted away all async code with a sync layer using fibers and that has served us well over the past year, but I can totally see how trying to mix the two would have been a recipe for disaster. Here is a video of a talk we gave on this: http://www.youtube.com/watch?v=pmyDJnEza6A http://www.youtube.com/watch?v=pmyDJnEza6A and here are the slides: http://www.slideshare.net/olegp/start-hq-server-side http://www.slideshare.net/olegp/start-hq-server-side

bhauer 12y ago
> Node has always had a problem with favoring performance over robustness I don't disagree with the gist of what you're saying, and I think you're correct. But the premise of Node being high-performance is perhaps more reputation than actual fact. I think it gets that reputation because it is higher-performance than some more popular options, but in the big scheme of things, it's but a medium-performance platform [1]. [1] http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=json http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...
- olegp 12y ago
  Agreed. I benchmarked Node/V8 vs. the JVM and while Node has lower memory usage, Java is as performant while being more reliable, with less variance in HTTP response times, due to the better garbage collector. http://www.slideshare.net/olegp/server-side-javascript-going-all-the-way http://www.slideshare.net/olegp/server-side-javascript-going... - there are some graphs from slide 46 onwards.
jeswin 12y ago
There is no guarantee that a custom fork with fibers will be maintained and patched in the long term. Generators are a safer, forwards-compatible choice for doing async work. That's why there is little support in the community for adopting fibers. The big issue with generators is making sense of stack traces while debugging. And due to the nature of how generators work we'll probably need an fairly creative solution here. I'm fine with generators today, but it would be better if await sugar landed sooner.

thiago_fm 12y ago

The hype of writing javascript everywhere is over long time.

deepakkapoor 12y ago

http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...

oknoorap 12y ago
he is genius boy from 21st century
mburst 12y ago
That was a pretty cool read. The theory definitely makes sense
- deepakkapoor 12y ago
  If I was in Canada then I would go to Vision Media's office just to meet or rather verify the assertion. It would be a win win in either case.
  - gkoberger 12y ago
    visionmedia is his screen name, not the company where he works. He worked at a company called LearnBoost (https://www.learnboost.com/blog/welcome-aaron-and-tj/ https://www.learnboost.com/blog/welcome-aaron-and-tj/), which I can only assume is some sort of mob-style front for laundering JavaScript code. (Look at their employee list and GitHub repo) Now, I've heard he works for Segement.io (in SOMA), but does so remotely.

cnp 12y ago

Always, always loved his attitude towards stuff. Seriously. And when its time to go, its time! Good luck TJ and thank you so much for everything.

archgeek 12y ago

Maybe Golang is great for developing frameworks, but as someone who build websites i prefer Node because Go's typing makes development slower and more expensive.

notduncansmith 12y ago
I used to feel similarly about most static type systems, but Go's feels unusually light and I rarely feel encumbered by it.
- codexon 12y ago
  I still found it more awkward to do things like access JSON in Go.
  - skuwamoto 12y ago
    Can't you just unmarshal into interface{}?
    - notduncansmith 12y ago
      You can, but the properties need to be string pointers, not strings (this one stumped me for hours).
ragesh 12y ago
Dynamic typing was very cool when I started out with Node, too. It lets you get things wired up very quickly and come up with a very functional app with almost no friction. But in my experience, once the app reaches a point where I no longer remember every single line of code that was written in it, I start to miss what a type system could tell you. Hmm, do I pass a string in the first parameter, or was it the second? What does that funciton return? Am I really getting a number in this parameter? Of course, you can get around that confusion by adding more unit tests and parameter validation but with strong typing I'd get all that for free.
- 12y ago

nemothekid 12y ago

We're a pretty heavy Go production shop, but today I decided that we would move our dumb rails codebase (we were really only using the asset pipeline) to nodejs+mincer (mainly to get rid ruby). Hope the departure of an incredibly js developer doesn't impact the community too badly.

derengel 12y ago

I guess the important lesson from him here (which he mentions) is to get out of your comfort zone and learn new stuff, as to be able to tackle problems with a wider view of things and solve them with the most adequate tools.

shadowmint 12y ago

I was suprised to see the comment that tooling for Node wasn't great; I thought the node tooling (npm, gulp, grunt, etc.) was significantly superior to the primitive (ie. relatively low level) tooling go provides. ...but I see that's a very specific comment: the tooling Go provides for profiling and debugging is great... Ah, that makes more sense. This is definitely an area where node applications are really troublesome to work with (live debugging).

notduncansmith 12y ago
I was surprised as well, until I saw that. The npm/gulp/bower/less/node stack is pretty awesome for full-stack web development. All in one language, all open source, easy-breezy package management. If Go had that sort of complete stack (and for God's sake a package manager to rival npm), I'd probably be pushing Go as hard as possible at work. As it stands, there's way too much friction and it would cost a LOT of money to invest in Go. There's a good chance that the ecosystem may not evolve to Node's level for years - and worst of all, if you want to build competitive web apps, you still can't avoid Javascript.

mambodog 12y ago

One (very arbitrary) metric of TJ's position in the node community: https://github.com/substack/npmtop https://github.com/substack/npmtop running it today tells us that he's still number one: rank percent packages author ---- ------- -------- ------ 1 0.60 % 548 tjholowaychuk 2 0.44 % 401 substack 3 0.41 % 379 jongleberry 4 0.40 % 367 dominictarr 5 0.37 % 341 jonschlinkert 6 0.37 % 337 sindresorhus 7 0.36 % 331 juliangruber 8 0.34 % 317 mikolalysenko 9 0.31 % 289 raynos 10 0.28 % 260 mathias 11 0.28 % 257 hughsk 12 0.28 % 255 forbeslindesay 13 0.26 % 239 tootallnate 14 0.23 % 216 clewfirst 15 0.23 % 208 azer

deleted 12y ago

[deleted]

throwaway41597 12y ago

> We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there I wish more people realized this. Generators seem to be billed (ironically by TJ amongst others with his Koa project) as the solution to callback hell but, having tried Go, I got the same felling that actors are much easier to reason about and debug (although concurrency is still hard). On the client side, web workers allow parallelism but the API is inconvenient to use: you need to have a file for each web worker whereas Go's `go` routines are akin to a function call. In addition to this standardized conundrum, you have browsers discrepancies with the APIs available inside a worker varying between vendors [1]. On node, you have the cluster API, which allows managing several processes so it's even further from light threads. On the bright side, most (all?) APIs have both a sync and async version. As a result, there's nothing you can use for multithreading in a module without coordinating with the whole project. I think JavaScript needs language support for light threads, not APIs for multiprocessing. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers https://developer.mozilla.org/en-US/docs/Web/API/Worker/Func...

iambase 12y ago
Rather than cluster API, I guess you meant child process API but otherwise I agree 100%.
aikah 12y ago
Nodejs could have workers,it's not really a javascript.Node maintainers just didnt implement that stuff. I personnally dont like generators for concurrency.It's the wrong solution to the problem.For now I stick with promises,and I hope JS gets async/await keywords quickly.
- throwaway41597 12y ago
  > Nodejs could have workers Agreed, but what I meant is that the API (running a file in a worker) is inconvenient, first because there is no closure. Go allows the go routine to read variables in scope and has a race detector to tell you when your accesses are unsafe. There's also the issue of managing workers: is a web worker an OS thread or a light thread [1]? how many can you spawn? which worker should you send work to? These problems are solved by Go. I think it would be very hard to obtain the same reliably and performance with today's web workers. Other languages solve this with a language construct, not an API to run another file. > I hope JS gets async/await keywords quickly It would be a step up. But most of the time you want to express a linear list of tasks. Javascript should support this by having a synchronous variant of its APIs and having light threads. My hope is more that some language having such features will compile to asm.js [1]: it's either a thread, a process or an "equivalent construct" http://dev.w3.org/html5/workers/#processing-model http://dev.w3.org/html5/workers/#processing-model

ilaksh 12y ago

I wonder if people are picking Go over Nimrod mainly because Go is more popular.

woah 12y ago
It's certainly one of the best reasons to pick a language. Popular = Ecosystem .
deleted 12y ago
[deleted]

_greim_ 12y ago

This post really resonates with me. I'm not as prolific and don't have the ability to breeze into a new language on a whim, but seeing so many other languages gaining momentum nowadays really makes me feel restless. All the best of luck to him, and I certainly hope I'm not stuck in the same rut the next ten years.

sriku 12y ago

Server side dev folks have always enjoyed choice of language/system when it comes to building. You can simply choose the thing that works best for you, that you're more comfortable with, is most performant for your app, etc. On the client side, we have ... javascript. While JS is pretty fast these days everywhere and we can cross compile with emscripten and all, I'm almost tempted to say that the true web standard for programmability on both client-side and server side ought to be some kind of a byte-code .. a concept the Java guys had right way back. If you consider that we have PNaCl compiling llvm-bitcode to native within the browser, Emscripten cross compiling llvm-bitcode to asm.js (which Firefox's engine converts to native), Safari's engine compiling js itself to llvm-bitcode, I'm thinking why not make llvm-bitcode an open web standard? That way, any language that compiles to llvm-bitcode would be equally usable on the server side and on the client side. The biggest potential downside to that would probably be educational. I learn a lot by looking at source code and the web was always open in that way, though with minified JS these days that's not so possible any more. However, it might make it easier to distribute source code in any language, since a module can then compile and run such code right in the browser. edit: These thoughts came up when I was thinking about how TJ won't be able to take his work with him as he moves to Go. Well, I suppose he wants to do new kind of work for which Go is better suited, but is then all of the prior work just a brief view along the journey?

pjmlp 12y ago

Another I left <dynamic language> for <strong typed language> when faced with performance/large codebase/tooling issues post. Additionally we are now past Rails wave, Node.js wave and into Go wave.

adamors 12y ago
> Additionally we are now past Rails wave, Node.js wave and into Go wave. And the narrative is similar as well: starting a new project with the shiny new thing is cool but maintaining it is boring and awful and to quote the OP "I need maintainers!". Part of the problem is the language of course. Maintaining even a medium sized codebase written in a dynamic language is a challenge. But the other part is the mantra that "coding is easy" and "everyone should do it". And now there's an entire generation of developers whose idea of software development is "writing an app in Node in a weekend". Which of course doesn't require years of maintenance, complicated tooling or even adherence to common best practice.
drdaeman 12y ago
Erm. If you meant "static", not "strong", then Go is as statically typed as, say, C - fine in theory, but not so much in real world practice.

kolev 12y ago

Reminds me of Zed Shaw leaving Ruby... Honestly, Node.js has done a lot, but, come on, it's still JavaScript in the core. The selling point that you can run the same code both on the client and on the server doesn't really hold up to the reality check. I'm not so excited about Go, I honestly find Rust better. Dart also seems promising - especially having dart2js and Google backing it, too, but it doesn't seem to be picking hype as fast as Ruby and then Node.js did. To me, having a powerful package manager seems to be the common theme and they key to success. I still can't believe with all the ego, Python is still relying on a joke like pip. Although I agree it would be challenging, I think the world will be a better place if there's a cross-language package manager, with language-specific plugins. At the end of the day, maybe 75% of the logic is shared and is around downloading things, installing symlinks, checking dependencies, and so on. Package that with a cross-language pyenv/rbenv/nodeenv, etc., and you would have a killer.

sriku 12y ago
> I'm not so excited about Go, I honestly find Rust better. Same here, but Go has productive libraries that can help you hit the ground running. Just with the packaged standard libraries, you can do things like have a useful webserver going. I prefer Rust though and might stick with JS until I exhaust it .. or until Rust matures enough to put into production and then jump fully on to Rust. Rust compiles to llvm-bitcode, unlike Go, so that's a win for me. edit: I stand corrected - https://github.com/go-llvm/llgo https://github.com/go-llvm/llgo
- kolev 12y ago
  I've seen that, but just noticed that the project is led by a Canonical developer, which I find interesting.
boothead 12y ago
Try Nix(Os) https://nixos.org/wiki/Howto_develop_software_on_nixos https://nixos.org/wiki/Howto_develop_software_on_nixos We use it at work for both packaging and deployment and it's awesome!

mike-- 12y ago

Wait a couple of years and author finds erlang or scala...

th0br0 12y ago
... or Rust, given that the language should have matured by then. But other than that, I'm also waiting for people to eventually discard Go and move on to one of those languages...

davidw 12y ago

Pity he didn't have a look at Erlang. It's not likely to be the "next big thing", but it's really good at what it does.

brickcap 12y ago
He did give erlang a try and tweeted about it 4 years back. I think judging from some of this other comments on disqus(I can't find them at the moment) he did not like it very much. https://twitter.com/tjholowaychuk/status/16988926506 https://twitter.com/tjholowaychuk/status/16988926506

bipin-nag 12y ago

He is one of the topmost contributors to the node.js ecosystem if not the most. He has given a plenty of good libraries. Besides the reasons he gave to leave node.js, I feel that he was under-appreciated and over-worked many times. With components he tried to create a toolchain, wrote express and koa for server, jade for templating, mocha for debugging etc. He tried to do a lot many things single-handedly. Which is why he needs a lot of maintainers. I don't blame him for overloading and stressing out. That is the way how it goes in node.js. Working in node.js is like battling a multi-headed beast. The core javascript keeps evolving, node.js isn't even in version 1.0, API changes a lot. There are lot of blanks to fill and too much time goes into boilerplate stuff and managing existing code. It is just not rewarding and fulfilling to contribute to node.js. On top of that he faced a lot of friction from other contributors. He had some really difficult times, like express-connect conflict, bower-components conflict. Having handled conflicts too many, some people also consider him as being rude and too self-centered. Besides he is young and is probably one of the first things he has done he is serious about. Many times before I asked to myself how does this guy do it. In a community where to contribute even a little one has to put in a lot of effort, his contributions are gigantic. I hope he continues to work, although not at too many projects . His experiences will definitely be handy.

enome 12y ago
On top of that I remember the first nodeup podcasts and on twitter some key member from the community would bitch about express all the time. Ranging from express is bloated to middleware is a shitty abstraction to you don't need a framework in Node.js. It was really weird because express was (is?) one of the most used framework in the Node.js community and here you have people that other people follow and listen to tell you that it's crap.
- tjholowaychuk 12y ago
  Haha yup, I wont lie I have been an asshole at times, mostly because you sort of have to defend yourself when you're surrounded by people who attack your work, but after a while I realized it wasn't worth it so I just sort of detached (no longer on IRC, the mailing list etc). Defending your work isn't worth becoming rude yourself. Communities always form cliques that's just how it is. The core node community was very unreceptive to change since the very beginning, to be honest Ryan and Isaac were some of the few humble people in the bunch. I've always been a "threat" to "the node way" of doing things, whatever that means. The elitism gets a little old.

develop7 12y ago

despite Go isn't actually an answer, good for him anyway

spasquali 12y ago

Go is a great language, and I'm looking forward to see what TJ does with it. He's bored, and moving on. That's it. He's trying to justify what must be a painful decision by making a bunch of abstract claims about how Node isn't a production-ready language. The elephant in the room: how is it that TJ was able to build so many things, over so many years, that are used -- in production -- in so many places, in a language that is "difficult to debug, refactor and develop."? Is he a masochist? I think he's hit a personal wall. It seems he has a beef with the way the core is being developed. And Go is indeed fun, and exciting. This isn't surprising. People get burned out.

tjholowaychuk 12y ago
Not at all, my claims of node not being production ready are 100% legit, and based on real-world applications. The thing that is enjoyable Go is that it IS production ready, if I could say the same about node I would still be using it. Like I mentioned in my post, I decided to rewrite an application that I had been working on for the last month with Go. I decided that if I could do it in a week, and if it went well that I would ditch node. It went even better than I had hoped, and is much less frail. Node has many design flaws down to its very roots. I'm not saying those are due to terrible engineering or anything, but they were choices that were made and Node is stuck with them for the foreseeable future until breaking changes can be made. That is if the core people can admit that it's not great to work with :) I think the main problem is often people working on the depths of some system forget to really use it. It's so easy to get caught up in the details but if you don't step back and use your own product you're screwed!
- spasquali 12y ago
  Your experiences moving a Node app to Go would make for a great study. You're extremely influential, and it may be better to give concrete examples of how Node can be improved. I wonder about this "enjoyable" criteria. I'm assuming you're not claiming to be the only person who has written large Node systems, or that nobody has ever written larger, more highly trafficked, more complex Node applications than you have. So the point seems to be: for you, Go is more fun than Node at scale. As a well known contributor, that's a valuable perspective. I'd like to know more about how your personal experience could be translated into general truths all developers could understand. It seems to me that Node is used rather extensively by the core contributors. I don't get the impression that they have never actually used the product, based on their repos etc. Thanks for all your work. I'm sure the Go community will similarly benefit from your efforts.

alecco 12y ago

Hilarious/sad how this has 210 points in 9hrs and it's 2nd page.

wesbos 12y ago

TJ did a lot for this community, sad to see him go but really happy that he did contributed so many library that we will continue to learn.

ericff 12y ago

I really want to know why he chose golang instead of X or Y (Elixir, Erlang, Scala, ClojureScript). Have he said anything about that in other blog? Or anyone of you have sent him email about that? I use node.js (0.3 to now) quite a long time. I also feel the smell of node.js, forever, express and socket.io. Recently, I am considering switch to Elixir. But I am afraid now. From day one in node.js to now, we know that node.js is not prefect and not fastest. But it is so popular and some many great guys, like TJ, contributed many packages into the eco-system. Go is not prefect too. But once it get more popular and more packages. Better vm like Erlang or X or Y may be just ignored by devs.

ericff 12y ago
TJ replied my email, he said: Hey! Mostly Go because it suits what I pictures as my ideal language pretty well. It's simple, C-like, great concurrency primitives, great standard library. I've had bad experienced with anything JVM so I'd stay away from Clojure, and Erlang has some legacy baggage but I'd still like to give it a better look some day! Elixir is cool but too Ruby for me

novaleaf 12y ago

I guess I'm a little late to the party, but can someone comment on the issues TJ mentions? Specifically, I've never seen problems with callbacks being double-executed. Under what conditions would it occur?

disputin 12y ago

Moving from Node to Go? From a platform to a language? And what's with the one size fits all - moving? And if moving a project from Node to Go, was Node the correct choice initially, for that project - more one size fits all?