14 ms·

Node.js and the new web front-end

165 points by thisisblurry 13y ago

JacksonGariety 13y ago
Can someone explain why the author refers to the nodejs layer as "front-end?" It is a UI-layer, but is it not still back-end?
- dak1 13y ago
  I think it makes more sense if you think of it as "domain of the front-end engineer". There's certainly an increasing number of developers who are focusing more on the front-end plus Node.js, often for connecting backend services and providing a RESTful API.
- sisk 13y ago
  I think it may be more appropriately called the mid-tier. You have your back-end handling storage, low level validations, complex business logic, service integration and coordination, background jobs, etc. You have your mid-tier with the implementation-specific validations / logic, template rendering, etc. And then you have your front-end with (as appropriate) all the client-side stuff (validations, logic, and rendering). It's worth considering the source, in this case. Nicholas has spent a lot of time both employed full-time and as a contractor at organizations that operate at a massive scale. This solution works if your application, architecture, or even engineers would benefit from additional abstraction. I do take issue with one point he brings up, however. He mentions the mid-tier communicating with the back-end over HTTP(S). Unless you have some need to serve your API exclusively over HTTP(S), why not use something with a little less overhead (like a message queue)?
EGreg 13y ago
This is interesting. Basically what I like Node.js for is the evented programming that JS encourages. That and the fact that web developers are already familiar with JS. Consider this: you have a site that will have to scale to millions of people. If you have a lot of reads, you can simply replicate your database, but if you have a lot of writes too, then you'll need to shard (partition horizontally) your database. An aside -- if you find yourself using an ORM and sharding a lot, then most likely you should have used a NoSQL database such as Riak, instead of a relational DB. But let's say you've already gone this route, and used MySQL, which a lot of sites including facebook have done. In this case, anytime you need your query to hit N shards, PHP will take (s1 + s2 + ... + s_n) time to do it. Node.js will take MAX(s1, s2, ... s_n) which is much faster. There is a big difference for latency. (It's true that the mysqli driver in PHP does support concurrent queries, but the above comparison isn't just for DB but for EVERYTHING. In JS and Go you have the option to do concurrent I/O, in PHP you don't.) Another difference is in the memory usage. PHP has to create a copy of your environment for every preforked process. It depends on Linux to do copy-on-write, for instance. APC helps a little with shared memory segments, but not much. On a 2GB RAM machine, how many clients can you support with PHP vs Node? Node has just one copy of the code running, and each request costs very little in comparison. Of course, since everything is in the same memory space, you can easily bring down the whole process, so Node.js processes need to be built to survive crashes, unlike PHP scripts which are isolated. And let's not forget that Node.js stuff can push to the client, whereas for PHP to do that you need wasteful, long-running sleeping processes sitting in memory, and having some nginx event module to simulate evented programming. In short, Node.js and stuff like that gives you much more flexibility, many more things you can do (such as pushing data in near real time to many different endpoints including the browser), but at the same time you need to code everything in a way that crashes don't matter much.
- jsnk 13y ago
  Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?
  - EGreg 13y ago
    Yes and no. If Node.js can do things like * cache responses * not send duplicate responses but instead maintain a waiting queue * throttle requests based on # of preforked threads etc. then it would be faster most of the time. And equally importantly you can take a page from Yahoo's book and pre-render stuff on the presumably faster server, for mobile devices and robots.
    - rubiquity 13y ago
      Why can't you do these things in PHP (or whatever other language you're already using)?
      - EGreg 13y ago
        You can, but Node.js is often a better choice than PHP. Caching: you can have ONE node.js process listening to all requests, and it can keep the cached info in memory, to be looked up much more quickly. In PHP, you'd have to load the entire script environment, connect to an external source like Memcached or APC, etc. Waitlist: Similar to caching, except Node.js can hold off on responding to the request until the response came back. It's MUCH harder to make something like PHP iterate through the waitlist because a bunch of scripts might get called at once, and the way it works, all of them will have to sleep. With Node.js, only one process has to sleep -- or handles something else while you're waiting. etc.
      - Touche 13y ago
        Because that shouldn't be the responsibility of the business layer. Perhaps they are serving many apps other than just the web client, some of which don't want cached data.
  - deleted 13y ago
dimadima 13y ago
Yeah—what the fuck is this post and how did it get to the front page of HN? 1- What is a Node on the front-end? Isn't that called... ~~Chrome~~? 2- "I definitely don’t believe that an entire back-end should be written in Node.js just because it can." <-- What is this 2011?
jacques_chester 13y ago
OK, dumb question time. How are front-end and back-end defined? To me the distinction was about the location of execution. "Front-end" meant "in a browser" and back-end meant "anywhere else with some surface addressable via HTTP". Now it seems that "front-end" means "View and Controller" and "back-end" means "Model", except ... not quite. Sometimes. On the other hand, perhaps I protest too much. It's not as though there's a High Court of Internet Nomenclature for this.
- mercer 13y ago
  Yeah, I've felt for a while that we need to start ditching the terms 'front-end' and 'back-end', as there is no way to use these terms anymore without following up with an explanation of what this means. I've been primarily a 'browser developer', with most of my time spent in the Chrome dev tools, editing css, html and 'light' javascript. I call myself a front-ender for this reason. However, over time I find that I prefer the 'real' programming stuff over battling browser quirks and pumping out html/css structures that I learned over time are optimal. I gravitate more and more to what amount to full web apps where I do stuff that requires, to a degree, 'real' programming beyond just a javascript/jQuery widget. That's where the real division is, I think. As I get into more and more complicated development, I become more aware of my limitations and my lack of formal training. This reached a point where calling myself a 'front-ender' is starting to feel less and less applicable, because there's a huge divide between many front-enders I know who are not really programmers, and what I am in the process of becoming, and calling myself a front-ender feels like underselling myself.
