Reviewing

The students completed a 3-day front-end assessment recently, which was subsequently marked, and reviewed with each student's fork. It was a labourious experience, but I hope all the students came out of it feeling better equipped for the future.
We're now continuing on the project to practice our front-end skills, and use it as an opportunity to learn new skills too.

A new week, a new technology or three

We are now into month 5 of CSS, feeling relatively comfortable, but the curriculum threw a new curveball: Sass.

I had some proper cringy moments trying to get the students up and running with node-sass, explaining how the JavaScript ecosystem works, and how easy it is to get any Node-based project up and running. *cue smirk*

Watching the students navigate the node package quagmire was gut-wrenching. I was reminded of my own encounters with Node.js unknowns and the difficulties they introduced. To make it even more troublesome, the students are all using Windows 10, which has its own idiosyncracies we have to deal with.

But with many explanations and back-tracking on wrong-turns, the students and I managed to get Sass to watch a directory, and compile our SCSS files. [Can you hear the angels singing?]
In doing so, we have to navigate those introduced hurdles such as having to restart our watch script every time we add a new SCSS file to the mix.
A few of the students asked why all this was necessary, when they could achieve what they needed to with vanilla CSS. Factoring in CSS Custom Properties, and the forgiveness of the browser, I saw their point… but they hadn't seen the potential Sass (or any transpiler for that matter) has to offer.

After having converted all their existing CSS to SCSS, some insights started to drop. Sass was checking their CSS for validity, something the browser and editor let slide.
The lights came on when they could link the max-width value of a containing element to a breakpoint that would reshape that element.
Or, when they could generate all their @font-face declarations from a Sass list.
Or, when they could start using @mixins, abstract classes, and @functions to express all their intentions through code, rather than keep it bottled up in comments or worse, their minds.

It's fantastic to see the students applying their new programming tricks to things like CSS. Some of them are even relieved that they don't have to do so much typing as they would with traditional CSS.

The knowledge gap

As the assessment shows, some of the students are falling behind. Those students with poor English skills mostly do poorly with front-end disciplines too. And, as we pile more technologies on, the gap widens. We don't have the time budget to offer remedial classes.
How do teachers deal with such experiences?! I can see some of our students struggling, but it feels like I can't help start that spark of insight they need.

Front-end is knowledge first, logic second.

I see the maxim Quick to start, Slow to Master at play each day here when the students work on the front-end aspects. They have to build up their experiences, and pave those knowledge pathways so that they're better equipped for similar challenges in the future.
They have foundational knowledge, but it's going to take years before they're comfortably and confidently working on front-end projects.

I can see how HTML and CSS are often overlooked by other developers. With a small cost of time and effort, you can learn most of what the two languages offer, which comes saddled with misplaced confidence. You could cover 80% of this tech with 20% of the effort, but the real benefit is in the last 20% of the tech. The first 80% is just outputting code, the last 20% is coherency, resiliency, and synchronicity.

If the various web technologies were instruments, then surely the Front-end Developer is the conductor.
*hands waving*