ahuth

Done. Now it's double the size (50 x 50).

100 x 100 works too, although was noticeably slower.

I'm amenable to the idea of not making breaking changes if you can help it.

But...

> To say it another way: If you need to make a breaking change to your API, it means you screwed up. Don’t screw up.

I'm skeptical that we can always predict the future well enough to get an API perfect from the beginning.

Sometimes the best we can do is do the best we can, learn, and do better.

Holy smokes, I've never heard of Inform7, but I wouldn't be surprised if ChatGPT could output it for an adventure it creates

I am defending eslint/JS's honor in other replies, but you're right... setting up eslint is too complicated (and more complicated in TS).

Sure, for some tools. Most the time it's fine, though.

It's also nice that people in the JS community can easily contribute to tools written in JS (including writing custom eslint rules).

Nice article

This is one thing I’m loving about Remix. It’s how the framework works, so there’s no need to enforce this pattern or educate folks about it.

AND Remix’s nested routing still has you break down the data loading into a couple different parts (1 per route segment).

So it feels like you’re not loading everything in one place, and may be less likely to make people feel like they’re doing something “different” or “wrong”. It’s

Programming the programmers

Nice framing - need to be better than supercharged auto-complete.

What kind of stuff do you work on?

Some good points, and it's nice seeing the thought that went into this.

However...

> You’ll never get fired for picking it, but it’s going to be expensive, bloated, difficult to get right, and it’s going to be joyless implementing it every step of the way

Doesn't jive with my experience (at small and large companies).

You’re totally right. Companies should invest more in developing managers.

I didn’t talk about this in the article, but (right, wrong, or indifferent) I find it helpful to think about how to help my manager help me.

Good point. I should’ve talked more about _when_ it’s appropriate to talk about challenges.

Adding my own raycasting implementation, in... what else... React/JavaScript -> https://huth.me/raycast/

No worries. I made an assumption about what you were saying that wasn't helpful, either.

All good!

You're totally right. Different teams and situations require different tradeoffs.

While TypeScript is great for the tradeoffs I deal with, there are certainly others where it's not.

Good call out.

Can you link to where we previously discussed TypeScript? I don't remember that, and can't find it anywhere in my comment history (looked back to 2019).

Also, I didn't mean to misinterpret what you said. Sorry about that.

I can't get behind the idea that a type system is either completely sound or completely useless.

Surely preventing 99% of issues (or 90%, or 80%) is good?

I'm also not aware of too many real-world instances of unsoundness in TS that has caused problems. Obviously I don't know your specific scenario, but it's possible there are ways to work with TS (instead of against it) to get a good level of type safety.

Good point about lazily fetching some animations can be a good idea.

Not sure that all, most, or even many JS folks are addicted to bundling everything into one file.

Depending on what you're looking to do, you can use a tuple type to get an array of a certain length.

[number, number, number]

Submitted link is to a reddit thread.

Better one might be the GitHub issue discussing it: https://github.com/faisalman/ua-parser-js/issues/536

> If you maintain speed and strict curation of such a suite

This seems to be the hard part. Any tips for maintaining speed and strict curation, especially at scale (in terms of developers)?

At the very least, it seems that E2E tests are a tool that's easy to misuse. Not sure of the best way to mistake-proof it.

Author here. I wrote this a couple years ago, and chose JavaScript because it's the language I know best.

And I used React as a convenient way to display and manipulate the DOM, but of course it's not strictly necessary.

Overall this was a fun project that stretched the limits of my math knowledge (haven't done any trigonometry since high school). Was really satisfying when it finally started working right!

I too like node_modules. What's nice is you can use Yarn 3 and keep node_modules by setting the https://yarnpkg.com/configuration/yarnrc#nodeLinker config option.

I didn't read the advice as literally get yourself replaced. I think it's more of think about your value as how you work with others, influence an entire organization, and what you can get done together. Your value isn't about silo-ing knowledge.

When viewed that way, it could be good advice for anyone.

> It's basically inline CSS.

It's not, because there's a system to it. With Tailwind you pick specific values. Inline styles let you specify any value.

> It should not be ".text-gray-500" (like Tailwind does)

This is fair. I'd never considered that specifying the actual color in the class name would be problematic, but another thread pointed out that it makes theming (such as dark mode) difficult.

> 1. Select based on cascaded semantic HTML elements; 2. Don't repeat yourself; 3. No unnecessary classnames; 4. No style-descriptions in classnames.

I'm sure this works great when there are a small number of people working on styles. When there are many, however, I've found that the cascade often results in styles overriding one another, and needing to introduce more specificity to fight it, in an endless cycle.

Obviously people should write better CSS to avoid that. Which is actually what Tailwind is, I think.

You don't need to remember all the classes. Instead, you can go to https://tailwindcss.com/docs and search for whatever you're looking for.

Having IDE autocompletion (or even TypeScript integration) would be really nice. I'm sure there's plugins for many IDEs or editors that can do that, though.

Tailwind doesn't mean less space for skilled CSS people any more than design systems mean less space for skilled designers, or React means less space for skilled JavaScript folks.

Tailwind is a tool that's absolutely for skilled CSS people (you still have to know what everything is doing). And it is much more maintainable for a large number of people working on styling.

Nicely done!

Yep. The answer to "why do X thing in React/JS" is usually "why not?"

Ha, yeah. I gave a talk on this project once and pointed out that "If it's possible to do on 1980's hardware, it's possible to do in React".

Also, I'm pretty sure there are many websites out there pushing around way more divs than this is.

Good question, and mainly to see if I could. Also, React was a convenient way to render some DOM.

But you're right, vanilla JS would easily do the job.