- andrewl-hn 13y ago
  It largely depends on a culture of the people you talk to. For many Java developers Backend means communicating with the database and application logic. But they would consider templating and other veiw code a "frontend work", even though it has nothing to do with the web browser. However, if you talk to JavaScript developers many of them would consider all code that is executed in a browser "frontend" but would exclude any server-side templating, partials, etc. Then, some of them would still consider ALL JavaScript code a part of Frontend, be it a browser code or Node code. This can bring up some fun conversations. One of my coworkers talk about server-side bits of project A a "Frontend" because they are written in Node, but considers same functionality in project B "Backend" because they are written in Python.
carsongross 13y ago
In as much as the distinction is useful, wouldn't node be considered backend? This is what drives me bonkers about the node and JS community: there is so much goddamned noise and "nobody cares!" arrogance in the signal it's difficult to know who to take seriously.
- k3n 13y ago
  I think that is sort of the underlying theme of this article, in that the definition of "backend" has been traditionally had to define, philosophically speaking. And you can take my word for it that you should take this guy seriously, or you can check his credentials to make that determination yourself, but suffice it to say I think most would consider him a source of much signal and not much noise.
  - Touche 13y ago
    I don't think it's really that different. I see "front end Ruby on Rails developer" job ads all the time and have for years. It really depends on how the company is structured as to what is the front and back ends.
- dmak 13y ago
  Well, I think the lines begin to blur with these cohesive technology stacks that only use one programming language. I code that is run on the server and not in the browser is considered "backend".
badman_ting 13y ago
I love JS, but I have trouble with this idea that people are against using Node because they're afraid of JS or whatever. EGreg has mentioned some situations like millions of users or pushing data to the client, where Node makes sense. But I'm not sure what inherent value running JS on the server has. Also, while it may be true that the backend devs don't care about the flow of pages that the user browses, the user does care. That means that the services that put together the pages need to work for the user's use case. That means that the system needs to be designed for the pages the user looks at. You can't escape this, this is bigger than your architecture. It's almost like a law of physics.
- rubiquity 13y ago
  Back-end (god I hate this term) developers should be concerned with modeling the domain of the problem they are solving. That is all.
  - Rygu 13y ago
    I disagree, being a good server side software developer means that you understand fully how your models and APIs will be used and what consuming developers really want from it. You enable them to easily drop your solutions into their stack. Be it an external JSON API or an internal class's API. Every end has a front and back.
    - rubiquity 13y ago
      Note that I said "concerned" and not anything about the level of skill this developer has. ;) I think in the size of applications/companies Zakas is talking about it's probably best if the various layers are like black boxes to one another.
  - badman_ting 13y ago
    Would it be OK if the services they build take one year to respond? They care about other things too.
dmak 13y ago
Traditionally, I defined backend as server side programming basically anything that is run on the server before it reaches the browser. Since front-end engineers know JavaScript already, they can just effectively make an abstraction that spits out what they need using Node.js which is technically still in their domain. I never thought of it like that, but that totally makes sense too, wow. Nice read.
webjprgm 13y ago
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.
- dmak 13y ago
  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.
- ChikkaChiChi 13y ago
  At the expense of being flamed, I'd say that every back-end engineer can do front-end work even if the end result is terrible from a user experience perspective. You may even find cases in which a person can be equally adept at both. That being said, I believe that there are more front-end specialists and designers who cannot do what it takes to build an efficient back-end tool. Try showing your latest application around an office. Few people will comment on how you are grabbing the data, but everyone and their mother will tell you how to make it prettier.
  - dasil003 13y ago
    There are also back-end specialists who cannot do what it takes to build an efficient back-end tool :) The skills involved in web development and software engineering are so varied that I'd hesitate to define too few buckets to categorize people. Traditionally I think the reason designers get away with learning a bit of JS is because of the simple request, pageview and DOM semantic of the web makes it easy to hack on things until they work without the danger of really screwing things up too bad for 3 reasons: 1) you don't worry about persistence, 2) you don't worry about scalability, and 3) any problems you created only live as long as the pageview does. Newer APIs like client-side storage and pushstate are allowing browser js to quickly evolve into the realm of serious software engineering with even a few twists of its own (like no easy production logs.) Of course a web designer can still come and do a tutorial and duct tape some things together, but this is equally true of PHP, rails or node. There is an inherent learning curve in learning how to operate at various levels of abstraction well enough to engineer a system that meets latency, scalability, correctness and maintainability requirements for a non-trivial app.
ChikkaChiChi 13y ago
This new javascript wave in which we eschew the needs of the consumer is going to start costing companies big. Processing power, memory, and power consumption are still a pretty big deal in the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake. Engineers that make their lives easier at the expense of the customer will find themselves in a very empty and very optimized echo chamber. Users will be found elsewhere dealing with products that are faster (for them) and teams clamoring for how they can continue to improve the experience with each iteration.
- jeffasinger 13y ago
  In some cases, doing things client side is massively faster, and in other cases it isn't. It's something that teams need to look at case by case. For example, over a small data-set, doing typeahead search on about 5000 elements was many times faster, even on some of the slowest hardware than doing it server side.
