jorgebucaran

I reached out to him when I could've filed a takedown notice instead. Later, after the tweets, I even asked him to shake hands on the whole thing[1][2][3], but he was already sunk-cost-mode on and determined to die on a stupid hill. Only because I called him out is that we were able to had my git history restored and copyright attributed.

> Their attitude since then has left a lot to be desired.

That refers to the forker's attitude following the tweets[4][5].

[1]: https://github.com/ai/nanocolors/pull/14#issuecomment-927757...

[2]: https://user-images.githubusercontent.com/56996/135221889-52...

[3]: https://twitter.com/jorgebucaran/status/1442055448899641348

[4]: https://news.ycombinator.com/item?id=28661094

[5]: https://github.com/jorgebucaran/colorette/issues/78

I'm sorry to hear that. I address the Oh My Fish fiasco here:

https://news.ycombinator.com/item?id=28661561

Yes, indeed.

1. From a technical standpoint, it just meant swapping Oh My Fish for Wahoo and changing the name. But my complete lack of planning led to numerous issues that escalated to falling out with the team. I was new to FOSS, immature and reckless.

2. Absolutely. You can't take back gifts that you gave away in the first place. I could've looked for another way, but sadly, I didn't.

3. True. I felt slighted, and used that feeling to justify myself, but in hindsight, I was only being selfish.

I'm that person, but that's not exactly what I did.

Wahoo, a framework I had built, became the base for the then, new Oh My Fish.

I, myself, committed[1] it into the Oh My Fish repository, effectively replacing everything but the name. This was a huge change.

Regrettably, I didn't include a migration strategy, and ended up breaking other things down the line because of that. This and poor communication on my part, eventually led to a fallout with the other maintainer and I exited the project. So, I asked them to revert my changes or provide full attribution.

Reverting my changes would've made no sense at that point, and I realize that.

Attribution was left as "Copyright (c) 2015, Oh My Fish!". That didn't do it for me. My name was not anywhere. Ironically, my name is now almost everywhere Oh My Fish is brought up.

Filling a DMCA notice was my careless reaction to the situation. I know that I could've handled it better. I wasn't at my best.

[1] https://github.com/oh-my-fish/oh-my-fish/commit/2693a2fd18bd...

Colorette author here. I put the benchmarks in a CI workflow so anyone can check. Click Benchmarks to see the results:

https://github.com/jorgebucaran/color-bench-test/runs/371243...

Not exactly what you are looking for, but 3blue1brown's https://github.com/3b1b/manim is a great resource all in all.

What's the difference between the bracketed syntax, e.g. [City] and `list`?

Thank you Zanchey, Ridiculousfish, Fabian, and everyone else!

And Fish!

Basically, yes!

In practice, we don't advocate users to reach out for dispatch, as Hyperapp intends to provide all the fx/subscriptions building blocks you need to create the right abstractions and stay within the safe, declarative side of things.

The reality is, though, that crafting these building blocks takes time and thought, so we don't have them all yet. But people in the community have created fx/sub libraries that are already available, see e.g. this one: https://github.com/okwolf/hyperapp-fx that

Cheers!

Can't use DOM events to create side effects. What we do is define UI interactions as state transitions. Transitions allow you to say [nextState, myEffect] to update the state and create a "controlled" effect (just an object representation of a side effect, very much like how VDOM uses objects to represent DOM nodes). Effects in Hyperapp are the same as Elm commands.

Finish the site and docs, merge the minimizations branch (has memory performance improvements, and brings it down to 1690 bytes gzipped / 1528 bytes brotlified total), add tests, then we can officially proclaim V2.

Definitely not planning to remove the current state or anything haha.

Just saying "purely functional SPAs" was lazy, but it's usually enough to convey what makes Hyperapp different from other frameworks like React, etc. Let me try harder.

There's no native API for representing apps as finite-state-machines (Moore style) [1]. Admittedly, we could do a better job at explaining why you should care.

Hyperapp actions (Elm messages) correspond directly to FSM "events". Hyperapp effects (Elm commands) correspond directly to FSM "actions". The "single-global-state" corresponds to the fact that an FSM is always in just one of a number of "states".

Hyperapp is FSM architecture for JavaScript apps.

It is also bundled with a VDOM implementation optimized for immutability, e.g., you must derive your UI from the state, can't produce uncontrolled side effects, and can't use traditional DOM events, instead you think of every UI interaction as a state transition.

