10 ms·

Vanilla-FP: A no-framework framework for component-based purely-functional UIs

74 points by boris_m 3y ago

boris_m 3y ago
Discussion on Mastodon, from which the idea came: https://mathstodon.xyz/@zens@merveilles.town/110369866152393710 https://mathstodon.xyz/@zens@merveilles.town/110369866152393...
andybak 3y ago
> FP Nope. I've got nothing. "Functional" something? Anyone?
- stavros 3y ago
  Functional programming?
  - andybak 3y ago
    Yeah. I guess that's obvious - the fact that it's javascript probably indicates they mean "Functional-ish Programming"
    - xcdzvyn 3y ago
      abuseofnotation indeed :)
  - worldsayshi 3y ago
    Yeah I would assume that this would be the obvious reading of the acronym and would probably use that myself. I guess acronyms should be considered bad in general?
    - boris_m 3y ago
      Character limit
- Gualdrapo 3y ago
  First line on the README says "The no-framework framework for building component-based purely-functional UIs.", So I guess it's "purely-functional" but put backwards for some reason?
superice 3y ago
This seems awfully similar to the Elm model of managing state. Perhaps it's me being unenlightened, but I never understood why all state in an application needs to be managed centrally. Take a select box for example, its open-state is not something I think a central store should necessarily know about right? I always find that if I want to write an app in the Elm style (or with Redux), I have to traverse up the tree every time I am working on a leaf node. Each input field in a form should not necessarily cause me to have to rework everything up to the root node right? Am I doing it wrong, or am I just missing what benefits this approach brings to offset this extra development cost?
- rq1 3y ago
  You are doing it wrong yes. The root node can intercept all messages but its main responsibility (TEA) is to dispatch the messages to the right component(s).
  - superice 3y ago
    Sure, that makes sense in a Redux app where you can use FP techniques as you see fit. How do you do that in something strictly functional like Elm? As I understand it 'local state' or a component handling messages locally is not really a thing there.
    - Akronymus 3y ago
      I am using elmish, which I think is similar enough: every component has its own update method and events it dispatches.The events get wrapped in every parent component until it gets to the root, there it gets unwrapped and passed to the appropiate child update method. At any point, you can intercept the event/update. (Each component consists of a view, a model and an update function, the model contains wrapped versions of the children models and dispatched updates get passed into the children updates)
      - boris_m 3y ago
        What is the role of the "root node" in Elm?
iakov 3y ago
This is not serious, right? It's a no-framework framework (what?) to build purely-functional UIs using pure-ish (what?) components. The "why" section doesn't answer the question of "why" though - it briefly mentions Redux and useState limitations without explaining how this is going to be a better solution. Really, how is this different from a top-level useState call, that then gets passed down via props drilldown to children components? The repo mentions that the "heart" is not a code but a convention, but you can do the same convention in React. In fact I believe you can do much better with context - prop drilldown absolutely sucks when the complexity of your component tree grows. Am I missing something?
- boris_m 3y ago
  Yes, you can use the same convention in React (or rather use React with the same convention), this is mentioned in the description actually. As far as "prop drilling" goes, I never understood what is the problem that some people have with it. If you just put your state in one object its just one more param that you have to pass to components. Do we really need a big-ass framework just because of one extra param. Also, by passing state explicitly, you get a clear visibility over which component needs what. And it also allows you to restrict which component uses which parts of the state.
  - iakov 3y ago
    If this convention can be used in React, what is the "no-framework framework"? What's the point? React is not "just one extra param". One thing it does and your "no-framework framework" does not is figuring out what needs to be updated when the state changes. Add some console.log statements to your components and you'll see that clicking on any button on the demo page results in all components being updated, causing update of DOM nodes. How can this possible work in a complex web page? I click on the "Close Modal" button, and every single DOM node on the page gets updated, from the menu bar down to each and every button? That's the very basic thing that React does. I am not talking about anything else, like component lifecycle or hooks. This not-framework doesn't even begin to approach what React does. If you don't want the "big-ass framework" for whatever reason, there are Inferno and Preact already. Both are great projects and have all the things a developer expects from React replacement.