- rdtsc 13y ago
  > the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake. I've been thinking about that as well and was playing this N2O framework: http://synrc.com/framework/web/ http://synrc.com/framework/web/ they are sort of making this point as well, render on the server and send html to client but do it via a websocket. That is an interesting approach.
- camus 13y ago
  NodeJS is async by default and RAD. Does it really scale at the corporate level ? depends on what is your product. If you are better off with the JVM or .net , there is no reason to use it. But in my opinion , it definetly has its place in startups.
  - ChikkaChiChi 13y ago
    The concern I express isn't with Node; it's with the front end tools like Angular that shift the cost of building UI scaffolding to the client side javascript engine.
karanbhangui 13y ago
I've been thinking about this a lot lately (and in fact probably driving a lot of my friends nuts with my views on this), but I think if you take a look at what Airbnb has done with Rendr and what ex-Google Wave engineers have done with Derby, it becomes immensely clear what the potential here is. Traditionally you've had to maintain two codebases for things related to rendering (think generating URL slugs, or formatting dates). This code duplication is obviously solved by running node layer in the middle. But the benefits go well beyond unifying rendering code and separating "backend" developers from "frontend" developers. My excitement is the ease of building highly interactive apps while staying true to how web pages were meant to be architected. Since your client and server runtime are aware of each other, the framework can handle things like partial rendering, multi-client sync via OT, request caching, incrementally pushing required css/js/html payloads to the clients as necessary (instead of doing one massive push at the beginning). Right now the client and the server talk to each other through a constricted API layer you have to create endpoints for manually. It's exciting to think how much of this can be automatically handled by the framework. I believe this generation of web architecture will finally bridge the gap between "websites" (often progressively enhanced HTML payload) and "webapps" (massive javascript payload, almost no HTML).
- deleted 13y ago
  [deleted]
agibsonccc 13y ago
I'm a big fan of using node for an intermediary web stack. It really plays well for handling your web layer with the tools available as well as handling builds with grunt and friends. I think the real potential comes in when you blend it with a heavy lifting API written in go or on the JVM. Easy web layer that's agnostic to whatever heavy processing language should you decide to do. Obviously there's a bit of complexity that comes with this, but if you need to scale up it's right there. Even then, node is pretty powerful on its own, where you might not need a crazy backend.
pjmlp 13y ago
Frontend Engineer?!?
- mattdeboard 13y ago
  You don't know the right developers.
mjackson 13y ago
> As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example. After developing almost exclusively in JavaScript for the better part of the past year (and doing a lot more in the previous 6), I'm convinced that this mentality is going to start fading as more and more developers become more capable and productive with JavaScript. There's nothing inherently wrong with the language that prevents you from writing sufficiently complex and reliable systems to power something like a shopping cart, or anything else for that matter. The main thing that is missing at this point is experience and maturity in the JavaScript community at large, which is quickly changing as more and more developers start embracing the language.
- lmm 13y ago
  It doesn't have an adequate type system. There are too many silent conversions. The syntax is very clunky. All the object systems feel hacky and they can't be relied on to interoperate with each other. Problems like no standardized threading support or decimal type could be resolved in the future. But the language as it exists currently lets you override everything, and that's the sort of thing that you can't remove in later versions because existing code will be using it. So it's always going to be possible to e.g. modify Object.prototype and then expect the method you added to be accessible on anything. And then that library breaks because you defined an object that already has a method with that name. Yes, a sufficiently smart developer can write good code in Javascript. But there are very few people who I'd trust to write financial code in Javascript, and I think all of them would use a better language rather than expending the effort working around its deficiencies.
  - embwbam 13y ago
    I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system. The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.
    - 13y ago
heynairb 13y ago
Isn't this architecture redundant? Why have two application servers in between the database and the browser? Wouldn't it be better to serve the page once and have the browser communicate directly with the api? Is this setup common? Is it really the future?
- svachalek 13y ago
  Most large applications tend to be a constellation of servers anyway, with the advantages of individual scaling, updating, reliability etc. The disadvantages are roughly the same. So, it's optimizing the advantage of having more servers against the disadvantage of having more servers.
hrjet 13y ago
I was working in a largish project recently with a three-tiered architecture as described in the article. However, both of the server-side tiers were in Scala, and it was hard to see the advantage in that case. However, using NodeJS in lieu of Scala for the middle tier, suddenly makes a lot of sense. Thanks to the article for showing this path! To be sure, NodeJS can be replaced with something equivalent, such as N2O or JScala (as others have mentioned). But the concept is more clear when expressed in terms of NodeJS.
thomasreggi 13y ago
all javascript everything
mtam 13y ago
I am struggling to see how this approach would be beneficial outside of large organizations with massive web apps. For most apps, the benefits do not seem to outweigh the drawbacks of having (1) another dependency, (2) another piece of software (node) to install, update, and maintain, (3) another set of code base, (4) an increase in latency, and (5) all the added complexity to troubleshooting, debug, document, etc...
shapeshed 13y ago
Isn't the point that with a REST interface you can move your UI layer entirely to client-side JavaScript with any of Ember/Angular/Backbone. Behind the REST interface your tech can be anything and you can swap it at will.
10098 13y ago
> I was never a fan of PHP Interesting how the same people who are "not fans" of PHP somehow like Javascript. As if it's better.
- rtfeldman 13y ago
  Considering there are an increasing number of designed-to-be-likable languages that compile to JS, it's about as close to objectively better as you can get.
