I have a feeling that the stuff you learn riiiiight as you are getting into all this making websites stuff sticks with you harder than what you learned, say, yesterday. That stuff, whatever it is, feels like foundational knowledge that ingrains itself. Other things you learn are in relation to that foundation.
As such, it matters what educational material starter-outers are exposed to! That’s why I’m a fan of early courses from long-timers like Geoff and Blake or the free Frontend Masters Bootcamp. I’m also encouraged when actual university courses run with really solid foundational knowledge. For example, Cyd says they teach progressive enhancement to their students getting an Associate Degree in Frontend Design and Development at the University of Applied Sciences in Amsterdam.
We teach our students to build features in three steps:
- First determine the core user task, and implement it in the most robust way possible in HTML
- Layer on additional capabilities with CSS
- And finally (optionally) add JavaScript when the browser allows (or needs) it
A classic:
Filtering, for example, is usually treated as a client-side interaction problem. But at its core, filtering is really about narrowing down information. And HTML already gives us a way to do that natively: a form that submits a request and returns a refined result.
I tend to agree that filtering is a good concern to make server-side first. And that is what this is saying. HTML can’t do filtering alone; it can just submit a form to a URL (effectively reloading the page with query params) that can ask a back-end language to return filtered results. In a way, this approach is saying: it’s also possible the HTML doesn’t even contain all the data you want to filter. The server has better access to that data, so let it return the filtered data.
I hadn’t really thought of it this clearly before, but leaning into progressive enhancement, while it feels like an approach taught to front-end developers, is really a technique that leans heavily on back-end developers. Or a full-stack concern, as it were.
I also kinda get why some groan at the idea. Like if you’ve got a <table> of the 10 movies Paul Thomas Anderson directed, adding filtering and sorting to that table is a handful of lines of JavaScript (perhaps), which feels much less daunting than designing an API of sorts to handle the work on the backend, and having it refresh the entire page to do the work, which feels a little antiquated. But if you do it the right way and give yourself that API, now you’ve got a re-usable system for displaying, say, the 5,241 films ever nominated for an Oscar as well. Websites tend to grow and change in scope, which is another lesson to learn. So is premature optimization, but I digress.
I’ll let Kilian do that instead, with Programming principles for self-taught front-end developers.
It can be very tempting to optimise the code right from the start, making sure each line is fast and efficient. Often times though, the fast and efficient code is not the most readable code.
When it comes to writing code, we don’t actually spend that much time writing. Instead, we spend time reading the code we just wrote, or that already exists and reasoning about it to decide what to write next. So the easier it is to read and reason about the code, the faster we can write the right code.
Maybe that’s a good lesson to learn early on: start by making code very readable. The move through the classic steps:
“Make it work, make it right, make it fast”
Kent Beck, the inventor of Extreme Programming.