It is quite beneficial for people who aren't writing python. And for them managing jupyterlab installations is a bit of pain.

I would like to use this with xeus kernel for sql (which is also native) and if this reduces the resource consumption of that setup significantly, its a big plus for me.

The README says the savings is ~75 MB. In most notebook workflows you’re at most running a couple at once. Saving <1% of my system memory doesn’t let me do anything I couldn’t do before. This also isn’t going to add concurrency/parallelism to your SQL unless xeus has some special magic that this is somehow able to exploit.

I was primarily talking in the context of shared server deployments for teams

uvx --from jupyter helps with that significantly.

I use teable with sqlite - it has a kanban board view

Just because some edge cases aren't supported, doesn't mean you can't take advantage of the type-safety in the rest of the application.

This particular feature seems to have nothing to do with the query builder even, just the migration system. You can always write just those specific migrations manually.

Does using template strings not compromise with type-safety? The drizzle example will be a compile time error for example if id wasn't a numeric column.

Seems a strange design choice for a library that claims to offer a type-safe sql builder.

Right the SQL expression is validating that you're referencing tables that are included in the query and that all column references exist, not that the parameter value matches the property type, although SQLite and MySQL does allow you to use a string to query an int column, e.g:

    SELECT * from Contact where id = '1'

With that said you can achieve something similar in litdb with a custom expression:

    const eq = <T,V>(ref:(x:T)=>V, value:V) => (x:T) => $`${ref(x)} = ${value}`

Which will type check that the value matches the column type:

    .where(eq(c => c.id, 2))

and fail type check when they don't:

    .where(eq(c => c.id, '2'))

Examples of other custom expressions: https://litdb.dev/#composable

Understood. IMHO it would be desirable to have built in support for all common crud operations to be end-to-end type-safe.

Typst is great, but really doesn't really serve the primary use case of mdbook which is building documentation websites or digital knowledge gardens that are accessible as a website.

If you are typesetting a research paper or writing a technical book for print publication typst is a great solution, but for a lot folks not having web support is an absolute dealbreaker.

Apparently HTML output support is coming for typst. I'm very keen, since to be honest markdown just isn't powerful enough to support a lot of the typesetting I want to do. For example, using markdown you can't put text in boxes, reuse styles, link references to diagrams or sections, number headings, do math, and so on.

All of this stuff is crazy useful in typesetting. I love markdown, but its missing too many features.

It has been coming for a while. But I am looking forward to it. It is the only thing preventing me from using it.

This is a great concept. I'd love for this to be a part of a notetaking solution that I can run locally.

Curious what your long term plans are.

I am also curious if it supports taking (entire) tables as inputs and creating derived tables from them which can then be presented as chart etc. That would be really powerful.

I was trying to get a sense of what people like and find useful. Your suggestions and comments are helping to figure that out.

I am planning to add support for entire tables, like one coming from a gSheet, and then present data from it. But not there yet, if you have suggestions, please add them to the feedback form https://forms.gle/A8Q8WAG8zj4sLvwQ7

It would be cool if you could run SQL queries against lcoal SQLite or DuckDB instances and generate tables

There is also an official typescript implementation [1] and sops supports it natively [2].

[1] https://github.com/FiloSottile/typage

[2] https://github.com/getsops/sops?tab=readme-ov-file#encryptin...

Foliate's core function is an ebook reader and not library management. Once installed you can double click your epubs to open them on foliate - it will not move around your stuff.

There is a library view in the app but it is mostly a history of recently accessed files.

I started using this a few hours ago and so far am really pleased with the experience. Vim keybindings mostly work as expected and TS integration works great oob. I can totally see this becoming my primary editor going forward.

Nice. I use pgcli for postgres and wanted something similar for sqlite.

same core devs.