TJ Holowaychuk is leaving the community and now

[vitor.sh...@gmail.com]

TJ is leaving node as he posted here https://medium.com/code-adventures/4ba9e7f3e52b 

What do you think about it and what projects are you using that came from him?

[Bruno Jouhier]

I reacted on my blog: https://bjouhier.wordpress.com/2014/07/05/tj-leaving-node-js/

[Jonathan Ong]

read it carefully. he says he won't be using node anymore except for web stuff. he just doesn't do web sites right now, so node doesn't suite him anymore.

but most of his stuff will still be maintained anyways so don't worry about it

[Chaoran Yang]

I think what TJ complained about Nodejs are valid points. However I also think Nodejs preference of performance over usability is not wrong. We need to understand the Nodejs is not the best choice for all web applications, just like C is not the best choice for programs. There are already loads of languages that favors usability, and Nodejs should not become one of them. Nodejs exists because it is different. It provides an alternative for those who cares about performance, and doesn't bother to get their hands dirty in low level details.

I do agree with TJ with the fact that Streams are broken in Nodejs is becoming a problem. It should be a major help for simplifying asynchronous programming but it is still in unstable state now.

Chaoran

[Dan Peddle]

It's a pretty unusual situation - at least, I can't think of another one where someone who has made such a huge impact in terms of code that probably the majority of us use daily (oh hey, mocha, express..) has decided it's time to move on to focussing on another language. Express is one of the libraries that almost anyone who starts playing with node touches at first, no? Has something like this happened in other parts of the coding world?

He made some really great points about the ecosystem - it can definitely be hard to assess the relative merits of various libraries, without really digging into the code, or playing with something for a while and seeing how it does. is that laziness? maybe. looking at the npm downloads graph can be useful, but those numbers can be a bit artificial (Forrest, if you're here, mentioned on twitter that they include numbers for people replicating to their own npms, for example). I can imagine npm have a ton of ideas about how to improve that experience of discovering what modules are available ;)

It was interesting that he made the comparison between the standard library in node and go too - maybe with native promises and generators more or less landing in core (please correct if wrong) then things like the profusion of async libraries might start to die back a bit, and a canonical approach emerge. Not sure. It could be great if you knew that when you were dealing with an async operation, then the return was always a promise, for example, or you had that option. I know you can wrap almost anything in a promise and go crazy, but its not quite the same thing.

I wonder if the NPM people could produce some stats about relative popularity of repos that he's had a hand in? Maybe try and figure out if there is some scope for a GH organisation to collect this stuff, and then the volunteers for maintaining them could work together under that umbrella for things like code reviews, merging PRs etc. 

If he's reading this - really huge thank you for all the work, and best for the future!

On 4 July 2014 17:40, <vitor.sh...@gmail.com> wrote:

TJ is leaving node as he posted here https://medium.com/code-adventures/4ba9e7f3e52b 

What do you think about it and what projects are you using that came from him?

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/e6a1c8ad-69d1-4169-bb8d-fcd72bf413cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aria Stewart]

On 5 Jul 2014, at 9:26, Dan Peddle <dan.p...@gmail.com> wrote:

> It's a pretty unusual situation - at least, I can't think of another one where someone who has made such a huge impact in terms of code that probably the majority of us use daily (oh hey, mocha, express..) has decided it's time to move on to focussing on another language. Express is one of the libraries that almost anyone who starts playing with node touches at first, no? Has something like this happened in other parts of the coding world?

_why left the Ruby world in a perhaps sharper exit. Projects deleted, everything he'd made taken down, every connection broken.

TJ's left us with a lot more to build with.

[tjholowaychuk]

FWIW node could be much better for web stuff as well, but yeah I wouldn't use Go for that personally. However Go suits well-defined things like APIs very well, and if you have a large application that needs to be robust, and built on smaller services, then your site/app would just become a front-end for that anyway, so Go would be a great solution there.

languages that favors usability, and Nodejs should not become one of them

Well scaling vertically isn't the "correct" way to scale either, so it might as well be usable. Massive applications run on much much slower platforms, YouTube etc, and I can guarantee most uses of node hardly need the "performance". When you have a real performance problem, you usually have the money to spawn a server or two. Throwing man-hours debugging brittle code is not worth it, especially in young startups that can't afford to make mistakes. The great thing about Node is that it's JavaScript, the terrible thing about Node is that it wastes the good part by being fundamentally flawed and broken usability. If you want raw performance Node isn't the right choice either IMO.

