Ok, you’ve decided to keep going onto Level 2 — this is where it really starts to get fun and a little closer to the reality for most professional engineering teams in the field. First, let’s do a quick thought experiment to get your mind primed for the knowledge bomb currently fixed on your coordinates…
Close your eyes and imagine that you’re building a house. One option is that you can go out into the woods, chop down some trees, saw everything by hand, forging nails one-by-one in a fiery-hot cauldron of liquid steel, poured meticulously into individual molds. While you’d certainly earn a wilderness badge and maybe even some Instagram likes for your efforts, it probably doesn’t line up with how you’d likely go about building a house in reality. After all, you’ve other things to do in your life, and you just want a damn house.
Instead, you’re likely to buy perfectly precut wood from a lumberyard, nails from a home improvement store, and a myriad of other things already manufactured and ready to serve you in the process of transforming your vision into the reality that is your dream home.
With that in mind, anyone making modern software for the web rarely engages in the software equivalent of hand-hewing logs. Rather, they utilize the tools, parts, and pieces that other software developers have created and assemble them into the next hot dating site for 60-something quilting enthusiasts.
Let’s look at some examples of frameworks for the two browser languages we covered above,
CSS above, and if you recall, it gives an
HTML document a little visual flash and pizazz. In the simple example, we just modified the color and size of an
P tag. Still, if you think of the extensive styling that exists on most large-scale websites, you can hopefully appreciate the mountain of work involved in crafting something real-world and truly from scratch. There are things to consider, such as spacing, typography, colors, and every visual element that appear on the screen. Couple that with the need to work at various screen sizes and the maddening way in which various browsers decide to interpret
CSS, and you have a valid rationale for some good old-fashioned day-drinking.
To solve this, many great people on the internet have worked hard to abstract away the browser quirks, responsive breakpoints, and commonly implemented elements used to craft web applications.
Some commonly used
CSS frameworks you may run across are:
- Bootstrap - an opinionated and full-featured UI kit from Twitter, it contains typography, forms, buttons, navigation, and other interface components.
- Tailwind - designed to be customized and not a UI kit, but rather a bunch of utilities to help you get your own custom design system put in place.
- Foundation - a wide range of modular and flexible components, with an emphasis on using SASS
- Material UI - similar to Semantic, but adhering to Google’s Material UI design standards and focused on reusable React Components.
- And so many others…
All of these frameworks provide components such as form fields, base typography settings, and responsive grids you can use to bring your site to life across devices. What you choose is up to you and your preference, as many have opinionated styles, both visually and in how you plan to utilize them.
Many start with one of these frameworks as a foundation and modify and adapt it to their desired visual style or corporate design system. It just makes sense not to reinvent the wheel.
As we talked about before,
CSS, there are a ton of things to account for when creating a production-grade application that would make writing all your
If you think about most web applications, they all kinda do the same stuff. You’re filling out a field, searching for that thing, or scrolling through some table of data. You can break any web application down into a number of component parts, and many modern
In some ways, you can think of many of these frameworks as different collections of Legos. Some sets are extremely complete and have gears, motors, and pulleys…everything you need. Yet others are oversized and easy to use for a 4-year old. Each set comes with instructions for how the various component pieces work, but ultimately it’s up to you to put them together to make something cool and express your creativity. That’s the fun of Legos — following the directions for the first few times and then tossing the script out and making your own plane-boat-dragon-thing.
React is easily among the most popular
React such a joy to work with is the desire and aim that many of the components you create are intentionally dumb. They just wait for data to be passed into them, and they…wait for it…react…to that data and change themselves accordingly. This pattern ensures that you don’t have a spaghetti bowl of code to update everything on the screen when your data changes. The data simply changes, and each component knows what to do when it receives an updated payload of data.
Imagine that there exists a web application that contains a table/grid that displays, in real-time, the internet’s favorite episodes of Saved by The Bell. The outer Table would be a component, and each and every row could be sub-components. In
React, components are often a part of a hierarchy, like Russian nesting dolls of functionality. As the data regarding the world wide web’s opinion of A.C. Slater waxes and wanes in real time, new data could come into the app. When fresh new data comes in, the table may order itself accordingly, and the visible information in each table row (like votes, rating, or number of comments) would update accordingly.
This is in contrast to different paradigms, such as using (much) older frameworks like
jQuery would give you tools to fetch data, but then you would have to go through each and every element on the page, manipulating them directly to achieve the desired UI state. With declarative frameworks like
React, data is the source of truth, and things like updates happen much more predictably, and in many cases, automagically.
There are volumes and volumes of books and online courses dedicated to the plethora of
In an effort to give you the biggest bang for your click, here are the most common
- React - A small but mighty library (some would argue that it’s not even a framework) that helps you manage your view layer, that is, the elements on screen that your users interact with. React is almost always coupled with other libraries of your choosing to afford your application’s desired functionalities.
- Angular - A full-fledged framework with darn near everything built-in. Unlike
React, it has opinions on how you should do things, like making network requests.
- Vue - Very similar to
Reactas far as its focus (on the View layer, get it?), but
Vuedoes offer a few more ‘companion’ libraries out of the gates that can, to some, simplify development by limiting the number of decisions you need to make to get off the ground.
If I were to start trying to learn a
React hands down, especially when paired with things like NextJS or Create React App, which both make it dead simple to get an app off the ground. But, as with
CSS frameworks, you need to look at each one and dink around a bit to figure out which one meets your needs and speaks to you in a way that energizes your creativity.
If you want to be a cool, modern web nerd, please don’t use jQuery; you probably don’t need it.
At this point, you could easily spend the next few months or even years of your life learning and mastering the various frameworks mentioned above. That statement should not intimidate you, because I know you’re smart as hell and can learn anything, but I feel it is my civic duty to underscore the depth and breadth of many of these frameworks.
Another level complete! Now, take the dog for a walk, drink a nice warm cup of joe, and get ready to go one layer deeper…into the dark nether-realm known as the