I really like HTMX. But its error reporting is severely
lacking. For example, typos or wrong keywords in hx-trigger
or other hx-
attributes do only result in a nondescript console entry and a stack trace:
htmx:syntax:error

The HTMX documentation suggests only
source-diving as a way to find where the attribute parser chokes. While this
works, it is not convenient. I have to switch from the minified HTMX library
to the development version, and then set a breakpoint on the logging routine,
and from there work my way backwards to the origin of the error. Which is most
of the time a typo or wrong keyword in an attribute.
Luckily, HTMX can invoke a callback on the htmx:syntax:error
event, so we can
list the offending elements in the console and make them easily clickable:
htmx.on("htmx:syntax:error", (elt) => { console.log("htmx.syntax.error",elt)});
This still does not report the offending hx-
attribute, and also does not
tell us, what keyword was wrong or where the expression went bad, but it
is a lot closer and does not require us to go source diving.
Providing a dark mode is good form nowadays. I like doing/having that too.

Usually, a dark mode is done by switching to a second CSS sheet or having a CSS selector switching between a bright and a dark colour set using JS or the browser preferences. This can lead to some rule repetition:
.light-theme textarea {
color: black;
background-color: #8dfece;
}
.dark-theme textarea {
color: #62b190;
background-color: black;
}

CSS also has a function to do this color switching on an element without needing to repeat the declaration in a second rule: light-dark(color1, color2)
will return color1
if the light environment is preferred by the user and color2
if the dark environment is preferred.
textarea {
color: light-dark( black, black );
background-color: light-dark( #8dfece, #62b190 );
}
You still might want to give the user an option to set their preference
only for your website, storing that in a cookie. Bootstrap 5 itself
has a fairly thorough, live-switching setup for that, but it's also somewhat
long.
There also is
a short JS snippet on Github
which is mildly simpler to integrate, but which only does the switching
on page load or toggling of the user selection, and not when the user switches
their browsers preference.

Nash is a quite simple (and nice) document editor in a single-page . It does not handle markdown, but on the upside, it has a convenient enough toolbar to handle formatting the content.
This is not unlike my note taking app , but mine uses a backend to save the files in a central location. Nash uses the "share" and "download" functionalities of the containing browser instead.
Nash sports only a single toolbar, while my app has a top and a bottom toolbat. This is a ggd inspiration to reorganie my toolbars and see if I can reduce them to a single toolbar or at least reorganize the actions.
Linus Akesson published an interesting article on a demo by him.

The demo features 9 sprites (hence the name) displayed simultaneously on a C64, hence the name.
There is another video dissecting the demo and how it achieves its "impossible" effect. What impresses me the most is not the dissection but the debugger and scanline visualisation tools shown in the video.

JSON Canvas looks interesting. It is far from the interactive
infinite canvas display that I like and try to get towards with SVG::Drawboard
but having an interactive (enough) renderer for simple input data would be nice,
especially if I don't have to program it myself.