How do you know what your values are? I've spent a lot of time thinking about this after listening to this podcast episode: https://rationalreminder.ca/podcast/238
The interviewee gives a good map for figuring out how to figure out your values.
i.e. something like this: CREATE INDEX idx_events_type ON events(json_extract(data, '$.type'))?
i guess caveat here is that slight change in json path syntax (can't think of any right now) can cause SQLite to not use this index, while in case of explicitly specified Virtual Generated Columns you're guaranteed to use the index.
For home use I have got a bunch of very cheap ($20 each?) 2.5gbit switches with 4x 2.5gbit and 2x10gbit SPF+ off aliexpress. I've ran fibre round my house and it works perfectly.
WeasyPrint is great, but PlutoPrint takes a different angle: the engine is all C++, so it’s faster and lighter on memory. It can render directly to PNG as well as PDF, and has stronger SVG support.
I've used it extensively myself, for creating complex web apps with many (nested) components interacting with each other.
I don't understand why Lit hasn't gained more popularity, because for me it is basically React, but then more browser-native, much less boiler plate, and much faster rendering. There are some things you have to get used to, but when you do it doesn't limit you in any way.
The JS world leaves me more and more perplexed.There's a similar rant about forms, but why is this so hard? Huge amount of dev time spent being able to execute asynchronous functions to the backend seamlessly yet pretty much every major framework is just rawdog the url string and deal with URLSearchParams object yourself.
Tanstack router[1] provides first class support for not only parsing params but giving you a typed URL helper, this should be the goal for the big meta frameworks but even tools like sveltekit that advertise themselves on simplicity and web standards have next to zero support.
I've seen even non JS frameworks, with like fifteen lines of documentation for half baked support of search params.
The industry would probably be better off if even a tenth of the effort that goes into doing literally anything to avoid learning the platform was spent making this (and post-redirect-get for forms) the path of least resistance for the 90% of the time search params are perfectly adequate.
I don't use HTMX but i do love how it and its community are pushing the rediscover of how much simpler things can be.
CAC is great for detecting calcified plaque in your coronary arteries. But before you have calcified plaque, the above risk factors tell you about the buildup of soft plaque. And 4 out of 5 of them are modifiable through lifestyle, exercise, and medication.
I'm guess that since this is an academic paper and not say, a website or GitHub repo, that you're in school. But given the research paper nature of this, did you want to contrast and compare to other methods of authoring web components?
There are many existing and popular approaches out there. Is your take easier, faster, or more capable? That discussion would be interesting.
I just published a deep dive into the Claude 4 system prompts, covering both the ones that Anthropic publish and the secret tool-defining ones that got extracted through a prompt leak. They're fascinating - effectively the Claude 4 missing manual: https://simonwillison.net/2025/May/25/claude-4-system-prompt...
I have changed from Copilot to Cline with Claude 3.7 and it is a total gamechanger. For some one like me being able to describe a multi file edit is really empowering. I hate that kind of busy work
- I can write for-loops, conditions, etc. in the same language I write my logic in with the same TypeScript and (Vscode) IDE support (e.g. refactoring, formatting, error reporting) vs using a special template language + IDE plugin.
- I find HTML templates really ugly and harder to read in that your dynamic logic code gets lost inside the static markup and presentation code e.g. `<li v-if="items.length > 2" v-for="{ id, text } in items" :key="id" class="card card-body fw-bold small"> {{ text }} </li>` vs `{items.length > 2 && items.map(({ id, text }) => (<li key={id} class="card card-body fw-bold small">{text}</li>))}` (still quite ugly but most of the logic is on the outside now).
- I can easily assign chunks of HTML to variables or generate HTML snippets via concise functions in regular TypeScript instead of being forced to create a new verbose component via HTML templates each time e.g. the arrow function above can be assigned to variable and reused. HTML templates feel very limiting in comparison.
It's sometimes awkward finding the JSX syntax (like for using Vue slots), but this is more because it's less common.
Would be curious of others who have tried this Vue 3 + JSX combination!
Would the same teams at Google be interested in implementing better line breaking? The Japanese text in the screenshot in the article breaks words in half. There's a library that does it already; it just needs adding to Chromium: https://github.com/google/budoux/
Would be nicer if it would distinguish (just varying line thickness) between footpaths, roads, highways etc. Many European cities look messy in this view.
Best way is to use ChatGPT + Whisper + ElevenLabs and a prompt where you tell the LLM to answer in German but to tell you what mistakes you made and what you should have said instead in your own language. Instead of this lazy "immersion" method German schools use in order to avoid speaking in any other language so students never understand what went wrong.
I read a lot of blog posts from both sides in the most recent big "web components vs frameworks" brouhaha a month or so ago. The conclusion I came to was that both sides' arguments were mostly correct but orthogonal to each other, so neither side is ever going to convince the other because they're not really seeking the same goal.
The pro-web-component folks argue that WCs are standardised and will continue to work basically indefinitely regardless of the ebbs and flows of popular libraries, and because it's easier to progressively enhance and therefore more accessible. This is correct, and those points are valuable if what you seek is a way to add resilient islands of interactivity to your document.
The pro-framework folks argue that in their model where the entire UI is a function of state, WCs are incredibly cumbersome, because all you really want from a component is to be a smaller function with which you can compose part of the whole. They are not nearly as concerned with maintaining that component under React vX in five year's time, because the entire system is written in React vX. The components are not maintained or used as individual units unless you are shipping a library. This is also correct, and those points are valuable if what you seek is an effective way to break down complexity in your application UI.
Of course, many (maybe even most?) SPAs should be documents with progressive interactivity—it involves less fighting with the fundamentals of the web (which is, ultimately, still based around documents) and therefore offers better performance and accessibility with less effort. SSR for frameworks is an absurdly complex solution to a problem that doesn't exist if you can just send a complete document right to the browser.
But, likewise, implementing a genuine high-interactivity web application using web components would be far more difficult than using a framework, and I am certain would result in re-implementing some sort of reactive UI/function-of-state paradigm anyway.
Personally I think it's kind of a pointless debate, until and unless we get something that is close enough to <insert popular JS framework here> + SSR built into the browser. I don't know how that would work or whether it's even possible, but at that point the set of standards would actually cover all of the problems everyone is trying to solve and it would be worth arguing whether or not to use them.
Somewhat tangential but I've found Claude 3.5 to be ridiculously good at doing this kind of prototyping with React, and you get the preview immediately in the artifact pane to the right of the chat. Mind you I don't ever use React (I'm writing a desktop app in Rust), so I'm probably as unbiased an audience as it gets.
Here are a couple of examples of things people asked for help with and I just iterated with Claude for 5-10 minutes on (code upfront and gif demo at the bottom):
I think given the sheer amount of training data on React, these models tend to really hit it out of the park when they are allowed to use it. Part of me thinks the best approach is to have it model in React first and then translate it to whatever other language/framework you need it in
Another shoutout for leptos, which I'm also currently using, and loving (except for compile times (a Rust problem, not a leptos problem), and other smaller annoyances).
A few of notes regarding AOT compilation if you would like to have the best experience:
1. print* functions with "%A" format do not work because "structured output" uses reflection patterns that the linker cannot analyze. You can easily replace them with string interpolation that F# now has. I carry around these bindings:
open System
let println s = Console.WriteLine s
let print s = Console.Write(x: string)
and use them as
println $"Hello, {thing}"
2. AOT compilation is not a scripting environment so accessing fsi args does not work, here's the snippet that I use for it:
open System
// Detect fsi, if not - slice appropriately
// You do not need this if you know that you will be
// only compiling the script or only running it with fsi
// just use the offset of 2 or 1 respectively :)
let args =
let args = Environment.GetCommandLineArgs()
if args[0].Contains "fsi.dll" then args[2..] else args[1..]
// Use args in some way
args |> Array.iter println
3. For quickly publishing script files you may want to define a (fish) shell function like this:
function fspk
set name (string replace '.fsx' '' $argv[1])
fspack $argv[1] -f net9.0 --aot -o . \
/p:InvariantGlobalization=true \
/p:OptimizationPreference=Size &&
rm -rf ./$name.dbg ./$name.dSYM
end
This will reduce the binary size and will give you just a single executable for every `fspk my_script.fsx`. The binaries do start at ~4MB but beyond that - they scale efficiently with dependencies.
4. Except what is explicitly noted in repo, other scripting features work like referencing nuget packages or importing files. I did not expect to like this as much as I did, it's incredibly productive and you can just throw a few files together while having fully statically typed scripting environment and built-in package manager.
You can also get Ionide for VS Code for language server, autocomplete and debugging support.
The interviewee gives a good map for figuring out how to figure out your values.