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.

We might need a change in terminology.

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