Pronounced tmux. That's a thing. A very related thing. A very well-known thing. It's a bad name. I do like the concept though (haven't tried using it yet).
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.
While in a rendering scope, `getParentElement()` will get you access to the raw DOM element. As long as you don't detach/move it, you'll be fine letting third-party code loose on it.
Aberdeen has one life cycle callback: `clean`, which is called right before rerunning or destroying a scope.
I think that's enough for just about anything you'd want to do.. ?
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.
Threw me off at first as well. I was thinking of tasks per month. But this seems to be just pay as you go top-ups. Makes sense from a freelancer perspective. If I have work, I top-up my account. If there is none, I don't feel pressure like from all the other monthly subscriptions.
Pay as you go is better for all but the heaviest of users. The low cost per task and topping up a balance make it one less thing to think about, one less monthly fee, and will almost certainly result in cheaper cost per month.
It's the same reason why I use api keys from all of the LLM providers rather than pay monthly fees to any one individual company. It's $5-10/mo vs. ~$80/mo.
I love this pricing model as a potential customer. The cost is so little that it wouldn't be a deterrent. This is way better than another subscription.
There's a lot of problems trying to run a business with this model though IMO (forecasting, recurring expenses, etc.). I hope it works out for them though!
I like the pricing - I think its interesting. But I think the author should just give the option to do one or the other. Unlimited at $10/month or per task.
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).
