
Node.js and the new web front-end - thisisblurry
http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/
======
mjackson
> As much as I love JavaScript, there are just some things I don’t want
> written in JavaScript – my shopping cart, for example.

After developing almost exclusively in JavaScript for the better part of the
past year (and doing a lot more in the previous 6), I'm convinced that this
mentality is going to start fading as more and more developers become more
capable and productive with JavaScript.

There's nothing inherently _wrong_ with the language that prevents you from
writing sufficiently complex and reliable systems to power something like a
shopping cart, or anything else for that matter. The main thing that is
missing at this point is experience and maturity in the JavaScript community
at large, which is quickly changing as more and more developers start
embracing the language.

~~~
lmm
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
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.

~~~
Kiro
What's so good about TypeScript's type system and what problem does it solve?

~~~
ilaksh
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.

~~~
CmonDev
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.

~~~
joshuacc
> Nobody developed a language to run on top of Java

Clojure? Scala?

~~~
CmonDev
I said 'Java' not JVM.

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

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

~~~
bencoder
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.

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

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

~~~
andrewl-hn
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-hn
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".

------
EGreg
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
Here's a stupid question. If Nodejs is sitting between the client and PHP
backend, isn't latency higher than just using PHP backend?

~~~
k3n
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.

~~~
anonymoushn
Is it actually impossible to query the DB asynchronously in PHP?

~~~
k3n
Not impossible, but not easy either considering PHP is single-threaded and
synchronous.

~~~
anonymoushn
I've never heard of languages being synchronous or asynchronous before. It
looks like PHP ships with asynchronous DB APIs.

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

1\.
[http://www.php.net/manual/en/intro.pthreads.php](http://www.php.net/manual/en/intro.pthreads.php)

2\.
[http://www.php.net/manual/en/pcntl.installation.php](http://www.php.net/manual/en/pcntl.installation.php)

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

~~~
rmrfrmrf
I'm a fan of both PHP _AND_ Javascript! Take that, haters!

~~~
pessimizer
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!

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

~~~
ChikkaChiChi
At the expense of being flamed, I'd say that every back-end engineer can do
front-end work even if the end result is terrible from a user experience
perspective. You may even find cases in which a person can be equally adept at
both.

That being said, I believe that there are more front-end specialists and
designers who cannot do what it takes to build an efficient back-end tool.

Try showing your latest application around an office. Few people will comment
on how you are grabbing the data, but everyone and their mother will tell you
how to make it prettier.

~~~
dasil003
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.

------
carsongross
In as much as the distinction is useful, wouldn't node be considered
_backend_?

This is what drives me bonkers about the node and JS community: there is so
much goddamned noise and "nobody cares!" arrogance in the signal it's
difficult to know who to take seriously.

~~~
k3n
I think that is sort of the underlying theme of this article, in that the
definition of "backend" has been traditionally had to define, philosophically
speaking.

And you can take my word for it that you should take this guy seriously, or
you can check his credentials to make that determination yourself, but suffice
it to say I think most would consider him a source of much signal and not much
noise.

~~~
Touche
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.

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

------
aufreak3
I code a lot in JS these days and I find this divide suggestion interesting.
Though I'm proficient in JS, I don't trust myself enough to write server stuff
in JS - for ex: while an accidental global access likely has limited
consequences on the browser side, it can result in data cross talk between
users on the server side. So I do prefer the help offered by some static
typing. Even go feels better, Haskell would rock, typed racket also looks
awesome from this perspective.

To my main point, I'm unclear how such a split would actually work in
practice. For example, if I have a file upload to do from the client, should
that get streamed to the "ui front end at the back end" (whew!) or directly to
the "real back end"? Are there any fundamental architectural problems with
client side code pulling together an application by accessing a number of
independent REST services _without_ going through such a "front end at the
back end"?

Thoughts/suggestions?

~~~
ilaksh
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.

~~~
aufreak3
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.

------
badman_ting
I love JS, but I have trouble with this idea that people are against using
Node because they're afraid of JS or whatever. EGreg has mentioned some
situations like millions of users or pushing data to the client, where Node
makes sense. But I'm not sure what inherent value running JS on the server
has.

Also, while it may be true that the backend devs don't care about the flow of
pages that the user browses, the user does care. That means that the services
that put together the pages need to work for the user's use case. That means
that the system needs to be designed for the pages the user looks at. You
can't escape this, this is bigger than your architecture. It's almost like a
law of physics.

~~~
rubiquity
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
I disagree, being a good server side software developer means that you
understand fully how your models and APIs will be used and what consuming
developers really want from it. You enable them to easily drop your solutions
into their stack. Be it an external JSON API or an internal class's API.

Every end has a front and back.

~~~
rubiquity
Note that I said "concerned" and not anything about the level of skill this
developer has. ;)

I think in the size of applications/companies Zakas is talking about it's
probably best if the various layers are like black boxes to one another.

------
JacksonGariety
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?

~~~
sisk
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)?

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

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

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

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

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

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

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

~~~
svachalek
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.

------
sassyalex
If you are smart enough you can make every code fit your need and reach the
code quality you need.

JS weakly typed ? Seriously learn on how to adapt your coding style. I've
built more than 20 API/Apps and Node is the best thing I ever had to build
networked apps. I have a J2EE/Spring, Python and RoR background, NodeJS/NPM
took the best of every stuff created before.

In my case, I need to be fast and JS + NodeJS + his awesome community permits
me to build stable, innovative solutions and high performance networked app in
a very short amount of time.

We are in a world of inter-connected apps. NodeJS is for that. Adapt yourself.

I need hacker modules to accomplish and solves problems of my current worlds,
hacker offers me that.

NodeJS is great and lot of thing I read before was old school shit.

And BTW, yes a lot of logic must be delegated to the client side. This is a
trend and it will not be stopped. Rendering page server side, qu'est ce que je
peux pas entendre comme connerie parfois.

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

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

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

------
pjmlp
Frontend Engineer?!?

~~~
mattdeboard
You don't know the right developers.

------
thomasreggi
all javascript everything

