miso VS hevm

Miso does support jsaddle, docs mention this under the "Live reload with jsaddle" section, although it could be more prominent.

For those interested in DOM-related benchmarks using GHCJS. Miso has some benchmarks here: https://krausest.github.io/js-framework-benchmark/current.html (Ctrl+F `miso`)

ghcjs is the way to go for you, and soon it might be asterius. i do not know how hard it is to set ghcjs up without a framework. but frameworks like obelisk (based on reflex-dom), shpadoinkle, and miso automate that for. i personally like obelisk for its functional reactive programming but it can get awkward and get in your way. so if gui programming is just a means to the end of this one small application and you are not really interested in it nor functional reactive programming, shpadoinkle or miso might suit you better. miso implements the elm architecture (also "TEA", "functional model view controller") and shpadoinkle implements something directly equivalent to the elm architecture. but shpadoinkle achieves more composable widgets by minimalizing the elm architecture. so i recommend shpadoinkle for its better concept although miso is more mature.

via ghcjs (miso, etc.)

I've built miso, https://haskell-miso.org and it does use the VDOM appraoch. Svelte uses static analysis to compile down to the minimum number of DOM operations required to run your specific app. I think it's the future. This would only be possible in Haskell w/ GHCJS, since you'd need the GHCJS runtime to support it.

hevm - written in Haskel

However, since we are using a pure Solidity stack, writing tests with ds-test and running them with dapp.tools or foundry, this was a bit more complicated.

There's also jshon which is a simple stack-based DSL for constructing JSON from shell scripts.

http://kmkeen.com/jshon/

It's written in C and is not actively developed. The latest commit, it seems, was a pull request from me back in 2018 that fixed a null-termination issue that led to memory corruption.

Because I couldn't rely on jshon being correct, I rewrote it in Haskell here:

https://github.com/dapphub/dapptools/tree/master/src/jays

This is also not developed actively but it's a single simple ~200 line Haskell program.

It fits into the stack the same way that Hardhat, Truffle, and Dapp Tools do.

I find it insane that much of Solidity code testing is still happening in external languages. I've recently found https://github.com/dapphub/dapptools and that has blown a lot of my confusion away.

Honourable mention would be https://github.com/dapphub/dapptools for those who prefer UNIX-like tooling, but I'd say for the most part Foundry seems to be the better choice now.

Firstly, I'm warning you that I'm going to shill some amazing things in the Ethereum ecosystem. I would even go so far to say as some of these things are so positive sum and self-evidently public goods that shilling them in the ethereum subreddit should be considered neutral. For example, GitcoinDAO is a place where we all have the permissionless ability to coordinate in building tools and services, like dapptools, for all open-source software, full stop. There's ways to fundraise in public besides joining Discord or sliding into Twitter DM's, like Juicebox. There is a plethora of industry leaders exploring decentralized hosting for bluechip-scale applications, such as Skynet.

Dapptools is another framework that has nothing to do with JavaScript.