- Cyranix 13y ago
  Are you claiming to have an objective yardstick for comparing the goodness of languages? (Don't answer that.) If not, please remember that different languages are just that -- different, not necessarily better or worse. Personal attitudes towards the differences between languages are totally normal. Bearing this in mind will help the conversation proceed in a more civil manner.
  - 10098 13y ago
    > "not necessarily better or worse" I don't agree with that. Sure, comparing something from completely different domains (for example, SQL and HTML) doesn't make sense. However, for some languages (e.g. C#/Java, Python/Ruby, etc.) it is entirely possible to compare them and point out which is better in some aspects or worse in others. What I'm saying is that Javascript and PHP are comparable (now that node.js exists and it's possible to write server-side javascript), however, I don't see much advantage over PHP other than being more trendy.
    - tracker1 13y ago
      Well, probably the biggest difference is npm... A great package manager makes things easier to create and use as independent modules. PHP has frameworks, but these are a bit cumbersome. JavaScript even with the bad parts is still more consistent and friendly to use than the core methods within PHP, inconsistent naming structures, parameter ordering and a lot of other issues at the language level. I've NEVER liked PHP as a language... and that stems from VERY early on in web development. I've used a number of platforms and languages over the years, and none have irked me nearly as much as PHP has.
pweissbrod 13y ago
Unless youre dealing with a large complex app or scalability is a major concern I dont see how adding an extra nodejs vestige is worth all the trouble. Take the coolness of node out of the equation and not much compelling arguments are left from a business value perspective.
indubitably 13y ago
Right, the Chrome icon should represent the user-facing internet.
deleted 13y ago
[deleted]
sassyalex 13y ago
If you are smart enough you can make every code fit your need and reach the code quality you need. JS weakly typed ? Seriously learn on how to adapt your coding style. I've built more than 20 API/Apps and Node is the best thing I ever had to build networked apps. I have a J2EE/Spring, Python and RoR background, NodeJS/NPM took the best of every stuff created before. In my case, I need to be fast and JS + NodeJS + his awesome community permits me to build stable, innovative solutions and high performance networked app in a very short amount of time. We are in a world of inter-connected apps. NodeJS is for that. Adapt yourself. I need hacker modules to accomplish and solves problems of my current worlds, hacker offers me that. NodeJS is great and lot of thing I read before was old school shit. And BTW, yes a lot of logic must be delegated to the client side. This is a trend and it will not be stopped. Rendering page server side, qu'est ce que je peux pas entendre comme connerie parfois.
ronreiter 13y ago
This is a disaster. Why would you want to create such a complicated system? node.js has a bright future and will be able to replace languages such as Python, Java, C#, etc. But why do two back-ends when you can do one instead?
- lnguyen 13y ago
  Legacy services. If you're starting from scratch, you can choose a cleaner setup. But if you're dealing with an existing site, you have to figure out if and how you can migrate all the existing functionality. For any non-trivial case (or one with a realistic budget), you're not going to be able to just do a re-implementation and single cutover.
aufreak3 13y ago
I code a lot in JS these days and I find this divide suggestion interesting. Though I'm proficient in JS, I don't trust myself enough to write server stuff in JS - for ex: while an accidental global access likely has limited consequences on the browser side, it can result in data cross talk between users on the server side. So I do prefer the help offered by some static typing. Even go feels better, Haskell would rock, typed racket also looks awesome from this perspective. To my main point, I'm unclear how such a split would actually work in practice. For example, if I have a file upload to do from the client, should that get streamed to the "ui front end at the back end" (whew!) or directly to the "real back end"? Are there any fundamental architectural problems with client side code pulling together an application by accessing a number of independent REST services without going through such a "front end at the back end"? Thoughts/suggestions?
- ilaksh 13y ago
  I don't understand what you mean by "ui front end at the back end". I think maybe I can guess but really not sure at all. I don't see how static typing is really necessary to prevent you from storing user-specific data in a global and sending someone another user's data. Seems like that would be fairly straightforward to detect and avoid and I don't think you would usually be tempted to use a global for something like that. You could use a session variable or database. If you have never worked on the back end, then you are right to be afraid of doing something wrong. However, you are incorrect if you think that means you are likely to make a serious error that you can't correct and therefore shouldn't try. Back end programming is in fact less complex than front-end programming today. So you should jump in. You will learn the most important things you need within a few months. When you upload a file this generally happens as an HTTP POST. Usually this is sent to your own back-end server code. And without special headers on the target domain your browser won't even allow you to POST to another third-party server. This I think is the issue you are talking about when you mention accessing independent REST services -- that needs to use JSONP or have CORS enabled on the third party server. Of course you may not need to learn anything about back-end programming because you can in fact build just about any kind of application these days without using your own server at all, just by integrating a number of third-party APIs and running everything from the browser.
exo_duz 13y ago
I'm quite new to Node.js but I heard that it's really good. Does it really solve the need of server side scripting? I'm thinking of learning it if I can get good justification to. I currently program in PHP for all my websites. Any pointers and comments greatly appreciated. Thanks in advance.
CmonDev 13y ago
If you ever complained about having to refactor a messy ex-outsourced codebase in Java/C#, then wait for wider JS adoption. I bet JS not being used for business logic will be advertised as a feature in job listings.

165 points by thisisblurry 13y ago

Can someone explain why the author refers to the nodejs layer as "front-end?" It is a UI-layer, but is it not still back-end?

dak1 13y ago
I think it makes more sense if you think of it as "domain of the front-end engineer". There's certainly an increasing number of developers who are focusing more on the front-end plus Node.js, often for connecting backend services and providing a RESTful API.
sisk 13y ago
I think it may be more appropriately called the mid-tier. You have your back-end handling storage, low level validations, complex business logic, service integration and coordination, background jobs, etc. You have your mid-tier with the implementation-specific validations / logic, template rendering, etc. And then you have your front-end with (as appropriate) all the client-side stuff (validations, logic, and rendering). It's worth considering the source, in this case. Nicholas has spent a lot of time both employed full-time and as a contractor at organizations that operate at a massive scale. This solution works if your application, architecture, or even engineers would benefit from additional abstraction. I do take issue with one point he brings up, however. He mentions the mid-tier communicating with the back-end over HTTP(S). Unless you have some need to serve your API exclusively over HTTP(S), why not use something with a little less overhead (like a message queue)?

EGreg 13y ago

This is interesting. Basically what I like Node.js for is the evented programming that JS encourages. That and the fact that web developers are already familiar with JS. Consider this: you have a site that will have to scale to millions of people. If you have a lot of reads, you can simply replicate your database, but if you have a lot of writes too, then you'll need to shard (partition horizontally) your database. An aside -- if you find yourself using an ORM and sharding a lot, then most likely you should have used a NoSQL database such as Riak, instead of a relational DB. But let's say you've already gone this route, and used MySQL, which a lot of sites including facebook have done. In this case, anytime you need your query to hit N shards, PHP will take (s1 + s2 + ... + s_n) time to do it. Node.js will take MAX(s1, s2, ... s_n) which is much faster. There is a big difference for latency. (It's true that the mysqli driver in PHP does support concurrent queries, but the above comparison isn't just for DB but for EVERYTHING. In JS and Go you have the option to do concurrent I/O, in PHP you don't.) Another difference is in the memory usage. PHP has to create a copy of your environment for every preforked process. It depends on Linux to do copy-on-write, for instance. APC helps a little with shared memory segments, but not much. On a 2GB RAM machine, how many clients can you support with PHP vs Node? Node has just one copy of the code running, and each request costs very little in comparison. Of course, since everything is in the same memory space, you can easily bring down the whole process, so Node.js processes need to be built to survive crashes, unlike PHP scripts which are isolated. And let's not forget that Node.js stuff can push to the client, whereas for PHP to do that you need wasteful, long-running sleeping processes sitting in memory, and having some nginx event module to simulate evented programming. In short, Node.js and stuff like that gives you much more flexibility, many more things you can do (such as pushing data in near real time to many different endpoints including the browser), but at the same time you need to code everything in a way that crashes don't matter much.

jsnk 13y ago
Here's a stupid question. If Nodejs is sitting between the client and PHP backend, isn't latency higher than just using PHP backend?
- EGreg 13y ago
  Yes and no. If Node.js can do things like * cache responses * not send duplicate responses but instead maintain a waiting queue * throttle requests based on # of preforked threads etc. then it would be faster most of the time. And equally importantly you can take a page from Yahoo's book and pre-render stuff on the presumably faster server, for mobile devices and robots.
  - rubiquity 13y ago
    Why can't you do these things in PHP (or whatever other language you're already using)?
    - EGreg 13y ago
      You can, but Node.js is often a better choice than PHP. Caching: you can have ONE node.js process listening to all requests, and it can keep the cached info in memory, to be looked up much more quickly. In PHP, you'd have to load the entire script environment, connect to an external source like Memcached or APC, etc. Waitlist: Similar to caching, except Node.js can hold off on responding to the request until the response came back. It's MUCH harder to make something like PHP iterate through the waitlist because a bunch of scripts might get called at once, and the way it works, all of them will have to sleep. With Node.js, only one process has to sleep -- or handles something else while you're waiting. etc.
    - Touche 13y ago
      Because that shouldn't be the responsibility of the business layer. Perhaps they are serving many apps other than just the web client, some of which don't want cached data.
