Clean Code In The Browser
Buy the entire series and save $12 (streaming) + $24 (download)!
5. The Interface Segregation Principle
By Chris Powers, 1h 16m

Clean Code in the Browser, Episode 5: The Interface Segregation Principle

Our "Paintastic 2000" software is selling like hotcakes, but now the bosses are asking for more features than ever. Our code is bloating – fast! We need new strategies to keep our code slim, decoupled, and legible as the app outgrows its original abstractions.

This time, Chris Powers calls upon the value of the "I" in SOLID: the Interface Segregation Principle. At first blush this principle might not seem to offer much value in JavaScript. After all, how can a language without interfaces possibly benefit from the Interface Segregation Principle?! Thankfully Chris is able to demonstrate to us how this principle genuinely applies to JavaScript, both in metaphor and in live coding.

Along the way, Chris explores the misleadings of multitasking, the focus of flow state, and the gravity of Gantt charts. Software development teams can make huge gains not just by changing the quality of their code, but also by improving the quality of their time. Chris discusses the intrinsic motivators that power our best work, and leaves the audience with a single plea: "Stop multitasking!"

Oh, and he re-organizes his garage. It makes sense, trust me.

So join Chris (and the voices in his head) in this fun episode to improve your SOLID skills and encourage quality engineering on your team!

4. The Liskov Substitution Principle
By Chris Powers, 1h 10m

Clean Code in the Browser, Episode 4: The Liskov Substitution Principle

It's all fun and games until an angry Enterprise customer calls demanding new features and expecting them now! Hopefully, a dollop of React UI code and a dash of SOLID principles will get the job done before the weekend arrives.

In another entertaining and informative video, Chris Powers discovers the importance and implications of the "L" in SOLID: the Liskov Substitution Principle. This principle tends to be the most overlooked and misunderstood of the SOLID principles, and it's not immediately clear how it applies to JavaScript. Yet after some digging, Chris discovers that LSP may just be more meaningful to developers using dynamic languages than to developers using static types!

Along the way, Chris dives into the topic of identifying and managing complexity within our software development process. He uses the Cynefin framework to distinguish between "complicated" and "complex" problem domains - turns out they have dramatically different paths to success! He draws on inspiration from drum circles and orchestras to equip us to apply Agile principles to our ever-changing projects.

Join Chris (and his host of characters) to level up your SOLID skills and to raise the quality bar on your team!

3. The Open Closed Principle
By Chris Powers, 1h 25m

It's 4:55 pm on a Friday afternoon. You're packing up your things to head out for the weekend when suddenly the phone rings. It's the boss. Don't worry, they only need "one little change"... shouldn't be too bad, right?

Join Chris Powers in this fun episode as he desperately tries to get home on time while discovering the benefits (and challenges) of using the "O" in SOLID: the Open Closed Principle. This episode specifically hones in on applying the technique to browser code in JavaScript. Through a series of poor implementations and subsequent refactorings, we learn how the Open Closed Principle helps reduce code churn and improve maintainability by making it open to extension but closed to modification.

Along the way, Chris explores the topic of production incidents and how leading practices should (and should not) be used while systems are "on fire". He also discusses the importance of team collaboration, the hidden danger of Lone Wolves, and the critical nature of building shared understanding and expectations within software development teams.

2.2. The Single Responsibility Principle
By Chris Powers, 53m

"Clean Code in the Browser" Episode 2 Part 2 picks up where Part 1 left off by implementing changes to a code example using the Single Responsibility Principle and Command Query Separation.

Next, we learn about the benefits of "Taco Bell Programming", discovering how it can be used in a JavaScript environment with functional composition techniques.

We talk about applying the Single Responsibility Principle (or at least its spirit) to HTML documents and template files. Using several code examples we see how HTML code can be clarified by focusing on a single job for each element.

Finally, we finish the episode by applying SRP to our CSS. By carefully using SRP-inspired naming conventions and techniques in our CSS, we prevent collisions and improve the robustness of our styling code.

2.1. The Single Responsibility Principle
By Chris Powers, 54m

In the first part of "Clean Code in the Browser" Episode 2, we start talking about the "S" in the SOLID Principles: the Single Responsibility Principle.

First, we discuss the meaning of software "best" practices. Everyone knows those are the practices that we're all supposed to be using, but is that always the truth?

We dive into the Single Responsibility Principle, identifying what it means, why it matters, and how we can apply it specifically to JavaScript. Picking up from some code we started in Episode 1, we use SRP as our guide for refactoring code structure and finding the right place for each piece of logic to live.

Finally, we explore how Command Query Separation can be a complimentary technique to SRP for reducing the scope and role of individual methods and functions. We work our way through another code example, finding opportunities to use both SRP and Command Query Separation to avoid code churn and cohesion.

This episode had so much content that we had to split it into two! Be sure to check out Episode 2 Part 2 for more insights into how SRP can help you write Clean Code in the Browser!

1. Clean Code In The Browser
By Chris Powers, 1h 20m

The Web has been a dominant platform for over twenty years, but over that time code quality has been surprisingly low. An entire generation of developers came up through the ranks with a working understanding that front-end code was hard to write well, and harder to maintain over time. How did we get here, and how can we make positive changes towards quality in our browser code?

This new series is called "Clean Code in the Browser" and focuses on improving the code quality of our front-end code. In this first episode we look at how we got into this mess in the first place:

We start by exploring common pitfalls and patterns that lead to failure in Web projects.

Next, we go back through a brief history of quality on the Web since its inception, analyzing the forces that set the stage for poor code quality in front-end code.

Once we've looked at the historical forces, we move on to cultural forces. We talk about the division between front-end and back-end developers and how these rifts reinforce cultures where quality is not valued.

Finally, we will look at Client-Server architecture and how its role in the Web has shifted over the last 50 years. These changes have introduced architectural challenges to Web developers and make it more difficult to maintain best practices.