I didn't realize it was moom giving me my "move app to other monitor" hotkey, and moom didn't launch on startup after upgrading to tahoe. I've been using that hotkey for years.

That's when I realized there's no default hotkey for moving an app to an external monitor. That is absolutely wild. (Happy to be wrong)

I think there is an option in Keyboard Shortcuts to set a keybinding for moving to other displays, but it‘s not by default like in Windows.

For this kind of stuff Raycast is more than enough though. I use its window management features extensively.

This is why I love cycling so much.

I'm wondering if using an electric caravan is a similarly good option for slow travelling on land. It would force you to you stop after less than 300 kilometers, unfold the solar panels on the roof, wait a day or two (perhaps also catch some rain using the roof) and then continue.

Another, less romantic option would be to recharge it somewhere faster ;-)

Wonder if it's worth squashing in the branch, merging to main, then immediately reverting.

Now the work is visible in history, branch can be deleted, and anyone in the future can search the ticket number or whatever if your commit messages are useful.

Dunno if it's worth polluting history, just thinking out loud.

https://typescript-eslint.io/rules/switch-exhaustiveness-che... if that is something you're not aware of!

You can restructure your JS to avoid some crazy verbose TS though, sometimes. I think that's the point they were making. Why be so hostile?

On the other hand, would we even be talking about it if it hadn't stuck to its goals?

More than one assumption in that sentence, ha!

Including "code is delivered in a way that involves merges"

This feels like a "is a hotdog a sandwich?" situation.

"Is sftp-ing to prod a merge?"

My team follows good practice but I deal with a vendor who emails us a ZIP file :scream:

Honestly it's kind of refreshing to just push files to a server.

I've been telling people for years, if the process to deploy to an environment is more complicated than one click, it's too complicated!

I guess if it doesn't update the url, it's a button.

If it changes the url, it should be a link. At least that's how I've always done it.

Is is not okay to wrap a link inside a button ? I guess not

Which elements are allowed to wrap which is unclear to me

FWIW, you can generally figure out what's allowed fairly quickly by checking the content model for a given element[1]. Some browsers might be more or less restrictive, but for normal usage this'll be more than enough to avoid unexpected behavior.

[1]: https://html.spec.whatwg.org/#the-button-element:concept-ele...

What is the use case? It’s hard for me to think of a reason you’d want to wrap a link in a button. If you want to navigate, use an anchor. If you want to trigger JS logic, use a button with onclick handler. If you want to navigate while doing some side effect like an API call, use an anchor with onclick handler (and don’t prevent default).

MDN includes a “Permitted Content” section for elements, eg for button it says

> Phrasing content but there must be no Interactive content. If the <button> is the first child of a customizable select element, then it may also contain zero or one <selectedcontent> element.

“Ok, but what constitutes ‘phrasing content’ or ‘interactive content’?” you might ask. Those terms are links that give a very good overview of their constituent elements.

Literally absolutely never ever do this.

I mean the use of tailwind in the article is not good. Shows a lack of CSS understanding. Why are they applying `text-base` instead of just setting that on the root element? Why are they setting text color on the <a> tag and then overriding it on the <span> inside?

This person would write bad CSS, let's not put the blame on tailwind.

Also so much repetition instead of pulling each breadcrumb link out into a shared component. I understand it's just demo code for an article, but if all code bases end up like this that you've seen, the issue isn't tailwind.

My limited experience is that it's a fair bit harder to do a good job of reviewing PRs with tailwind versus CSS. So many classes tend to blur together in the markup.

Might just be me, but I'd rather just see clean(er) markup and styles in a css file.

I don’t think they would write CSS that was as bad. And even if they did, I’d rather look at bad CSS than bad tailwind.

Watch out, Lee is gonna show up and defend this decision and not respond to any valid criticisms.