- deleted 13y ago

dimadima 13y ago

Yeah—what the fuck is this post and how did it get to the front page of HN? 1- What is a Node on the front-end? Isn't that called... ~~Chrome~~? 2- "I definitely don’t believe that an entire back-end should be written in Node.js just because it can." <-- What is this 2011?

jacques_chester 13y ago

OK, dumb question time. How are front-end and back-end defined? To me the distinction was about the location of execution. "Front-end" meant "in a browser" and back-end meant "anywhere else with some surface addressable via HTTP". Now it seems that "front-end" means "View and Controller" and "back-end" means "Model", except ... not quite. Sometimes. On the other hand, perhaps I protest too much. It's not as though there's a High Court of Internet Nomenclature for this.

mercer 13y ago
Yeah, I've felt for a while that we need to start ditching the terms 'front-end' and 'back-end', as there is no way to use these terms anymore without following up with an explanation of what this means. I've been primarily a 'browser developer', with most of my time spent in the Chrome dev tools, editing css, html and 'light' javascript. I call myself a front-ender for this reason. However, over time I find that I prefer the 'real' programming stuff over battling browser quirks and pumping out html/css structures that I learned over time are optimal. I gravitate more and more to what amount to full web apps where I do stuff that requires, to a degree, 'real' programming beyond just a javascript/jQuery widget. That's where the real division is, I think. As I get into more and more complicated development, I become more aware of my limitations and my lack of formal training. This reached a point where calling myself a 'front-ender' is starting to feel less and less applicable, because there's a huge divide between many front-enders I know who are not really programmers, and what I am in the process of becoming, and calling myself a front-ender feels like underselling myself.
andrewl-hn 13y ago
It largely depends on a culture of the people you talk to. For many Java developers Backend means communicating with the database and application logic. But they would consider templating and other veiw code a "frontend work", even though it has nothing to do with the web browser. However, if you talk to JavaScript developers many of them would consider all code that is executed in a browser "frontend" but would exclude any server-side templating, partials, etc. Then, some of them would still consider ALL JavaScript code a part of Frontend, be it a browser code or Node code. This can bring up some fun conversations. One of my coworkers talk about server-side bits of project A a "Frontend" because they are written in Node, but considers same functionality in project B "Backend" because they are written in Python.

