Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyperapp – A tiny framework for building web interfaces

hyperapp.dev

Post reply on HN
Print view View original

191–198 of 198 posts

Re: Hyperapp – A tiny framework for building web interfaces

#191

Post by jorgebucaran »

WealthVsSurvive wrote: post #190
jorgebucaran wrote: post #184

Earlier quoted context omitted.

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.

Okay, so there's no Web API or native abstraction for what? Immutability? There is, but it's somewhat semantically obtuse to express natively with Object freezing, not even to mention some other variably-efficient jiggery-pokery with proxies or something (or maybe there's a new language feature for this that I've forgotten about, so many after all, or was it a proposal?). Purely functional single-page application: oo…

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

Re: Hyperapp – A tiny framework for building web interfaces

#192

Post by jorgebucaran »

onetom wrote: post #189
jorgebucaran wrote: post #134

Earlier quoted context omitted.

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…

what else is missing other than docs? in hope you won't remove the current state, just because you don't consider it released yet :)

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.

Re: Hyperapp – A tiny framework for building web interfaces

#193

Post by RyanGoosling »

WealthVsSurvive wrote: post #181
RyanGoosling wrote: post #141

Just another transient DOM API abstraction library

Almost like the DOM Web API isn't useful for its intended purpose anymore and should be replaced or built upon to avoid all this abstraction churn. Why is simplicity the enemy of the Web APIs? Why is everything useful left to user-defined dependencies? Are the spec creators even checking to see what their code looks like when people have to cobble it together to create something useful? I suspect they are NOT.

The DOM API is useful and usable. Oh and software built on it is maintainable because it's a standard. Software "devs" toiling about with their transient libraries are writing code that goes unmaintainable once the "next new thing" comes out and all the sheep flock to that. The spec creators are the only ones with logic and rational in the whole web dev "ecosystem"/culture/whatever.

Re: Hyperapp – A tiny framework for building web interfaces

#194

Post by RyanGoosling »

jorgebucaran wrote: post #191
WealthVsSurvive wrote: post #190

Earlier quoted context omitted.

Okay, so there's no Web API or native abstraction for what? Immutability? There is, but it's somewhat semantically obtuse to express natively with Object freezing, not even to mention some other variably-efficient jiggery-pokery with proxies or something (or maybe there's a new language feature for this that I've forgotten about, so many after all, or was it a proposal?). Purely functional single-page application: oo…

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…

> can't use traditional DOM events

Wtf are you doing man?

Re: Hyperapp – A tiny framework for building web interfaces

#195

Post by jorgebucaran »

RyanGoosling wrote: post #194
jorgebucaran wrote: post #191

Earlier quoted context omitted.

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…

> can't use traditional DOM events Wtf are you doing man?

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.

Re: Hyperapp – A tiny framework for building web interfaces

#196

Post by _old_dude_ »

jorgebucaran wrote: post #186
_old_dude_ wrote: post #180

Earlier quoted context omitted.

I'm familiar with Elm but i think the model of Hyperapp is better than the [state command] pattern. This is how i see Hyperapp, the event part of Hyperapp is not about commands, it's about transition functions, functions that takes a before state and returns an after state. Hyperapp doesn't let the user to control the state by itself. But there is worst, the problem with the pattern [state command] is that it doesn't…

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…

Thanks for taking the time to explain me how it works. So you're right that you can not use a previous state.

And if i want to get the dispatcher directly, i can write a helper function

  function effect(fun) {
    return state => [state, [dispatcher => fun(dispatcher)]]
  }
and use it to access to the dispatcher/updater

  h(
    "button",
    { onclick: effect(updater => setTimeout(() => updater(Decrement), 1000)) },
    "subtract"
  )
Thanks a lot !

Re: Hyperapp – A tiny framework for building web interfaces

#197

Post by jorgebucaran »

_old_dude_ wrote: post #196
jorgebucaran wrote: post #186

Earlier quoted context omitted.

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…

Thanks for taking the time to explain me how it works. So you're right that you can not use a previous state. And if i want to get the dispatcher directly, i can write a helper function function effect(fun) { return state => [state, [dispatcher => fun(dispatcher)]] } and use it to access to the dispatcher/updater h( "button", { onclick: effect(updater => setTimeout(() => updater(Decrement), 1000)) }, "subtract" ) Tha…

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!

Re: Hyperapp – A tiny framework for building web interfaces

#198

Post by WA »

mr0010110fixit wrote: post #89

So I have extensively used hyperapp (1 and 2) for hybrid mobile applications that run the cab of big rigs. We actually won best in show this year at Freight Waves for our two apps. These are medium/larger apps, with lots of functionality, need to hook into native device features (done with ionic capacitor, and custom plugins), and need to be fast, robust, and flexible. Hyperapp has allowed all of those things. Hypera…

Why didn’t you go with Ionic or Stencil? Did you roll your own design?
Post reply on HN