Chiming in a bit late.

I believe frontend devs should have basic knowledge of not just Node, but what goes on in the backend in general. Same for UI/UX design. Not saying they need to be masters of each domain and be fullstack devs at all, but there's a lot of empathy to be gained from understanding how each part of the product you're building works. In the workplace, it opens up more dialogue with the rest of your team (or other teams, depending on how your company structures its engineering efforts).

I voted no from my own personal perspective, because I'm more a UX/UI designer and I do not rely on anything related to Node. No LESS/SASS, no complex JS stuff, no APIs... But that's okay I guess. I've played with Node for a bit (the backend part), but it's not something I need ;)

My advice: take a good look at Node and see if it can work for you. If it does, use it! :)

Since most client-side interactions, libraries and frameworks are JavaScript based and the basics of Node.js are so extremely easy to get, it seems lazy not to care about learning a couple of things about it.

As I take it, the more understanding there is between the back-end devs and the front-end devs, the easier will be the streamlining of their development processes.

And that not taking into account that most tooling utilities is built around Node, as others have extensively and correctly covered.

I voted yes, because not only do i use Node for tooling, but i use it as a mock-api server to allow me to develop UI features before/while the actual api's are being built by the backend team. I've been doing this now for over 2 years and it's an extremely useful part of my daily workflow.

I answered yes. The past few years have brought JS modules from npm as the way to do things. jspm and bower both require and use Node and are distributed via npm... Most of the time you can "just use npm" as npm, private and git based modules are all supported.

Beyond npm are common tools for composing client side applications. Less, sass, browserify, Babel, webpack, gulp, grunt etc. All of which (except for sass) are Node (cjs module) based, and even sass is available as a nice module, using the c library and faster than the Ruby one.

Node modules also tend to use a consistent error-first callback pattern. Now things are changing. Promises for callbacks and es6 syntax for modules via Babel are becoming the norm.

You should understand all of the above, and that's a large part of what Node is... Beyond a fairly small set of modules for io, crypto, and network services.

This is why you should know these things... No, you may not need to know how to diy a server in Node, but you should understand the tooling and core concepts Node used as most of the js community has already moved in that direction, even for client side builds.

If you want to build a front end application that consumes third party APIs you'll generally need to send those requests from a server to get around CORS.

It doesn't necessarily need to be Node but it is lightweight and simple to set up as an API proxy.

Nodejs backend - no.

Nodejs tooling - yes. It's incredibly common to use npm, grunt/gulp/etc and do pre/post-processing with node tools.

Not "should", but "must". I think we can not get the most interesting and userful things in JavaScript area today without node.js :)

Depends, are they making front-ends for websites and actually care about accessibility, or are they sleazing out web crapplets that give a giant middle finger to users with accessibility needs.

Generally speaking (and this is a gross over-use of the wide paintbrush) off the shelf scripttardery is by it's very nature -- and this is more so for using off the shelf libraries -- telling users with accessibility needs to go plow themselves. It rarely has any business being used for websites thanks to the gross inefficiencies, massive overhead, and general ineptitude of development associated with it. Hence the "unwritten rule of JavaScript" where "If you can't make a fully working page without JavaScript first, you likely have zero damned business adding scripting to it!"

Basically if on the front end the page "needs" JavaScript to deliver content, you've probably screwed up and utterly ignorant of things like the WCAG, accessibility norms, semantics, separation of presentation from content, etc, etc... Good client side scripting should enhance functionality provided by the markup, and NOT be the only means of providing it. This is where idiocy like angular.js, backbone, or ember falls flat on their faces.

Now, that said -- that applies to CLIENT SIDE. node.js (which is what I assume you mean, not seen people omit the .js part before) is (usually) a server-side technology. Front end developers should have a general idea how the back-end they are coding for works, so they have some idea what to provide the poor sods working on the back-end to integrate into the codebase. Sadly regardless of what's being used on the back-end be it node.js, PHP, Java, .NET, Ruby, whatever, the people working on the back end -- and indeed a lot of people working on the front end -- do not know enough about HTML, CSS, or accessibility to even be touching front-end code. They are utterly and completely unqualified to even be doing any aspect of the work -- just "view source" the default code vomited up by turdpress or 99.99% of the nube predating scam artist BS at the various template whorehouses like ThemeForest or TemplateMonster for proof of that.

It's truly disturbing how often you'll come across back-end developers working in things like .NET or PHP who will actually say "I know PHP but I don't really know HTML and CSS"... and all I can think is "Then how the string of expletives omitted are you even qualified to be writing a single line of code when the entire POINT is to output HTML?!?"

To that end, I wonder how in blazes people can even put up with using node.js to output a front-end. You're stuck either building a DOM and wasting time parsing it back down to markup, or dicking around with garbage like innerHTML which we just spent a decade and a half being told to stop using. Generally speaking creating markup -- aka a frontend -- from JavaScript inhales upon the proverbial equine of short stature, and is why as someone who actually understands HTML, CSS, separation of presentation from content, bandwidth limitations, limitations of the medium, content first development, and accessibility norms, I cannot fathom why anyone would use node.js to output their front-end by choice over something designed to work with HTML like PHP.

Though I can see how it's useful to output data to be handled by client-side scripting, you have to remember that only really serves a purpose if you are going to again tell certain groups of potential users where to stick it... Like those who block JS from lack of trust or facing bandwidth caps, or those don't have access to JS thanks to their workplace locking it out, or users for whom what JS does flat out isn't accessible.

Really though like anything else, it has to be treated as a right tool for the right job scenario. Far too many people using certain languages -- and JavaScript/ECMAScript is the poster child for this right now -- have the "hammer is my only tool" mentality; suddenly every problem looks like a nail... and whilst Uncle Red may refer to his hammer as a flathead screwdriver, you pull that stunt no amount of duct-tape is going to fix said misuse.

More than anything, that's the real problem; people learning just one thing, then assuming it's the answer to every problem...

Bottom line, IF the front end you are developing is going to be tied into a back-end language -- be it Java, JavaScript (via node.js), PHP, .NET, whatever -- you SHOULD have a command of that language so you have some idea what to hand to the people working on the back end and/or how to explain it! Does that mean ALL developers should learn it? No... but if you're creating a front end for it, you damned well better know it!

With the prevalence of build tools like Gulp, Grunt, Babel, and Webpack, which all use Node, I feel there is a need to have a basic understanding of how Node streams data, how to pipe it through different functions, and how to use / create modules as well as when to use a module / package.

I'm not saying you need to know how to build a app and master the event loop but I feel a front-end developer should be able to implement their own build systems.

I hope this is the elaboration you were looking for @josfaber.