
Show HN: Frax – Experimental abstraction layer for coding of web UIs - mikaelaast
https://docs.google.com/gview?url=https://raw.githubusercontent.com/MikaeI/frax/master/Frax%20presentation.pdf&embedded=true
======
vorpalhex
Google docs link which displays the email and identity of all viewers.

Direct link to pdf on Github:
[https://github.com/MikaeI/frax/blob/master/Frax%20presentati...](https://github.com/MikaeI/frax/blob/master/Frax%20presentation.pdf)

~~~
mikaelaast
Hmm. That doesn't sound right. It just displays the document for me. What am I
missing...?

------
lioeters
Having a single function as an interface actually complicates things. I'd
recommend separating it into functions that each does one thing only.

For example:

\- Register template

\- Register worker

\- Create store

\- Create element

\- Add event handler

Give them explicit names and function signatures (number and type of
arguments).

An abstraction is great until it becomes too far removed from the actual
operations that it performs. Among programmers, this is called "magic", as a
term of criticism. Avoid too much magic: show us the internal workings, and
give users the power to handle the things (data and algorithms) directly and
concretely.

------
lux
I like the minimalism, and I don't hate having alternatives to React and the
like. It's not like this is a forever solved problem with a single accepted
solution in world of programming. There are a thousands of takes on "UI
abstraction" in dozens of languages at this point.

I'd love to see a code example of how you see clickableClassNames and
changeableClassNames working in practice (and how that may be expanded to
support other events), or even a clone of the token todo app.

------
molszanski
Looks exactly like a React api

~~~
mikaelaast
Look closer! (I regret posting this as a PDF, so now I've put the whole text
in the readme of the repo:
[https://github.com/MikaeI/frax](https://github.com/MikaeI/frax))

~~~
molszanski
Oh. Now I see the difference. Keep experimenting :)

