Cody Jackson
What’s the difference between back-end (BE) programming and front-end (FE) programming? For that matter, why does it matter? These are key questions many people thinking about getting into coding ask themselves and I will try to answer them on this page.
To start, BE programming focuses on server-side or console-based applications, i.e. things most users don’t want to deal with. FE programming involves a graphical interface of some sort, whether a normal desktop program, a web browser, or something else besides a text-based interface.
For purposes of this article, I’ll define BE as anything that doesn’t have a graphical interface, i.e. browser, app, or desktop GUI; I also consider FE to be primarily web development, unless otherwise indicated.
Also, I’ll state that everything here is my opinion, based on my experience. I’m a self-taught programmer who spent ten years as a hobby-developer before I got a full-time developer position, so my world-view will be very different from someone who has a CS degree or otherwise started programming after graduation.
My Personal Programming Story
I’ve spent most of my programming years in BE development. While I am familiar with FE development, it is primarily via older tech, i.e. pure HTML/CSS web sites, legacy GUI frameworks, etc. I just don’t have a need to do a lot of FE development. My current job is making computer models and simulations; the software is either a network emulation suite or pure Python code, so I don’t have to deal with making a web interface or GUI applications.
I actually started my self-guided journey by learning web development, HTML4, and hand-coding websites. After a few years of that, I enrolled in a computer engineering degree. Unfortunately, I hated it! As I learned C, C++, and J++, I didn’t understand object-oriented programming and the books jumped into it without useful explanations, and C (which doesn’t use objects) seemed to involve writing far too much “repeat” code to get things done, rather than having the data structures already available. By the way, this is one of the reasons C code is difficult to use to make secure code; it is very easy to figure a simple thing and create a vulnerability in the program.
Interestingly, I didn’t actually like programming until I taught myself Python years later. During the intervening years, I tried to learn PHP, and could make basic, interactive web sites but since it wasn’t my full-time job (I was in the Navy at the time), I didn’t bother trying to make extensive sites.
Nowadays a lot of development work is FE-based. With the bump to HTML5, a lot of tech were replaced, such as Flash, leading to more functionality via web browsers. This moved desktop programs to web browsers; it’s now common to find web interfaces in a lot of devices, particularly embedded systems and IoT devices. This is why a lot of companies look to hire FE developers; it’s quicker, easier, and uses less resources to create a lightweight site than to create a fully-functional desktop app.
I prefer to be a BE developer as I find it easier to work with and also because my hobby projects are text-based apps. But there’s a lot of new advances in FE development, like JavaScript ecosystem and web frameworks; like many things, it’s easy to have knowledge of both FE and BE, but many end up specializing in one or the other because of the specific knowledge required for each type. However, FE programming can be easier because the tools and web frameworks cut down on manual coding.
Next, I’ll explain the differences between these two and why you should consider concentrating on becoming a software developer for one or both.
Why BE Is Actually Easier to Work With
I find BE easier because I have to code something once. That’s the most important thing. Yes, FE development can be done once too, but my current mode of operation is to finalize all the logic on the back end, with whatever user interaction required set up via text console, i.e. non-graphical prompt, like a Windows DOS prompt or a Linux BASH shell. This allows me to make sure my logic works, whether through automated tests or simply writing code to verify my expectations.
Once I’ve confirmed the logic works the way I want, it’s easy to slap a graphical front end on it. The existing variables and functions can be called by the graphic wrapper code, or used as input/output for HTML, with little modification or new functionality required. This way, problems are segregated to either BE or FE code.
FE programs can be difficult to troubleshoot because problems can be found in my code, in the web framework, or in any number of places. For example, is the lack of a response to the screen because I am not accessing the variable correctly or is it because the variable isn’t getting the correct data? Is the problem related to database queries or the actual I/O connections?
This is even more frustrating if you are using an online code library, which is common with JavaScript or other web technologies. While it could be normal Internet connection problems, it could also be because a critical library was removed or broken, such as this example.
For some people, like a full-stack developer who works on FE programs more frequently, some of these issues are trivial to fix, or possibly even non-existent. But I don’t do this every day, so jumping right into FE development without clarifying the program actually works is harder for me.
That’s not counting the fact that most FE web development today is handled by frameworks and rarely is the raw HTML touched directly, except for template creation. This means that FE developers are much more reliant on their tools and libraries working correctly than in the past, when they hand-coded everything with HTML and CSS, and maybe a sprinkling of JavaScript for user-side interaction. A bug in a development tool may be unnoticed for some time, causing users to be frustrated if the site doesn’t work correctly or leaving a vulnerability for malicious use.
As a Python developer, I have some experience with Flask and Django frameworks, but doing anything beyond making a basic blog is beyond my immediate capabilities. By that, I mean that I would have to spend a lot of time looking at the documentation and searching the web to figure out what to do if I wanted to make a wiki or file repository, for example. For a FE developer, these may be trivial elements, but it’s not in my muscle-memory.
On the other hand, when I work with FE developers, they often don’t understand the logic required to make actually make a program “work”. A web framework is an abstraction of the development process; rather than manually writing the HTML and associated code to create the site and make it interactive, the framework hides a lot of that functionality behind easy-to-use function calls. All the FE developer needs to know is what the necessary command is to perform the desired action.
Web designers can get the framework to talk to the components they need, such as pulling data from a database and populating a web page, but they don’t fully understand what is happening. The framework hides a lot of the transactions and back-end logic behind the easy commands; as long as the correct command is used, the results are generated by the system.
A good example a labor-saving toolkit is SQLAlchemy. It acts as middleware to translate Python commands into SQL queries. In many cases, it isn’t even required to know what the SQL command is, as long as the Python commands are written in the necessary way.
This type of tool makes it quicker to make sites that communicate with databases, as the developer doesn’t have to know the exact SQL query required for a particular database. It also means a SQLAlchemy-powered site can be easily moved to another back-end database; the only thing required is to change the configuration file so SQLAlchemy knows how to talk to the new database.
I’m not saying I’m a database administrator who can spontaneously create the correct SQL query. But having the basic working knowledge of database queries using a development database and being able to test program functionality without having to use middleware can be a useful skill. It may not be required that often, but much like knowing how to do math on paper, there are times when it may be necessary to get the job done (like for a job interview). Of course, frameworks, toolkits, and similar developer tools greatly enhance development speed and generally makes life easier, so I still recommend using them when possible. Just know what is going on in the back-end; it can help when troubleshooting if you can figure out what results you should be getting vs. what you really are getting.
I’m probably sounding like an old “neckbeard” who believes programmers need to start with C language and learn from there. Far from it; I learned Python after struggling with C, C++, and Java, and you can pry my Python from my cold, dead fingers. The same could be said of any of the newer languages: JavaScript, C#, Ruby, et al. They improve on the functionality of older languages and, in some cases like Go, could actually replace C/C++.
The key point is knowing what languages work best in a situation and then choosing the language most preferred. However, a lot of people who go to programming bootcamps or otherwise focus on FE development don’t get a lot of exposure to non-browser-based technology.
More than Just a Website: Prepare Yourself Fully with Full-stack
Many questions I see on online forums and the like are from people who want to know what they can do with a CS degree or are tired of their regular programming job and want to do something else. Unfortunately, a majority of answers are FE-related. While I will admit that a large number of jobs currently on the big job sites are FE-focused, you are limiting your job opportunities if you focus just on web development.
Even desktop GUI development requires knowledge of BE coding because, essentially, the GUI is simply a wrapper to the back-end code. A simple dialog box that asks the user to input an IP address, port number, and a “submit” button is nothing more than a pretty interface to the exact command-line calls to submit the same information to the operating system. If the developer doesn’t know how the OS accepts input, processes the data, and returns values, the GUI is worthless.
When it comes to web development, however, you can be a successful developer without ever knowing what’s going on behind the scenes. I can’t say it makes you any less capable of a programmer, but the ability to transition from FE programming to a non-FE role can be difficult for some people who don’t know how to do any BE development.
There are a lot of “hidden” programming jobs that require BE knowledge but aren’t glamorous. For example, a lot of industrial programming is BE-oriented, simply because industrial processes tend to not require a user interface; the data is generated and transferred between systems. Only at certain points does a user need to interact with the system, and a lot of the time the UI is simply a dumb terminal that displays the data running over the wire, such as system flow rate. Some examples of this include power distribution, assembly lines, water treatment, petrochemical operations, etc.
Why Full-stack Knowledge is Good in Today’s Job Tech Landscape
As many legacy programmers retire, these “hidden” programming jobs will open up and an FE developer may not have the knowledge required to do the work. The paradigm shift in knowledge between making a browser display data from a database is different from knowing how to make a conveyor belt talk to a warehouse server and an engineering workstation.
One paradigm shift occurring in the industrial control sector is the move from proprietary human/machine interfaces (HMI) to more open standards. In the past, controller manufacturers created turn-key solutions: they provided the controllers, the training, the interfaces, everything. If you wanted to make an industrial process, you picked a solution based on the vendor, not on the technology and didn’t “roll your own.”
In Europe, it’s common to find industrial controllers built from Raspberry Pi computers and an HMI that utilizes HTML/CSS/JavaScript, as opposed to custom-built hardware and software. Thus, a company can purchase 10 Pi-based controllers for the cost of a custom model, and can make an HMI in-house, rather than spending thousands of dollars for specialized training.
With this situation, a developer could focus on BE programming, in building the logic that allows the controllers to do their job; FE programming, by developing custom HMI software, or somewhere in-between, by taking a pre-built HMI and identifying the controller “tags” that need to be monitored or manipulated through the HMI.
In summary, I would say that, as a programmer, it is important to know both BE and FE programming, even if you don’t expect to ever need it. You never know what opportunity may land in your lap.
Learn both by applying to App Academy.