carsongross 13y ago

In as much as the distinction is useful, wouldn't node be considered backend? This is what drives me bonkers about the node and JS community: there is so much goddamned noise and "nobody cares!" arrogance in the signal it's difficult to know who to take seriously.

k3n 13y ago
I think that is sort of the underlying theme of this article, in that the definition of "backend" has been traditionally had to define, philosophically speaking. And you can take my word for it that you should take this guy seriously, or you can check his credentials to make that determination yourself, but suffice it to say I think most would consider him a source of much signal and not much noise.
- Touche 13y ago
  I don't think it's really that different. I see "front end Ruby on Rails developer" job ads all the time and have for years. It really depends on how the company is structured as to what is the front and back ends.
dmak 13y ago
Well, I think the lines begin to blur with these cohesive technology stacks that only use one programming language. I code that is run on the server and not in the browser is considered "backend".

badman_ting 13y ago

I love JS, but I have trouble with this idea that people are against using Node because they're afraid of JS or whatever. EGreg has mentioned some situations like millions of users or pushing data to the client, where Node makes sense. But I'm not sure what inherent value running JS on the server has. Also, while it may be true that the backend devs don't care about the flow of pages that the user browses, the user does care. That means that the services that put together the pages need to work for the user's use case. That means that the system needs to be designed for the pages the user looks at. You can't escape this, this is bigger than your architecture. It's almost like a law of physics.

rubiquity 13y ago
Back-end (god I hate this term) developers should be concerned with modeling the domain of the problem they are solving. That is all.
- Rygu 13y ago
  I disagree, being a good server side software developer means that you understand fully how your models and APIs will be used and what consuming developers really want from it. You enable them to easily drop your solutions into their stack. Be it an external JSON API or an internal class's API. Every end has a front and back.
  - rubiquity 13y ago
    Note that I said "concerned" and not anything about the level of skill this developer has. ;) I think in the size of applications/companies Zakas is talking about it's probably best if the various layers are like black boxes to one another.
- badman_ting 13y ago
  Would it be OK if the services they build take one year to respond? They care about other things too.

dmak 13y ago

Traditionally, I defined backend as server side programming basically anything that is run on the server before it reaches the browser. Since front-end engineers know JavaScript already, they can just effectively make an abstraction that spits out what they need using Node.js which is technically still in their domain. I never thought of it like that, but that totally makes sense too, wow. Nice read.

webjprgm 13y ago

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.

dmak 13y ago
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.
ChikkaChiChi 13y ago
At the expense of being flamed, I'd say that every back-end engineer can do front-end work even if the end result is terrible from a user experience perspective. You may even find cases in which a person can be equally adept at both. That being said, I believe that there are more front-end specialists and designers who cannot do what it takes to build an efficient back-end tool. Try showing your latest application around an office. Few people will comment on how you are grabbing the data, but everyone and their mother will tell you how to make it prettier.
- dasil003 13y ago
  There are also back-end specialists who cannot do what it takes to build an efficient back-end tool :) The skills involved in web development and software engineering are so varied that I'd hesitate to define too few buckets to categorize people. Traditionally I think the reason designers get away with learning a bit of JS is because of the simple request, pageview and DOM semantic of the web makes it easy to hack on things until they work without the danger of really screwing things up too bad for 3 reasons: 1) you don't worry about persistence, 2) you don't worry about scalability, and 3) any problems you created only live as long as the pageview does. Newer APIs like client-side storage and pushstate are allowing browser js to quickly evolve into the realm of serious software engineering with even a few twists of its own (like no easy production logs.) Of course a web designer can still come and do a tutorial and duct tape some things together, but this is equally true of PHP, rails or node. There is an inherent learning curve in learning how to operate at various levels of abstraction well enough to engineer a system that meets latency, scalability, correctness and maintainability requirements for a non-trivial app.

ChikkaChiChi 13y ago

This new javascript wave in which we eschew the needs of the consumer is going to start costing companies big. Processing power, memory, and power consumption are still a pretty big deal in the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake. Engineers that make their lives easier at the expense of the customer will find themselves in a very empty and very optimized echo chamber. Users will be found elsewhere dealing with products that are faster (for them) and teams clamoring for how they can continue to improve the experience with each iteration.

