Imagine what a large-scale web project would look like if frontend development were not treated as an add-on, but as an equal partner with backend development and content strategy. This practical book takes experienced web developers through the new discipline of frontend architecture, including the latest tools, standards, and best practices that have elevated frontend web development to an entirely new level. Using real-world examples, case studies, and practical tips and tricks throughout, author Micah Godbolt introduces you to the four pillars of frontend architecture. He also provides compelling arguments for developers who want to embrace the mantle of frontend architect and fight to make it a first-class citizen in their next project. The four pillars
I think the title of this book could be: "what I learned and experienced during developing Redhat's design system"! I think the writer just wanted to share his knowledge and experiences with others briefly.
This is a case study detailing how frontend team tried to make the best of their situation in an organization with systemic problems in how they approach design, frontend and development - as in, corporate hell with silos, where graphic designers design things completely out of touch with platform used on the backend, project manager/owner refuses to fix communication and also refuses to address legitimate issues with wrangling the code to achieve something similar to design mockups, and frontend team has to hack their way through all this without affecting anyone else in the organization.
If you work in similar environment (maybe bail out) the book may help illustrate how to smuggle in some standards and best practices into your codebase, but the tech stack is very specific and won't be much actionable help.
This book is NOT about different frontend architectures, design systems, and ways to organize work - it's just a case study. Arguably most of the problems could have been fixed if designers and developers could / were allowed to communicate. (This book treats design mockups as something saint that can't be questioned and changed - that's not healthy.) Other than that... It's nothing groundbreaking. It's just bridging the gap between old style frontend development (think 2000-2005) and new (2015+). Maybe I'm judging this too harshly - I'm fortunate enough to work in a company that supports better collaboration and effort- and time-saving tools, for everyone - but please, a lot of frontend architecture depends on things that start NOT on frontend. If design is mucked up (not even by designers' fault - there's high chance they're working on incomplete data too), if it doesn't match the backend, heck, if the project itself is not suited for the platform chosen by someone higher up... then your frontend architecture will be at best an effort to put lipstick on a pig. And/or delay the moment when developers run away screaming.
The author boxed themselves in the frontend slice of the pie, without consideration that a project is a team effort. As a case study, it's ok. But I can't recommend this to anyone, because there is not one word of warning that the situation here is very specific and NOT something desirable (maybe they couldn't say this - still, can't recommend a book that doesn't challenge communication issues and thus indirectly promotes siloing). AND it's just one specific tech stack.
Some good thoughts, a little outdated and some things were much too specific about the implementation on Red Hat and not enough about the process they took to make the decisions they made which is what I'm after at the moment. Going to look at Professional Front-end Architecture next.
This book will let you know about plenty of ideas and thoughts when working on front-end projects. What I liked the most are the chapters about Performance Budget and Visual Testing. However, I felt bored sometimes because of explaining code blocks line by line, or telling stories about issues for a specific website (Red hat) which I really don't care about (Sorry). For example, I don't need to read 2-3 pages in order to understand how Pattern Lab works, I can simply google it and read the entire documentation.
The book is outdated by now but many of the things described in it came to pass in the last few years. Even so, we're still not in a place where a majority of companies are organized to 'architect' their frontend as described here.
For new developers there's some interesting history about how some frontend tools and processes came to be historically speaking. There are plenty of useful pointers towards how to setup a team’s way of working: testing, deployment, documentation and project management.
For me, testing was the most useful part and the Red Hat design system examples most difficult to follow.
it is good to have this kind of books to remind the important pillars of front end architectures. The book just covers a scenario and more focused on CSS and styling. However there are plenty of different JavaScript frameworks and one approach that works perfectly cannot be applied to others.
There is much common knowledge about setting up frontend development (might be too long, I believe it can be shorter). It helps me understand OOCSS, SMACSS and BEM. I would like to see more details and practical example.
A good example and breakdown of the project in RedHat. However, certain examples and technology are fast evolving, with some tools being verified in 2024. I believe this work is appropriate to be read before 2020.
For folks with extensive software development experience, most of the content will seem common sense/knowledge. Even so, they may find interesting new bits in the book. I found two bits to be interesting: 1) the list of automation tools mentioned in the book and 2) explicit exposition about how common software engineering best practices are applied to front-end development.
My biggest qualm with the book was the term "front-end architecture" used in the book was a misnomer as architect/architecture was defined/described in relation to the process and tooling used to build a system and not the overall structure and organization of the system/building (traditional notion of architecture). I thought the book was dealing with software engineering best practices being applied to front-end development.
A good starting resource for intermediate front-end developers who have no extensive software development experience.
A slim, clearly written book for experienced professional web site developers, making the case that following the principle of "Separating container from content" makes it possible to create properly modular front-end web code. You should know web development arcana such as Twig, OOCSS, Sass partials, wireframes, bands, and heroes before reading this book; the author relies on terms such as these without a word of explanation and if you are not already part of this milieu it would be extremely hard to follow the story.
Quite interesting book about modern frontend architecture approach. Mostly covers topics related to CSS (modularity, testing, performance testing e.t.c). But it's book gives you quite brief overview without going deeper into the details.
It's more of a cook book detailing the circumstances the author had to overcome and the solutions he arrived at. I liked the overview, although it was mostly concerned with the build tools that the author preferred using.