One more cool thing about Hyperapp is subscriptions. An abstraction to toggeable event streams: think bidirectional effects, e.g., global mouse/keyboard events, time, animation frames, geolocation.

[1]: https://en.wikipedia.org/wiki/Moore_machine

Thank you. That's a marquee haha.

My example actually has no issues, but [here is an example][1] so you can confirm that. I included the implementation of `delay` there as well so you can also see what happens behind the scenes.

---

So, in Hyperapp there are no async/await functions. Or Promises. Can't use functions that create side effects. Can't use setTimeout, setInterval, new Promise, fetch, add/removeEventListener, etc.

delay(100, Action) looks familiar to setTimeout, but it's just a function that returns an object that tells Hyperapp what to do. It doesn't do anything by itself. You can write your own delay function too if you want as long as you give Hyperapp what it wants.

The state becoming stale is never an issue in Hyperapp, because you get a fresh copy of it inside actions, which is the only place where you can "update" the state.

[1]: https://codesandbox.io/s/hyperapp-minimal-counter-with-effec...

I hope not! :)

Hyperapp only makes sense if you want to write immutable, purely functional SPAs in JavaScript. There's no Web API or native abstraction for that. And if your site was only content, then I'd say why even bother with JavaScript.

Preact would be the lighter React. Hyperapp is more comparable to Elm.

We built it into the framework, if you happen to be familiar with Elm, this should make sense right away, but here's how you'd write something like that using Hyperapp:

    import { h, app } from "hyperapp"
    import { delay } from "@hyperapp/time"

    const Decrement = (state) => state - 1

    app({
      init: 0,
      view: (state) =>
        h("div", {}, [
          h("h1", {}, state),
          h("button", {
              onclick: (state/*, event*/) => [state, delay(100, Decrement)],
            }, "subtract"
          ),
          h("button", { onclick: (state) => state + 1 }, "add"),
        ]),
      node: document.getElementById("app"),
    })

See how you never actually called setTimeout as that would be a side effect.

Instead, we have "controlled effects" in Hyperapp. This `delay` function doesn't even call setTimeout itself, but return an object that tells Hyperapp how. Just like how `h("button")` or `<button>` with JSX doesn't actually create a button, but an object representation of it.

Finally this part: [state, delay(100, Decrement)], only placed here for convenience (as you'll usually want that in its own action) is how you tell Hyperapp to do the effect when the button is clicked. This is the same (model Cmd) continuation pattern used in Elm.

And you'll get it! Just check again soon as we should have the official release out there in just a few months, maybe less.

Ouch, yes, that's also a WIP, thank you for checking in, though.

Yep, there's a feature called Lazy (will be renamed to memo for the official release) that allows you to do just that! :)

That's fine. If you're already happy with Svelte, I encourage you to explore more with it. Try building a couple of non-trivial projects and keep learning about your craft. If you're also into computer science, I recommend you look into functional programming if you haven't done so yet. Then look at Svelte again. Try React too. Check out Elm.

I can tell you that Hyperapp is not for everyone. If you want to write pure, immutable, functional JavaScript and think hard about client side app architecture (unidirectional state management, controlled side effects, toggleable subscriptions), then you'll love it.

If you are looking for a more accommodating, meet-in-the-middle kind of approach where you can mix programming styles, and don't want to think much about those things I mentioned above, then React, Vue, Svelte are all great choices.

V2 will be released in a few months, so do circle back to Hyperapp then to see how you like it again.

It's my fault for not fully understanding the functional universe I was getting into when I first started working on Hyperapp. The latest Hyperapp is more strict, but it's all in good measure. Lifecycle events are impure, that's why they're no-good.

I can tell you that Hyperapp is not for everyone. If you want to write pure, immutable, functional JavaScript and think hard about client side app architecture (unidirectional state management, controlled side effects, toggleable subscriptions), then you'll love it. I also suggest looking at Elm while you're at it.

If you are looking for a more accommodating, meet-in-the-middle kind of approach where you can mix programming styles, you might be better served by, say, P/React.

Reagent is amazing, thank you for sharing it.

Stimulus is not so much concerned with rendering HTML. Hyperapp is almost exclusively focused on rendering HTML and client side application architecture (state management, controlled side effects, subscriptions).

It's more comparable to Elm than React, Vue, Angular, Svelte, etc., since it's based on functional principles and you can only write pure, immutable code.