Node.js and the new web front-end

I think what EGreg is talking about (benefits of using node over, e.g., PHP) and what this article is talking about (benefits of throwing node between the client and the back-end) are kind of two different things. But I think the similarities address what you're asking.

If node is being used simply as a proxy then—no question—throwing it in to the mix will simply introduce latency (shortest distance blah blah blah). However the suggesting made by both the article and EGreg seems to be, "use the right tool for the job." In the case of the article, Nicholas seems to be suggesting that aspects of your data model might be better suited in the hands of your front-end engineers as they're the ones presenting that data. EGreg is suggesting leveraging the asynchronous nature of node (and evented programming in general) to handle certain tasks more efficiently.

But to answer your question, not necessarily. Even if you introduce additional latency, you might still benefit from putting more of the data model into the hands of your front-end guys (particularly if you're at a massive organization where coordination is the biggest hurdle). Plus, there's nothing stating you can't push the mutations performed at the node layer down farther into your stack and, potentially, remove it entirely. And, there's also the case that node might do the work you've delegated to it more quickly than if it were performed in PHP, negating the loss due to additional latency (but if that additional latency is the concern, I'd recommend relying benchmarking to help you make that decision).

I'm not really sure what your post is trying to get at. There is nothing unique about the benefits of evented programming in Node.js other than that you're using JavaScript. PHP, Ruby, Python, etc. all have evented libraries. Granted, those libraries don't have as much support for non-blocking drivers (EventMachine is pretty damn close though in my opinion in terms of polished libraries, not quantity of libraries).

Zakas' post isn't really about the crusade for Node.js. At least it shouldn't be anyway. It's about how he perceives a change in UI architecture. I think it's a bit weird that he specifically uses Node.js as you can accomplish this with any "back-end" server language/framework. I think he does a poor job of communicating the change as well. It really boils down to one thing: Some people are generating templates client-side instead of generating HTML sever-side and sending it down. What he refers to as the "Back-end UI layer" is simply just a server generating HTML.

I can't really argue whether his approach is good or not. The way he explains it seems like an extra useless layer that you're going to have to maintain to me though. So you have a RESTful PHP/whatever app returning JSON or the like. And then you have your front-end developers create a Node.js app that takes the PHP apps response and ends up rendering HTML or just returning that same JSON anyway?

I agree that business logic and rendering that business logic into HTML, JSON, whatever are separate concerns but there's no reason why you can't implement them in the same language and just give the client (browser, mobile, whatever) what it wants.

Do people really pigeon-hole themselves into being just back-end engineers? Or just front-end? I can imagine a designer-type person picking up HTML, CSS, and eventually JavaScript and calling him/herself a front-end engineer in a limited way. But as a programmer I work on all of it, both server-side and client-side portions. (So I'm a full-stack engineer I guess.)

It seems to me that a designer who picked up some JavaScript would still not be a programmer. Lots of apps require advanced JavaScript to run a UI client-side. I would not expect anyone who was a full programmer to be just a front-end engineer and be completely unwilling to learn PHP or Ruby to also work on the back-end. If I met a person like that I would think the person a horrible programmer and not hire him/her. (Unable or unwilling to learn, lack of passion for software engineering excellence.) A designer with a few extra skills is one thing, but a restricted programmer is something else entirely.

But what do I know? Hence I ask whether this is common.

Back-end (god I hate this term) developers should be concerned with modeling the domain of the problem they are solving. That is all.

When your application gets big enough, you'll need to split these roles and find more specialized people. Web is a big thing, and it's getting bigger with the introduction of MV* front-end frameworks.