In Korea (and probably other cultures) the whole group orders items together and shares. So the splitting math is a little different:
- Simplest: just divide total by N people
- Different subtotals for food, alcohol, and drinks
- The most complex is probably: food is split evenly, but individuals claim beverages. (And there are some cases where certain food items are also claimed.)
Usually one person is the "treasurer:" they pay the entire bill and make a chat room to finalize with other members (share a table of who owes what and maybe send payment requests)
Interestingly, KakaoTalk has a built-in feature to split bills in this manner. It's not intuitive to use, so a lot of people just do it manually.
This is actually very similar to our implementation. The host pays the bill then users go in and either claim an entire item or split the item between multiple people. Each person is then assigned an individual bill with quick links to pay the host!
Oh~ I missed "Shared items split cleanly" in the copy. And I didn't feel like creating a new account to check it out. Would be nice if you didn't have to sign up/login. (Maybe like how a shopping cart allows creating an account at checkout)
(And I initially thought "TabChop" would be a windows management tool: split windows...)
Svelte used to have compile-time reactivity, but switched to runtime reactivity via signals: https://svelte.dev/blog/runes
I'm curious if Coi will also suffer from the drawbacks of compile-time reactivity. Or as its own language that doesn't have to "fit" into JS, can Coi side-step the disadvantages via syntax?
Runes allowed simpler Svelte syntax while making it more clear, consistent, flexible, and composable.
I suspect Svelte’s heavy lift with compile-time reactivity came largely from trying to infer "reactive intent" from standard JavaScript code. Since JS is so dynamic, the compiler had to rely on heuristics or strict assignment rules
Coi avoids this ambiguity because the compiler can definitively trace usage patterns. Since mut variables are explicitly declared, the compiler essentially just looks at where they are used in the view {} block to establish dependencies at compile time. This static analysis is precise and doesn't require the compiler to "guess" intent, effectively preserving the benefits of compile-time reactivity without the fragility found in dynamic languages
Instead of directly passing the CSV data to the LLM, have the LLM write a script that will read the CSV and output the trends. (Then it can run the script and report on the results.)
I wanted to figure out reasonable values for range of daily/hourly precipitation for https://weather-sense.leftium.com. Claude wrote a script to call the Open Meteo API to collect hourly stats for a few cities for an entire year (8000+ rows), then just reported the 80th, 90th, etc percentiles and recommended ranges.
I think web sites are often a "feature" or means to an end. It may be better to focus on the benefits. (Like more sales/revenue. Reduced customer support. Etc.)
For example, I had a client who wanted me to build a web site that hosted her piano lessons. She was sure if only they were hosted somewhere, people would flock to it.
I tried to tell her what she really wanted was marketing and sales, which the web site could be a small part of. She insisted so we built the site anyway. I don't think it's ever gotten any sales...
I agree, and that’s exactly the failure mode I’ve seen too.
What seems to work better is when the “website” isn’t treated as a sales or marketing engine at all, but as a low-friction publishing surface for information that already exists and already has an audience.
That’s actually what I’ve been experimenting with www.sheet2notice.com: instead of building sites, letting people expose a public, read-only page directly from something they already maintain (like a spreadsheet). No funnels, no SEO promises — just a clean, auto-updating view over an existing workflow.
In that setup, the page supports whatever goal already exists (updates, coordination, trust), rather than pretending to create demand on its own.
Based on actual convention used by (dance) groups in Korea to use Google forms for event sign ups. It doesn't require changing their workflow: the original forms still work (as a fallback), they just need to share a different URL based on the form ID.
I've shown Veneer to several dance group organizers who use these Google forms on a regular basis. While two people have embraced the concept and registered their custom domains for their forms most people are surprisingly hesitant to use Veneer. Objections I've heard:
- Already have a workflow; don't want to learn something new
- Know how to program themselves, can make themselves if needed
- Already registered an unused domain, but have other plans for the site
Each Veneer page has a link to the original Google form and sheet. (Also a link to the full MIT-licensed source.) Here is the only one that is "in production:" https://viviblues.com
This is a really useful data point, thanks for sharing it.
The hesitations you listed line up closely with what I’ve been seeing too — especially “already have a workflow” and “prefer simple”. It feels like most resistance isn’t about capability, but about introducing anything that feels like a new tool, even if it’s thin.
That’s actually the tension I’ve been trying to solve as well: keeping the original workflow completely intact, and making the public layer feel more like a passive view than something you have to “adopt” or manage.
- If you just paste an outerHTML from the dev tools, AI coding agents can immediately figure out what it will look like; debug styles; etc.
I personally preferred PicoCSS for a long time. Pico was nice, but it injected a lot of CSS var noise into the dev tools and I started fighting with the breakpoints.
More recently, I've been just doing handcrafted CSS with a bit of OpenProps.
> It removes a sense of artificial precision that doesn’t really exist because weather forecasts fundamentally have very high uncertainty and error bands.
So true.
Open Meteo supports 28 different WMO weather condition codes[1]. Most weather apps only support half as many. (Just "rain" instead of light/moderate/heavy rain.)
Showing all 28 is less helpful because of the noise. More useful just to show it might rain for a period of several hours vs oscillating between light rain and heavy rain. The light vs heavy precision wasn't worth it when there was high uncertainty whether it would even rain at all.
So https://weather-sense.leftium.com consolidates hours with similar weather conditions into a single segment by default. You can click on the weather icons at the left of the plots to toggle the original unconsolidated view.
- Simplest: just divide total by N people
- Different subtotals for food, alcohol, and drinks
- The most complex is probably: food is split evenly, but individuals claim beverages. (And there are some cases where certain food items are also claimed.)
Usually one person is the "treasurer:" they pay the entire bill and make a chat room to finalize with other members (share a table of who owes what and maybe send payment requests)
Interestingly, KakaoTalk has a built-in feature to split bills in this manner. It's not intuitive to use, so a lot of people just do it manually.
reply