Terminology in Web Development

Descrip­tions and def­i­n­i­tions of words com­mon­ly (or not…) used.

Words can be dif­fi­cult, since their def­i­n­i­tion occa­sion­al­ly dif­fers depend­ing on the bias­es of the per­son who uses them. To at least try to min­imise that, this is a catch-all page for ter­mi­nol­o­gy and how I use it. It shouldn’t dif­fer too much from the dic­tio­nar­ies (and Wikipedia), but with more exam­ples so we are on the same page.

3-tier Architecture

For the more for­mal and broad­er (IE not just web devel­op­ment) def­i­n­i­tion, Wikipedia has an arti­cle on 3-tier Archi­tec­ture, which is the basis for my def­i­n­i­tions.

Front-end/User Interface/Presentation layer

What the brows­er ren­ders. HTML, JavaScript, graph­ics, CSS. It can be quite sim­ple, or advanced through use of more com­plex JavaScript appli­ca­tions, or for that mat­ter CSS ani­ma­tions and such. The to me impor­tant mat­ter is that it should be sep­a­rat­ed from data and, in par­tic­u­lar, from what­ev­er serv­er-side lan­guages are used. It should not be impor­tant to the UI whether this is a Word­Press site writ­ten in PHP, or a Python site with (or with­out…) Djan­go, or a Ruby on Rails appli­ca­tion, or for that mat­ter a fat client which gets the data using a REST adapter from “some­where else” (I’m look­ing at you, Ember!).

It can (and prob­a­bly often is) debat­ed on whether tem­plat­ing lan­guages such as Smar­ty or Blade belongs to the front-end, but I over­all con­sid­er them sep­a­rate from it, but using the stan­dards devel­oped by the front-end.

Anoth­er con­sid­er­a­tion is whether the admin areas would be part of the front-end, to which I say “absolute­ly!”, at least from a devel­op­er per­spec­tive. There is very lit­tle dif­fer­ence between build­ing a UI (to use that part of the front-end) intend­ed to show the lat­est cat images to any one who wants to see them and build­ing a UI that is intend­ed to allow an author to upload their lat­est mas­ter­piece, out­side of com­plex­i­ty. It’s expec­ta­tions that the deep­er lay­ers of the stack should ful­fill: If I do X then Y, if I do Z then A. This hap­pens if I mouse over that, if I upload a valid file then it should be uploaded.

Forms and such should be val­i­dat­ed in the front-end, but they should also be val­i­dat­ed deep­er in the stack, obvi­ous­ly.


This often gets referred to as “back­end”, my main rea­son to divide the terms has to do with testibil­i­ty. This is where your serv­er-side lan­guage of choice fits in, and it should serve the infor­ma­tion in a way that the pre­sen­ta­tion lay­er can han­dle. That might be trans­lat­ing tables to a JSON object that is con­sumed by an Ember mod­el, and/or gen­er­at­ing the agreed-upon scripts/CSS/HTML that the pre­sen­ta­tion lay­er has devel­oped. Gen­er­al­ly, if one uses/develops for Word­Press, this is about as deep in the stack as one gets.

As a note, if you’ve ever played on role play­ing chats, most of what is referred to as “the data­base” is in this lay­er, the mis­nomer hav­ing to do with con­fus­ing the stored characters/data and the pre­sen­ta­tion of said characters/data. This lay­er com­mu­ni­cates with the actu­al data stor­age, but it should not be depen­dent upon one par­tic­u­lar type of it. In real­i­ty it’s imprac­ti­cal to build some­thing that could be eas­i­ly changed from using, say, MySQL to NoSQL, but with a bit of care­ful­ness it’s at least pos­si­ble to build some­thing that doesn’t need too much effort to move from a SQLite data­base (for development/testing) to a MySQL data­base (for pro­duc­tion).

Back-end/Persistence layer/Database

This should be the most secured part of the web­site. In an ide­al world, you should not be able to access it (out­side of ded­i­cat­ed areas on your web­host) through any oth­er means than mid­dle­ware, and there should be strict rules on how to inter­act with it.

