Welcome to part two of our three-part series breaking down the terms web developers most want their team to know: this time, highlighting back-end terminology.
Familiarizing yourself with front-end development terminology can be fairly straightforward; much of the time, the words tend to indicate visual cues or subjective points. But back-end development is the real nitty gritty of “traditional” coding that builds a website.
Defining these components gives better context to all the steps before a webpage is live, especially if your background is not rooted in HTML or CSS.
This time, we’re focusing on definitions that help make up the behind-the-scenes creation of code, to show exactly how these terms play a role in back-end development.
Pre-development planning
Code base
One of the very first decisions in web development is what code base to utilize – a decision generally driven by specific project requirements, or simply a developer's preference. Code bases are collections of source code (more on that below) that are organized in repositories to provide a foundation for developers. There are many code bases out there related to the dozens of programming languages developers work in: HTML, CSS, C++, Ruby, Python, Java...the list goes on.
Environment
When it comes to developing a site, you want to have a space where edits can be made and problems debugged, while you work through small tweaks before it goes live. A dev environment is just that – a location where development can privately take place, instead of on the live Internet. Picture this as a digital working environment, where code is tested, staging is planned for an eventual launch, and the site can be managed until there is final approval.
WYSIWYG
In development, WYSIWYG (pronounced “whiz-ee-wig”) is an acronym for What You See Is What You Get. These straightforward editing windows contain the proper formatting to show content in a setup similar to its published appearance. WYSIWGs often contain common editing tasks like Bold, Link, Bulleted List, etc. that will show edits to content in a way that resembles the live display. Such editing is also easier for making quick changes that might affect the final product’s format.
Creating & editing
Open source vs. closed source
All software is created with source code, which is the technical background plan of how a program will function. The major difference between open source and closed source code is the decision to make it available to other users, or to keep it private. Closed source code is proprietary and only accessible or editable by those who developed it (and those who pay for a license to use it). Making something open source allows the code to be publicly available to any user, who can either use it as-is (usually for free), or make changes to it for their own projects.
Plugin
A plugin is a piece of software code that acts as an add-on to a website, providing additional features or interactive elements. They can be free or require payment for use. Plugins are designed to provide functionality "out of the box" and can be later customized by developers to fit specific needs. While plugins can be a convenient time-saver and enhance a website's function, they do need to be inspected to ensure they don't interfere with other code on the site, and require updates for maintenance.
API
Another acronym coming into play: API, or Application Programming Interface. APIs are go-betweens for software that allow two separate applications to communicate and share data. They are on a wide spectrum, but modern usage generally refers to any connectivity within an application. For instance, commenting on a social networking app uses APIs – when you contribute your input, the app server interprets it to show it as data. Besides serving up information, APIs are valuable because they only share smaller pockets of data, never fully exposing a device to an app server and vice versa.
Asynchrony
Have you been on a website that pulls in live data as it is posted, rather than having to keep refreshing a page to read the new information? That’s an example of asynchronous data pulling. Sites that take in a lot of input rely on an asynchronous setup to process requests for viewing without reloading the whole page each time new input is published. Besides providing a more seamless, info-rich user experience, asynchrony also promotes better responsiveness and site load time.
Finalizing & launching
Security layers
You may notice some URLs start with “https://". This is an example of a security layer, or security protocol, used for encryption on websites that require a login or have sensitive user-identifying areas. Since personal information is being submitted, security layers make sure that only the device that you're using will be able to recognize your data, preventing outside users from viewing it. These layers of security protocol are certified, so they are regularly renewed on a website to authenticate its security.
Cookies
You probably know that these types of cookies don’t come in flavors like chocolate chip or snickerdoodle. In computing, cookies are data files that contain points of identification for a user, such as a username, clicking patterns, or a saved shopping cart. Cookies are unique to each user, and built to give them a more customized web experience. This information is stored between your device and the server of the website you visit. Sites now readily ask permission for users to approve of this tracking, especially since it’s a large factor for targeted online advertising and identifying user habits.
Push live
When all the code is written, testing has been wrapped, and the site has been approved, the last decision is when to push the site live: aka making it available for public viewing. This is the last step of a launch plan, after all other factors have been checked off, since pushing a site live means it’s officially out there for the world to see!
The big takeaway?
Website builds can be complex projects that require a lot of moving parts. But one of the keys to a successful web launch is the ongoing collaboration between teams. Even if you’re not the one developing the site, these definitions can provide better context along the way. Projects often have learning moments throughout their journeys, so we hope this piece can be a quick cheat sheet to some back-end development lingo.
After all, web projects should be accessible and collaborative – that’s the goal we strive for at M. But that’s only possible if we’re all speaking the same language. And since the digital space is constantly evolving – with new features, new trends, and yes, new terminology – it’s essential to evolve along with it. Stay tuned for our next chapter in the Decoding Dev Speak series!