Check out a free preview of the full The Hard Parts of UI Development course

The "Introduction" Lesson is part of the full, The Hard Parts of UI Development course featured in this preview video. Here's what you'd learn in this lesson:

Will Sentance begins by discussing the goals of the course, which include understanding how user interfaces display content, manage data-binding, are represented in the virtual DOM, and can be optimized. Core principles of engineering, including problems solving, technical/non-technical communication, and programming experience, are also discussed in this lesson.


Transcript from the "Introduction" Lesson

>> In User Interface Hard Parts, we're going to explore, I think the most significant part of most of our experience of computers, of technology, that is through a screen that we are able to type at, to click, to swipe, to tap, to change what we see. And we are going to today build out an understanding of those user interfaces from scratch.

This is two simple goals to user interface engineering. One, display content on the screen such that the user can see it. And two, enable the user to go ahead and actually change what they see. It turns out that's it. We'll finish goal one within about 20 minutes. Unfortunately, it turns out goal two is profoundly difficult.

Enabling the user to change what they see, turns out to be profoundly difficult. However, we want to be able to do that because user interfaces are a vital part of the our modern experience of technology. And not least because I think we're going through a kind of a Cambrian explosion right now of technology.

Through sort of two parts, one I would say is like the normalization of tech, the rise of software engineering at the center of everything that we experienced. It was before centered around some of the big tech firms where Google's is water now. We're in a time where we have the JP Morgan's of this world hiring and talking to the founder tech elevator based here in the Midwest and absolutely phenomenal program, that they pay 600 engineers at JP Morgan.

This is the world we're moving to where tech is at the center of everything we do. On top of that, we have our wonderful friend ChatGPT, that is absolutely lining up, again, a explosion in the amount of tech, the amount of software that is gonna be out there.

I think all of that is gonna lead to a huge increase in the number of user interfaces we're gonna need to be building out, that is screens, that allow us to interact with that technology and change what we see and change the state of that technology. Okay, so in UI Hard Parts, we're gonna explore four parts, four hard parts of user interface engineering.

One, is going to be understanding how in the web browser this particularly ad hoc developed application creation environment. How we're going to even build the most minimal user interface? We're gonna require in that to understand JavaScript, how it interplays with the C++ runtime where our DOM is happening, where our event API's are defined.

We're gonna have to understand webCoRE WebIDL. A whole bunch of features just to even build out the most minimal user interface. Then in part two, we'll realize that at any significant scale, you're dealing with potentially 1000. Any sales or sales had 1000s of pieces of content displayed on the screen, all of which the user can interact with and change..

That is going to require some restrictions on how we write our code just to make our lives more predictable and easier. A vast amount of what we're doing in the hard parts of user interface is not gonna be intrinsically a kind of a truth. Only really part one, building a minimal user interface is gonna be a truth.

Beyond that it becomes moves by us. Here's my first catchphrase of the day. Moves not truths. One, two, three.
>> Moves not truths.
>> Excellent, everything beyond part one of hard parts is gonna be moves not truths. So efforts by us to make our lives easier as developers and part two, we're gonna introduce one way data binding.

An effort to limit how we as users can actually end up changing what we see to just via changing underlying data, and then a single function is gonna pull that data through and display it. Part two will then allow us in part three to actually present in JavaScript a visual representation of what is gonna show up on the page.

We're gonna start with HTML almost before part one and realize what a beautiful language it is. For displaying content is phenomenally intuitive. Just because it's simple, doesn't mean it's anything but phenomenally intuitive. So we'll start there with HTML. Once we get into JavaScript, it's gonna be profoundly unintuitive as to what shows up on the page, it will not mirror at all what's in our code.

In part three of hard parts, we're gonna build out a visual or a virtual DOM that does mirror what shows up in the page. And then finally, in part four, we're gonna realize that all of these gains come at a cost, the cost being performance. And if we're gonna build out anything that is sustainable at scale, we're gonna need to introduce some sort of efficiency measures, sorry, one of which will be state hooks.

Another will be a diffing algorithm, which is sort of clever code although as will be very, not clever, a very basic, a diffing algorithm that is going to ensure that we're only making changes to what the user sees based on what actually changed. All right, so here we go.

In UI Hard Parts we develop an under the hood understanding of building user interfaces in the web browser. There's me, there's my world, there's my wonderful nephew, Theodore, the lovely Theodore, there's my sisters, and here I think there's some principles of engineering. These are both we look for in candidates for code Smith, and what I think make just long term great engineers.

So we have firstly, problem solving. This is what we're really centered on today. If you can build out from scratch. The underlying mental model of what's happening in UI engineering, then you can derive from that all sorts of solutions to the new challenges that you face in your work day to day.

Then we have our technical communication. This is, can I implement what your mental model, myself via your verbal communication of it, perfect. Non technical communication here is the empathetic and supportive as every person talks through their code here, the endorsement of each other of that verbalization. And I think yes, in a sense, we're building out and under-the-hood understanding of how UIs are built.

That's our JavaScript and programming experience.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now