jacobobryant

ha, hi to you too!

It's a fun part of the code to work on for sure :).

I started trying out datastar in another part of the app by the way, mostly for the frontend signals so far e.g. https://github.com/jacobobryant/yakread/blob/8a61443235d1f6f...

Since this app isn't collaborative it's not clear to me if there'd be any benefit of doing any long-lived SSE vs. just sticking with the request-response model I'm already doing with htmx. Also since various parts of the app do take 100 - 1000ms to render/query, so rerendering the whole page on any change I don't think would be a good fit. But even just having the signals part baked in is pretty nice.

2nd place probably goes to another comment in this thread: https://news.ycombinator.com/item?id=41560711

Also the whole/part of the point of being hosted on the JVM is if there isn't a clojure lib for something you can just use a Java lib.

Good to know--I'll do another run through the tutorial sometime and see if I notice anything. I know there are a couple things I need to update in the example repo at least.

Mind sharing the parts of the tutorial you had trouble with, if you remember?

I applied 9 times and never got an interview. I've moved on from entrepreneurship (for now?), but would love to know what percentile I'm in for consecutive rejections as a consolation prize ;)

Mainly I just wanted something short because I knew I would be typing it a lot, and "biff" just popped into my mind.

This is great to hear! Glad Biff has been helpful.

Hmm... I like Babashka's quick startup time, but realistically it might not actually matter. I'll try out a tools.deps-based setup sometime. I would enjoy not having the extra dependency.

The description of Rails is helpful--thanks.

Make like a tree and get out of here

Too late to change the name now unfortunately ;)

at least it's short and easy to type

Oh, also re: "No Windows-specific quirks w.r.t. live reload or anything else" -- the Windows caveats mentioned at https://biffweb.com/docs/get-started/new-project/ only apply to "developing in prod", in which Biff deploys your code whenever you save a file. Reloading code during normal local development works fine on Windows, same as in Luminus.

Going with XTDB by default is an example of "what do I want for my own projects?" being the first priority as mentioned in the article--I agree that Biff would be easier for many people to pick up if it defaulted to Postgres/SQLite. My hunch is that building something I personally love is the best long-term strategy for Biff anyway. When XTDB2 is stable I'm planning to have SQL be the default, then those who want to (like myself) can switch easily to datalog. See also https://biffweb.com/p/xtdb-compared-to-other-databases/ for more of my thinking on XTDB.

The main reason I switched from Bash to Babashka for the project tasks (`bb dev`, `bb deploy` etc) is that it allows me to put the task implementations in a library and have Biff projects depend on it, as opposed to copying all the task implementations into new projects (which is what previously happened). This way people can upgrade the tasks by bumping the lib dependency. Some of the tasks also have somewhat complex logic and IMO benefit from being written in Clojure/Babashka.

The only bash script is `server-setup.sh`. I suppose I could rewrite that in Babashka for the sake of consistency, but it doesn't really seem like that big of a deal to me (?).

In response to "install a variety of tools without clear purpose" -- isn't it just one tool, Babashka? I believe that puts it on par with Luminus :).

Agreed that the docs could be better written for those new to Clojure. To really do a good job of this I'd want to do some actual user testing with people as they try out Biff for the first time. Main constraint here is just time. I'm always happy to get specific pieces of feedback and try to act on those (perhaps I could make the jacking-in section less prominent). I actually would love to make a course/series of guides for complete Clojure newbies, but until someone hires me full-time to work on Biff I think I'll have to rely on others to write the beginner resources.

In response to your three points:

1. There's a lot of stuff that goes into a web app :). It's also not clear to me that switching from Babashka to Lein templates + Bash scripts would improve this situation (if anything that sounds like it would involve more disjoint parts).

2. To act on this I'd need more specifics about how things are different in Rails / Django / Laravel.

