qq99

Win11, editor runs on Win11, all development happens inside WSL2 (Ubuntu)

Basically all the bonuses of Windows re: gaming, with a great developer experience (like Linux/OSX).

The prime annoyances are:

- exposing a port to the entire LAN (for local phone debug) is non-trivial

- I imagine Android or phone dev might be a bit harder re: simulator, luckily I don't do this

- dev that spawns native windows would by default spawn through some WM layer with X11 or something (and they are laggy)

For me, the better HN is https://hckrnews.com/

I absolutely love it. I find it empowers me more than ever before, and my satisfaction is at all time highs. I'm even building projects now (videogames) that I probably wouldn't have started before.

Here's where I'm at:

- Your subjective taste will become more important than ever, be it graphic design, code architecture, visual art, music, and so on for each domain that AI becomes good at. People with better taste will produce better results. If you have bad taste, you can't steer _any_ tool (AI or otherwise) into producing good outputs. So refining your taste and expanding it will become more important. re: "Yeah, I could've prompted for that too.", I see a parallel to Stable Diffusion visual art. Sure, anyone _can_ make _anything_, but getting certain types of artistic outputs is still an exercise in skill and knowledge. Without the right skill expression, they won't have the same outputs.

- Delegating the things where "I don't have time to think about that right now" feels really good. As an analog, e.g., importing lodash and using one of their functions instead of writing your own. With AI, it's like getting magical bespoke algorithms tailored exactly to your needs (but unlike lodash, I actually see the underlying src!). Treat it like a black box until it stops working for you. I think "use AI vs not" is similar to "use a library or not": you kinda still have to understand what you need to do before picking up the tool. You don't have to understand any tool perfectly to make effective use out of it.

- AI is a tremendous help at getting you over blockers. Previous procrastination is eliminated when you can tell AI to just start building and making forward progress, or if you ask it for a high level overview on how something works to demystify something you previously perceived as insurmountable or tough.

Nothing feels satisfying anymore

You still have to realize that were it not for you guiding the process, the thing in question would not exist. e.g., if you vibecode a videogame, you start to realize that there's no way (today) that a model is 1-shotting that. At least, it isn't 1-shotting it exactly to your vision. You and AI compile an artifact together that's greater than the sum of both of you. I find that satisfying and exciting. Eventually you will have to fix it (and so come to understand parts you neglected to earlier).

It's incredibly satisfying when AI writes the tedious test cases for things I write personally (including all edge cases) and I just review and verify they are correct.

I still find I regret in the long term cases where I vibe-accept the code it produces without much critical thought, because when I need to finesse those, I can see how it sometimes produces a fractal of bad designs/implementations.

In a real production app with stakes and consequences you still need to be reading and understanding everything it produces imo. If you don't, it's at your own peril.

I do worry about my longterm memory though. I don't think that purely reading and thinking is enough to drill something into your brain in a way that allows you to accurately produce it again later. Probably would screw me over in a job interview without AI access.

https://www.kyoubenkyou.com/

It's a few things:

- very fast Japanese->English dictionary

- hiragana / katakana / number / time reading quizzes

- vocabulary quizzes based on wordlists you define and build

- learn and practice kanji anki-style (using FSRS algo)

