I spend way more time with automation on a macOS than I probably should. I need a new hobby. . .

Anyway, something I do appreciate about Shortcuts is that most shortcuts can be invoked via CLI, so one can do some interesting things with them.

Honestly though, I still prefer AppleScript and/or Swift for most automation.

Woah I didn’t know you could invoke shortcuts with the CLI! Then again, I’m not sure that I really knew shortcuts were available on Mac. This is a game changer for me

Better than nothing, but not very effective. Plate armor was the most effective, but not perfect.

https://www.youtube.com/watch?v=qiyOIZ4Vm_I

I never was a fan of compound bows. I remember when I was participating in archery as a hobby. The instructor told us that in competition archery, if one uses a recurve bow, then winners are determined by who hits the bullseye (or closest) the most. In compound bow competitions, losers are determined by who hit the bullseye the least. It's a tongue in cheek way of emphasizing the ridiculous accuracy of compound bows.

I prefer the antiquity of recurve bows and the lesser amounts of maintenance that comes with them. Though, I also think compound bows are beyond dangerous in comparison.

I have found that recurve archers seem to be better about 'checking' their arrows after missed shots. Many compound users I have known think that as long as the arrow is not completely snapped, then it's safe to use. I just show them the Google images of what happens when an arrow with hairline cracks explodes the near instant the quick-release is released.

This issue can happen with high draw weight recurve bows, but I have never seen the damage like what a compound bow can do.

Always check your arrows, folks!

I second this. I shelled out the money for a custom fitted guard too. Mine was a bit over $400 after insurance. However, I strongly believe nothing over the counter comes close to it. At least, nothing I tried.

I honestly feel like not only sleep better with my guard, but I actually find myself having difficulties falling asleep without it now.

I do not know about this. As in, I do not doubt that necessity of daydreaming, and I do not doubt something is being lost. However, I think daydreaming can also be dangerous in of itself. There is even a term for it called, "maladaptive daydreaming."

Obviously, that is the extreme on the opposite side of the spectrum. But from what I recall reading, daydreaming, evenly moderately, can be somewhat unproductive. I mean that in the sense that daydreaming can provide the brain with a shortcut to a feeling that would be better served if an action provided it.

For example, one can daydream about going to the gym and becoming more healthy. One can follow the daydream all the way through. However, at least in my case, I have caught myself enjoying the pleasurable feelings and the "one day, I will..." too much to the point that I never go to the gym.

I think my brain has learned that I can quell whatever feeling I am having in the moment by daydreaming. It's my brain's shortcut. It's as if my mind say, "Why spend the effort to do something when we can just imagine how it feels and enjoy the reward now?"

Like anything in life, the key is balance. However, creating that balance is not easy in my experience.

>It's my brain's shortcut. It's as if my mind say, "Why spend the effort to do something when we can just imagine how it feels and enjoy the reward now?"

But I'd wager that, deep down, you know that the feeling you get thinking about it is far different from the actual feelings (both physical and mental) you'd get if you'd actually done it, no? I know that's been the case in the past for myself with regards to some thoughts - I know what I'm doing and I know that nothing will improve until I do it, and then I'm thrilled in ways beyond just what the thought provided when I actually execute.

This also kinda misses the forest for the trees. Not acting on a desire you think of is separate from the idea that people don't give their brains a break.

> But I'd wager that, deep down, you know that the feeling you get thinking about it is far different from the actual feelings (both physical and mental) you'd get if you'd actually done it, no?

I suppose there is probably some ratio for any given task that is amount of effort:reward. So, for some tasks, I would gladly take a quarter of the reward to avoid spending ten times the effort to acquire it.

> Not acting on a desire you think of is separate from the idea that people don't give their brains a break.

I agree and disagree. While there are obvious differences, I do believe not giving one's brain a break is partly causative in depleting one's desire/ability to act.

We all have different experiences, but I do not think daydreaming is really giving my mind a break. I find my mind to be quite active while daydreaming. But everyone is different, I suppose.

>... I do believe not giving one's brain a break is partly causative in depleting one's desire/ability to act.

The response I am flippantly tempted to argue is that it's good for people to not be acting/doing all the time and that downtime is essential, but, as we've both acknowledged, there's nuance there, and it all boils down to what the desire is and what the consequence(s) is/are should we not act.

>I find my mind to be quite active while daydreaming. But everyone is different, I suppose.

Totally! I mentioned elsewhere in this thread that I love backpacking in silence and without using my phone. These are 3-4 day trips deep in the wilderness, completely disconnected from the rest of the world and entirely in my own headspace. I love those moments, but I know plenty of people in meatspace who've expressed to me that they don't know how I can do that because of the way their own trains of thought run/work.

There was a study mentioned in one of Dr. K(YouTube)’s videos which cited that daydreaming or unstructured time is used for subconscious processing of thoughts and emotions and not giving your mind time for that causes negative consequences like like of sleep.

Of course, when I looked up citations on this I found some links on maladaptive daydreaming as well ._.”

I experience something similar. How do you avoid the pitfalls of daydreaming? Regular productivity aids like todos and pomodoro help to a degree but I wonder if there’s something else out there.

