This is great, I think this is perfect use for web components and gives your customers trying to build a fully custom storefront a much better experience. I built something similar for stripe based sites a couple years ago but didn't get too much attention: https://elements.launchscout.com/
Really like what I'm seeing so far. It looks a lot like Sprae: https://github.com/dy/sprae one of my favorite things that no one seems to be paying attention to :) I use it on live-templates, which uses Sprae to connect a template to stateful backend in Elixir over Phoenix Channels: https://github.com/launchscout/live-templates
This sounds awesome. As a GA pilot and software developer, I can tell you that voice comms and the need to work with them will be around for a long time. Just look at all the feet dragging just to get ADSB adopted. I'd love to find out more and possibly get involved. Are you looking for help?
We've definitely experienced chaos when building large React apps. I don't think it's necessarily React's fault (though I'm not particularly a fan), I think the complexity is inherent in managing stage in both a client app and a server app. We've since moved to building apps with Phoenix LiveView and been much more productive. I've also built some libraries to give you the same benefits (single source of state on the server) when serving the front end in Elixir isn't an option: https://github.com/launchscout/live_state.
This sounds like a really excellent product, and I really love the description in this post of how you got there. Not working on anything just this minute that needs it, but I will definitely keep an eye out for opportunities.
The promise of being able to use any library from any language is really quite compelling, and that's what the WASM component model is about for me. It's pretty sad to say this amount of hate TBH
Once again, missing the point of unit testing. Unit testing is about improving the design of the software, and allowing the design to evolve through refactoring (which is effectively impossible without unit testing). E2E or integration tests are for catching bugs
The live-template element provides a connected, or "live" template that connects to a stateful backend application provided by Livestate. After connecting to a LiveState channel, it will
- render the initial state
- subscribe to state
updates and re-render on changes
- push events to a Livestate channel which may then compute a new state
If you squint really hard, you can think of it as HTMX meets Elixir ;)
Since you mention that state management is an unsolved problem with Web Components, I thought I would share a project that aims to bring a solution: https://github.com/launchscout/live_state. The basic pattern and idea of LiveState is "dispatch events, subscribe to state". The events and state updates are sent over a websocket connection, and the front end and back end libraries are a thin layer over Phoenix Channels. Currently, event handler functions are written in Elixir, but work is underway to allow them to be written in any language that compiles to WebAssembly.
We've been working on a project for the last few months to make it easy to add dynamic features to static or statically generated websites. We started with ecommerce (cart, add item) and have recently added forms and comment section elements and looking to keep expanding. We've got a decent demo video, and are looking for beta testers. It is all open source. The plan is to eventually charge for hosting and custom development.
Oh, and as far as the "shortage of Elixir developers". Unfortunately with layoffs in the startup community it's probably easy to hire just now. Even when that was not the case, we've had great success with brand new apprentices picking up the language and being productive very quickly. We recently had an apprentice go from brand-new to keynoting Elixirconf in two years. She is super amazing, but still, other apprentices have also done very well.
We have switched to Elixir and Phoenix as our go to stack gradually over the last 5 years. We've found that LiveView in particular, with it's ability to avoid a separate front-end framework altogether, has let us deliver applications to clients in a significantly more productive way. We were a rails shop back in the day, and were able to build things very quickly. When the whole front-end framework thing got big, it slowed us down a lot because we were building two applications, essentially. Now that we are able to go fast again we (and our clients) are enjoying things a lot more.
I should also say that if you do need to use a separate front-end for whatever reason, I've built a thing called LiveState: https://github.com/launchscout/live_state that lets you keep things far simpler and gives a "LiveView like" experience.
Been using Lit for a few years now, it just keeps getting better. It does what it does, and stays out the way. Please don't call it a framework though, the best part of Lit is that is basically some (very lovely!) sugar over standards built into your browser. And as browsers keep improving (at an amazing pace IMO) Lit keeps getting smaller, which might be my favorite thing about it.
I ran across this wonderfully written article recently. I've lived through almost the entire history of the web myself as a developer, and it has led me to the same conclusions as the author about why it behooves us to start building our apps with web components (custom elements).