Show HN: TinyJs React like framework in 35 lines of code

36 points by atum47 4 days ago | 33 comments

Hi HN, I got to work yesterday and today and came up with a very simple way to create and manage state in TinyJS.

I end up creating a simple App to illustrate how to use the new createState function and custom components in a React like manner. Here's the code for it - https://github.com/victorqribeiro/tinyapp

Here's the PR for the createState function - https://github.com/victorqribeiro/TinyJS/pull/9

chrismorgan 15 hours ago | next |

A comment on code organisation.

https://github.com/victorqribeiro/TinyApp/blob/db92225cfd0ae...:

  export default function Input(state) {

      const inp = input({  // ①
          type: 'number', value: state.count, onchange
      })

      function update() {  // ②
          inp.value = state.count
      }

      function onchange() {  // ③
          state.count = parseInt(this.value)
      }

      state.addUpdate('count', update)  // ④

      return inp
  }
(Labelling comments mine.)

This ordering isn’t great: ① refers to ③, and ④ refers to ②. It’d be better to reorder them, at least to swap ② and ③, and remove the blank line separating ② and ④:

  export default function Input(state) {
      const inp = input({  // ①
          type: 'number', value: state.count, onchange
      })

      function onchange() {  // ③
          state.count = parseInt(this.value)
      }

      function update() {  // ②
          inp.value = state.count
      }
      state.addUpdate('count', update)  // ④

      return inp
  }
But you really can do much better:

  export default function Input(state) {
      const inp = input({
          type: 'number',
          value: state.count,
          onchange() {
              state.count = parseInt(this.value)
          }
      })

      state.addUpdate('count', function() {
          inp.value = state.count
      })

      return inp
  }
At least at this scale, that’s much easier to follow.

Inlining can improve other places too (though at larger scales it becomes more debatable):

  export default function Button(state) {
      return button({
          onclick() {
              state.count += 1
          },
          style: {
              color: 'black',
              border: 'solid 1px black'
          },
      }, '+ 1')
  }

gknoy 3 hours ago | root | parent | next |

This is somewhat off-topic, but I am blown away by your use of uncommon characters like "①". They stand out so much that they (for me at least) make referencing parts of the code snippet so much easier to follow.

I see these _nearly never_, so rarely that I forgot they were available to use. I didn't realize HN supports them, or that I could probably use them in review comments on Github. Thank you for the inspiration! (now to figure out how to actually type them...)

atum47 8 hours ago | root | parent | prev | next |

> (though at larger scales it becomes more debatable)

My thought exactly. In a small component as the Button I agree with inline everything (almost did it myself cause I knew people would read this code) but I have decided to keep it as is for readability. In a more complex component as the Canvas I think you'd agree with me that the long winded version is easier to grasp what's going on.

codingdave 4 days ago | prev |

So, if you are building this off 'window', you are basically just adding syntax sugar to one big global variable. That is absolutely a simple solution to storing state. In one place. But that is not comparable to the functionality of React, so I'm not sure I agree that it is a "react-like framework".

atum47 4 days ago | root | parent | next |

I'm guilty of using React as framework to try to copy from. After working with it for the past 5 years I end up wanting something like it but with less bloat to use in my personal projects. So, what I tried to do: have functional components with JSX like syntax and a managed state that is in sync with the UI. Giving those 3 features and the syntax, I used the term React like.

whizzter 10 hours ago | root | parent | prev | next |

While I see a fair bit of elegance in your experiment, IMHO I also think that for it to be React-like and start mentioning code size one should at least handle structural changes (ie adding/removing items like in a todo-app).

I made a minimal Vue-inspired templating thingy a while back and a fair bit of the codesize (part due to impl and part due to architecture to make it solid) is spent to handle cases of structural changes (adding/removing items, updating event listeners,etc).

EGreg 16 hours ago | root | parent | prev |

I never understood the fascination with JSX. Stuffing HTML into JS? You can stuff JS into HTML natively LOL.

Why not use HTML templates and Web Components, or something? I would have thought React would become like jQuery, after Web Components were implemented natively in browsers, just like jQuery's functionality was. But it's still very popular.

WorldMaker 3 hours ago | root | parent | next |

> Why not use HTML templates and Web Components, or something?