jeffasinger 13y ago
In some cases, doing things client side is massively faster, and in other cases it isn't. It's something that teams need to look at case by case. For example, over a small data-set, doing typeahead search on about 5000 elements was many times faster, even on some of the slowest hardware than doing it server side.
rdtsc 13y ago
> the mobile sector and offloading all these responsibilities to build the view client-side are a huge mistake. I've been thinking about that as well and was playing this N2O framework: http://synrc.com/framework/web/ http://synrc.com/framework/web/ they are sort of making this point as well, render on the server and send html to client but do it via a websocket. That is an interesting approach.
camus 13y ago
NodeJS is async by default and RAD. Does it really scale at the corporate level ? depends on what is your product. If you are better off with the JVM or .net , there is no reason to use it. But in my opinion , it definetly has its place in startups.
- ChikkaChiChi 13y ago
  The concern I express isn't with Node; it's with the front end tools like Angular that shift the cost of building UI scaffolding to the client side javascript engine.

karanbhangui 13y ago

I've been thinking about this a lot lately (and in fact probably driving a lot of my friends nuts with my views on this), but I think if you take a look at what Airbnb has done with Rendr and what ex-Google Wave engineers have done with Derby, it becomes immensely clear what the potential here is. Traditionally you've had to maintain two codebases for things related to rendering (think generating URL slugs, or formatting dates). This code duplication is obviously solved by running node layer in the middle. But the benefits go well beyond unifying rendering code and separating "backend" developers from "frontend" developers. My excitement is the ease of building highly interactive apps while staying true to how web pages were meant to be architected. Since your client and server runtime are aware of each other, the framework can handle things like partial rendering, multi-client sync via OT, request caching, incrementally pushing required css/js/html payloads to the clients as necessary (instead of doing one massive push at the beginning). Right now the client and the server talk to each other through a constricted API layer you have to create endpoints for manually. It's exciting to think how much of this can be automatically handled by the framework. I believe this generation of web architecture will finally bridge the gap between "websites" (often progressively enhanced HTML payload) and "webapps" (massive javascript payload, almost no HTML).

deleted 13y ago
[deleted]

agibsonccc 13y ago

I'm a big fan of using node for an intermediary web stack. It really plays well for handling your web layer with the tools available as well as handling builds with grunt and friends. I think the real potential comes in when you blend it with a heavy lifting API written in go or on the JVM. Easy web layer that's agnostic to whatever heavy processing language should you decide to do. Obviously there's a bit of complexity that comes with this, but if you need to scale up it's right there. Even then, node is pretty powerful on its own, where you might not need a crazy backend.

pjmlp 13y ago

Frontend Engineer?!?

mattdeboard 13y ago
You don't know the right developers.

mjackson 13y ago

> As much as I love JavaScript, there are just some things I don’t want written in JavaScript – my shopping cart, for example. After developing almost exclusively in JavaScript for the better part of the past year (and doing a lot more in the previous 6), I'm convinced that this mentality is going to start fading as more and more developers become more capable and productive with JavaScript. There's nothing inherently wrong with the language that prevents you from writing sufficiently complex and reliable systems to power something like a shopping cart, or anything else for that matter. The main thing that is missing at this point is experience and maturity in the JavaScript community at large, which is quickly changing as more and more developers start embracing the language.

lmm 13y ago
It doesn't have an adequate type system. There are too many silent conversions. The syntax is very clunky. All the object systems feel hacky and they can't be relied on to interoperate with each other. Problems like no standardized threading support or decimal type could be resolved in the future. But the language as it exists currently lets you override everything, and that's the sort of thing that you can't remove in later versions because existing code will be using it. So it's always going to be possible to e.g. modify Object.prototype and then expect the method you added to be accessible on anything. And then that library breaks because you defined an object that already has a method with that name. Yes, a sufficiently smart developer can write good code in Javascript. But there are very few people who I'd trust to write financial code in Javascript, and I think all of them would use a better language rather than expending the effort working around its deficiencies.
- embwbam 13y ago
  I think Typescript solves a lot of these problems. The type system is amazing, conversions are explicit. Syntax is slightly improved, built-in class system. The others I don't really mind: I like writing event-loop code over threads, and have never once run into Object.prototype problems in the wild.
  - 13y ago

heynairb 13y ago

Isn't this architecture redundant? Why have two application servers in between the database and the browser? Wouldn't it be better to serve the page once and have the browser communicate directly with the api? Is this setup common? Is it really the future?

svachalek 13y ago
Most large applications tend to be a constellation of servers anyway, with the advantages of individual scaling, updating, reliability etc. The disadvantages are roughly the same. So, it's optimizing the advantage of having more servers against the disadvantage of having more servers.

hrjet 13y ago

I was working in a largish project recently with a three-tiered architecture as described in the article. However, both of the server-side tiers were in Scala, and it was hard to see the advantage in that case. However, using NodeJS in lieu of Scala for the middle tier, suddenly makes a lot of sense. Thanks to the article for showing this path! To be sure, NodeJS can be replaced with something equivalent, such as N2O or JScala (as others have mentioned). But the concept is more clear when expressed in terms of NodeJS.

thomasreggi 13y ago

all javascript everything

mtam 13y ago

I am struggling to see how this approach would be beneficial outside of large organizations with massive web apps. For most apps, the benefits do not seem to outweigh the drawbacks of having (1) another dependency, (2) another piece of software (node) to install, update, and maintain, (3) another set of code base, (4) an increase in latency, and (5) all the added complexity to troubleshooting, debug, document, etc...

shapeshed 13y ago

Isn't the point that with a REST interface you can move your UI layer entirely to client-side JavaScript with any of Ember/Angular/Backbone. Behind the REST interface your tech can be anything and you can swap it at will.

10098 13y ago

