Phantasy Star remains to this day my favorite RPG. I was the kid in the neighborhood who's parents bought a SEGA Master System instead of a NES. I would play Final Fantasy a bit over their houses but it always paled in comparison to Phantasy Star. I recently replayed it on Nintendo Switch. Still a very challenging RPG and stil feels great.
I agree that borrowing against unrealized gains is crap, it's lead to major economic divide. However, just make borrowing against unrealized gains illegal. Taxing unrealized gains is the wrong solution for a real problem.
I don't know if closing the gap on features with Boa and hardening for production use will also bloat the compilation size. Regardless, for passing 97% of the spec at this size is pretty impressive.
You may be correct, but the rate of change in baseball is glacially slow compared to the other sports. One of baseball's intrinsic values is it's legacy, tradition, and history. Some may scoff at that, and I think there are good arguments against legacy/tradition as a reason to withhold change, but there are a lot of people out there that believe this. The MLB Commissioner's have largely been tasked with protecting that tradition and history.
I tried to do this a few weeks ago, I tried to build a NIF around an existing C lib. I was using Claude Opus and burned over $300 (I didn't have Pro) on tokens with no usable results.
tldr; we're building a headless browser in Elixir that will embed on device, communicate to the native 1st class rendering engine (i.e. SwiftUI, Jetpack Compose, WinUI3, etc...) via disterl, and allow for web-like ergonomics to build truly native SSR applications.
The README for Elixir Pack is a bit focused on the LiveView Native project but that documentation will soon be updated to remove mention of it.
This is one of the fundamental differences for what we're doing. We are not building a write-once-run-everywhere solution. SwiftUI will have its own templates, Jetpack (Android) will have its templates, WinUI3 will have its templates.
The LVN Elixir libraries are pretty much done and those really shouldn't change out side of perhaps additional documentation. I have been back and forth on the 2-arity function components that we introduced. I may change that back to 1-arity and move over to annotating the function similar to what function components already support. That 2-arity change was introduced in the current Release Candidate so we're not locked in on API yet.
What is changing is how the client libraries are built. I mentioned in another comment that we're building a headless web browser, if you haven't read it I'd recommend it as it gives a lot of detail on what we're attempting to do. Right now we've more or less validated every part with the exception of the overall render performance. This effort replaces LVN Core which was built in Rust. The Rust effort used UniFFI to message pass to the SwiftUI client. Boot time was also almost instant. With The Elixir browser we will have more overhead. Boot time is slower and I believe disterl could carry over overhead than UniFFI bindings. However, the question will come down to if that overhead is significant or not. I know it will be slower, but if the overall render time is still performant then we're good.
The other issue we ran into was when we started implementing more complex LiveView things like Live Components. While LVN Core has worked very well its implementation I believe was incorrect. It had passed through four developers and was originally only intended to be a template parser. It grew with how we were figuring out what the best path forward should be. And sometimes that path meant backing up and ditching some tech we built that was a dead end for us. Refactoring LVN Core into a browser I felt was going to take more time than doing it in Elixir. I built the first implementation in about a week but the past few months has been spent on building GenDOM. That may still take over a year but we're prioritizing the DOM API that LiveView, Hotwire, and Livewire will require. Then the other 99% of DOM API will be a grind.
But to your original point, going the route of the browser implementation means we are no longer locked into LiveView as we should be able to support any web client that does similar server/client side interactivity. This means our focus will be no longer on LiveView Native individually but ensuring that the browser itself is stable and can run the API necessary for any JS built client to run on.
I don't think we'd get to 100% compatibility with LiveView itself without doing this.