At least in my experience, the best way to write both HTML Templates and Web Components is with JSX. The type checking and language services of JSX are still something of a best in class for serious type safety in complicated data binding and reactivity.

HTML Templates have "slots", but those are the simplest of holes and on the one hand support any HTML you want to place inside those holes, but on the other hand aren't a very deep template language for interactivity.

Web Components have some auto-magic with "slots" if you plan to use your HTML Templates to populate the Shadow DOM. But the Shadow DOM is super complicated, hard to style, and entirely optional. It's also still not a deep enough auto-magic to do deep interactivity easily.

We also still don't have "HTML Modules" even in strong polyfill, so distributing HTML Templates for Web Components is still something of an open problem.

Most highly interactive Web Components still have a template engine inside, even when they work alongside/with HTML Templates. JSX is still a great template language.

React itself may still be the jQuery of JSX-based because we seem to be swinging from Virtual DOM approaches back to "Real" DOM approaches, but JSX can be used for more than just Virtual DOM. (I've been successfully using my own library Butterfloat that uses JSX but is not a Virtual DOM in nice to tree-shake, wonderfully type safe Web Components.)

MarcelOlsz 16 hours ago | root | parent | prev | next |

>Why not use HTML templates and Web Components, or something? I would have thought React would become like jQuery, after Web Components were implemented natively in browsers, just like jQuery's functionality was. But it's still very popular.

Us frontend devs are so lost in the framework sauce that there is a 5 year lag between what web api's can do and when it hits our slack channels.

mightyham 7 hours ago | root | parent | prev | next |

I don't think it's that hard to understand the appeal of JSX. If you want your interface to be modeled functionally (state as input, view as output), it makes way more sense for your view to be the result of a function in contrast with having app logic "stuffed" into a mutable view template.

I'm also not sure why you are offering Web Components as an alternative because it's exactly what you are criticizing, stuffing HTML into JS. It's basically just a more limited and less ergonomic version of React class components, that comes with it's own host of unique headaches.

jeswin 14 hours ago | root | parent | prev | next |

> I never understood the fascination with JSX.

HTML templating (without JSX) gives you markup as strings, which means you don't get type checks, auto-complete, syntax highlighting etc.

gryzzly 9 hours ago | root | parent | next |

it’s really a funny point, as if JSX is somehow native? JSX requires a compiler and definitely also editor extensions for syntax and auto-complete and type checks.

WorldMaker 3 hours ago | root | parent |

Sure, but the most common JSX compiler and language service is Typescript and Typescript is well supported everywhere. As the de facto language service for most JS work today, it certainly feels more like "native" than other template compilers.

Also, for what it is worth, JSX is mostly (despite a few attempts from React to complicate it) a very simple syntax transformer to boring function calls for mostly easy to write functions. We've had "h" functions for a long time before JSX and we'll have "h" functions still if JSX stops being an interesting thing to support.

mock-possum 14 hours ago | root | parent | prev |

Have you checked out lithtml?

esperent 12 hours ago | root | parent | next |

Do you mean lit html?

I've seen it before, it uses template strings for html templating:

const myTemplate = (name) => html`<div>Hello ${name}</div>`;

Compared to JSX, I don't like it much. I feel that template strings are unergonomic and fiddly to type a lot, although maybe I'd get used to it.

jeswin 13 hours ago | root | parent | prev |

Yeah. It requires a framework specific plugin in vscode (and other IDEs), since the markup is just text which requires framework-specific interpretation.

Ultimately, like everything else it's trade-offs and personal preference.

globalise83 15 hours ago | root | parent | prev | next |

Web components are still a little tricky to work with. For example, passing down a complex state to child components is easy in React, but in native web components not so straightforward. Stencil.js is a nice choice for that, but it is just as complicated as React to learn.

jy14898 12 hours ago | root | parent | prev | next |

Maybe I'm missing something, but there isn't any global state attached to window? They attach a constructor for state to the window, but that isn't the state itself - it just returns a smart state object.

atum47 7 hours ago | root | parent |

    const appState = {...state}
With that line I end up creating a appState inside the createState function which uses the state dictionary just as a template.

Would it be better if I attached the things I need to the state object that I receive?

    function createState(state) {
        state._update = () => ...
        ....
        return new Proxy(state, ...)
    }

legit question.