Brad Frost

I'm surprised how much the personal standards I've built up working solo for many years align with these.

Regarding "Presentation-Specific vs Layout-Specific Styles," the way I've come to organize things is roughly "outside-in" i.e.: position, margin, border, width/height, padding, font/line-height, text styles. I also always put "display" and "box-sizing" first, if they're present, since they change the effect of several things that follow.

I disagree with "Prefer nested selectors ... only if both .foo and .foo .bar need styling." I prefer nested selectors always, mostly because it's annoying to have to go back and nest something later when you realize the container needs rules, too. Also I sense that there's something beneficial about the nesting of the (in my case) scss matching the nesting of the HTML, but that might just be aesthetics.

Also disagree with "Settle for a few (2-3) breakpoints and use those only," at least for the types of designs I have to work with nowadays. The prevailing style seems to consist of a series of striking, highly independent sections with their own internal layout (think the landing page of a typical, new open source project or startup, with a hero unit or carousel, a list of features in some number of columns, testimonials in some [other] number of columns, etc.). If you make each of those sections adhere to the same handful of breakpoints, either you carefully limit your design or you risk ending up with strange looking layouts in…

I have a long history of doing "community development" type work both online and off. And that includes being lead mod for an organization trying to make the transition to registered non-profit and volunteer work of various sorts over the years and so forth.

It's actually hard to communicate what I do. I'm sort of like the "mortar" person described in this article about trying to convey your job title: https://bradfrost.com/blog/post/job-title-its-complicated/

I do a variety of things and I know something about design and I know something about economic development and I know something about community building (the social fabric part of that) of various sorts and so forth. It's not you, it's partly that community development work tends to suffer from this problem that outsiders have no idea what "planning" (or "development") is and so forth and it's partly that I'm kind of a Jill of All Trades and I never quite know how to tell people what I do.

Thank you for that suggestion in your second paragraph. I have no idea how to do that, but that's terrific feedback and a great idea.

I'm currently short of sleep, but will try to make those changes at some point (hopefully soon-ish). That looks like a huge improvement to what I did and I will think some more on what I did there and how that got misinterpreted by you and how I can make it better.

I love how this article cites Brad Frost's "Don't Get Clever with Login Forms"[1], yet at the same time advocates specifically for doing one of the "don'ts" listed in that cited article ("don't split login across multiple pages").

Reading through Twilio's article, I still don't see a satisfactory explanation why they did it this way instead of just presenting both fields plus a list of buttons for other authentication methods (like what they even acknowledged to be the norm, citing examples like Pinterest and Twitch). If you're trying to dynamically choose the authentication method by looking up some preference associated with the user's email address, then you are exhibiting the textbook definition of overthinking the problem.

If users want to login with Google/Facebook/Twitter/Microsoft/etc. credentials, provide a button for it and call it a day. Those login methods will automatically (in all likelihood) provide an email address for your app to tie to its internal "user" representation (though you might have to explicitly request that particular permission in the OAuth or SAML or whatever flow).

[1]: http://bradfrost.com/blog/post/dont-get-clever-with-login-forms/

> Is someone forcing you to use it against your will?

I mean, kind of?

My problem with GraphQL isn't necessarily GraphQL itself, but with the sprawl of things creeping further and further into client-side code.

As companies are finding GraphQL to "unlock greater developer productivity", it's becoming more and more expected to have this in our toolkit as "front-end people".

There's been a few blog posts recently that I relate to. I feel like I'm at a point in my career where I could "knuckle-down and get good" but I don't actually want to get good at more and more endless technologies. I'd rather be able to define my niche specialization and thrive within that space.

[1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/

[2]: https://www.trysmudford.com/blog/i-think-im-a-design-engineer/

[3]: https://notes.baldurbjarnason.com/2021/02/20/the-layers-of.html

Are you referring to posts like this?: http://bradfrost.com/blog/post/my-struggle-to-learn-react/

"There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.",

The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.

With Android it's actually difficult as most boilerplates go obsolete in 2-3 years.

But basically copying functionality that takes a while to build.

1. Design system [1] that's integrated with Compose. Meaning blocks are built as part of other blocks.

2. Networking and caching - these can take half a day to assemble and debug.

3. Test integration. Easily days or weeks to do on Android, because dumb stuff like some misaligned libraries.

4. Dependency injection, also harder to set up the larger code gets.

[1] https://bradfrost.com/blog/post/atomic-web-design/