How much effort goes into the data­base depends quite a bit on the kind of appli­ca­tion, obvi­ous­ly. As I not­ed high­er up, most peo­ple who devel­op in Word­Press nev­er real­ly look into the data­base, and both Djan­go, Lar­avel and Ruby on Rails (among oth­ers…) have ways to cre­ate tables and such with­out the devel­op­er need­ing to get their hands dirty with the func­tion­al­i­ties of the data stor­age.

How­ev­er, the more impor­tant the data and its’ struc­ture is, the more impor­tant it is to take good care with the per­sis­tance lay­er. The larg­er the appli­ca­tion, the high­er the num­ber of users and num­ber of trans­ac­tions, the more effort needs to be put into mak­ing it right to begin with, and very few Object-Rela­tion Man­agers can deal with com­plex and large sets of data as effi­cient­ly as some­one who knows exact­ly what needs to be done, and how to do it. Fig­ur­ing out keys and indices and how much of a cell needs to be cov­ered for the full-text search to per­form well with­out being use­less are all tasks bet­ter suit­ed for peo­ple than for soft­ware.

Per­son­al­ly, I would also add cron jobs and sim­i­lar things to the descrip­tion of back-end. They might use the same libraries/framework as the mid­dle­ware, but any tasks intend­ed to do things heav­i­ly on the serv­er are back-end tasks.

Flat Build

This is a term I picked up quite recent­ly, when I was brows­ing around and found Matt Bailey’s arti­cles on it, and it imme­di­ate­ly res­onat­ed with me, so once I final­ly fin­ish it there will be an arti­cle on how I imple­ment it, but until then this def­i­n­i­tion will have to do. Oh, and also David Bushell’s two arti­cles that go a very dif­fer­ent route from Matt Bai­ley.

What is it? Well, it is the descrip­tion of devel­op­ing the fron­tend inde­pen­dent­ly of the back­end, that is with pure HTML, CSS and JavaScript, using either mock­up data or a fixed dataset of some kind.

Matt Bai­ley in his pieace speaks of Assem­ble which is based on Han­dle­bars tem­plates, using Grunt to build HTML-pages, David Bushell rolls his own. The big thing that both of them push (and that I adopt­ed whole­sale) is that hav­ing some kind of build sys­tem even for pure HTML, eas­es main­tain­abil­i­ty. The cur­rent HTML-mock­ups of my site looks noth­ing like the way the site does, because I changed some­thing, and fig­ured it was enough to test it in the index.html page.

It prob­a­bly is a touch overkill occa­sion­al­ly, but by build­ing the mock­ups using some kind of assem­bling sys­tem, it ensures that a change in one gets reflect­ed in the oth­ers, and you can test that the JavaScript and CSS chang­ing on one page doesn’t break anoth­er.


Snake case, camel case, etc, etc, etc. What are they? Well, it’s not always agreed on, but here’s a start­ing list.

Snake Case (or snake_case)

  • Only low­er­case let­ters (with the pos­si­ble excep­tion of the first let­ter)
  • Words are sep­a­rat­ed with a sin­gle under­score
  • Both Python and Ruby rec­om­mend snake case for non-con­stants and non-class­es

Camel Case (or Pascal Style)

  • Each new word starts with a cap­i­tal let­ter
  • If the first let­ter is a cap­i­tal it’s referred to as Upper­Camel­Case (or Studly­Caps or Cap­Words), if it’s a low­er­case let­ter it’s low­er­Camel­Case (or camel­Case or mixed­Case)
  • .NET and JavaScript both encour­age the use of Camel Case, with Studly­Caps denot­ing class­es
  • Ruby and Python rec­om­mend Studly­Caps for class names



  • Only cap­i­tal let­ters
  • Words are sep­a­rat­ed with a sin­gle under­score
  • Many languages/code styles rec­om­mends it for con­stants

For the moment comments are not enabled, but feel free to reach out on Twitter.