- the coolest feature (imo) is a "reader": upload Japanese texts (light novels, children's books, etc), then translate them to your native language to practice your reading comprehension. Select text anywhere on the page (with your cursor) to instantly do a dictionary lookup. A LLM evaluates your translation accuracy (0..100%) and suggests other possible interpretations.

I just revamped the UI look and feel the other day after implementing some other user feedback! I'm now exploring ads as a way to monetize it.

Very cool!

I'm working on a few things, but the one that's gaining the most traction right now in terms of users is kyoubenkyou

https://www.kyoubenkyou.com/

In short, it's a few things:

- JA->EN dictionary

- hiragana / katakana / time reading / number reading quizzers

- learn kanji with FSRS, anki-style

- vocab quizzer

- the coolest feature (imo) is a "reader": upload Japanese texts (light novels, children's books, etc), then translate them to your native language to practice your reading comprehension. Select text anywhere on the page (with your cursor) to instantly do a dictionary lookup. A LLM evaluates your translation accuracy (0..100%) and suggests other possible interpretations.

It's all elixir+liveview+postgres+pgroonga (though there are times when I would like to have SolidJS).

I've been considering open-sourcing it due to lack of commercial success, but might try an ad-based approach first.

grok-code-fast-1 has been my preferred model lately, but I don't see any mention of it as part of this release. I'm wondering if this might be better? Even if grok-code-fast-1 might be slightly worse than Gemini 2.5 Pro, the speed of iteration can't be beat.

Love the idea of local keys and appreciate your video explaining it! What do you use to record that style of video?

Cool!

Some feedback: it's too easy to get into a "dead chat".

Sorry, an error occurred while processing your request.

No way to retry or resubmit or edit anything to get things moving again. Too terminal.

If I just type "try again" (lacking a retry mechanism), having it say "Here is the current image I'm working with" seems unexpected (my follow-up request was going to be for 4 entirely new variations with more specific aspects)

If I go back to the home page and attempt to begin what I imagined is a new chat, it appends this new message onto the previous chat's history. Not sure if that's a visual / caching bug, but it's also jarring

So your <Button> component still has 60 tailwind classes on it?

I think that might work in React, but might have a payload impact on server-rendered React.

Another interesting point for using something like this (specifically, using shorter semantic class names instead of multiple tailwind classes) is: Phoenix LiveView

LiveView streams DOM changes over the websocket, so afaik can't really meaningfully be compressed to eliminate bytes. By using `btn` instead of 30 tailwind classes, your payloads will be smaller over the wire.

A bit niche, but something to think about.

The fact that your `<Button>` React component renders 60 tailwind classes might not seem bad (because gzip or otherwise might actually make it ~negligible if you have a ton of buttons on the page and you're server rendering with compression enabled), but in LiveView's case, I don't think there's really any other option (not enough of a text corpus to compress?).

Not sure if this was a factor in Phoenix's recent default inclusion of DaisyUI or not.

Even in Phoenix, I'm still using a `<.button>` Phoenix component, but that uses a smaller semantic classname most of the time

Sure, you might make a `<Button>` UI component (assume React), but if it embeds 30 classes in it, when you server-render this, every button on your page is contributing ~30 classes worth of bytes to the payload sent across the wire.

I think you're agreeing with me. DaisyUI is 1 implementation of a standardization shortcut so you don't have to e.g., develop your own button, dropdown, modal, nav, etc (whatever you are interested to consume from DaisyUI)

Yes, they'll typically have a UI component that accepts props and may have some internal state.

DaisyUI is operating at the style layer, so you might use it to achieve the visuals for your UI component (regardless of how you achieve your UI component, be it React/Vue/server-rendered/etc)

I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class.

How are you going to style your components, if not via CSS classes?

Tailwind is just a set of utility classes (that also tends to be compiled), while SCSS is a full-on CSS compiler that offers no utility classes by default.

A lot of the features that SCSS enabled are now natively part of CSS, so it has fallen somewhat out of favor (because: why compile when you can use the same features for free without compiling?). Nesting is in CSS now, which was the killer feature at the time. & scoping too. Variables especially are better in raw CSS because you can re-assign them and have them transition/animate, which is not possible in SCSS. SCSS helped to evolve CSS.

I initially thought Tailwind was very stupid, but after using it, it is somewhat freeing to write some "1-off inline CSS" (essentially) on the DOM node itself. Sometimes inline CSS is OK (and it's nicer to do so with an easy to remember and powerful utility class rather than via `style=`).

For some, it eliminates `MyComponent.css` that has literally 1 rule with 1 style inside it. Colocation with the DOM in some cases making it easier to modify + reason about, less context switching.

IIRC the creator of tailwind might have been against @apply too, but it didn't seem like a good recommendation to me

Just because you have Tailwind in your codebase doesn't mean you can _only_ use Tailwind. I often use a mixture of both when it makes sense. The Tailwind classes are often terser. Tailwind is not great for all things.

which emulates class based styling

IMO, what DaisyUI does is how you are meant to be using Tailwind. You aren't supposed to use _only_ TailwindCSS classes in HTML directly (although you can). It's faster for prototyping, then once the prototype solidifies and becomes a pattern, you can extract your long tailwind string into a nice utility class.

It happens to use things like `@apply gap-2` internally in its src, so that if you want to override "how large the gaps are" in Tailwind, Daisy will also inherit that override.

Tailwind is a set of utility CSS classes you can use that tend to guide you into writing CSS that looks like it "fits" together. E.g., consistent gaps if you use `gap-1`, `gap-2`, etc., rather than a hodgepodge of "hmm did I use margin-right: 2px or 1em or what" that can emerge in a large CSS codebase with many developers. We can use a `m-1` or `p-1` class to define a base padding, and as long as everyone knows that `1` is the amount of space to use by default, everything will generally look like it fits together.

Later, you can optionally redefine what `1` means if you want more space in your design. In a way, using tailwind can be like variablizing your CSS at compile time (in a faster way than just using writing and using CSS variables).

For a lot of things, using just 1-3 tailwind classes on a div is sufficient for many common tasks, e.g., `flex flex-row gap-1` boom done. You can put this directly in the HTML, and is considered "fine".

An example from DaisyUI's site is:

``` <button class="bg-zinc-100 border font-semibold text-zinc-900 text-sm px-4 duration-200 py-2.5 transition-all hover:border-zinc-300 hover:bg-zinc-200 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-zinc-900 active:translate-y-[0.5px] inline-flex gap-2 rounded-sm active:border-zinc-300 active:bg-zinc-200 active:shadow-none text-center align-middle cursor-pointer border-zinc-200 dark:border-zinc-700 dark:bg-neutral-700 dark:text-zinc-300 dark:hover:border-zinc-950 dark:hover:bg-zinc-950 dark:focus-visible:outline-zinc-200 dark:active:border-zinc-950 dark:active:bg-zinc-900"> ```

This is everything needed to make a button look nice in tailwind, and obviously it would be insane to copy+paste this every time you want a nice looking button in your HTML (not to mention the byte size, it's just unreadable).

The best thing to do is define a `.btn` or `.button` (usually I might avoid `button` DOM level selector for future flexibility) and encapsulate these styles as a semantic component in your .css file. You can write them with raw CSS or `@apply bg-zinc-100 border ...;` using tailwind style @apply.

This is what DaisyUI provides you, a shortcut to common nice looking UI components.

I'm surprised that a lot of the comments seem to be missing the reason that this project exists.

In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind.

Can you just apply it to `button { @apply flex items-center blahblahblah; }` in app.css? Of course you can. Or you can use the btn from DaisyUI.

I think DaisyUI is just a shortcut for many common UI components that you will inevitably want to build out and that you will necessarily eventually standardize in any app that grows large enough.

How does it differ from bootstrap? Well, you can continue to use tailwind for everything else that DaisyUI has not implemented. It's just an additive layer to tailwind. The project is at its core just a shortcut for common UI components.

As a user, my criticism is that many of the DaisyUI components seem to be lacking good contrast, so some just don't seem to be usable. The theming situation is really interesting and quite cool to use, but if you look at the example page, it just feels hard to read. I can't really find a light and dark default theme that look good to me (re: contrast and brightness). I think the color hooks might just not be there but I didn't dig far enough in.

For me, I've found a lot of value in being able to easily copy+paste parts of DaisyUI source code, e.g., a particular widget and modifying it to fit my design system, rather than use it in its entirety.

I imagine (and hope) I'm not being billed for requests that fail. In my own apps that use Anthropic API, sometimes the req just fails the initial connection (and so has to be retried), usually works in 1-2 retries.

Cursor doesn't auto-retry my request, it presents me with a button to click to retry. If you know the request failed, you could just retry on my behalf!

It's the Venom symbiote

I was wondering about this. I was hesitant to add embedding-based search to my app because I didn't want to incur the latency to the embedding API provider blocking every search on initial render. Granted, you can cache the embeddings for common searches. OTOH, I also don't want to render something without them, perform the embedding async, and then have to reify the results list once the embedding arrives. Seems hard to sensibly do that from a UX perspective.

To render locally, you need access to the model right? I just wonder how good those embeddings will be compared to those from OpenAI/Google/etc in terms of semantic search. I do like the free/instant aspect though

Wasn't this already available in AI Studio? It sounds like they also improved the image quality. It's hard to keep up with what's new with all these versions

That's a really good point.

I haven't done a lot of optimistic updates with LiveView yet. I'm not sure how sanely you could really achieve it (because it seems you'd lose the primary benefit: server-side rendering / source of truth).

However, there are a few mechanisms you can use to note that the page is loading / processing a LV event that can assist the user in understanding the latency. e.g., at the very least, make a button spindicate. I've experienced (in my own apps) the "huh is the app dead?" factor with latency, which suggests I need to simulate latency more. If the socket is unstable or cannot connect, the app is just entirely dead, though the fallback to longpolling is satisfactory.

I think it would really shine for internal apps due to the sheer velocity and simplicity of developing and deploying it.

In the worst case, you could fall back to using regular controllers or APIs controllers, so I still see it being a "better version of Ruby" overall. However, if we're going back to this, I would rather use SolidStart and do it all in TypeScript anyway.

At the end of the day, I'm very torn between the resilience/ease/speed of Elixir and the much better type system in TS. The ability to just async something and know it will work is kind of crazy for improving performance of apps (check out assign_async)

the majority of results are 300ms+

Another thing to consider is that a lot of apps (SPA powered by API) take 300~1000ms to even give you a JSON response these days. So if you can get by with making a button spin while you await the liveview response (or are content with topbar.js) I think you can get roughly close to the same experience.

deployed 'at the edge'

The nice part of Elixir is you could probably make a global cluster quite easily. I've never done it though. You could have app nodes close to users. I think you'd have to think of a way to accelerate your DB connection however (which probably lives in 1 zone).

The biggest downfall in my experience has been it can be a massive pain to find out where a method is defined in a huge codebase, especially with all the crazy ways in which one can declare methods. You can spend a non-trivial amount of time just trying to find the definition for a method.

Can't speak to ORMs, but I'd have a look at SolidStart. If you need an API, add in tRPC. End result is highly typed, can do SSR, and once you get used to it, it's a much better experience than using React.

I still haven't found an ORM with JS that really speaks to me.

there are so few rails people available (compared to js) that it's not viable for any professional project

I don't think this is true; Shopify is a Rails shop (but perhaps it's more accurate to say it's a Ruby shop now). It feels easy to make a mess in Rails though, imo that's the part that you could argue is irresponsible

If you're thinking about going back to SSR, I think you owe it to yourself to check out Phoenix LiveView (Elixir) and play with it for an afternoon.

I've built a few apps in it now, and to me, it starts to feel a bit like server-side React (in a way). All your HTML/components stream across to the user in reaction to their actions, so the pages are often very light.

Another really big bonus is that a substantial portion of the extras you'd typically run (Sidekiq, etc) can basically just be baked into the same app. It also makes it dead simple to write resilient async code.

It's not perfect, but I think it's better than RoR

However, Lynx isn't limited to React

I think this could be huge! I'd love to see a SolidJS version

What factors made you choose to go with a publisher vs. self-publish?