Node.js and the new web front-end

http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

by thisisblurry • 13 years ago

165 155 13 years ago

nczonline.net

JacksonGariety• 13 years 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• 13 years 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.

sisk2• 13 years 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)?

EGreg3• 13 years 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• 13 years 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?

EGreg3• 13 years 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.

k3n5• 13 years ago

Though there's no absolute answer here, and it could very well go either way, as he explains it would most likely be irrelevant due to the fact that PHP can only process serially.

For instance, if you need to run 3 SQL queries in PHP, then the total execution time will be t1 + t2 + t3. On the other hand, if you make those queries in NodeJS instead, it will be MAX(t1, t2, t3).

So, it depends on the complexity of your app and your ability to decouple and separate concerns in the NodeJS server.

ChikkaChiChi4• 13 years ago

Node can issue multiple non-blocking commands which can let PHP create children processes to handle each request.

It can work, though you lose a bit of transparency.

sisk2• 13 years ago

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).

rubiquity4• 13 years ago

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.

Touche3• 13 years 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.

lmm4• 13 years 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.

jeffasinger3• 13 years ago

We've been using node.js as our entire backend for a project that just needs a simple, low latency interface to a complicated SQL database, with some push abilities. It has served wonderfully in this role. In fact, for our most common API call, the average response time is about 8ms.

rdtsc3• 13 years ago

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.

See, I think the fix not using evented programming with tangled callbacks but spawning a (green) thread. Just because PHP does that model inefficiently, shouldn't be a signal to dive into evented programming but find something that does that model right.

Some example: Python's gevent or eventlet based servers. Java's vert.x server. Go, Erlang, Rust. All support a more sane model I think.

jacques_chester2• 13 years 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• 13 years 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-hn2• 13 years 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.

andrewl-hn2• 13 years ago

Oh, I also would like to add an anecdote. Several years ago I worked at a bank and we had a system with 2 components. One of them was written in Java, the other - in Cobol. Our management referred to the Java part as "frontend" and to Cobol as "backend".

ebiester• 13 years ago

That's basically it, except in most shops, the controller is this middle ground. It's on the back end, but the back end engineers can't really do the job on their own, so the front end developers end up writing the controllers, calling out to services that are written by the people who are actively implementing the business logic. In most cases, there are really four layers rather than three, and the two groups handle two layers each.

Moving to a service oriented architecture where the two groups communicate by REST seems like it would work just as well in most situations, and this was the point.

jacques_chester2• 13 years ago

That's part of what I was wondering about. In the classic MVC sense, we're turned the Controller into a distributed system with a footprint both on client and server.

LandoCalrissian• 13 years ago

I think the lines have quickly blurred, to be effective in the 'front-end' I think you need to be an amalgam of both.

webjprgm2• 13 years ago

Maybe someone has an official answer, but I always thought of front-end as anything in the browser and back-end as anything on the server. Front-facing is user-facing. Back-facing is hidden plumbing.

The article seems to be more about UI vs. non-UI code. Rather than have part of the UI code in the business logic, it can be split out. This was already possible, but with Node.js you can have the server-side half of the UI code be in Javascript so all the UI code is Javascript and the business logic code can be in some other language.

pessimizer2• 13 years ago

I'll tell you what - people are starting to get confused because they're talking about back-end client and front-end server. The browser is getting to be a thicker and thicker client, and more and more decoupled from a server (or servers) that expose(s) a completely application-agnostic API to some object store (or stores.) People hit webpages that run applications on the client that allow it to interface with those object stores in some specific manner through APIs.

We might need a change in terminology.

carsongross• 13 years 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.

k3n5• 13 years 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.

Touche3• 13 years 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.

dmak3• 13 years 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_ting3• 13 years 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.

rubiquity4• 13 years 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• 13 years 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.

badman_ting3• 13 years ago

Would it be OK if the services they build take one year to respond? They care about other things too.

dmak3• 13 years 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.

webjprgm2• 13 years 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.

dmak3• 13 years 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.

ChikkaChiChi4• 13 years 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.

dasil0033• 13 years 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.

proexploit• 13 years ago

It depends on the employer but I find it quite common. Non-technical hiring managers might see a full-stack developer as a both a backend and frontend developer and it seems very attractive. Top tier employers usually want the best of the best and can afford to have multiple members on a team and thus allow that specialization.

