What are the remaining gaps in the elixir ecosystem?

[sodapopcan]

Are you saying this having tried Ash?

[andyleclair]

I mean, we have :wx and :gl as part of the erlang stdlib, but idk if you’ve used it, it’s not uhhh the most ergonomic

[shishini]

A JDBC like library

It seems we have different libraries for MS SQL, Postgresql, SQLite, etc…

I dont think Elixir have any libraries to connect to OLAP databases or engines or Data Lakes

[cmo]

There are one or two DuckDB and several Clickhouse libraries.

[andyleclair]

GitHub - elixir-explorer/adbc: Apache Arrow ADBC bindings for Elixir

[eahanson]

@apoorv-2204

we dont have fully fledged .xlsx writer

What kinds of things are missing from the various XLSX libraries?

[woylie]

I love working with LiveView, but I yearn for the opposite: Local-first applications that can run completely on the client side and optionally sync with the server when back online.

I’m aware of:

• Local-First LiveView Svelte ToDo App - Here, Svelte assumes the sole responsibility for the client/offline side.
• Electric SQL

I haven’t done any experiments myself in this direction yet.

[mau013]

Have you checked out Hologram?

I think it’s worth a look.

It’s also discussed in its forum page here.

I’ve seen Hologram’s creator @bartblast very active here and in other forums (HN), so he might want to chime in.

[hauleth]

If you really want that

https://www.erlang.org/doc/apps/odbc/odbc.html

But honestly such interfaces have problem, that they need to target lowest common denominator. And by looking how easy it is to work with binary protocols in Elixir, I do not feel much urge for that “common interface” thingy. Actually db_connection can treated as such common interface as well.

[woylie]

I have seen Hologram, but I didn’t place it in the same category mentally. Isomorphism generally means something different from local-first, so I’m not sure the goals are the same here. Local-first applications tend to work with databases (i.e. indexeddb-based) on the client side and reconcile data using CRDT when coming online, but you can also use the whole application offline without ever connecting to a server for data synchronization. It doesn’t sound to me like Hologram is occupying that space.

(see also Evolu and Jazz)

[mau013]

You are absolutely correct. I don’t think Hologram occupies that space.

When I read local-first and saw the Svelte reference my head immediately went to the server vs client state paradigm. (I.e. Liveview vs JS - with all DB conns being managed by the server).

[MatteoGauthier]

I think the Elixir ecosystem still lacks good documentation (beginner-friendly, guides, recipes), courses, example projects, and bootstrap projects. For web developers, seamless frontend integration with UI rendering libraries like React or Vue is also needed.

[cschmatzler]

• working language server
• better linting. Styler is getting there, but it’s an internal tool without configurability
• focus on accessibility in the ecosystem. There’s not a single component library out there that gets even 5% there
• better database tooling. Automatic schema diffs and migrations that work with plain Ecto would be a great start
• analytics

[cmo]

@eahanson

What kinds of things are missing from the various XLSX libraries?

Anything other than basic formatting IIRC. e.g. can’t do tables.

[hubertlepicki]

@sodapopcan

Are you saying this having tried Ash?

No. And I appreciate the suggestion. I looked at it several times, and I know some good people that enjoy it very much.

From what I saw, I did not like it at all. It seems very resource-oriented, i.e. database driven. Which is also what Rails by default is, to be fair. You define schema and it creates you all sorts of interfaces on top of it, which is great for some apps but in my experience it’s often a trap for larger, more complex systems. A ticket to make a small UI change can turn into a huge endevour because your schema and more importantly - data - does not fit the use case anymore. I would love something with UX-first approach, that operates on the level of Forms and validations and Workflows that take in forms and perform actions if the forms are valid. I’ve been using this approach for both Rails and Phoenix apps for almost two decades now and it’s IMHO much better than building the app around your database schema, especially if you derive functionality from it.

[lud]

Trailing commas. (A bit off topic I know, but every other language has them.)

[dimitarvp]

@hubertlepicki

I would love something with UX-first approach, that operates on the level of Forms and validations and Workflows that take in forms and perform actions if the forms are valid.

Any examples, reading through which would help us understand what exactly were you doing, in coding terms?

[hubertlepicki]

We’re probably getting off topic here if we go this way very much. Should we start another thread? That’s more of a thoughts about software architecture in general than Elixir specific. I don’t know what’s the forum policy on these discussions.

[dimitarvp]

@hubertlepicki

Should we start another thread?

Please do. I am super interested in this. I am quite sick of most DB<->language barrier libraries that I’ve seen in all my career. Looking for something else. I have ideas but I need to refine them by discussing with others.

[bartblast]

@mau013

Have you checked out Hologram?

I think it’s worth a look.

It’s also discussed in its forum page here.

I’ve seen Hologram’s creator @bartblast very active here and in other forums (HN), so he might want to chime in.

Thank you @mau013 for mentioning Hologram!

@woylie

I love working with LiveView, but I yearn for the opposite: Local-first applications that can run completely on the client side and optionally sync with the server when back online.

@woylie

I have seen Hologram, but I didn’t place it in the same category mentally. Isomorphism generally means something different from local-first, so I’m not sure the goals are the same here. Local-first applications tend to work with databases (i.e. indexeddb-based) on the client side and reconcile data using CRDT when coming online, but you can also use the whole application offline without ever connecting to a server for data synchronization. It doesn’t sound to me like Hologram is occupying that space.

@woylie - You’re absolutely right about placing Hologram in the isomorphism category rather than local-first applications. While Hologram currently focuses on isomorphism by automatically transpiling server code to JavaScript for client-side execution, my roadmap includes building a client-side database solution. This will essentially be a wrapped IndexedDB that synchronizes with the server database when online, handling schema consistency, migrations, and other database management aspects automatically.

@dimitarvp

Speaking of which, a proper cross-platform UI framework – probably made with Rust as there are several of them in the last years – and wrapped in OTP actors, would be probably the last ever UI framework invented. Or I hope so. Because having each UI element accept messages individually while still having “parents” is IMO the best paradigm for UI.

@dimitarvp - Your vision of a cross-platform UI framework aligns well with Hologram’s long-term goals. I’m working towards a single codebase solution that can deploy to web, mobile, and desktop while reusing UI components. Hologram already implements inter-component messaging, allowing components to communicate with each other. While I don’t yet have a supervision system, it’s on my roadmap for future development.

@hubertlepicki

A higher level and simpler (i.e. lower in code) web framework would be nice to have. Not even on the levels of Django, but Rails. Convention over configuration, simpler DB access interface that does more out of the box and requires you to write fewer queries, exposing fewer abstractions to the end programmer.

@hubertlepicki - Your description perfectly captures Hologram’s philosophy! When you mention wanting a higher-level and simpler framework with convention over configuration, it resonates with my DX-first mentality. I prioritize minimal boilerplate while maintaining the flexibility to implement solutions outside of Hologram’s happy path. I’m also planning a database layer that will support automatic client-server synchronization when online, with an interface that’s more streamlined than Ecto while maintaining its power.

---

It makes me happy to see that many of Hologram’s planned features align well with what the community is looking for. I’ll be presenting at ElixirConf 2025 and will be conducting a full-day training as part of the conference. I’m planning an intensive 3-month “coding blitz” to get everything ready for the conference, after which Hologram should be production-ready. I’ve been gathering lots of constructive feedback through different channels lately and doing extensive planning. I’ll be presenting a detailed Roadmap and 3-month development plan soon.