There are certain terms used in the web industry that most people think of as “industry-standard,” but are actually used in slightly different ways at different companies. For instance, I’ve run into several definitions for “alpha,” “beta,” “wireframe,” and “comp” at different shops I’ve worked at. Learning how a new company uses these terms isn’t that difficult, and the definitions are usually similar enough that it’s an easy adjustment.

I recently ran into a situation where my new manager’s definition of a term was different enough to radically change the situation. That term was “front-end.” Now, I think most people in our industry share a similar definition of front-end – it’s anything that the user sees through the browser, as opposed to back-end, which is anything that has to do with the server.

The problem arose from a gray area in our definitions with regard to javascript. In my mind, javascript can be used for both front-end and back-end work, depending on whether you’re using it for style and effects or more ajax-y stuff where you’re talking to the server. To my manager, however, since javascript is run in the browser, it’s front-end, no matter what you’re using it for.

Neither of us is wrong, the problem is that we were trying to describe two different things. I was describing intent and he was describing technology. I was arguing that javascript that talks to APIs on the server is back-end because of the work it’s doing, and he was arguing that it was front-end because it’s javascript.

In the end, I adapted the way I was speaking to clarify what I meant, and started talking about functionality vs. styling instead of front-end vs. back-end. Neither of us changed our minds, but at least we were talking about the same thing now, instead of using the same words, but meaning different things.