Show HN: Micro JavaScript framework inspired by finite-state machine | Hacker News Reader

Show HN: Micro JavaScript framework inspired by finite-state machine

github.com

Some feedback on the API design and README:

- Having a global registry of machines does not scale. Anyone building an app won't want to deal with the name conflicts. Having a `displayName` for debugging is fine but that's all. Having people pass the Machine instance to transitions directly is much more reliable/scalable.

- This [...rest] for event handlers is not good. Put those in a dedicated object because if you don't any new prop you add has the potential to break users. It's also bad because it looks like memory gets merged with those methods, making it likely the keys will conflict in view().

- Find a better name for T, it's confusing with Transition. Since it looks like a simple struct, maybe just have people pass {name, to} as plain data.

- You don't provide a rejected Promise example. I am interested how that works since it is something people tend to overlook.

- How the heck do I test my machines?

- A micro-framework that doesn't mention byte-size? Probably worth adding that statistic. My idea of a micro-framework is one that fits in a tweet.

- Write up how you expect this to be used. I don't think you could use this to build a real app because there's no way compose machines, only switch between them. You'd end up with huge machines because UIs are trees.

Happy to discuss more.

Thanks for feedback, I agree about T, testing and Promise rejection. I should improve README and API to fix this.

Also, if you have some solution or extra thoughts about machine composition (or about anything else) please write it here (or open issue) because is interesting for me

I like the use of template strings for, well, templating, with automatic differentiation between data values and event handlers, nice touch. The state mechanism seems similar to Elm and its derivatives (e.g. Redux), which I guess is a plus considering how much of a convention that's becoming.

Thanks, work a lot with Redux right now and love it "time travel" debug system.

Automatic differentiation? I'm unfamiliar with the term and it didn't appear on the page.

Mind elaborating?

Although unasked: My best guess is that the functionality provided by https://polymer.github.io/lit-html/ was meant (mistakenly attributing the feature to the micro framework).

Thanks for pointing this out to me. I hadn't heard of lit-html before. Another case of learning about something very useful via HN :) Yes it is lit-html that I was impressed by more so than the micro framework that uses it. When I say automatic differentiation I mean treating different binding types (text value vs event handler) differently.

I've been investigating xstate [0] recently, it adds a FSM to React, plus it has an excellent visualisation tool [1] for the states.

[0]: https://github.com/davidkpiano/xstate

[1]: https://bit.ly/xstate-viz

In the "Simple Counter Example", it seems odd to me that both increment and decrement keys have the same "INCREMENT" parameter (ie Finite.Transition("INCREMENT" <- this).

I'd have expected "DECREMENT" for the decrement key... is that a bug or just me not understanding how it works?

It's just typo, but (yes it's confusing) it work the same.

Let me explain: the name of Transition like 'INCREMENT' or 'DECREMENT' in this example have same "endpoint" - Counter itself. So in case like this there is no difference what Transition use, payload do all job (count + 1 or count - 1). So it's only important for debug (like action name in Redux).

Looks really similar to react + redux.

btw - what's the state of JS Frameworks Madness in 2018? Did you guys stop producing and throwing away JS frameworks 500 times a day? Have React/Angular devoured the world?

Weird how it has been 4-5 years since people - without proper knowledge - kept shouting about JS framework fatigue, while the three top frameworks (React, Angular and Vue) remain the same. (Same as in leading, Angular has been reworked quite a lot, I do not want to do anything with it.)

JavaScript is a research language. We produce and throw away ideas quickly because we are exploring and testing.

No one should be using research software in production. If you want use JavaScript in production, use older, vetted libraries and use the smallest subset of API you can.

Basically: use good engineering practice.

You might be able to get away with not vetting your libs in other languages, but it will probably bite you eventually. And other languages might not force you to choose your building surface, but that’s probably just because there’s not much of a choice.

Reply on news.ycombinator.com