> I was never a fan of PHP Interesting how the same people who are "not fans" of PHP somehow like Javascript. As if it's better.

rtfeldman 13y ago
Considering there are an increasing number of designed-to-be-likable languages that compile to JS, it's about as close to objectively better as you can get.
Cyranix 13y ago
Are you claiming to have an objective yardstick for comparing the goodness of languages? (Don't answer that.) If not, please remember that different languages are just that -- different, not necessarily better or worse. Personal attitudes towards the differences between languages are totally normal. Bearing this in mind will help the conversation proceed in a more civil manner.
- 10098 13y ago
  > "not necessarily better or worse" I don't agree with that. Sure, comparing something from completely different domains (for example, SQL and HTML) doesn't make sense. However, for some languages (e.g. C#/Java, Python/Ruby, etc.) it is entirely possible to compare them and point out which is better in some aspects or worse in others. What I'm saying is that Javascript and PHP are comparable (now that node.js exists and it's possible to write server-side javascript), however, I don't see much advantage over PHP other than being more trendy.
  - tracker1 13y ago
    Well, probably the biggest difference is npm... A great package manager makes things easier to create and use as independent modules. PHP has frameworks, but these are a bit cumbersome. JavaScript even with the bad parts is still more consistent and friendly to use than the core methods within PHP, inconsistent naming structures, parameter ordering and a lot of other issues at the language level. I've NEVER liked PHP as a language... and that stems from VERY early on in web development. I've used a number of platforms and languages over the years, and none have irked me nearly as much as PHP has.

pweissbrod 13y ago

Unless youre dealing with a large complex app or scalability is a major concern I dont see how adding an extra nodejs vestige is worth all the trouble. Take the coolness of node out of the equation and not much compelling arguments are left from a business value perspective.

indubitably 13y ago

Right, the Chrome icon should represent the user-facing internet.

deleted 13y ago

[deleted]

sassyalex 13y ago

If you are smart enough you can make every code fit your need and reach the code quality you need. JS weakly typed ? Seriously learn on how to adapt your coding style. I've built more than 20 API/Apps and Node is the best thing I ever had to build networked apps. I have a J2EE/Spring, Python and RoR background, NodeJS/NPM took the best of every stuff created before. In my case, I need to be fast and JS + NodeJS + his awesome community permits me to build stable, innovative solutions and high performance networked app in a very short amount of time. We are in a world of inter-connected apps. NodeJS is for that. Adapt yourself. I need hacker modules to accomplish and solves problems of my current worlds, hacker offers me that. NodeJS is great and lot of thing I read before was old school shit. And BTW, yes a lot of logic must be delegated to the client side. This is a trend and it will not be stopped. Rendering page server side, qu'est ce que je peux pas entendre comme connerie parfois.

ronreiter 13y ago

This is a disaster. Why would you want to create such a complicated system? node.js has a bright future and will be able to replace languages such as Python, Java, C#, etc. But why do two back-ends when you can do one instead?

lnguyen 13y ago
Legacy services. If you're starting from scratch, you can choose a cleaner setup. But if you're dealing with an existing site, you have to figure out if and how you can migrate all the existing functionality. For any non-trivial case (or one with a realistic budget), you're not going to be able to just do a re-implementation and single cutover.

aufreak3 13y ago

I code a lot in JS these days and I find this divide suggestion interesting. Though I'm proficient in JS, I don't trust myself enough to write server stuff in JS - for ex: while an accidental global access likely has limited consequences on the browser side, it can result in data cross talk between users on the server side. So I do prefer the help offered by some static typing. Even go feels better, Haskell would rock, typed racket also looks awesome from this perspective. To my main point, I'm unclear how such a split would actually work in practice. For example, if I have a file upload to do from the client, should that get streamed to the "ui front end at the back end" (whew!) or directly to the "real back end"? Are there any fundamental architectural problems with client side code pulling together an application by accessing a number of independent REST services without going through such a "front end at the back end"? Thoughts/suggestions?

ilaksh 13y ago
I don't understand what you mean by "ui front end at the back end". I think maybe I can guess but really not sure at all. I don't see how static typing is really necessary to prevent you from storing user-specific data in a global and sending someone another user's data. Seems like that would be fairly straightforward to detect and avoid and I don't think you would usually be tempted to use a global for something like that. You could use a session variable or database. If you have never worked on the back end, then you are right to be afraid of doing something wrong. However, you are incorrect if you think that means you are likely to make a serious error that you can't correct and therefore shouldn't try. Back end programming is in fact less complex than front-end programming today. So you should jump in. You will learn the most important things you need within a few months. When you upload a file this generally happens as an HTTP POST. Usually this is sent to your own back-end server code. And without special headers on the target domain your browser won't even allow you to POST to another third-party server. This I think is the issue you are talking about when you mention accessing independent REST services -- that needs to use JSONP or have CORS enabled on the third party server. Of course you may not need to learn anything about back-end programming because you can in fact build just about any kind of application these days without using your own server at all, just by integrating a number of third-party APIs and running everything from the browser.

exo_duz 13y ago

I'm quite new to Node.js but I heard that it's really good. Does it really solve the need of server side scripting? I'm thinking of learning it if I can get good justification to. I currently program in PHP for all my websites. Any pointers and comments greatly appreciated. Thanks in advance.

CmonDev 13y ago

If you ever complained about having to refactor a messy ex-outsourced codebase in Java/C#, then wait for wider JS adoption. I bet JS not being used for business logic will be advertised as a feature in job listings.