If you specialize in a certain skillset, focusing on that skillset gives you time to be even better. Sure, there's developers that can write both back-end and front-end code but they've given up a level of specialization in order to do that. It's not a reluctance to learn but a different focus of what to learn. It has nothing to do with passion.

Most full-stack developers I've met are really backend developers that can also write some front-end code. They don't spend the time to learn all the intricacies of CSS/HTML or stay up to date with changes in spec / new tools and methodologies. I don't know you at all so I can only guess but if you think about it, do you find yourself better at either the frontend or the backend? It's very rare for someone to be a top 10% backend developer and a top 10% frontend developer. I could call myself a full-stack developer because I'm capable of writing both portions of an application but I know that I don't write one end as efficiently or securely as a specialist.

UlyssesGranted• 13 years ago

I call myself a front end engineer. I could easily write an essay about it. In lieu of that, here are a few reasons why.

I came from so-called full stack development. I, unlike many engineers (though the percentage seems to be trending upward), took an early interest in the client-side stuff. As I learned more, I found I was answer more and more of my peers' questions. So that interest turned into a full time job.

The thing about the front-end is it's very easy to pick up in part because it's extremely flexible. You can write horrible, horrible markup, for example, and the rendering engine will bend over backwards attempting to make sense of your mess. And it generally does a pretty amazing job. But, is that code going to be robust? Given that that code has to run on thousands of permutations of environments (different versions of different engines/parsers, on different OSes, on different hardware), how confident are you that it will render correctly? Lets say it doesn't render correctly somewhere, is it because of something you did or is it a bug in the engine? How do you figure that out? If it's a bug, how do you circumvent it?

Many people I work with like the thought of building for one environment. You write code. If it compiles / parses without throwing, you know that execution path works. You cover the different execution paths with test and, if those pass, you ship it. Case closed.

The front-end isn't nearly as clean. It's definitely getting better but there will never be one universal engine / parser. You could argue this is similar to the situation with Ruby, having multiple interpreters. The difference, however, is you choose the interpreter. Front-end guys don't have that freedom as it's controlled entirely by the client.

But lets say you've written bulletproof code. You've got it rendering everywhere. Does it make sense for that platform? Is that same bit of code appropriate for the device it's running on? What about if the network drops out? What if the user has difficulty seeing, will the screenreader bark nonsense or will your site be intelligible? What about if the user is on a touchscreen? Or using a input peripheral for someone with limited mobility? You can be sued for having a site that isn't accessible (discrimination); would your application pass muster?

And that's just the presentation piece. I could go into JavaScript stuff but this is already long. Let's just sum it up by saying there is a lot of terrible, TERRIBLE JavaScript out there (again, mostly due to how simple and flexible it is). Just like anywhere, it takes work to write good, clean, performant, and maintainable JS.

I would argue that the front-end should be considered another tool in a polyglot programmer's toolbelt. Specialization should consist of knowing the edge-cases and gotchas that your typical polyglot won't necessarily know or have interest in but that shouldn't mean you're incapable of developing elsewhere, or are in any way less apt at being a "back-end engineer."

heynairb2• 13 years ago

From the other end of the spectrum there are a lot of backend engineers who don't want to touch the frontend.

IMHO aside from javascript, there's a huge tedious side to frontend engineering involving html, css, browser incompatibility and ugly hacks that aren't really programming in a sense (more just endless debugging). It's all very domain specific knowledge that doesn't translate well onto other facets of of traditional programming. Hence a lot of backend devs want to stay away from that so they build a wall of separation between the people who do want to deal with it and the ones who don't: "Frontend" and "Backend" engineers.

kvcrawford• 13 years ago

It's just a matter of specialization, is all. Not exclusivity. My interest in web development originally stemmed from design, and I am much stronger working on the front-end, as my passion is in UX.

That being said, I absolutely aspire to be a full-stack engineer, and I'm having fun working towards that goal. I agree that somebody unwilling (let alone, not enthused!) to learn the full stack would make for a horrible programmer.

ChikkaChiChi4• 13 years 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.

jeffasinger3• 13 years 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.

rdtsc3• 13 years 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/ 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• 13 years 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.

ChikkaChiChi4• 13 years 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.

dmunoz• 13 years ago

Discourse has run into a pretty nasty performance issue on Android lately [0]. It would be too strong of a critique to say they are already having the problem you mentioned, but surely if they shipped this as a finished problem and had this issue it would be a big deal. It doesn't appear to be a fundamental problem with their codebase, as the video comparisons to iOS show that it runs reasonably smoothly there. This shows that JavaScript performance on mobile has a ways to go yet.

