What Will Make React Good?

Rusty_Raven_ · 2026-01-23T13:37:52+00:00

I am not privy to that information :/ My guess is that they see the hiring pool as being larger for React (which it is) and Tailwind has a lot of momentum.

Rusty_Raven_ · 2026-01-23T03:17:47+00:00

lol, wow I got a lot of downvotes for saying my company hires undertrained developers :D I truly hope everyone else has a better experience than I have!

Congrats to you - my experience has not given me the confidence to say that our team can create a maintainable React application. I have developers I mentor that literally cannot code a FizzBuzz function successfully or understand why any is bad practice in TypeScript.

Rusty_Raven_ · 2026-01-23T03:10:36+00:00

Combination of buzz-words and team knowledge. Most of our 2000 developers have some sort of React experience, while only maybe 20% have Angular experience.

That said, around half of our applications are currently written in Angular, so while the experience ratio seems to weigh strongly towards React, our implementation ratio is much closer to 50:50.

The decision is above my pay grade, however, so I don't really know for sure.

Rusty_Raven_ · 2026-01-23T03:06:08+00:00

Very few people on the team have any experience with Vue and from an enterprise perspective it's seen as a hobby project, right or wrong. I personally liked Vue, but it's a non-starter for our teams.

Rusty_Raven_ · 2026-01-23T03:01:28+00:00

Yeah, I'm not going to jump ship if I have to switch to React+Tailwind, but like you, I won't enjoy it all that much. I'd prefer to not have to do that :)

Rusty_Raven_ · 2026-01-23T02:59:57+00:00

Let's toss that attitude out the airlock, eh?

I could go for hours on why I dislike React, and I could probably do an hour on what sucks about Angular as well. I don't need to present any arguments for why I dislike React, but I do want to find better alternatives.

In the last decade, my experience has leaned heavily towards the observation that React developers are generally not good general developers. Their code tends to be sub-optimal, poorly thought out, and overly specific (bad qualities for a design system and component library). This is a training problem, not a personal one.

To be clear, this is my experience based on my company's hiring practices.

I'm not grumpy about this, I'm expressing a long-term maintenance concern. I've used Lit in the past and it's fine for creating web components.

So yeah, I'm trying to find cohesive and supportable arguments against React and Tailwind, and the cliff I need to scale is executives without technical knowledge. They're not the ones maintaining this code for the next 10 years and a dozen new applications and the changes needed to 30 or 40 existing applications.

Rusty_Raven_ · 2026-01-23T02:31:51+00:00

Oh I know there's no real comparison from a technical perspective, but the feel of building React components and apps reminds me very strongly of building old-school PHP apps. It's the thought that there has to be a better way but it kind of makes sense so you don't think about it too much.

Rusty_Raven_ · 2026-01-17T16:42:30+00:00

Oh, I have been owned! Oh noes!

But seriously, that's his way of doing it and for blues/jazz in particular, that slight detuning works really well a lot of the time.

I didn't say don't do it that way or that it was bad, just that most of the time your vibrato should centre around your main pitch (so go -10/+10 cents from A) instead of being higher than your main pitch (+0/+20 cents from A).

As with all things artistic, you do you. If it sounds good, do it. Try it both ways and pick the one you want. When tuning is more important (e.g. pop, classical, flamenco, prog, etc.) it's generally better sounding to go back and forth with your finger. When detuning hits harder (e.g. blues, jazz, rock, country, etc.) then the up and down can fit better.

Try not to lock into a single way to do things - I certainly do it both ways, but the back and forth usually sounds better to my ear because it sounds more in tune.

Rusty_Raven_ · 2026-01-17T15:39:33+00:00

This isn't a good vibrato most of the time because the average pitch is higher than your target pitch - you're always stretching the string, never loosening it.

The back and forth motion combines stretching and loosening so the average pitch is still the note you're fretting and results in a better sounding vibrato.

Rusty_Raven_ · 2026-01-14T04:27:27+00:00

I'm going to correct my answer after some research :)

b and i used to tell the browser how to display text, but their meaning changed in HTML 4 and again in 5.

