It may be a good choice for golang, but support for other languages is not as great.
I remember creating a PR [1] for some very obvious issues with Typescript generator for better-sqlite3 some two years ago which never received any attention from maintainers. There are bunch of such PRs languishing in obscurity in their repos.
My use cases are fairly minimal though, and the adjacent ecosystem is not as well developed. You likely won't be able to get an out of the box integrated gems for shopping cart, blogging platform, newsletter, analytics etc. as you might for rails. If you are building something new from basic blocks, a lot of the foundational blocks seem to be good state. But again, my experience is very limited.
I like the nim language, but the lack of interfaces has been a bit of a turn-off for me.
Do nim programmers not see the need for abstracting out behavior in a manner that different implementations can be switched somewhere else, or is there different idiomatic way to handle this?
Obvious reason would be that all major js libraries have ts definitions available now and if the language is TS based they can all be used without compromising with type-safety.
The end result seems very close to svelte with runes, except with lower learning curve because we dont have special syntax for things like loops, conditionals etc.
I don't any support for lifecycle hooks (eg. something like onMount when the returned node will be attached to the document) in the component api. In absense of those, I imagine integrating with vanillajs libraries will be difficult (eg. codemirror, slickgrid etc.) Curious what your thoughts in the matter are.
I think an underappreciated library in this space is Logux [1]
It requires deeper (and more) integration work compared to solutions that sync your state for you, but is a lot more flexible wrt. the backend technology choices.
At its core, it is an action synchronizer. You manage both your local state and remote state through redux-style actions, and the library takes care of syncing and resequencing them (if needed) so that all clients converge at the same state.
The project looks cool, but I'd strongly recommend against the per-task pricing.
This makes budgeting & forecasting difficult to impossible for a lot of teams, and creates wrong incentives. It is better to have a per user pricing, and then allow them to use as much as they want.
Love this. The proliferation of software that imposes artificial limitations and puts features that can be (and have been) easily performed locally, behind subscriptions is quite frustrating.
I have been working on a free markdown editor that works entirely in the browser and can edit local files through the new filesystem access api (available in chromium only browsers).