[0] http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

nathanhammond• 13 years ago

From that same thread, the issue isn't with Ember, it's with V8. Ember itself is looking for a workaround to the issue.

http://meta.discourse.org/t/why-is-discourse-so-slow-on-andr...

kevincennis• 13 years ago

Moving more responsibility to the client can let you be a lot smarter and more selective about the data you request from the server, though.

So yeah -- you might have more JS, which will eat some CPU cycles, but you can save yourself from having to request a lot of duplicate data. So, smaller request sizes and if you do it right, fewer requests. The less you can bother the radio, the better.

bencoder• 13 years ago

Alternatively, I could suggest that CPU is cheaper than bandwidth, especially on mobile, so not sending a full html document with every request and just sending the required data and updating via JS makes much more sense for mobile.

Although this article is mostly about javascript on the server, and so isn't focussing on the fat js sites that you are talking about.

GrinningFool2• 13 years ago

Bandwidth is a deferred cost. CPU is an immediate cost (on a mobile device).

When you run a CPU-sucking stie on your device, you typically know exactly which site or app is the culprit - you can watch your battery drop and feel your CPU heat up.

When you get your bill at the end of the month, it's a lot less clear why, exactly, that happened. And - fairly or not - it's a lot less likely to be blamed on a lightweight site that grabs extra data.

Not that these two things should be mutually exclusive anyway: an app designed for mobile will do most of its processing on the server with short bursts on the client, and ALSO be optimized for data on the server side. (The server, after all, typically knows what kind of client it's serving.)

rmrfrmrf2• 13 years ago

It would be interesting to try a solution where Node.js incorporates itself either on the client side or the server side depending on the device. Or even putting Node on both sides and "load balancing" depending on processing power.

I'm also really interested in seeing how feasible it would be to push all Javascript to the server and basically letting the client act as a dummy terminal that sends and receives Javascript snippets through a WebSockets connection (which is more mobile-friendly than AJAX since some mobile users pay per TCP connection). I would expect that latency would result in an overall slower app, but maybe some client side-heavy apps could benefit from it.

tracker18• 13 years ago

There are projects to do exactly this... LinkedIn for example does this for mobile vs. desktop rendering... so they can share the same rendering templates and logic.

ilaksh4• 13 years ago

The advantage with JavaScript is that you can run the same rendering code on the backend for static pre-rendering as you can on the front end.

karanbhangui• 13 years 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).

agibsonccc• 13 years 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• 13 years ago

Frontend Engineer?!?

mattdeboard• 13 years ago

You don't know the right developers.

mjackson2• 13 years 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.

lmm4• 13 years 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• 13 years 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.

spankalee• 13 years ago

This is why I hope and work towards making Dart succeed. Dart is very nice as server-side or command-line scripting language - the VM and dart:io provide a very node.js-like environment. It provides much more safety, structure and feedback to help guide developers towards better code than JavaScript.

rpedela2• 13 years ago

Java and .NET are the only strongly typed languages used heavily as a web backend. Python, PHP, Ruby, and Node.js are all weakly typed.

ricardobeat3• 13 years ago

Almost every shopping cart in existence right now is written in PHP, Python or Ruby, and they have much of the same "issues". Write tests, use a good bignum library, maintain code standards. Syntax is subjective, I find it pretty nice when following a certain style.

Almost nobody modifies Object.prototype, and we now have plenty of APIs to deal with that - defineProperty, seal, freeze, etc.

peterhunt• 13 years ago

If you use jshint (it will yell at you when using == with non-null) much (all?) of these problems go away.

ronreiter2• 13 years ago

Once ES6 will kick in, things will get better. Right now it's definitely a shit storm.

marcuswestin3• 13 years ago

Devil advocating:

I coded exclusively in javascript from 2006-2011. Most of that time was spent at Meebo, where we authored one of the most sophisticated JS application in existence at the time. It was great stuff!

I've worked extensively with node.js 2011-mid2013, launching multiple backends written partially and exclusively in node. Lots of fun!

On https://github.com/marcuswestin I maintain multiple widely used open source projects, much of it JS.

In the past 4 weeks I've rewritten my current product's entire nodejs backend to a statically typed language. Why? Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.

