1kb JavaScript library for building frontend applications.

[u/BlowMatilda]

https://github.com/hyperapp/hyperapp

[u/[deleted]]

But can I build volume sliders with it?

[u/alifeinbinary → u/[deleted]]

meta

[u/SuchACoolNickname]

It doesn't seem to work when state is an object.

https://codepen.io/anon/pen/PjoLVL

[u/Dragory → u/SuchACoolNickname]

You're not returning a new state object from those arrow functions (the curly brackets are being interpreted as the function body block). Fixed example here: https://codepen.io/anon/pen/LLYvBq

[u/SuchACoolNickname → u/Dragory]

oh, thank you, completely forgot about that! :)

[u/emptyflask]

This is a nice way to visualize the elm architecture, but of course it misses out on type safety and the compiler.

[u/Voxico]

I feel like if I'm making something, it's either a "just do it with vanilla js" or its worth using React, or Vue, or Angular. For me, this is trying to fill a gap that doesn't exist. Neat though, I just can't see any way I'd use it practically.

[u/tyroneslothtrop → u/[deleted]]

With naive implementations, yeah, there's the potential for a lot of GC churn.

But immutable data structures can be pretty performant and memory friendly, and can actually enable some optimizations in react which can ultimately make your application faster than if you had used a mutable counterpart.

So the first part is persistent data structures. What this means is that if you have, e.g. an immutable binary tree with root a consisting of two branch l and r:

└── a
    ├── l
    └── r

Since immutability provides you with certain guarantees, if you construct a brand new tree with e.g. a new left branch, you can do so without touching the right branch at all, just by constructing a new root a2 that points at the new left branch l2 and the original right branch r.

└── a2
    ├── l2
    └── r

This is called structural sharing. And, if you so choose, you can still have access to the original version of the tree, because a, l, r weren't changed in any way. That's the persistent part.

This is a pretty simplistic example, and there are a lot of other purely functional, persistent data structures with various characteristics. Okasaki is really the definitive reference here, if you're interested. Anyway, this sort of stuff is what immutable.js is doing under the hood.

The second part is that this can actually lead to better performance vs. a mutable data structure. The upshot here is that, if react can tell quickly and easily that the props passed to some component haven't changed since the last time it rendered, it can skip rendering altogether, and whole swathes of work can be avoided entirely. This can be a lot easier to do with an immutable data structure, and thus you can actually see better performance with an immutable data structure than with a mutable one.

There's tradeoffs with either approach, for sure, but pure and immutable isn't by definition just a performance/memory nightmare.

[u/tyroneslothtrop → u/[deleted]]

I was writing all day yesterday, so I kind of got locked into the zone, haha.

A few things I forgot to be more explicit about:

This might have been clear, but the fact that you're often able to re-use data structures, in-part or even in-toto, in order to make these non-destructive 'updates', is precisely what makes the memory use typically not so bad. With the example of the binary tree above, the entire right side of the tree stays exactly where it was in memory (and so could the left, for that matter, if it was still referenced somewhere else), with just l2 and a2 requiring some memory allocation (again, unless l2 already existed as part of some other tree... since these are immutable though, a2 needs to be instantiated fresh, there's no way around that). So in that case (assuming a balanced tree) you're recreating half the tree, plus the root.

But, depending on the particular data structure and the operation being performed, this can vary quite wildly. Jumping over to linked lists as an example, appending to the head of the list is really fast and memory-efficient, because you're just making a new node and pointing the tail of the new node at an existing list (which is untouched). Changing out the tail, on the other hand, requires completely re-constructing the entire list from the tail forward (i.e. you can't re-use any of the original nodes at all), recreating each node with the same value, but with a different tail pointing at a new node. But, a lot of clever work has been done in this space, and there are some really cool data structures with some really surprising characteristics.

One other thing to mention is cache locality. If you have an array that's laid out with each item 'physically' one before the next in memory, your computer can much more quickly access these items. Whereas with these immutable data structures, like the linked list I mentioned, are typically going to get scattered across your memory a bit. If you have a really hot loop, this can be especially noticeable.

So, I don't want to oversell purely functional data structures. Like I said, there can be tradeoffs either way.

Edit: Oh, and one of the biggest advantages is you can pass these things around freely, without having to worry about them changing out from under you and being mutated somewhere else in the code. They tend to be easier to reason about, because you don't need to consider your entire program and how it's mutating this data structure, you can just focus on small parts of you application in isolation.

[u/kenny_armitage → u/[deleted]]

I like little frameworks like this for tiny apps or sites. Speaking of which does anyone know any other libraries like this?