TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Farewell Node.js

357 点作者 beltex将近 11 年前

28 条评论

nadaviv将近 11 年前
I&#x27;ve been using his libraries since I started out with node, and there isn&#x27;t a single project that I&#x27;m working on today that doesn&#x27;t have at least 2 or 3 of his libraries as dependencies.<p>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!<p>[1] <a href="https://www.npmjs.org/~tjholowaychuk" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.org&#x2F;~tjholowaychuk</a>
评论 #7987359 未加载
spasquali将近 11 年前
Go is a great language, and I&#x27;m looking forward to see what TJ does with it.<p>He&#x27;s bored, and moving on. That&#x27;s it. He&#x27;s trying to justify what must be a painful decision by making a bunch of abstract claims about how Node isn&#x27;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 &quot;difficult to debug, refactor and develop.&quot;? Is he a masochist?<p>I think he&#x27;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&#x27;t surprising. People get burned out.
评论 #7990863 未加载
olegp将近 11 年前
Couldn&#x27;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.<p>At StartHQ (<a href="https://starthq.com" rel="nofollow">https:&#x2F;&#x2F;starthq.com</a>) we&#x27;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.<p>Here is a video of a talk we gave on this: <a href="http://www.youtube.com/watch?v=pmyDJnEza6A" rel="nofollow">http:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=pmyDJnEza6A</a> and here are the slides: <a href="http://www.slideshare.net/olegp/start-hq-server-side" rel="nofollow">http:&#x2F;&#x2F;www.slideshare.net&#x2F;olegp&#x2F;start-hq-server-side</a>
评论 #7987392 未加载
评论 #7987413 未加载
bipin-nag将近 11 年前
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.<p>He tried to do a lot many things single-handedly. Which is why he needs a lot of maintainers. I don&#x27;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&#x27;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.<p>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.<p>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.
评论 #7988443 未加载
mambodog将近 11 年前
One (very arbitrary) metric of TJ&#x27;s position in the node community: <a href="https://github.com/substack/npmtop" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;substack&#x2F;npmtop</a><p>running it today tells us that he&#x27;s still number one:<p><pre><code> 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</code></pre>
kolev将近 11 年前
Reminds me of Zed Shaw leaving Ruby... Honestly, Node.js has done a lot, but, come on, it&#x27;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&#x27;t really hold up to the reality check. I&#x27;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&#x27;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&#x27;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&#x27;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&#x2F;rbenv&#x2F;nodeenv, etc., and you would have a killer.
评论 #7987687 未加载
评论 #7987919 未加载
aroman将近 11 年前
This is as significant a loss for the Node community as the loss of _why was to the Ruby community. Maybe even more so.
anonfunction将近 11 年前
For those that don&#x27;t know TJ Holowaychuk, he&#x27;s the guy behind express and commander.js (and a lot more) which are two of the most popular node.js packages.
评论 #7987231 未加载
评论 #7987312 未加载
评论 #7987205 未加载
pjmlp将近 11 年前
Another I left &lt;dynamic language&gt; for &lt;strong typed language&gt; when faced with performance&#x2F;large codebase&#x2F;tooling issues post.<p>Additionally we are now past Rails wave, Node.js wave and into Go wave.
评论 #7987897 未加载
评论 #7990350 未加载
deepakkapoor将近 11 年前
<a href="http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive" rel="nofollow">http:&#x2F;&#x2F;www.quora.com&#x2F;TJ-Holowaychuk-1&#x2F;How-is-TJ-Holowaychuk-...</a>
评论 #7987429 未加载
评论 #7987422 未加载
ericff将近 11 年前
I really want to know why he chose golang instead of X or Y (Elixir, Erlang, Scala, ClojureScript).<p>Have he said anything about that in other blog? Or anyone of you have sent him email about that?<p>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.<p>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.<p>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.
评论 #8004097 未加载
throwaway41597将近 11 年前
&gt; We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there<p>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).<p>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&#x27;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].<p>On node, you have the cluster API, which allows managing several processes so it&#x27;s even further from light threads. On the bright side, most (all?) APIs have both a sync and async version.<p>As a result, there&#x27;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.<p>[1]: <a href="https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Worker&#x2F;Func...</a>
评论 #7987856 未加载
评论 #8019020 未加载
sriku将近 11 年前
Server side dev folks have always enjoyed choice of language&#x2F;system when it comes to building. You can simply choose the thing that works best for you, that you&#x27;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&#x27;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.<p>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&#x27;s engine converts to native), Safari&#x27;s engine compiling js itself to llvm-bitcode, I&#x27;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.<p>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&#x27;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.<p>edit: These thoughts came up when I was thinking about how TJ won&#x27;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?
alecco将近 11 年前
Hilarious&#x2F;sad how this has 210 points in 9hrs and it&#x27;s 2nd page.
shadowmint将近 11 年前
I was suprised to see the comment that tooling for Node wasn&#x27;t great; I thought the node tooling (npm, gulp, grunt, etc.) was significantly superior to the primitive (ie. relatively low level) tooling go provides.<p>...but I see that&#x27;s a very specific comment:<p><pre><code> the tooling Go provides for profiling and debugging is great... </code></pre> Ah, that makes more sense. This is definitely an area where node applications are really troublesome to work with (live debugging).
评论 #7988936 未加载
cnp将近 11 年前
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.
novaleaf将近 11 年前
I guess I&#x27;m a little late to the party, but can someone comment on the issues TJ mentions? Specifically, I&#x27;ve never seen problems with callbacks being double-executed. Under what conditions would it occur?
_greim_将近 11 年前
This post really resonates with me. I&#x27;m not as prolific and don&#x27;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&#x27;m not stuck in the same rut the next ten years.
nemothekid将近 11 年前
We&#x27;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).<p>Hope the departure of an incredibly js developer doesn&#x27;t impact the community too badly.
disputin将近 11 年前
Moving from Node to Go? From a platform to a language? And what&#x27;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?
derengel将近 11 年前
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.
archgeek将近 11 年前
Maybe Golang is great for developing frameworks, but as someone who build websites i prefer Node because Go&#x27;s typing makes development slower and more expensive.
评论 #7987479 未加载
评论 #7987548 未加载
评论 #7987985 未加载
评论 #7987453 未加载
davidw将近 11 年前
Pity he didn&#x27;t have a look at Erlang. It&#x27;s not likely to be the &quot;next big thing&quot;, but it&#x27;s really good at what it does.
评论 #7988296 未加载
wesbos将近 11 年前
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.
bsiddiqui将近 11 年前
convinced he represents an org of devs <a href="http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive" rel="nofollow">http:&#x2F;&#x2F;www.quora.com&#x2F;TJ-Holowaychuk-1&#x2F;How-is-TJ-Holowaychuk-...</a>
mike--将近 11 年前
Wait a couple of years and author finds erlang or scala...
评论 #7988201 未加载
develop7将近 11 年前
despite Go isn&#x27;t actually an answer, good for him anyway
ilaksh将近 11 年前
I wonder if people are picking Go over Nimrod mainly because Go is more popular.
评论 #7987630 未加载
评论 #7987768 未加载