tobr 3y ago
Nice, but it does not look practical considering it appears to be replacing the whole DOM with every update. However, thumbs up on the idea of UI components that aren’t implemented as a framework, but rather as a convention that different frameworks could support. It would be so nice to just have a way to specify which part of the markup is owned by which component, and the basic life cycle events they need to agree on to work together, but then allow the internal considerations of each component to be handled by any framework or even plain JS if you prefer.
- danielvaughn 3y ago
  I’m actually working on something like that, but it isn’t a framework necessarily. I’ve described it as a “programming language for designers”. The idea is to allow designers to specify the graphical layer of apps, without specifying any behavior. The core language itself is platform-agnostic, with platform-specific dialects. So you could use it to spec out a web/iOS/android/etc app. And the cool thing about it is that it compiles to an intermediate representation, which will be a JSON data structure. So you could use it to generate a React component library, or Vue, or Angular, or web components, etc etc.
  - 20after4 3y ago
    To me this sounds a lot like reinventing CSS.
    - danielvaughn 3y ago
      No no, not at all. The web dialect just uses CSS under the hood, and maps properties 1:1. There’s no magic, no abstraction.
- boris_m 3y ago
  This is a reference implementation, you can easily implement it by using React or any other virtual DOM lib. All components would work as well.
  - 3y ago
EGreg 3y ago
If you're curious about a different approach to components and state, I'd love to get feedback on what we've been doing for the last 7 years: https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools
igtztorrero 3y ago
Nice, Let's kill HTML, I like it
- flopriore 3y ago
  Imho a language similar to the combo Dart and Flutter (which is pretty similar to this project) would be perfect to replace all the HTML, CSS and JS. Unfortunately, the former has a terrible web support, but a completely new language that implements styling like Flutter could literally be a game-changer in frontend
mrozbarry 3y ago
Neat proof of concept. I think what you'd want to do is have some form of dom vs component diffing, and traverse the old dom and only create new elements if you find a node type mismatch. Consider this, you have a slider input, and oninput, you update the state, which creates a new slider input, which causes your mouse drag to get invalidated. Another consideration - a textarea where you update state each keystroke; will that reset the cursor or have unintended consequences?

74 points by boris_m 3y ago

Discussion on Mastodon, from which the idea came: https://mathstodon.xyz/@zens@merveilles.town/110369866152393710 https://mathstodon.xyz/@zens@merveilles.town/110369866152393...

andybak 3y ago

> FP Nope. I've got nothing. "Functional" something? Anyone?

stavros 3y ago
Functional programming?
- andybak 3y ago
  Yeah. I guess that's obvious - the fact that it's javascript probably indicates they mean "Functional-ish Programming"
  - xcdzvyn 3y ago
    abuseofnotation indeed :)
- worldsayshi 3y ago
  Yeah I would assume that this would be the obvious reading of the acronym and would probably use that myself. I guess acronyms should be considered bad in general?
  - boris_m 3y ago
    Character limit
Gualdrapo 3y ago
First line on the README says "The no-framework framework for building component-based purely-functional UIs.", So I guess it's "purely-functional" but put backwards for some reason?

superice 3y ago

This seems awfully similar to the Elm model of managing state. Perhaps it's me being unenlightened, but I never understood why all state in an application needs to be managed centrally. Take a select box for example, its open-state is not something I think a central store should necessarily know about right? I always find that if I want to write an app in the Elm style (or with Redux), I have to traverse up the tree every time I am working on a leaf node. Each input field in a form should not necessarily cause me to have to rework everything up to the root node right? Am I doing it wrong, or am I just missing what benefits this approach brings to offset this extra development cost?

rq1 3y ago
You are doing it wrong yes. The root node can intercept all messages but its main responsibility (TEA) is to dispatch the messages to the right component(s).
- superice 3y ago
  Sure, that makes sense in a Redux app where you can use FP techniques as you see fit. How do you do that in something strictly functional like Elm? As I understand it 'local state' or a component handling messages locally is not really a thing there.
  - Akronymus 3y ago
    I am using elmish, which I think is similar enough: every component has its own update method and events it dispatches.The events get wrapped in every parent component until it gets to the root, there it gets unwrapped and passed to the appropiate child update method. At any point, you can intercept the event/update. (Each component consists of a view, a model and an update function, the model contains wrapped versions of the children models and dispatched updates get passed into the children updates)
    - boris_m 3y ago
      What is the role of the "root node" in Elm?

