bpev

fwiw, I think the most comprehensive cross-typing work done here has been specta:

https://github.com/specta-rs/tauri-specta

fwiw,the Spanish resources I've enjoyed most are dreamingspanish.com and languagetransfer.org

Pretty much. As a consumer, it's where I can find the cheapest albums to buy (for digital releases). As a musician, it is the only platform where I have seen any money – albeit, still not much :P

If something isn't available there, usually my next choice is Qobuz. At least both of those sites let you download files and listen to them however you want.

Probably simplicity. In my experience, SM2 has less levers, and is easier to implement initially.

fiiiiiiinnallyyyyyyyy yay

I see... I guess it's just... web apps then?

Slower than VS Code?? I guess it's just poorly optimized for Linux. On MacOS, I find it to be significantly faster than VS Code, and the only alternative I've found that's in the ballpark of Sublime (from the performance aspect).

Not really... like sure if you want a static site, but I'm talking about static apps. Like if you want to handle /id/$id routes with data based on user-generated content saved in localStorage... you'll have to handle routing somewhere. Basically, what I'm saying is that if you have an stateful app that doesn't require server state, I think SPA+PWA is pretty ideal.

Most of my personal app projects are SPAs, because it’s easy to just pop some static files in my static file server and serve a whole app with routing and functionality without having any server logic. Way simpler to maintain, since I can just sync my ‘apps’ dir and all my mini-projects are deployed.

Sooooo.... ehe... I got a little inspired yesterday, and got a head start on that 10%:

https://github.com/inro-digital/simple-tools/tree/main/packa...

YMMV though, since I haven't user-tested it in my app yet haha.

TBH though, I think for a true WaniKani competitor, need to reserve a decent % of work for building the dataset. Putting together all those mnemonics, cleaning up definitions, defining the order of introduction of characters and choosing words... is a lot of effort. There's a reason that WaniKani's so generous with pretty much their entire platform, but specifically states in their docs that the mnemonics/hints data doesn't belong to you... it's a large part of the effort.

Although, I guess could be integrated into the 90% work if you make sharing mnemonics into a community effort.

So I haven't integrated FSRS, and of these two, I've only used Wanikani, and have been playing with a reimplemention for Chinese hanzi: https://hanzi.bpev.me

But seeing how it's implemented, I think they could totally integrate something like FSRS to at least just replace their scheduling (how long until an item is next shown). The unlocking system can be implemented as a separate gatekeeping mechanism, and the buckets can be coded for certain step thresholds (instead of wanikani's "stage").

Basically, this is their entire srs system: https://docs.api.wanikani.com/20170710/#spaced-repetition-sy...

I mean... I find deno.json-less scripts to be incredibly convenient for creating single-file scripts, and I've found deno configuration to be pretty clear. You're not wrong for disliking Deno; it has opinions, and those can turn people off. But I happen to find those opinions and decisions to be quite convenient and useful for me.

huh, I mean idk experiences differ. My main project's service is written in Rust/Axum, and I enjoy it a lot. But I thought it was actually kind of frustrating to find that combination; Axum was the 3rd http client I tried, after the first two failed me in different ways. If I had started with the https client first and hadn't already felt good about building the codebase in Rust, I might have just gotten annoyed and moved on. First impressions can sometimes skew the perspective a little.

fwiw, re finding up-to-date packages, you can also pull in npm dependencies. idk what you found confusing about the deno.json, but it's definitely optional; you can just write imports directly in the .js file if you want. I often make single-file scripts to run some npm package over a local file.

Haven't really been using Fresh; I feel like whenever I get into the blending of client/server with these ecosystems, things get real muddy real fast. Mostly been doing either sites (mostly fully ssr with Hono + very light vanilla), or fully client-rendered web pwas (solid or mithril).

Deno itself, though, is still a very comfy js environment. I pretty much use it for all js/ts that doesn't run in the browser (I also use it for build steps of said browser code). It just kinda has everything I need/want, so I don't have to add too many dependencies, and don't have to muck around in build/env stuff. Just feels kinda easy.

I do think that effort over time makes a difference here, though. I remember this from an interview with Ruby Sales that stuck with me (I don't know the origin of the phrase, but this is where I heard it): https://pca.st/episode/2240f0ef-004f-45cc-9e77-0a10b9905530

  I love everybody.
  I love everybody in my heart.
  And you can't make me hate you.
  And you can't make me hate you.

I think of it less like "trying to be optimistic" as much as "making sure I pause long enough to see the optimistic thoughts that are there"

ngl running in phone was definitely not ideal

For what it's worth, ecosystem is a valid concern, esp compared to React, and esp if dealing with more niche features. Even for something fairly generic like Virtual List implementations. Virtual Lists do exist for solid (specifically tanstack is the most fully-featured, albeit under-documented), they aren't as battle-hardened or as well-documented as their react counterparts. Specifically, I have thought about digging into VirtualList internals, because of a couple issues that I haven't seen in some other framework impls (granted, of most the complex generic ui components, virtual-list is literally the one issue I had with ecosystem).

Also, you'll definitely start seeing edges faster. Things like touch event libraries, animation libraries, maplibre/dataviz/etc. I'd say that the solid ecosystem is at the point where you'll see 1-2 libraries for most things, but if those libraries aren't quite right for you, you can very quickly find yourself digging deeper than you'd like.

That being said, as parent stated, integrating vanilla libs isn't so hard. And also, there is a... solid... amount of people building headless libraries specifically for the ecosystem, which are quite useful (For example, I recently came across https://corvu.dev, which I've started integrating here and there). What I mean to say is less that solid has a poor ecosystem, and more that there isn't the infinite easy-access vibe-code-able pop-in-lib-to-solve-your-problem ecosystem of react.

