What's a Framework?

Last time we talked about what is meant when a web app developer talks about ‘the stack’. I had some great feedback from readers including:

• How do you know which stack to pick for a project?
• What is meant by the term ‘framework’?

These are great questions and I’m going to give my answer to both, starting with the second this time around as I believe it will give additional context for the first.

I love getting feedback and questions so let me know your thoughts or if there is anything you’d like me to cover in a future article. You can find my contact details at the end.

Managing Web Pages

In the purest and simplest form, web pages are text based files written in a format called HyperText Markup Language, HTML for short. HTML itself isn't a programming language, because it can’t automate anything; there is no way to add logical control structures to change what is displayed using HTML alone. It’s a bit like a Word document but for the web.

Open up your favourite browser, navigate to a webpage and right click selecting ‘view page source’ to see the raw HTML the browser interpreted to render the page content. If you look at a few you will see it can get pretty, pretty complicated.

The limitation of using HTML on its own, is that every page on our website, even if our site is a blog with hundreds of posts, requires its own corresponding HTML file on the server. One option is to type in every single HTML page manually in a text editor. That's a heck of a lot of work and there’s a ton of duplication assuming all your blog posts will share the same page layout and design. Not to mention the absolute headache, you'd have if you ever wanted to update the blog post design or layout. You'd have to go through and apply the same changes to every single blog page 🤯. And what about the page where you list each of the posts individually? You’ll need to manually keep that up to date with all the latest posts. Bit of a pain in the neck. As we’d say in technical terminology, it doesn’t scale, because the bigger your site gets the less feasible it is to manage.

Copying and pasting code between projects might seem an easy solution initially, but we're inexorably on our way to a hot mess

Instead of all this effort and duplication, we could generate our blog page by squirting the bit of content that changes into a blog post template, which contains all of the repeated layout HTML. That way we only need to write a single template file which is far more manageable to maintain and scales much better. This is where a back-end programming language comes into the equation.

We can tell our HTTP server on the back-end, waiting for requests for HTML pages, that when a browser asks for a blog post page, instead of sending them a specific hand-written ‘static’ HTML file we instead want it to use an interpreter like PHP (or Node, Python, Ruby etc.) to run a program we’ve written to dynamically generate the HTML to be sent.

Back-end programming languages can do all sorts of useful things, like opening [template] files and storing their contents in memory, connecting to a database to retrieve content for the blog post being requested, then combining the two together and outputting them as a complete HTML document. We can also use them to query (ask) the database for a list of all the published blog posts then dynamically generate the post listing page too so we don’t have to worry about doing it (or forgetting to do it).

Managing Back-End Code

Now, believe it or not when building a modern, dynamic web application, whether that’s a blog, e-commerce site, some sort of social media application, B2B service or back office system there are a heck of a lot of these type of things that you’re almost always going to need to be able to do; connecting and communicating with a database, rendering HTML pages using templates, taking steps to prevent content containing security exploits from dodgy commenters, handling input when a user submits a form, sending email, talking to data services over the internet, handling authentication (logging users in), and on, and on.

While back-end languages provide rudimentary utilities which can be combined to do these kinds of things out of the box, the reality is, it’s still a huge amount of effort. Not only do we have to worry about accomplishing the tasks we set out to, we also need to understand all the potential security vulnerabilities we might be introducing into our application and take steps to mitigate them. We also need to spend time figuring out how this code project should be named and structured; the architecture.

Imagine now that we need to build another web app which needs similar functionality. So we copy and paste the code, tweaking a few lines here and there to suit the requirements of the new project. As the projects evolve we can continue to modify our existing code and copy useful bits between projects as they are required, right?

Copying and pasting code between projects might seem an easy solution initially, but we're inexorably on our way to a hot mess. Imagine we’ve copied, pasted and tweaked the same back-end code across tens of different projects then one day we need to make an urgent security update to the code we’ve copied, now running on live client sites.

Is there an audit trail so we can find all the projects the code was copied to? Probably not, so we need to search through all our projects one by one 🤦. Depending on the size of the projects that might not be so straight forward. Once we’ve identified affected codebases we need to manually apply our updates to each, again by copying pasting and tweaking. The problem gets further compounded the more sites we have, and once again we’re hitting a scaling issue.

These scenarios are the tip of the iceberg but you can already see how this approach isn’t going to work in any kind of professional environment.

Libraries & Frameworks

All contemporary programming languages have a way to package up bundles of code so they can be easily installed into different projects from a centralised location usually called a package repository. Examples of these are NPM for Node (JavaScript), PyPI for Python, RubyGems for Ruby and Packagist for PHP.

This enables developers to use the same, reusable chunks of code in several projects without having to copy and paste. They can also collaborate on sets of code utilities with the wider open source community via social coding sites like GitHub then distribute them using these package repositories. Commonly, collections of reusable code utilities are know as libraries.

The built-in program which developers use to install these packages is called (drum roll 🥁) a package manager. The package manager can quickly add code packages to a project, tell us which ones are already installed, update them if the publisher has fixed some bugs or made a security patch as well as remove them if they are not needed anymore. The key here is the automation; cast your mind back to our copy-pasted security update horror scenario 😱 and you can imagine what a difference this makes.

So that’s helped solve one of our problems. However there are a huge number of code libraries out there and, building our complex web application, we’re going to need tens if not hundreds of them depending on how complicated the application we are developing is. Aside from the fact that each will almost certainly work in a slightly different way there are other pitfalls to consider such as license compatibility and whether the library developers should be trusted / are likely to be maintaining their package in a few years. We’ll also still have to spend time on all those architectural decisions around how our application’s code will be structured.

Finally, this is where frameworks come in 😅.

Think of a framework as a kind of project kickstarter with a particular goal in mind, such as building a web application. A curated experience for getting things done. All the hard work of deciding which libraries to use and what the code architecture should be has been taken care of. They usually prescribe where to put code to achieve certain types of things and provides base templates for the common things every project of this type needs to do. The framework curators have spent time creating their own ‘glue’ packages to make sure that there’s a consistent way to get things done using a ton of underlying libraries.

The trade-off is, that [as developers] you need to do things in the way the curators have prescribed. Given frameworks usually represent thousands of hours of open sourced software collaboration by many experienced developers, often experts in their fields, following agreed best practices, it’s hard to pragmatically argue against using them.

Examples of popular web application frameworks are:

• Laravel (PHP)
• Express (Node JavaScript)
• Django (Python)
• Ruby on Rails (Ruby)

As Taylor Otwell, the creator of the Laravel [PHP web application] framework describes it:

Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small things.

I think that says it all.

Wrapping up

I hope this has helped make some sense of what a framework is! Next up I'm going to look at answering the feedback question:

How do you know which stack to pick for a project?

Look forward to seeing you in a couple of weeks. Once again, any feedback or stuff you'd like explained in future, tap me up on the contacts below 👇.

Joby Harding is a web app engineer and consultant with 15 years industry experience. As a youth he played with photocopiers.