3 ms·

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 usin

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.

Touche 13y ago
How he's describing it is new to me but I think it makes a lot of sense. What he's describing is a business layer written in whatever language the backend team wants (likely different from the frontend team). The backend is not concerned only with the web client, their code can be used for a variety of internal and external clients. Then the frontend team can use Node, they're already hired based on their JavaScript expertise, as the UI layer. It makes a lot of sense. With services architecture the backend team shouldn't be concerned with the web client but because of historical reasons this is typically how things work.
lmm 13y ago
>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 think there is value here. The way I see it: there are sometimes calculations that you want to perform on the server, but that are logically part of the UI layer. Maybe you need to aggregate the results of several service calls for a particular screen. Maybe you need to do an operation that's actually several steps. You could do this all on the client side, of course, but that would perform badly, and might make e.g. security more complex. You could do it on the backend, but that results in a backend service that's tightly coupled to the UI - bad architecture, and possibly requiring close collaboration between two separated teams. By having a component that runs on the server, but belongs to the UI team (and therefore necessarily needs to be written in a language they understand), you get the best of both worlds.

Touche 13y ago

How he's describing it is new to me but I think it makes a lot of sense. What he's describing is a business layer written in whatever language the backend team wants (likely different from the frontend team). The backend is not concerned only with the web client, their code can be used for a variety of internal and external clients. Then the frontend team can use Node, they're already hired based on their JavaScript expertise, as the UI layer. It makes a lot of sense. With services architecture the backend team shouldn't be concerned with the web client but because of historical reasons this is typically how things work.

lmm 13y ago

>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 think there is value here. The way I see it: there are sometimes calculations that you want to perform on the server, but that are logically part of the UI layer. Maybe you need to aggregate the results of several service calls for a particular screen. Maybe you need to do an operation that's actually several steps. You could do this all on the client side, of course, but that would perform badly, and might make e.g. security more complex. You could do it on the backend, but that results in a backend service that's tightly coupled to the UI - bad architecture, and possibly requiring close collaboration between two separated teams. By having a component that runs on the server, but belongs to the UI team (and therefore necessarily needs to be written in a language they understand), you get the best of both worlds.