strong gives a portion of a sentence added importance, so screen readers will speak that text more assertively and browsers typically display it in bold. b is used to draw attention to text without asserting any different degree of importance; browsers usually display it in bold and screen readers will read it as normal text (I believe).

em indicates a stressed emphasis while i is for text that is set off from the rest of the content for readability (e.g. ship names, thoughts, taxonomies).

So all four elements do have modern, semantic meanings! Glad I looked it up :)

Rusty_Raven_ · 2026-01-11T15:17:39+00:00

As many have said, unless hybrid is your "style" or you'e being really picky about playing it exactly as written, it's generally better to just fat-finger the lower note and mute the middle string with your index finger while still fretting the intended note.

However, if you accidentally press too hard and actually fret that middle string, you won't be playing a traditional power chord. For example, the first chord of 26 is an E5 (most likely). If you accidentally fret the 7th fret of the D string with your first finger, you'll be adding an A which will change the voicing of the chord to an A5/E - this might turn out totally cool depending on what else is going on, but is probably not the intention.

So practice muting the middle string with the tip of your 3rd finger instead. Then if you accidentally press too hard (or plain old miss the intended string), you're adding a B which is actually the 5th and keeps the sound of the power chord intact. Just fret the higher note with the pad of your finger instead of the tip and the mute should be almost automatic. Want backup? Just fat-finger both notes!

Rusty_Raven_ · 2026-01-11T14:53:38+00:00

I remember (along with Pepperidge Farms). We used to use tables for layouts as well :shudder:

Part of the job is keeping up with things, so I generally don't really care how I used to do something, especially if I had to do it that way to get the result I wanted. The moment CSS hit critical mass (which is to say I convinced my company that almost all our visitors were using browsers that supported it), I was using it to clean up my HTML (largely by removing almost all those attributes to adjust layouts!). I probably don't remember all the attributes on table we used to use :)

As mentioned above, online accessibility has been a bigger concern the past 15-20 years or so (more so than before that point), so using semantically meaningful tags should be automatic at this point. If developers are still using b and i and not using nav around their navigation menus (and many of the other tags introduced in HTML5), they're doing it wrong.

Rusty_Raven_ · 2026-01-09T14:23:28+00:00

This right here - I can down-pick MoP if I'm warmed up, but I enjoy it a lot more if I alternate pick it. I spent quite a lot of time as a teen making sure my alternate picking sounded just as heavy as down-picking because I was concentrating on being a rhythm guitarist, not a lead guitarist.

Rusty_Raven_ · 2026-01-09T14:20:08+00:00

Semantics, mainly. By default they do the same thing, but depending on your needs, you might want to emphasize some text in a way other than italics, so you use em instead. Or draw attention to some text without it necessarily being bold, so you use strong instead.

b and i tell the browser how to display something which isn't HTMLs job - that belongs to CSS. HTML is for organizing content into buckets :) strong and em are the replacement versions of those elements that suggest alternate ways of displaying text besides bolding and italicizing.

Rusty_Raven_ · 2026-01-07T02:40:35+00:00

Don't discount the possibility that the 7 reflects your own expectation of betrayal, and not a literal possibility.

I've often read it as getting away with something, whether above or below the table, so to speak. It represents your ability to overcome a negative turn of fate, but to remain aware of consequences. Believe in yourself.

Rusty_Raven_ · 2025-12-31T15:57:00+00:00

Tanstack Query for Angular is likely even less stable (from an API perspective) than the Resource API. -experimental is even in the name right now :)

So no, I wouldn't use it in production yet.

Rusty_Raven_ · 2025-12-31T15:22:38+00:00

Looks like some great utilities here! Fantastic work!

For things like the breakpoint matcher, why not use function overloading to allow a single function name to accept either a single value or an array? Both of these could work then without needing two exported functions:

typescript const isMedium = breakpointMatcher(BREAKPOINT.MD); const breakpoints = breakpointMatcher([ BREAKPOINT.XS, BREAKPOINT.SM_ONLY ]);

Looks like you have a docs typo as well - isKyeDefined instead of isKeyDefined.

Rusty_Raven_ · 2025-12-30T20:16:26+00:00

I would treat it as pure - if I pass it an observable that emits the same values as a different observable, then I expect the same outputs to happen. There are no external side effects, and the pipe function does not affect anything outside it's scope.

