What I feel is missing from Parenscript is runtime macro-expansion, hard to do without using JS to build the AST.
What I feel is missing from Parenscript is runtime macro-expansion, hard to do without using JS to build the AST.
In practice though, it looks closer to C/ASM. The author even wrote comments in C. This is the first time I've looked at an actual program written in the wasm text format and it's pretty interesting to see how one would actually use it. Very neat.
s2 has the advantage of being much smaller (a little over 2kb compressed), and faster on benchmarks[0] and probably real world performance. The API tries to get out of your way as much as possible. The dependency tracking is seamless by using Proxy.get trap. There's no forced separation of models or views, it's all data.
I wrote it because I had to make a complex UI with streaming WebSocket data work smoothly.
[0] https://krausest.github.io/js-framework-benchmark/current.ht...
To play the devil's advocate, I would suggest that there is price discovery at play here and people + corporations are willing to pay for what they get value out of. Which is suggesting that many companies don't get much value out of Babel or it is one of many tools utilized in a toolchain. The value proposition is to be able to run new JS in old JS runtime, which may be less valuable now than it was 5 years ago, since evergreen browsers exist and outside of stale corporate environments, most browsers are auto-updating now.
This looks neat tho.
If this gets more features I can see it being a contender.
There are a few benefits: removing features is dead simple, just delete the whole feature module, and there's no conditional branching in the base application.
There are some drawbacks too: the base application must have entry points for the feature modules to overwrite. Usually the default values are no-op or some default behavior. Features also must implement setup and teardown, which can take longer to write than a conditional.