spartanatreyu's comments

On: VisualJJ – Jujutsu in Visual Studio Code

[spartanatreyu]

I'm not convinced by jujutsu yet.

If I'm using git for version control, I'm going to use the Fork client (fork.dev) since it essentially replaces git's UI already.

And in a few years if I'm in the position where we want to switch away from git, I'd probably be looking at pijul.

But maybe that will change if jujutsu gets an open source non-git-based backend.

On: The dank case for scrolling window managers

[spartanatreyu]

> was that one claude terminal I'm looking for scrolled off to the right or left?

Isn't that what the overview feature is for?

Video: https://github-production-user-asset-6210df.s3.amazonaws.com...

[hombre_fatal → spartanatreyu]

Kind of. In practice it's like that equivalent macOS view that shows all your windows: you don't want to use it that often.

Also, it zooms out too far to distinguish text. And if you configure it to not zoom out so far, it also loses its overview power.

On: Android’s desktop interface leaks

[spartanatreyu]

Right off the bat:

1. Those loading spinners being bumpy pulled my eyes around the screen wildly to the point that they were experiencing pain. They need to be removed.

2. There is a status bar along the top, and an application launcher docked at the bottom. That's way too much vertical space being used, especially on laptops (which I'd wager is going to be the most used viewing modality for this OS). It should be merged into a single bar along one side of the screen.

3. The dropdown at the top left of each window seems to be taking up a lot of space. Especially when you're trying to fit four tabs on the screen. Get rid of it so the tabs can actually be read.

4. At 27 seconds in, there are two close icons in the focused window. That being bad could be a presentation all in itself.

5. Random padding in the status bar.

On: A 26,000-year astronomical monument hidden in plain sight (2019)

[spartanatreyu]

Graham Hancock the fraud?

[ifh-hn → spartanatreyu]

I think author and journalist is how he presents himself. Or pseudo-scientist according to Wikipedia. But yes Graham Hancock.

On: Steam "Offline" status leaks exact login timestamps (Valve: Won't Fix)

[spartanatreyu]

If Offline meant "don't bother me", it would be called "Don't bother me", or "do not disturb", and not "Offline"

On: CSS Web Components for marketing sites (2024)

[spartanatreyu]

No, daisyui is a bandaid over the class soup that is tailwind.

It's treating the symptom rather than the cause.

The solution is not to use tailwind in the first place.

On: CSS Web Components for marketing sites (2024)

[spartanatreyu]

> My point is that defining a complex behavior for a custom tag is not possible without js.

Not necessarily. CSS alone can allow for a lot of useful complex behaviour. You can customise how something renders (or not) or is interactable based on parent elements, sibling elements, css variables, or other state.

> For example, you can't define a reusable 'host-element' tag and expect some additional elements (or some behavior) to automatically appear inside it each time your html includes or you create <host-element> ... </host-element>.

Actually you can, using <template> and <slot> elements. No JS required.

> What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?

This is really two questions:

1. What's the point of using <link-button> instead of a link-button class?

2. What's the point of using a size="large" attribute instead of a "large" class?

To answer 1:

Classes end up being misused compared to custom elements. When you make a custom element (in this example "<link-button>"), you're explicitly saying this is a <link-button>. It is not a <blockquote class="link-button">, it is not a <form class="link-button> and it is most certainly not a <picture class="link-button>. It is a <link-button>.

Also with what was stated above, you can use <link-button> to declare default internal elements (using <template> and <slot>) without using js to say what should be inside a link-button.

To answer 2:

Because you should make impossible states impossible (or at the very least present impossible states as impossible). Size is a state, it could be small, large or any other list of predefined values. If you use classes then you can end up with something like <link-element class="small large">. If you use attributes, you end up with something like <link-button size="small"> or <link-button size="large"> but not <link-button size="small" size="large"> (since that's illegal in html and duplicated attributes are ignored).

Plus you're already using attributes for interactive aria roles (or you should be).

So with a basic collapsible menu:

<nav role="navigation">

<a href="#">home</a>

<button id="navbar-toggle" aria-expanded="false" aria-controls="navbar-menu">Menu</button>

<ul id="navbar-menu">

  <li><a href="#">Login/Logout</a></li>

  <li><a href="#">Feedback</a></li>

  <li><a href="#">Other links...</a></li>

 </ul>

</nav>

You use css to style the menu being open or not with: `#navbar-toggle[aria-expanded=true] ~ #navbar-menu` and not something inaccessible like: `.navbar-menu.navbar-menu-open`.

On: CSS Web Components for marketing sites (2024)

[spartanatreyu]

If you're not actually getting anything semantically useful out of the element, then you may as well use a custom element.

Also by using a custom element instead of a class, you're saying this isn't anything else other than what I say it is.

It's not a <section class="swim-lanes">, it's not a <form class="swim-lanes">, it's not a <blockquote class="swim-lanes">, it's a <swim-lanes>.

If you make something only a class, people end up misusing it in odd places.

On: jQuery 4

[spartanatreyu]

It didn't solve frontend, it sold developers one lie (i.e. ui = f(state) ) and managers another (developers are interchangeable gears).

Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.

[insin → spartanatreyu]

> Problems are only truly solved by the folks who dedicate themselves to understanding the problem, that is: the folks working on web standards and the other folks implementing them.

It kills me to think of how amazing Web Components could be if those folks had started standardising them _now_ instead of in "competition" with userland component libraries of the time (while punting on many of the essential challenges of developing UI in the DOM those libraries were still evolving solutions for), and introduced more problems entirely of their own making.

[kulahan → spartanatreyu]

Too bad the problems getting solved aren't the problems that need solving. Maybe this is one of the reasons software development is such a joke of a profession.

On: jQuery 4

[spartanatreyu]

React's hello world:

```js

<div id="root"></div>

<script>

import React from 'https://esm.sh/react@19';

import ReactDOM from 'https://esm.sh/react-dom@19/client';

const root = ReactDOM.createRoot(document.getElementById('root'));

root.render(<h1>Hello, world!</h1>); </script>

```

---

HTML's hello world:

```html

<h1>Hello, world!</h1>

```

---

JS's hello world:

Nothing, it was already done in HTML