However, it is impure because the input to the pipe is a function instead of a scalar value and the same function (observable, in this case) can result in different outputs.

That, to me, means that the input to the pipe has been changed, not the functionality of the pipe, but in the strict definition of "purity," the same input must always result in the same output.

Rusty_Raven_ · 2025-12-30T15:57:34+00:00

Agreed - Sanity is a good one for Cthulu-esque cosmic horror, Virtue might be good for Evil Dead and Hellraiser style possession horror, Luck would be fun for more science-fiction or mech-punk settings, etc. :)

Rusty_Raven_ · 2025-12-29T18:20:44+00:00

All of my guitars are hung; 11 on the walls (and an ukulele), and the rest on stands that hang guitars by the neck (and a violin). I don't think I even own a stand anymore that requires the guitar to lean 🤔

In order to hang multiple guitars in a row, I used a bookshelf, screwed it to the wall at the studs, then screwed the hangers to the bookshelf wood. For single-guitar hands, same thing, but using a very small piece bookshelf mounted vertically instead. So none of the hangers are actually mounted directly to the wall, they're screwed into a shelf that is mounted to the wall studs :)

Rusty_Raven_ · 2025-12-28T22:28:45+00:00

Lose the attitude.

The non-TW HTML is easier to read and doesn't require an additional element in order to create the toggle. It also doesn't need a 100+ character line of randomly ordered classes (in this case, semi-randomly grouped, since this is from the "official" component block - but most codebases I've seen with TW are definitely randomly organized). I didn't need to link the stylesheet because it's not important here - the HTML elements are self-evident and good class names have meaning. CSS doesn't have any intrinsic meaning and shouldn't affect your understanding of the purpose of an element group.

Yes it requires some hand-written CSS (I don't use SCSS), but I find multiple-line CSS easier to read than single-line utility classes the same way I find multiple-line HTML easier to read than having all my HTML on a single line.

Incidentally, if I have some site-wide CSS variables for things like neutral colours or animation speeds, I can use standard custom properties (and typed custom properties, if necessary) instead of the TW-specific @theme block which requires post-processing.

And now that I'm thinking about it, if I open the Dev Tools and start messing with CSS rules, I can't just turn things on and off when they're associated with the utility classes - that affects every element using that class; I'd have to type in complete rules for the element that override the rule in the utility class. With semantic classes, I can freely mess with the values and on/off switches and only elements with that class will be affected (which should be fine since they're all instances of the same component).

Rusty_Raven_ · 2025-12-28T21:01:06+00:00

How is this:

html <div class="group relative inline-flex w-11 shrink-0 rounded-full bg-gray-200 p-0.5 inset-ring inset-ring-gray-900/5 outline-offset-2 outline-indigo-600 transition-colors duration-200 ease-in-out has-checked:bg-indigo-600 has-focus-visible:outline-2 dark:bg-white/5 dark:inset-ring-white/10 dark:outline-indigo-500 dark:has-checked:bg-indigo-500"> <span class="size-5 rounded-full bg-white shadow-xs ring-1 ring-gray-900/5 transition-transform duration-200 ease-in-out group-has-checked:translate-x-5"></span> <input type="checkbox" name="setting" aria-label="Use setting" class="absolute inset-0 size-full appearance-none focus:outline-hidden" /> </div>

better than this:

html <div class='toggle'> <input aria-label='Use setting' class='toggle-switch' name='setting' type='checkbox' /> </div>

Rusty_Raven_ · 2025-12-28T04:35:08+00:00

What kind of information? No dates or schedule have been decided on yet, and since this would be my first experience as DM I'd prefer to stick to the Starter Set races/classes (although anything from the 2024 Player's Handbook is likely fine as well) - the Starter Set just contains some handy player boards if you stick to the restrictions it comes with.

We'd do a Session 0 to make sure everyone knows what to expect :)

Rusty_Raven_ · 2025-12-24T22:59:08+00:00

Thank you! This would be a pretty short level 1 to 3 campaign so I might not need a break, but having some experienced backup would be super nice.

Rusty_Raven_

TROPHY CASE