What do you like about HTMX? I coming from a world of plain JS usage -- no SPAs or the like. I just felt like HTMX was just a more complicated way to write what could be simple .fetch() requests.

I like that it still feels like html. I think that's it's biggest selling point.

You write:

  <div id="moo" />
  <form hx-put="/foo" hx-swap="outerHTML" hx-target="#moo">
     <input hidden name="a" value="bar" />
     <button name="b" value="thing">Send</button>
  </form>

Compared to (ChatGPT helped me write this one, so maybe it could be shorter, but not that much shorter, I don't think?):

  <div id="moo" />
  <form>
     <input hidden name="a" value="bar" />
     <button name="b" value="thing" onclick="handleSubmit(event)" >Send</button>
  </form>

  <script>
  async function handleSubmit(event) {
    event.preventDefault();
  
    // the form submit stuff
    const form = event.target.form;
    const formData = new FormData(form);

    const submitter = event.target;
    if (submitter && submitter.name) {
      formData.append(submitter.name, submitter.value);
    }

    // hx-put
    const response = await fetch('/foo', {
      method: 'PUT',
      body: formData,
    });

    / hx-swap
    if (response.ok) {
      const html = await response.text();
      // hx-target
      const target = document.getElementById('moo');
      const temp = document.createElement('div');
      temp.innerHTML = html;
      target.replaceWith(temp.firstElementChild);
    }
  }
  </script>

And the former just seems, to me at least, way way *way* easier to read, especially if you're inserting those all over your code.

Yeah, the JS could technically be shorter, but your example is functional enough to get the point across.

Going with your example, how would you do proper validation with HTMX? For example, the input element's value cannot be null or empty. If the validation fails, then a message or something is displayed. If the validation is successful, then that HTML is replace with whatever?

I have successfully gotten this to work in HTMX before. However, I had to rely on the JS API for that is outside the realm of plain HTML attribute-based HTMX. At that point, especially when you have many inputs like this, the amount of work one has to do with the HTMX JS API starts to look at lot like the script tag in your example, but I would argue it's actually much more annoying to deal with.

two possible approaches:

1. Do the validation server side and replace the input (or a label next to the input, see https://htmx.org/examples/inline-validation/)

2. Use the HTML 5 Client Side form validation API, which htmx respects:

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

maybe check out fixi.js:

https://github.com/bigskysoftware/fixi

I appreciate the suggestion. Not sure I am a fan of this implementation though. It looks near identical to the HTMX JS API that is already backed into HTMX. Most of the annoyances I dealt with were around conditional logic based on validation.

After enough of the HTMX JS API, I figured, "What is HTMX even buying me at this point?" Even if plain JS is more verbose, that verbosity comes with far less opinions and constraints.

if you are using the htmx javascript API extensively rather than the attributes, you are not using htmx as it was intended

> (I weep for Silverlight).

'Twas before my time. What was so great about it? I remember needing it installed for Netflix like 15 years ago. Did you ever work with Flash? How was that?

A lot can be said for just putting a "back" button a page. I still do it occasionally for this very reason. Then again, my user base for the apps I write are the most non-technical folks imaginable, so many of them have no concept of a browser back button to begin with. I am not being hyperbolic either.

Thing is, the browser back button is still there, though. So now you have two identical buttons that do different things. And that's really bad UX.

I’m split on this. I used to agree with you but when I talked to internal users and customers, they really liked having a back button in the app. I would tell them the browser back button is there and we haven’t broken history so it should work to which they just often shrug and say they “just” prefer it.

My hypothesis is that they’ve had to deal with so many random web apps breaking the back button so that behaviour is no longer intuitive for them. So I don’t push back against in-app back buttons any more.

I think you're right on the money—those bad web apps that told people emphatically "do NOT use your browser's back button!" did the rest of us a lot of damage, as I really do agree that it trained many people to never press it unless they actually want to leave the app they're using.

I myself am guilty of (about 14 years ago now) giving an SPA a "reload" button, which had it go and fetch clean copies of the current view from the server. It was a social app; new comments and likes would automatically load in for the posts already visible, but NEW posts would NOT be loaded in, as they would cause too much content shift if they were to load in automatically.

Admittedly this is not a great solution, and looking back on it now, I can think of like 10 different better ways to solve that issue… but perhaps some users of that site are seeing my comment here, so yeah, guilt admitted haha.

/)

It's okay if both buttons do the same thing. But OP (if I understood them correctly) proposed the in-app Back button as a hacky solution to the problem of browser one being broken, which kinda implies that they don't behave the same.

Bad UX that provides a functionality that otherwise isn't there at all is still better.

> they just need partial HTML swaps.

Been a web dev for over a decade, and I still use plain JS. I have somehow managed to avoid learning all the SPAs and hyped JS frameworks. I used HTMX for once project, but I prefer plain JS still.

I was a JQuery fan back in the day, but plain JS is nothing to scoff at these days. You are right though, in my experiences at least, I do not need anything I write to all happen on a single page, and I am typically just updating something a chunk at a time. A couple of event listeners and some async HTTP requests can accomplish more than I think a lot of people realize.

However, if I am being honest, I must admit one downfall. Any moderately complex logic or large project can mud-ball rather quickly -- one must be well organized and diligent.