I've been a strong advocate for "javascript everywhere" for a long time. However, these days I believe that there is exactly one fantastic use case for javascript: delivering rich application experiences in web browsers.

So you may be right: perhaps this line of arguing is fading. But in that case I'm a real outlier.

(and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)

mjackson2• 13 years ago

Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.

This statement may be true for you, but it's not for everyone.

It's a dangerous argument because it assumes that static types are going to somehow magically turn bad code into good code, or (by extension) bad coders into good ones.

Static typing is a not a solution to the problem of any deficiencies in the language, but rather the problem of people shooting themselves in the foot with it. It's admittedly a related problem, but a separate one.

Kiro2• 13 years ago

In what language are you rewriting the backend?

rdtsc3• 13 years ago

So what is the other static language? I see go programs on your github account also Objective C.

tomphoolery• 13 years ago

I very much agree with this. While it's definitely fun to build apps in Node, especially when you need one really simple thing to happen with enormous capacity in terms of requests per second, I prefer to build my backend in Rails and frontend in Ember.js, because I feel JavaScript is best used as a frontend language, and Rails is really great at making RESTful APIs as well as encapsulating business logic far away from the JS frontend app. I much prefer writing Ruby rather than JavaScript, but I appreciate JS and know it well enough to do a good job.

badman_ting3• 13 years ago

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.

In other words, it's Turing complete. That's great but not exactly an argument for using JS server-side so much as a reason why it is possible. I love JS, but I also know what it was designed for.

svachalek3• 13 years ago

I can understand some trepidation around actual checkout but seriously, how much linguistic fortitude do you need to implement a shopping cart?

jeffasinger3• 13 years ago

Exactly this, I'd be far more concerned about which datastore was used for a shopping cart than which programming language.

GrinningFool2• 13 years ago

Developing things with the language has never been the problem.

Coming back and maintaining them a year later is a different story.

rpedela2• 13 years ago

Yeah I generally agree. With the builtin addition of require() and reasonable scoping rules, Node.js has turned Javascript into a weak-typed, memory-managed C. There is still the 64-bit integer and large decimal problem, but otherwise that is great. I don't see why the entire backend cannot be Node.js.

ramblerman• 13 years ago

You're kind of quoting him out of context

I believed, and still do believe, that statically typed languages are exactly what you want in the guts of your business logic.

He wasn't making a case against javascript for his shopping cart but rather against dynamic languages.

Now, you could certainly disagree with that as well, but it opens the discussion to a more correct one vs why you believe javascript is a mature language. Something the author actually agrees with.

heynairb2• 13 years 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?

svachalek3• 13 years 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.

hrjet3• 13 years 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• 13 years ago

all javascript everything

mtam• 13 years 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• 13 years 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.

100984• 13 years 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• 13 years 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• 13 years 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.

100984• 13 years 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.

rmrfrmrf2• 13 years ago

I'm a fan of both PHP AND Javascript! Take that, haters!

pessimizer2• 13 years ago

I can't stand either of them! Take that, people who make up rules about how the same people like and don't like stuff!

JPKab• 13 years ago

While "better" is of course subjective in many, many ways, Javascript on V8 via Node is much faster in most computations: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Obviously, performance isn't always a good reason to pick a language. I'm certainly not looking to write stuff in C, despite the performance benefits. Just pointing out that there are some solid reasons to prefer JS to PHP. ClojureScript alone is enough of a reason for me.

pweissbrod• 13 years 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• 13 years ago

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

sassyalex• 13 years 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.

ronreiter2• 13 years 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• 13 years 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.

aufreak32• 13 years 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?

ilaksh4• 13 years 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.

aufreak32• 13 years ago

Thanks for responding.

By "ui front end at the back end", I was referring to the OP's suggestion to use nodejs as the entry point which the talks to the "real" back end.

I'm interested in real time collaboration where message connections between connected users are easiest held in a shared data structure to reduce latency. I've on occasion mangled this data structure unintentionally without any feedback from JS before deployment. If I'd had some static checking, these problems would've been easily avoided. Hence my fear.

edit: to be clear, my "fear" only applies to languages like JS and untyped racket at the backend. Not of backend programming per se.

Rgd my example, so ... given that I would needs CORS support, the browser->nodejs->backend division of labour that the OP is suggesting doesn't seem workable for such a file upload case.

exo_duz• 13 years 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.

CmonDev5• 13 years 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.

Node.js and the new web front-end

Related Stories