iakov 3y ago

This is not serious, right? It's a no-framework framework (what?) to build purely-functional UIs using pure-ish (what?) components. The "why" section doesn't answer the question of "why" though - it briefly mentions Redux and useState limitations without explaining how this is going to be a better solution. Really, how is this different from a top-level useState call, that then gets passed down via props drilldown to children components? The repo mentions that the "heart" is not a code but a convention, but you can do the same convention in React. In fact I believe you can do much better with context - prop drilldown absolutely sucks when the complexity of your component tree grows. Am I missing something?

boris_m 3y ago
Yes, you can use the same convention in React (or rather use React with the same convention), this is mentioned in the description actually. As far as "prop drilling" goes, I never understood what is the problem that some people have with it. If you just put your state in one object its just one more param that you have to pass to components. Do we really need a big-ass framework just because of one extra param. Also, by passing state explicitly, you get a clear visibility over which component needs what. And it also allows you to restrict which component uses which parts of the state.
- iakov 3y ago
  If this convention can be used in React, what is the "no-framework framework"? What's the point? React is not "just one extra param". One thing it does and your "no-framework framework" does not is figuring out what needs to be updated when the state changes. Add some console.log statements to your components and you'll see that clicking on any button on the demo page results in all components being updated, causing update of DOM nodes. How can this possible work in a complex web page? I click on the "Close Modal" button, and every single DOM node on the page gets updated, from the menu bar down to each and every button? That's the very basic thing that React does. I am not talking about anything else, like component lifecycle or hooks. This not-framework doesn't even begin to approach what React does. If you don't want the "big-ass framework" for whatever reason, there are Inferno and Preact already. Both are great projects and have all the things a developer expects from React replacement.

tobr 3y ago

Nice, but it does not look practical considering it appears to be replacing the whole DOM with every update. However, thumbs up on the idea of UI components that aren’t implemented as a framework, but rather as a convention that different frameworks could support. It would be so nice to just have a way to specify which part of the markup is owned by which component, and the basic life cycle events they need to agree on to work together, but then allow the internal considerations of each component to be handled by any framework or even plain JS if you prefer.

danielvaughn 3y ago
I’m actually working on something like that, but it isn’t a framework necessarily. I’ve described it as a “programming language for designers”. The idea is to allow designers to specify the graphical layer of apps, without specifying any behavior. The core language itself is platform-agnostic, with platform-specific dialects. So you could use it to spec out a web/iOS/android/etc app. And the cool thing about it is that it compiles to an intermediate representation, which will be a JSON data structure. So you could use it to generate a React component library, or Vue, or Angular, or web components, etc etc.
- 20after4 3y ago
  To me this sounds a lot like reinventing CSS.
  - danielvaughn 3y ago
    No no, not at all. The web dialect just uses CSS under the hood, and maps properties 1:1. There’s no magic, no abstraction.
boris_m 3y ago
This is a reference implementation, you can easily implement it by using React or any other virtual DOM lib. All components would work as well.
- 3y ago

EGreg 3y ago

If you're curious about a different approach to components and state, I'd love to get feedback on what we've been doing for the last 7 years: https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools

igtztorrero 3y ago

Nice, Let's kill HTML, I like it

flopriore 3y ago
Imho a language similar to the combo Dart and Flutter (which is pretty similar to this project) would be perfect to replace all the HTML, CSS and JS. Unfortunately, the former has a terrible web support, but a completely new language that implements styling like Flutter could literally be a game-changer in frontend

mrozbarry 3y ago

Neat proof of concept. I think what you'd want to do is have some form of dom vs component diffing, and traverse the old dom and only create new elements if you find a node type mismatch. Consider this, you have a slider input, and oninput, you update the state, which creates a new slider input, which causes your mouse drag to get invalidated. Another consideration - a textarea where you update state each keystroke; will that reset the cursor or have unintended consequences?