At my work, I have a somewhat clever (or idiotic) technical solution to the problems of feature flags: they are actually implemented as feature modules that monkey-patch the base application in runtime.
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.
That sounds kind of complicated to reason about and thus pretty dangerous for feature flags. At my work, we use them to do partial rollbacks in case the new feature/behavior has unintended consequences. Deployments might take weeks to complete globally, so doing a hotpatch or code rollback is incredibly expensive compared to toggling a feature.
Really reminds me of Parenscript[0], which is a subset of Common Lisp that transpiles to JS with no runtime. It's basically a thin skin around JS and it feels more like writing JS with a Lisp syntax.
What I feel is missing from Parenscript is runtime macro-expansion, hard to do without using JS to build the AST.
Ah, I remember seeing this a long time ago. It seemed like something CL fans would enjoy, but to me it felt verbose. I guess this is my Clojure preference showing.
Regarding runtime macro-expansion - since Dak is written in JavaScript, it comes for free.
If I had to guess, it's because the WebAssembly Text Format is S-Expressions, similar to the target language, Scheme. Also, less tooling involved to build the binary, since the text format is pretty close to the binary format.
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.
I've definitely evolved my "style" as I've worked on it, the earliest code I was thinking in C and writing in WAT (hence the comment style), As I got more familiar I changed how I wrote it (adding the macro layer helped with that)
I've never actually used Knockout but I guess it looks vaguely similar.
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.
Open source is not a business model, and I think the expectation to get paid for open source is a bit disingenuous. There is also the ideological aspect of free as in freedom licensing, while it doesn't exclude monetization, often detracts from the incentive to pay for software.
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.
It is pretty much feature complete already, there are only so many fundamental operations and DOM attributes. besides, I would like to keep it around 2kb ;)
Why isn't it socially acceptable to state that looks are important? I feel like people are conflating "external appearance matters" and "external appearance is all that matters" and demonizing the former in their attempt to ward away the latter.
Also, putting the "X out of 10" scale aside, some people are just drawn to certain looks more than others. Tall, short, certain facial structures, different body types, beards/no beards on men, etc.
I know that I'm probably unusual. I really haven't ever cared much about looks. I've mostly valued intelligence, good sense of humor, interest in sex, independence and (frankly) a credible career.
And in retrospect, among my former wives and lovers, it seems like the less conventionally attractive ones have aged the best.
I think concurrent mode and fibers are kludgy hacks that arise from the problem that only the main thread has access to the DOM. As far as I know and I may be ignorant but few, if any, other frameworks are scheduling DOM updates as aggressively as React is, and are simpler to understand as a result.
Hopefully the standards folks can come up with a decent DOM API for WebAssembly.
This actually uses object getters/setters, has full support for arrays, and nested arrays of objects. There is no API beyond the initial binding, everything beyond that is just mutations on an object.
Nice! I will definitely consider this option for my next projects! Also, I am starting to think that this sort of binding could be implemented natively by browsers, which could make many applications faster.
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.