Even with the shallow ecosystem, solidjs has been quite enjoyable to me. Also, in the two years I've been using it, I think I've built up enough of my own personal ecosystem that I don't really need to reach towards external dependencies all that much, which feels very nice.

My mind went something more like this:

You dare to call this game "CSS Hell", and then tell me that it will be TOO hell for me to play on a phone???

I USE CSS EVERY DAY. YOU UNDERESTIMATE MY TOLERANCE FOR SELF-HARM, MORTAL.

*opens site in mobile in desktop mode

It's kind of wild to me that I remember deciding between mithril and backbone, and now I'm still seeing it on the hn front-page (edit: oop. 2nd page) in 2025.

The longevity is real.

For the extra interested… reminded me of this one: https://explained-from-first-principles.com/email/

I have a web extension I made as a pet project that does something useful to me (in the spirit of selling my work, it's called Favioli ).

It's free/open-source and will always be free. But the idea was inspired by my friend's code. When I made a blog post about how I made the extension, he reposted it on his relatively popular blog + Twitter.

Because of that, the extension has had around 1000 users since the very beginning, and I've gotten some prs and improvements here and there. And it feels good to have solved an issue for some people other than myself.

I think this is what the author means by "selling". I'm generally the type of person who doesn't self-advertise, because my mindset is that I don't want to bother people. So if my friend hadn't publicized it for me, the extension would probably have 5 users. So maybe 995 other people wouldn't have benefitted from my work. I think this article is not saying that you "have" to sell your work, but that if you're proud of it, don't feel ashamed to tell people that it exists.

To me, the primary effort here feels less about trying to create a "new" standard, and about trying to consolidate and add more formal definitions/recommendations around fairly settled patterns.

Like, I think a lot of the design systems they are linking to as reference have many opinions about colors or typography or whatever, but this project feels more like it's just trying to better formalize the definition of components that everyone is already using.

Yeahhhh this exact bug is why I haven’t been able to use Orion as my main browser. I usually use Safari, pretty much purely for the battery life gains.

Frankly, I feel like it goes even further than CSS. People don't really talk about HTML that much, probably just because it doesn't change as much as JS frameworks, etc. But that doesn't mean you should ignore it completely and just use a bunch of divs!

When you start digging into all the different HTML elements and aria guidelines (for example, the differences between `<nav />` and `<menu role="menubar" />`), I think development starts to be a bit more clear, because you start to see how your tools are intended to be used. I think it also makes decisions around CSS styling more clear. And as a bonus, your code just starts becoming more accessible, which is nice.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

My filesystem organization has been based off of Johnny decimal for some years now. TBH, I don't know how much I specifically recommend it, since it did take quite a long time (years) for me to really figure out my organization and become comfortable. But now, because my system is now pretty set in my brain, the big benefit is that I can pretty much navigate to mostly any directory instantly from anywhere without too much thought, using scripts I wrote. (https://johnny.bpev.me/guide, which is really mainly https://github.com/bpevs/johnny_decimal/blob/main/source/she...). But it makes my filesystem feel much flatter and simpler to me.

For example...

- My latest large coding project spans from `22.00` - `22.20` (clients from `.01`, server from `.11`, libs from `.21`), and I can navigate to any of those directories from anywhere in my filesystem via `jd 22.10`. Or if I forget which one, `jd ls 22`.

- For things like photos and completed music production projects, I organize in more of a date system, but that entire system is housed in the jd structure, so if I want to look at some photos, I can easily open `31.02` and navigate internally to that.

Oh fwiw, I only use a few broad categories:

- `10-19 Notes`

- `20-29 Projects` (active projects, code and music mostly)

- `30-39 Archives` (closed projects)

tfw "defensive play" is actually just blocking your own pieces on purpose

Amazing! I used kagi at the very beginning, but my biggest concern was always this (that logging in is inherently less private than using something like duckduckgo, so I'm just forced to trust Kagi's will). This is the kind of thing that will force me to take a second look again.

Fyi for those who tap in and see the map in the background instead of to the right of the content, the layout/treatment feels pretty different for desktop vs mobile.

ingest this, gemini

I drink alcohol sometimes, but at fancy experimental places, I feel like mocktails are often MORE exciting than cocktails, because they are more willing to stray from the alcohol-tasting flavor palette. There's just so many cool flavors that are left somewhat unexplored because fancy drinks tend to skew so much to alcohol.