3. Addressed above. There is a step-by-step tutorial at least (https://biffweb.com/docs/tutorial/build-a-chat-app/).

First-class SQL support will be really nice when XTDB2 becomes stable--I'm planning to make that the default in Biff for the sake of familiarity, then anyone who wants to can switch over to Datalog easily.

I'm a clarinetist and got focal dystonia in my senior year of high school. My right pinky would contract whenever I tried to press a key with it; I had to stop playing. The doctor referred me to somewhere at the University of Washington and they ended up giving me a couple botox injections and also took some videos for the sake of research or something. The botox didn't seem to do much. I remember they were really cautious about the dosage since they didn't want me to lose the use of my hand for months.

After 2-3 years without touching the clarinet (I went on an LDS mission after high school), I picked it up again and the focal dystonia had subsided quite a bit. I still didn't have a ton of dexterity in my right pinky, but I never did, even before the involuntary contractions started. I suspect that my brute-force approach to practicing may have exacerbated the problem and helped to trigger the dystonia.

In any case I was able to play in one of the orchestras at college which is an experience I'm really grateful for. I haven't had much time to play since college, but I'm hoping to get back into it in a few years when the kids are older. And I'll definitely be taking more of a slow-and-steady approach to practicing.

> I would love to see a service appear that allows us to publish discord forums on the net.

Check out https://linen.dev. See https://www.linen.dev/d/tfos for an example (that's my own Discord community). Before discovering Linen I also made a proof-of-concept for something similar (https://discord.tfos.co); I might try to make some updates to that at some point so I can change the design.

FYI, the site is returning a 500 error currently.

Anyway, re: the substance of your post--I've used a few email services for the handful of small web apps I develop. I'm currently on Postmark and I really like it. You state "Nobody is building an exceptional developer experience" and "There isn't a single developer-first email platform in the market today", and I have to disagree. Postmark has great developer experience. And the specific points you raise aren't much of a rebuttal:

- Templates: your own react.email project already has a Postmark integration. More generally, templating solutions don't need to be tied to the email service. I prefer to use separate libraries for rendering and then pass off the html output to the email service anyway.

- Slow performance: Postmark has excellent delivery speed.[1]

- Poor observability: Postmark (and every other service I've used) provides events.[2]

- Designed for marketers only: Postmark is clearly designed for developers, as are several other services.

I am rooting for you! But I'd also like to say that before you trash talk competitors, please be sure you have substance to back it up, because some of us actually like those competitors :).

[1] https://postmarkapp.com/email-delivery

[2] https://postmarkapp.com/email-analytics

I've thought about this as well. Privacy is actually one impediment I think. If you make everyone's raw usage data public (so that anyone can use it to train their own recommendation model), some of the training data might be de-anonymizable.

However there's plenty of data out there that people are already happy to make public, so the privacy thing probably isn't a show-stopper. e.g. Reddit seems like it'd be a rich source of training data. Twitter too, if it were more open. I'd keep an eye on Bluesky!

The key question I think is "how do you create a recommender system that serves the user's interests instead of just the business's interests?" And how do you help the user have confidence that the system is serving their interests?

I think competition is a big part of that. You want options for different reading apps, so if e.g. the one you're using keeps pelting you with culture war content/low-value viral content/etc, you can switch to a different app that gives you better recommendations. And then that creates a market opening for apps that really do put the user's interests first. (After all, we can design algorithms to optimize for just about anything--the question is what the business incentives push us to optimize for.)

RSS makes competition a lot more feasible: since Yakread doesn't host any of the content it recommends, anyone else is free to make a reading app that has just as much access to content as Yakread does. Even if Yakread really took off, it would never have the same amount of lock-in/internal network effects as e.g. Twitter. My "grand vision" is for Yakread to become a medium-sized business, and for plenty of other companies to develop "mainstream RSS readers" as well.

That being said, even though I am similarly concerned about this issue, I don't think it'll be a concern for most users. Mostly Yakread is an attempt to make an RSS reader that can get mainstream adoption beyond the HN demographic, so most people in the target audience probably don't have strong opinions about algorithmic recommendations anyway. Hence you don't actually even need to know what RSS is to use Yakread. Although I've focused on RSS and the recommendation/ranking algorithm in this Show HN, usually I just describe Yakread as an app that helps you spend more time reading long-form content.

I think that's the best way to promote interoperability anyway: build stuff that has the right foundations, but focus on the immediate user benefits in your marketing.

As an aside, I really think HN should stop auto-removing the word "how" from the beginning of submission titles. This article was submitted a few months ago[1] but didn't get much attention, perhaps in part because the title was truncated to "we build platforms," which sounds like... marketing for an agency? I edited this post right after submitting to put the "how" back in.

(Another, more humorous example: https://news.ycombinator.com/item?id=30679859)

[1] https://news.ycombinator.com/item?id=34863648

Both good points! Upon reflection, I guess my main thought here is that from the publisher's perspective, it's difficult to provide a "subscribe with RSS" button and have it be as frictionless as a typical email subscribe form. e.g. even if the user does have an RSS reader, the publisher has no way to know that, let alone which RSS reader they use.

I was thinking about Mastodon while I wrote this--IMO it would be a more approachable experience for many people if Mastodon profiles had a typical email subscribe form where you could put in your own Mastodon username + server, in the same format as an email address (i.e. without the leading @), and then have it send a request to your server. Then next time I open Mastodon I'd have a notification with an "approve" button or something.

Of course that may just open up a whole other can of worms around spam signups, so that may or may not be a worthwhile train of thought.

Their email verification endpoint has been hanging for me; disabled it yesterday. Sending seems to be fine at least.

Out of the many complaints I've seen leveled at Substack, I honestly can't think of a single time where someone was complaining about their default use of single opt-in. That's not to say you're wrong--however, as best as I can tell, it doesn't seem to be much of an annoyance for most people.

Ah, well that's encouraging then! Perhaps you can add that query to an automated report/dashboard in case the conversion rate decreases as the service grows.

Thanks for making this in any case!

Email isn't terribly expensive to send--a common rate is roughly $0.80/1,000 emails. It's absolutely dirt cheap ($0.10/1,000 emails) if you can get past the application for AWS SES. (I didn't--don't know the magic words I guess!--so I'm a happy Postmark user instead.)

This looks really nice. I've been fiddling around building newsletter-adjacent products for a few years, and I've been wanting a simple Substack-alternative* that's good for casual use so that I can recommend it to users.

Can I make one request? Please provide single opt-in as an option! v2 invisible Recaptcha is effective for stopping bots, and most of the time people won't even be shown a challenge. Double opt-in confirmation emails only have about a 70% conversion rate in my experience (and that's counting only people who get past Recaptcha), so you lose a big chunk of subscribers. I almost started using Ghost a while ago for my own newsletter, but no single opt-in is just a deal breaker for me.

See also https://mailchimp.com/resources/why-single-opt-in-and-an-upd...

*Substack _is_ good for casual use, but I have various beefs with them, the main one being that they're trying to build yet another platform instead of being part of an ecosystem.

Yep! You can think of email as a version of RSS that regular people actually know how to use ;)

I think it's worth doing! Just make sure the posts link back to the original so people can see the context if the comment looks interesting.

See my other comments:

- https://news.ycombinator.com/item?id=33990568

- https://news.ycombinator.com/item?id=33976289