This isn’t serious. Sorry! I love people’s JS frameworks that they made on a whim just to prove a point, but this doesn’t meet the bar of a serious attempt. It only supports onClick. That’s not serious. Look at the https://crank.js.org manifestos instead for an example of what it means to do something like this.
Crank is super cool, I wish more frameworks explored generator functions. I tried my hand at it and was surprised how far I could get with very little.
That’s very cool. I bet you could do a throttled spinner that works by Promise.racing the request and yielding the waiting screen if it finishes first.
I didn’t know about Crank, it’s really neat. Components-as-communicating-threads is a model with some history in the Unix/Plan 9 tradition that deserves its chance in the modern world.
For me personally, global state with a global render :: state -> ui remains too good to let go of. (And of course I made my own tiny-framework around it.)
This looks pretty interesting! But isn’t it less than ideal for state to be stored directly in components? What about state that needs to be displayed in multiple places? For example: a scoreboard that’s displayed both in a navigation bar and in the main body of the page. Would that require re-rendering the entire <body> each time the data changes, even though it’s only two small components that need updating?
State is not stored in the components, it is stored in the root component which can pass it down in the hierarchy to any other component, so making components “talk” is very easy.
As far as re-renders go, this is a proof-of-concept, it can be easily made to work with some virtual DOM implementation. Not that rerendering is such a big problem by - there are static apps that feel much faster than some JS-centric ones.
This isn’t serious. Sorry! I love people’s JS frameworks that they made on a whim just to prove a point, but this doesn’t meet the bar of a serious attempt. It only supports onClick. That’s not serious. Look at the https://crank.js.org manifestos instead for an example of what it means to do something like this.
Crank is super cool, I wish more frameworks explored generator functions. I tried my hand at it and was surprised how far I could get with very little.
That’s very cool. I bet you could do a throttled spinner that works by Promise.racing the request and yielding the waiting screen if it finishes first.
I didn’t know about Crank, it’s really neat. Components-as-communicating-threads is a model with some history in the Unix/Plan 9 tradition that deserves its chance in the modern world.
For me personally, global state with a global
render :: state -> uiremains too good to let go of. (And of course I made my own tiny-framework around it.)Discussion on Mastodon, from which the idea came: https://mathstodon.xyz/@zens@merveilles.town/110369866152393710
This looks pretty interesting! But isn’t it less than ideal for state to be stored directly in components? What about state that needs to be displayed in multiple places? For example: a scoreboard that’s displayed both in a navigation bar and in the main body of the page. Would that require re-rendering the entire
<body>each time the data changes, even though it’s only two small components that need updating?State is not stored in the components, it is stored in the root component which can pass it down in the hierarchy to any other component, so making components “talk” is very easy.
As far as re-renders go, this is a proof-of-concept, it can be easily made to work with some virtual DOM implementation. Not that rerendering is such a big problem by - there are static apps that feel much faster than some JS-centric ones.