I've been adding maintainers as people have responded to the post, happy to add more just email me with your npm/gh usernames, everyone should be in good hands that way!

[tjholowaychuk]

Weird apparently what I posted didn't work. Anyway I think it's a very odd choice for a JavaScript platform to strive for performance over usability, usability is the *only* reason you would ever go with JavaScript, because people know it. It's a terrible choice of a language if you're shooting for raw performance, and even worse is that you really shouldn't scale your application based on raw performance. If you have to serve tons of requests then you also have the money to spawn an machine or two, look at YouTube even it uses Python and it's much larger than anything node has been used for, it's really just not a concern these days. Startups should be concerned with robustness, not raw performance that they don't even need.

[Bruno Jouhier]

Hi TJ. Your post did go through but the mailing list is now moderated. It prevents flame wars but it also means long delays, especially when posting from Europe.

Bruno

[// ravi]

On Jul 7, 2014, at 6:21 AM, tjholowaychuk <tjholo...@gmail.com> wrote:

Throwing man-hours debugging brittle code is not worth it, especially in young startups that can't afford to make mistakes. The great thing about Node is that it's JavaScript, the terrible thing about Node is that it wastes the good part by being fundamentally flawed and broken usability.

The great thing about JavaScript is that it offers C-like simplicity (refreshing after a decade or two of C++ and Java) and structure (the syntax is not replete with mystifying arrows, nor does it treat whitespace as a significant token), but I disagree that JavaScript is a very usable language. In fact it is unusable exactly in those ways it departs from C: It is lenient when it should be strict (ASI) and strict (or at least unpredictable) when it should be lenient (these have been lamented on extensively elsewhere by others); it is primitive in unsettling ways (multi-line strings); it is leaky in the wrong place (messing around with prototypes) and magical/mysterious where it should make the implementation explicit (why do some assignments copy a value while others copy a reference? In C the answer is simple: ignoring the shortcut of arrays, all assignments copy a value, except in some cases the value being copied is a pointer to a block of memory). I could go on.

I also disagree that performance (raw or otherwise) should not concern startups. For not-yet-profitable and cash-strapped entities, it just does not suffice to answer “spin up another VM”. I do admit that performance absolutism does not sit well with a whole slew of interpreted languages, but that does not compel us to abandon performance as a significant criteria.

Most of everything else in your blog post, I find myself vigorously nodding in agreement with.

NodeJS, as an ecosystem, is a bit of Wild West, which is brilliant in many ways (nobody shoving MVC, or their clever little extension to the initialism, down my throat). But good grief, it took me (admittedly a slow-moving primate) 3 days to figure out that socket.io (to use one example) is not a vanilla WebSockets implementation.

—ravi

[Alex Kocharin]

 

> In fact it is unusable exactly in those ways it departs from C: It is lenient when it should be strict (ASI)

 

Nope. I don't understand why restricted productions are made so, but other than that ASI is a very good idea.

 

Why write something if compiler can figure it out by itself?

 

 

> and strict (or at least unpredictable) when it should be lenient (these have been lamented on extensively elsewhere by others)

 

I didn't see anything unpredictable about javascript so far. Well except for web browser bugs, but those can't be predictable by definition.

 

 

 

 

> it is primitive in unsettling ways (multi-line strings)

 

Good point about multiline strings, but that's already waiting to be fixed with es6 templates.

 

 

> (why do some assignments copy a value while others copy a reference? In C the answer is simple: ignoring the shortcut of arrays, all assignments copy a value, except in some cases the value being copied is a pointer to a block of memory).

 

You can assume that objects are C-like pointers. This way JS behave exactly like C.

 

 

> I could go on.

 

Please do, since I don't see anything wrong with JS as is. Maybe something is to be said about absence of compile-time metaprogramming support, but JS is certainly better than Go for all I know.

 

 

PS: what's wrong with node.js streams anyway?

 

 

07.07.2014, 20:58, "// ravi" <ravi-...@g8o.net>:

--

Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/40DA4F74-0F67-417E-8D7A-9790C1D7E8E8%40g8o.net.

[Phoscur]

Aren't we just speeding on the work of the V8 team? NodeJS just leverages a low level API to that beast (and that's why there are callbacks, they are low level function blocks in javascript.
So it's not about performance and Callbacks..

Where exactly are the usability leaks?

TJ thank you for your great frameworks like express, socket.io & co!

Ph

--

Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/8bfb84c3-60ae-4848-8fce-deae4f6367d8%40googlegroups.com.

[Alexey Petrushin]

Streams for example aren't part of v8.