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).
Actually, it was in person the one time we had it but we brought in the speaker from out of town. It was Glenn Vanderburg, who is is a smart and fabulous human being around my age (possibly a bit older) and he gave a great talk. I'll keep noodling on what the best reincarnation would look like. I think we possibly recorded it, I'll have to try to find it...
I just turned 50 in October, and have been coding my entire career plus. I still love and enjoy coding, and feel like I have more to contribute by far than I did early in my career. I have founded a smallish dev studio in Cincinnati (Launch Scout) that I started with a few other developers in 2009. I've tried a few different roles as the company has evolved, but eventually realized that I love coding and helping other people get better at coding. Management, organization leadership, etc, are all important but I've had to (with some misgivings at times) allow other people to fill those roles so I can do what I'm really best at. It can be very frustrating to see our industry fail to learn sometimes. I think the lack of TDD being as widely adopted, and the wide embrace of technologies like React that make development incredibly more complex than is necessary are my two big sources of frustration right now. But I still love learning, and love seeing new ways to make things much better. I still love building things. I'm inspired when I remember how my good friend Jim Weirich was actively coding and teaching right up until he passed away. Right now, my hope is to follow in his footsteps. I think there are a few of us who are like minded. A few years back I tried to organize a group I called Geek Geezer Guild. It might be time to resurrect that.
I spent several years building backbone applications, and recently have been doing a lot of work with Ember and Angular. For most of the applications I work on, I find Angular to be a really excellent choice. It fits in very well as part of a larger app with "islands of richness". It's really quick to learn and become productive with. The ecosystem of existing components (directives in angular parlance) is huge. The choice of plain old html for templates means I can take screens of html/css produced with our design team and iteratively turn them into an angular app. And last but NOT LEAST everything is very easy to test thanks to DI.
I started with an approach like yours, but really wanted the ability to have a subview helper function that inserts the subview in the right place in the parent's template. In order for this to work, I need the helper function to output the subview's element but defer rendering the subview until the subview's element is in the DOM. One case I really feel I see benefit from this is in creating reusable subviews for form elements, but I wanted to choose a simpler example to show the approach. Could be the example I chose was too simple.
Read to the end, that's pretty much what I end up doing in the final version. I create the TableRowView in the helper and then listen to the parent views "rendered" event so the row view knows when it's element is in the DOM and it's safe to render itself.