> 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.
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.
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.
Was just going to say, a large percentage of online shopping is based on open source e-commerce solutions, most of which are written in PHP. Which shares (and possibly overshadows) Javascript's problems.
What's the big deal with getting bignum into js? Everything else I can agree with, but not having 64bit int support in a server side language has to hurt. (just look at most node db adapters and bigints are handled as strings)
You seemed to have jumped from talking about integers to floating point!
And the example you have given is a problem with all floating point implementations, not just Javascript. You will get that exact same answer in C, Java, etc.
The only way to avoid this is to represent rational numbers directly, without simplification. For example:
There are no integers in js, all numbers are floats. What you want to do is represent all values as integers choosing an arbitrary precision, then only do integer math.
In the example given, using node-bignum and assuming our precision is a thousand of a cent:
big(30000).mul(3) => 90000
Of course you'd get the same result in plain javascript with these numbers, but then you'd have to handle everywhere an operation could return decimals, and using bignum you have "unlimited" precision > 52bits.
I agree with what you are saying. It's just that you gave a floating point multiplication example, where an integer multiplication with overflow would have been a relevant example.
Here's a relevant example,
2^26 * 2^26 == 2^52
may not hold in javascript because it only supports 52 significant binary digits. Whereas other languages usually support 64 significant binary digits.
I don't need "an integer bigger than 52 bits". I need a way to represent (fixed-precision) decimals exactly, and do arithmetic with them, preferably without performance being too terrible or the code looking too horrible. And I'd like it to be a standard implementation, or conform to a standard interface, so that a library ecosystem can build up with support for this type.
They're 64bit floats, but you get 52 bits of integer precision... You're as likely to hit issues as you are with a 32bit int.. the big difference is you need to use Math.round() if you want to multiply/divide in order to get to a whole number again.. Even with a 64-bit integer, you can suffer from overflow, it's only a matter of where.. and even with 32bit environments there have been work arounds for larger numbers/precision.. with JS there are bignum libraries for this.
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.
I hadn't heard of Typescript, but I think we'll be seeing a lot more efforts along these lines. Despite the pain and inelegance of compiling something to Javascript, I see two inexorable forces that will lead a lot of smart engineers in that direction.
First, running the same UI code on the front-end and back-end will enable the best performing apps across platforms. Imagine being able to run a rich client on a powerful PC that just talks to an API and does all the rendering as a single page app, while simultaneously being able to serve up pure HTML/CSS to mobile devices and search engines. Being able to run code on the server or client as needed solves too many problems to ignore.
But on the other hand, javascript flexibility and lack of type system will inevitably cause problems as the codebase grows unless you have a good lead developer to define standards and an iron-fisted approach to code reviews.
Personally I think coding standards are a stretch with a language as wild as javascript, and a higher level language to enforce certain things is the best way to reconcile these two problems. I can even imagine supplementing with something like (for instance) a Haskell library that lets you generate JS code for interfacing with the back-end in a provably correct fashion, and plugging that into the UI code.
Where have you been hiding? There's been a virtual explosion in the number of languages that compile down to JS[1] in just the past 1-2 years, and TypeScript is probably the youngest of them all. CoffeeScript[2] is another big one, I believe it's much more Ruby-like. There's even 7 projects involving Haskell.
I've been using TypeScript for experimenting with Node.js and while it's a great solution there's a few difficulties some might face with it:
-TypeScript definitions for many libraries, such as express are out of date and require modding to use.
-Visual Studio has no built in support for TypeScript with Node for debugging, but it has been mentioned as likely to be added by the TypeScript team eventually.
-There are third party plugins for Node in Visual Studio for debugging, but none support TypeScript yet.
I've found the best solution thus far is Intellij IDEA or WebStorm, as it has support for both Node and TypeScript.
Almost no one realizes this, but the main purpose of TypeScript is to negate one of JavaScript's greatest advantages which is the lack of typing. This is an advantage because it makes code easier to write and read.
The problem that TypeScript solves is that the web platform is in direct conflict with Microsoft's monopolies in PC gaming and business productivity software (Office). Confusing developers into thinking that JavaScript needs types leads them down the path of statically typed languages, i.e. C# and Microsoft's proprietary and closed .NET Framework and software ecosystem.
I think optional typing is better than no typing. It's useful for allowing APIs to be self documenting. It seems as if optional typing is going to get more and more popular. For example, see Google's optional typing in dart, where they actually recommend to not use types for local variables:
They can. But both tend to get out of date as a codebase develops. It's very useful to have an automated tool that ensures the documentation lines up with the actual code - i.e. a type checker.
The "Open Web" is closed to one single language choice that was made for you by someone else. TypeScript is being developed, because Microsoft adapts to where the world is moving and they are just trying to avert the disaster that will happen when enterprises will actually start trying developing whole applications in JS. And Google is developing a higher-order version language as well. Nobody developed a language to run on top of Java, C#, C++, but there is a plenty of choice for JS: Dart, TypeScript, CoffeeScript etc.
> Nobody developed a language to run on top of Java, C#, C++
Because instead of developing languages to run on top of them, people just designed languages to run on the same platform. The browser environment is a special case where the only common feature of the platform that is available to target is JS, there's no common VM underlying it, so replacements target JS.
Though its worth noting that while it may be true that no one developed a language to run on top of C++, C++ was originally implemented as a language that was preprocessed into C and then fed to a C compiler, much the way that many JS alternatives are compiled to JS and then fed to a JS interpreter.
The primary mechanism for running Dart on the client is by compilation to JS. There is a DartVM that runs Dart directly, but its not bundled into any browsers except for a special version of Chromium ("Dartium") bundled with the Dart SDK so that the development cycle can proceed without a dart2js run at each iteration, but its not intended for general use that way.
the two best features of Typescript's type system IMHO are:
- structural typing for interfaces (which means that classes implicitly implement an interface if the definitions match)
- gradual typing (mainly the ability to convert between 'any' and other types implicitly, which makes it much easier to interact with JS libraries/port JS code to Typescript.)
More generally speaking, Typescript aims to solve the problem of maintaining large codebases by giving you the additional security of static typing. The idea is that many simple errors can often be caught by a compiler, but would be much more time-consuming to find otherwise.
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.
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!
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?)
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.
And rails is particularly better/easier to implement a backend in than NodeJS + crudify/restify/express, or any number of other tools?
I've not used anything that allows for as easy modularity as node+npm lend themselves to... just because it's JS doesn't mean it's spaghetti that has blurry code sharing between the client and server.. it's not all meteor, even if that does have a lot to offer.
> 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.
> (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?)
I'd defend the statement you quoted like this: all languages are type. Dynamic languages simply have exactly one expression type, "any". Specifying multiple types affords you strictly beneficial abilities. Static type checks is probably the most significant. Performance improvements and highly specific and accurate code editing assistance (e.g auto suggest) can also be significant.
But yes, you're absolutely right. Nothing but sincere effort, lots of practice, and critical thinking can make you a better programmer.
At the same time, a great carpenter becomes even so much better with a properly weighted hammer and an accurate lever.
> 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.
> 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.
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.
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).
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.
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.
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.
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.)
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.
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.
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.
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.
> 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.
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.
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.
The potential with Node is that you could have the best of both worlds, using the same code to render on client and server depending on which would provide the best experience given the current hardware and connection capacity. (Edit: it looks like Rendr and Derbyjs are starting to realize this potential)
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.
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.
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".
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.
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.
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.
It's closer to a MCVMV or model, controller, view-model, view. Which is close to a MVVM pattern but adds a controller in. In my view the model is back-end, controller is mostly backend (processes the api requests and return the model data or the correct data value to the client), View-Model (grabs data via the model api and loads it into a model class on the client, this model class may or may not be the same structure as the server model, usually mapped to an/multiple api end point(s)), and View is the actual client side presentation.
That's how I tend to think of the pattern, it's not really MVC anymore it's a new pattern that is evolving out of MVC.
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.
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.
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.
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.
>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.
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.
> 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.
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.
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.
Ok, poor example; just consider that it's single-threaded. Pretty much the only threading support is by way of a young PECL extension called pthreads[1], which is still experimental and dangerous. Otherwise, you can use the PCTL extension[2], if you don't mind compiling PHP yourself (and if you're not on Windows, where it's not supported).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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".
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.
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"?
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.
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.
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.
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.
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)?
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.
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...
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.