I actually tend to drop off my mail ballots at the local library drop box.

I don't know what you mean by an API standard, but yes, it is technically a JavaScript library. But that's only an implementation detail and the spirit of htmx is that you write very little JavaScript. Javascript is simply used to extend the HTML standard to support the full concept of hypermedia for interactive applications. An htmx-driven application embraces hypertext as the engine of application state, rather than the common thick client SPAs hitting data APIs. In such a model, clients are truly thin clients and very little logic of their own. Instead, view logic is driven by the server. It has been around for quite a long time and is very mature.

It's fundamentally different than most JavaScript libraries out there, which are focused on thick clients by and large.

Obligatory "JSON APIs are not REST because JSON is not hypermedia".

GraphQL is a mess too as you throw out any ability to reason about query performance and it still requires thick clients with complicated/duplicated business logic.

If you're doing RoR anyway, then go for https://htmx.org/. It's much, much simpler and closer to how the web was originally designed. Highly recommend this book the author wrote on the subject (also provides tutorials walking through building an app): https://hypermedia.systems/book/contents/.

I'm sure it's fine for small-scale usage, but overall it's extremely inflexible and doesn't really scale well at all. There's also a lot of very basic functionality that's straight up missing. For example, there's no way to have a global epic priority. You can rearrange epics in an epic board, but the ordering of the epics there is not persisted elsewhere. There were many, many other shortcomings we kept running into.

Oh, and after a lot of our tickets had been imported (which itself was a huge undertaking since the auto import tools are complete trash), it started to be very slow. It feels like a very unfinished, unpolished product.

We use Gitlab's CI/CD features extensively at my current job and it's very, very nice. That's what they are actually good at, not project management.

Uh, there are an absolute fuckload of Java libs out there with nothing more than auto-generated garbage Javadocs.

Yeah it sounds like you're trying to mock me but it mostly just comes across as confusing. Maybe it's just sarcasm? Hard to tell.

Anyway, it's pretty well-known in the vim community that VSVim is pretty lackluster vim emulation. There are much better examples of vim emulation out there, such as evil for emacs.

It honestly has nothing to do with being a "power user". It's simply false to claim that vscode has more features than vim (which is what the parent comment was claiming), and this should be evident to anyone with more than the most basic, surface-level understanding of vim (more than vimtutor, basically). Vim is a lot more than HJKL and ciw.

I'm not annoyed with VsVim really since I honestly don't really think about it as it's not all that relevant. I do find it a bit irksome when people make false or misleading claims about vim from a place of ignorance about what it actually is.

It's a strange phenomenon with vim in particular, where many people are exposed to it at their periphery, read some reductive claim about it online, and parrot said claim all over the place as though it were fact. Perhaps the nature of being a tool that most are exposed to but few actually learn.

Yeah wtf, 100ms is great.

300ms is the average reaction time in humans. Less than 100ms reaction time would be insane and I'm pretty sure it's something no one has actually achieved.

"Overmorrow" is the word for the day after tomorrow, and "ereyesterday" is the word for the day before yesterday, though both are obviously archaic and not really used (you perhaps might see them in fiction or historical work, though).

Vim doesn't take any thought for me, it's all muscle memory.

It's a pretty standard flag in basically all compiled languages, just goes by a different name. -werror in C, -Werror in Java, TreatWarningsAsErrors in C#, etc.

...you don't accept them. Basically every programming language accepts some kind of -werror flag to turn warnings into errors. Warnings for development builds, errors for production builds. This has been a solved problem for a very long time. Not only is it assinine to force them to be errors always, it's semantically incorrect. Errors should be things that prevent the code from functioning in some capacity.

Or, you know, treat it as a warning like literally every other language. There's absolutely no good reason for it to prevent a build outright, but then again, there's not really good reasons for many of the decisions behind go.