A Sufficiently Complex Elm Application
Charlie Koster

I had a similar experience to you. I had done some rather contrived things with Elm, started understanding it intuitively, and wanted to take the next step.

For me, I wanted to focus more on “app” and less on “web.” I wanted to do something that would not traditionally be done in a browser, whether it be for performance reasons or the fact that managing complexity in javascript is a never-ending battle.

I ended up writing a proof-of-concept remote debugger for an emulator I was writing. It went better than expected. I continued adding features, thinking of progressively more complex things to do. I never ended up hitting a wall, or felt that the complexity was so out-of-hand that it stopped being fun.

Eventually, I had something that was like, legitimately useful. It was no longer a proof-of-concept but instead a tool that I use and will continue to use as I develop my emulator. In fact, I see the remote debugger as something that will make my emulator novel, as opposed to yet-another-NES-emulator.

With all that being said, there were pain points, but again, they are specific to my use case — Things like support for binary APIs. I was able to sufficiently hack around these issues, but I only expect these things to improve.

I have a quick-and-dirty silent demo here: https://www.youtube.com/watch?v=5JlHSK6BeKI. Links to source are in the youtube description.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.