Hyperapp – A tiny framework for building web interfaces
hyperapp.dev
hyperapp.dev
Funnily, the "ecosystem" page contains just Lorem Ipsum (https://hyperapp.dev/ecosystem) and the Awesome Hyperapp section for V2 is almost empty (https://github.com/jorgebucaran/awesome-hyperapp)
Also server-side routing is broken and that link will not work.
The link works fine, though.
As the parent said, you don't have a catch-all route. That is why!
What does this mean?
Developed with Hyperapp on big prod apps about three years; was used to inject small amounts of interactive functionality into existing apps (.Net with jQuery powered frontends). Sorta worked, nice, simple idea, but docs almost nonexistent at the time (to be fair there's very little to it), was in process of being dumped for React just as I was leaving (to work on apps with Elm frontends, which Hyperapp takes a lot from, and suffers from similar issues, heh)
A large project will run into many of these problems. It is a waste to re-invent the wheel because a cool new framework has too few pre-made wheels.
But it looks like a great start
> this site is a wip, stay in touch!
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.
Hyperapp can and will work, with larger applications, but hyperapp does not have super strict "guide rails" like other more popular frameworks do, so its up to you to design, and implement a clean code base. It ships with minimum overhead, and you can either roll features you need, or see if someone in the community has created them.
I have worked with angular (1,2,4,6) and react for quite a few projects, and I actually work faster, and end up with a better end product using hyperapp. Its an amazing little framework. Sure, not having stricter guide rails you can write very poor apps in hyperapp, it will let you do stuff poorly, but if you play to its strengths, and get comfortable with it, it really shines.
I would check out https://medium.com/hyperapp/a-walk-through-hyperapp-2-b1f642...
to get your toes wet though, good resource, also feel fee to join the hyperapp slack https://hyperappjs.herokuapp.com/ nice community and super helpful.
First, I think Hyperapp can make both small and big applications, opposed to u/PufPufPuf's opinion. A lot of people have this opinion because they are more familiar with v1's wired-in actions, which can become quite unruly. In the latest version, actions are decoupled, and can be organized/extracted however you see fit.
I've made a handful of applications in both v1 and the current released Hyperapp, and they work very well. If you want to see the latest Hyperapp in action, you can check these out:
- A timer for mob programming: https://github.com/mrozbarry/mobtime
- A canvas game, using Hyperapp for dom/state: https://github.com/mrozbarry/smash
- A router for Hyperapp: https://github.com/mrozbarry/hyperapp-router
I have a handful of older youtube videos regarding v1, you can check them out here:
- Intro to Hyperapp (v1): https://youtu.be/uWIyjI8nkz0
- Hyperapp (v1) forms and localstorage: https://youtu.be/qpt6aaMxm1E
- Unit testing hyperapps (v1): https://youtu.be/5wvPUj--HaA
Note, they are outdated, but there isn't much on youtube about Hyperapp in general.
One thing to keep in mind is the naming. A lot of people talk about "Hyperapp" as the first version, and "v2" as the current version, but this is wrong. It's more like "v1" (legacy) and "Hyperapp" (current). It gets confusing, because not everyone is on the same page with that, but this the the naming Jorge (primary author/creator of Hyperapp) has mentioned several times.
u/PufPufPuf only mentions the lack of ecosystem, nothing about the wired-in actions/etc, so it's odd that you defend v1 vs v2 instead of the lack of ecosystem here. This should probably have been a reply to that thread as well because otherwise it's two very unrelated comments in the list.
Also, letting the framework decide if a function inside the markup should be called or not gives opportunity for more optimizations that go beyond VDOM diffing. That would require an even more declarative approach.
i.e. [h1, {}, [MyComponent, {}]]
vs.
h("h1", {}, MyComponent({}))
If the framework figures out that MyComponent wasn't changed, it can re-use the VDOM nodes.
I’m pretty sure a lot of frameworks have similar mindsets, but Hyperapp is the one that I found works with the fewest headaches :P (as opposed to eg React, where I spent hours simply trying to untangle the knot of thousands of dependencies before I could get step 1 of the quickstart tutorial to compile...)
As an example of how trivial problems require trivial code:
https://github.com/shish/divetools2/blob/master/src/screens/...
Seeing the h() function makes me realise how much I miss Hiccup syntax for HTML and your component tree, especially with editor support for parens it's a joy. But it looks nicer than JSX.
I'm going to give Hyperapp a try, I like the small size aspect especially, and familiarity of the overall architecture, my fear is that if you're going off-piste enough to avoid the React/Angular well trodden track on an app, you might as well go the whole way and use Re-frame which is very pragmatic, with JS interop it's possible to do pretty much anything you want. And whilst the type system and compiler of Elm is nice, the slightly more 'infamous' parts of restrictions to JS extensions make it more limited in the real world.
Looks like som obfuscated JS-code..
If you keep your components small, as is best practice, whatever gut reaction one feels to it (which IMO is misplaced to begin with) is minimized, and quite readable.
If you have to do that anyway, I think I could use JSX instead of "pure" JS.
Plus, once you've done it, Typescript is easy to slot in, and that by itself makes the effort worthwhile.
It explains very well why is something being easy shouldn't be the main metric, when choosing some technology.
In this case you are advocating to pull in webpack (28MB, 348 packages from 210 contributors), @babel/core (12MB, 54 packages from 60 contributors), typescript (53MB, 11 packages, 4 contributors), to just mention the most obvious and necessary dependencies, not even mentioning the different plugins for integrating them with each other, test frameworks, linters, IDEs (syntax highlighting and auto-formatting) and of course the mountains of type definition boiler-plate.
100MB+ of dependencies which are all a responsibility to learn, teach, configure and upgrade.
Versus this ~12000 bytes: https://unpkg.com/hyperapp
It's like 6 pages of code on a 2K iMac monitor and none of the above...
I'm not saying that there are circumstances when you might want to put up with all that cost, but have you consciously considered, whether it really worth the overhead? What's missing from hyperapp, which is only present in the 100MB+ deps? Maybe `htm` (1MB, 11 packages, 4 contributors) is a better compromise between bloat and ease of development?
And if you are willing to take on the extra dependencies, wouldn't ClojureScript provide a lot lot lot more benefits? It's also based on the super mature Google Closure Compiler, which supports extremely sophisticated optimization techniques and DCE... Just to mention some recent optimization surprise: https://twitter.com/roman01la/status/1277148232276234240
Yes, I have. The overhead of a React/TS stack is considerably less than the overhead of having to hand-build all the stuff that Hyperapp's 12 kilobytes aren't enough to provide, or that using ClojureScript means very few other engineers will want to work with me to build because I'm doing everything in a language and stack they've never heard of.
> What's missing from hyperapp, which is only present in the 100MB+ deps?
Eleven years! Hyperapp is written in pure ES5, which was finalized in 2009, around the same time PHP 5.3 came out. The world has moved on a great deal since then. (But hey, I haven't had to think about hoisting for like six years now, so that was a fun blast from the past!)
That said, those 12 kilobytes of ES5 code are very concise, for sure. They also implement a virtual DOM and a sugar syntax over element creation and nothing else. To compare it based purely on codebase size, with a stack that provides orders of magnitude more functionality, seems at best very incompletely thought through, and at worst deliberately tendentious - although I'm sure that can't be the case.
There's a lot of misinformation floating around about the modern Javascript world. A lot of that dates from years back, like the left-pad problem, or that builds aren't reproducible - both of which were true at one time, but have long since ceased to be. Or that using these tools makes it impossible to deliver compact, performant code to the frontend - which, again, hasn't been true in quite a while. It's not false to say that webpage bloat is worse than it ever has been, but it is false to blame the tools for that problem.
Of course, I freely grant that it's hard to see these kinds of nuances if you don't have much or any context on what modern Javascript is actually like. What I don't grant is that that ignorance is any kind of worthwhile place from which to pass sweeping comments on the whole field of endeavor.
Typescript is a choice independent from anything else.
There are alternatives to Webpack, none of which have gained traction, possibly because developers appreciate other features that webpack provides out of the box.
But, you are complaining about the developer tools, why? The source code size of emacs/vscode/vi is just as relevant, or the size of the linter, or the complexity of whatever build environment is used to deploy code to production.
All of those require upgrading and maintenance, and occasionally have bugs!
I think you have a fair point that if it's not making the build artefacts larger in size it shouldn't be criticized for that.
Where the problem arrives is really about cognitive load: If my tools are emacs/vscode/vi or even visual studio or webstorm, I can use these tools, and come back to them in 18 months for a different project and use the new versions without giving it more than a few seconds of thought.
With Webpack, I am strongly encouraged to use create-react-app to allow for sane creation of new react apps with React/Redux/SASS. But: it's April 2018 and create-react-app doesn't yet support TypeScript, so I have to find somebody's forked version of it that does, but then that forked version doesn't support SASS, so I have to stitch support for that together into my own fork, and then understand it well enough to debug that if it doesn't immediately work.
When I want to make a new app 18 months from then, there is a new version of Webpack, CreateReactApp, etc which finally adds full typescript support, but the way these tools are configured is completely different which itself requires a lot of time and effort to adjust for.
The truth is that the experience of using a developer tool like Webpack is categorically very different than choosing your Code editor.
Or - a much easier tradeoff - just don't use Sass. I mean, Sass isn't without its merits, but if you're already compiling something else down to CSS, you may as well go full CSS-in-JS and get the benefit of a real programming language instead of whatever sharply limited DSL Sass has, that I've totally forgotten about because I haven't needed to touch it in years and I'm honestly a lot happier for that. Yeah, you'll have to look at and vet some new tools, and you'll have to get used to thinking a little differently about how you write stylesheets. But on top of learning the ins and outs of an entire new tooling stack, how much extra cognitive effort is that, really?
There's always going to be tradeoffs. You make the ones that are right for you. And if you find yourself, while investing in a new paradigm, trying so hard to stick with an old familiar tool to the point where it's compromising your efforts to get productive with the new tools - that's a signal to start looking at whether it's time for the familiar old approach itself to be replaced with something that not only composes better with the new paradigm, but, as with CSS-in-JS versus older approaches like Sass or Less, might prove to be a lot better in its own right.
I mean, don't get me wrong, I see a lot of merit in sticking with proven, familiar technologies in which I'm quickly able to be productive. I don't expect I'll ever stop using Emacs, for example, and that's almost as old as I am. Platforms change considerably faster, though, especially in web dev. I started with Emacs eleven years ago, and at that time the frontend "framework" of choice was jQuery - even AngularJS was still a year in the offing - and the closest you could come to a standard backend stack was Rails. But you were more likely to be using something written in PHP, or a hoary old pile of Perl 5, or the like. We've come a very long way since then.
The pace of change has slowed considerably in recent years, I think, and I expect it will continue to do so. But it's not going to stop, and individual tools and stacks will continue to develop regardless. There's always going to be new features, new approaches, better ways of doing things, and some of them are going to be breaking changes. Keeping up with that kind of change, and knowing how to recognize and take advantage of the good, is one of the things it's an engineer's job to do.
Sure, I can get by fine without that, but then I've got to educate 2 other members of my team, both who can program in numerous languages but are quite inexperienced with web development, how to correctly set up each project using the React/Redux/Sass/Typescript/Jest. I can do it myself and hand them a project template, but then no-one else will learn how to do it. The reason for CRAs existence is (more than any argument I might make) an implicit acknowledgement that setting up new webapps is a far more painful experience than it should be.
> it's kind of a surprise to see the claim that Webpack encourages its use.
It was React that recommended CRA, not Webpack recommending CRA, apologies for my misleading description.
> Or - a much easier tradeoff - just don't use Sass.
I'm already quite familiar with plenty of reasons to not use -or to use- SASS. The point is that as a tech choice it's hardly a minor player, and yet the experience of setting up / migrating a project using easily recognisable tech (React/Redux/Sass/TypeScript) is a long way from a straightforward. In my example, I already had SASS on existing related projects. My team members were already familiar with it. Create-React-App was at the time was also actually already built to include support for SASS - the problem IIRC was that the fork of CRA that added Typescript support was forked from a CRA version before SASS was supported, so (at the time) it was a "one or the other" situation before I forked it and fixed it myself.
> Keeping up with that kind of change, and knowing how to recognize and take advantage of the good, is one of the things it's an engineer's job to do.
It's also part of our jobs to look at processes and procedures identify areas of inefficiency, and to ask questions about what a better way of doing things would look like.
Finally, the trajectory of this discussion is pretty absurd. I'm offering examples of what happens in web development to illustrate that there is a massive difference between treating developer tools like Webpack / CRA as though they're similar to text-editors that you don't have to invest a bunch of time to understand and keep up to date with (a point that if I'm understanding you right, you likely agree with). My comment above's central claim is: that while critiques on size of dependency chain of developer tool like CRA or WebPack might be misguided, they are hardly lightweight cognitively, and the choice to use these tools (or not use them) isn't something to just take lightly because we clarified that our deployed artefacts didn't balloon in size.
I would say that CRA's cognitive overhead, in a situation like that, isn't all that different from that of Rails, for example. They're both trying to do a very similar thing, albeit with very different approaches, and they're both very much of the convention-over-configuration school, which attempts to trade off not having to think very much at first about decisions you may not have enough information to make well, with making those decisions costlier later on once you do have enough knowledge to approach them. I have reservations about that entire school of thought, but despite them, my experiences with Rails and with CRA lead me to think that CRA does a generally much better job with those tradeoffs than Rails ever managed.
Also, don't forget that `h` is just a function, so nothing prevents you from creating your convenience functions, which allow more concise/readable code, eg:
const div = (...args) => h("div", ...args) const span = (...args) => h("span", ...args)
(or something along those lines)
I've experimented with this approach before (in ClojureScript) and you can get pretty far with it:
https://github.com/enumatech/cljs-abi-viewer/blob/state-chan...
In fact the Hoplon (https://hoplon.io/) framework as already doing this many years ago, even just using the DOM directly.
I agree with another commenter that a lot of the common objections to JSX and React more generally, especially on HN, sound like things that people who've never used it but only seen a few examples would say.
It's a shame, because with a little more experience those people could complain about stuff like how the complex form logic story in React just isn't really there yet, or how you can't really provide a lot of the subtle touches that go into making a really polished form UX without having to wrap an uncontrolled component inside a controlled one and handle all the state interactions manually.
Forms are boring, I know, and everybody hates it when they have to be complicated. But they exist and are used for a reason, and I wish someone with fewer deadlines than I have right now would take the time to really nail down some of this stuff.
The point about onboarding deserves more consideration than it receives, too. I'd have an easier time finding good devs to work on a React/JSX project than one in Hyperapp, just because of the latter being unusual.
The syntax isn't so much at issue here; Hyperscript could as well be sugar over React.createElement calls, just as JSX is. Anyone familiar with the DOM can look at it and see what it's doing quickly enough.
What would concern me more would be the underpinnings; Hyperapp brings its own VDOM and ancillaries, parallel to React's, that anyone wishing to work on a Hyperapp project needs to learn to reason about - and that will have their own bugs, infelicities, and performance issues, just as React's does. But React's are generally very well known and not too hard to design around, even if actually designing around them can be a pain on occasion.
No shade on the team, and I'm not trying to turn anyone off the project - I used to be much more of an early adopter until I got badly burned that way a few times, and these are the sorts of considerations that result from that kind of experience. I'll definitely be interested to see how Hyperapp holds up, and what kind of profile it achieves, over the next year or so.
const define = (componentDefinition) => (props, ...children) => isReactNode(props) ? React.createElement(componentDefinition, {}, props, ...children) : React.createElement(componentDefinition, props, ...children);
const elements = new Proxy({}, {get: (target, tagName, _) => define(tagName)});
// ...
const {div, h1, button, input} = elements;
https://github.com/seancoyne/awesome-coldfusion#application-...
<cf_menu position="left">
<cf_menu_item current="true" label="Home" url="/"/>
<cf_menu_item label="Accounts" url="/accounts" />
</cf_menu>There are some bad templates implementation, and some good ones. The original PHP and ASP are bad. But that doesn't mean templates are bad.
It seems unnecessarily limiting, and I'm not sure why; For the sake of history? "Division of Concerns"? How is it that using libraries meant for string manipulation upon a standardized format not a concern in and of itself?
The reason JSX, Mithril, PHP's template tags, ASP, Mustache, Twig, etc, exist is because we want to generate HTML - a language that has been standardized for decades - so why are we still playing around with string manipulation tools?
The tendency for SQL is even weirder, it's for replacing it with languages that are much less useful for querying data.
The original PHP and ASP are really singular beasts, people aren't creating things like those anymore.
Personally, I prefer Hyperscript. It took maybe a day for me to get over its perceived ugliness and actually appreciate that it's plain, valid JavaScript.
Personally, I think indentation w/ hyperscript tends to look more natural for large sets of props, e.g.
h('div', {
id: 'hello',
title: 'hello'
onclick: () => {
console.log('hello')
},
}, [
// hi
'hello'
])
// vs
<div
id="hello"
title="hello"
onclick={() => {
console.log('hello')
}}
>
{/*hi*/}
hello
</div>
A good approach is to show us what we need to do with no other dependencies (i.e. just as you're doing now with this h() function), and link to alternative syntaxes/libraries that may be optionally used instead.
Idiomatic JavaScript alternatives that don't involve compilation include:
- https://github.com/zaceno/hyperlit, and the aforementioned - https://www.npmjs.com/package/@hyperapp/html
but please keep the current didactic of piecemeal introduction of concepts, providing clear reasons for their existence!
view: () => div({id: "app", class: "container"}, [
div({class: "filter"}, [
" Filter: ",
span({class: "filter-word"}, "ocean"),
button({}, "\u270E")
]),
I’ve heard this reaction before when people see hyperscript-like APIs. I don’t understand it. Isn’t it abundantly clear what is going on if you know DOM and JS? What is your suggestion if you don’t like hyperscript and don’t like JSX? Parsing string templates at run-time?
The most ergonomic solution (well, atleast for me) has been their old factory API upon which I layered a set of convenience utilities [1]. I have been trying it out in a hobby project and I find the reduction of className boilerplate, elimination of closing tags etc. quite productive. And unlike alternatives like react-pug etc. I don't have to compromise with type checking of attributes.
I'll probably release it as a library after doing some performance evaluation and if needed, wrapping it in a babel-macro [2] that eliminates the runtime overhead.
--
[1] Example in CodeSandbox: https://codesandbox.io/s/pedantic-shape-lq9q9?file=/src/reac...
Code in github gist: https://gist.github.com/lorefnon/53377e4d6a6b13adbcfa155f486...
Personally, I like using `h` over JSX - JSX can be nice to read, but for people that don't know how it works behind the scenes, it makes things look like magic.
Once you know how Hyperapp works behind the scenes, it's much easier to make the decision to JSX if that's something you care about when developing. I have the same opinion about React, and other libraries that have a strong preference to JSX over their native/function implementations.
I like how HyperApp takes this to another level, but the ecosystem of Preact is simply better.
Just a side note, I'm not fulltime front-end, so keeping up with modern frameworks is out of my capacity.
It's great for smart components to my standard multi-paged systems, but I used it even for small PWA applications.
The lack of lifecycle events in v2 complicates things a great deal for seemingly no reason. Subscriptions and Events are similar enough that they could have become a single thing, instead of having two highly similar but not-quite-the-same things to grok. The tuple syntax it uses is very strange coming from v1.
I wish I could call it a strict upgrade instead of saying "some things are worse, but other things are better."
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.
(the function 'update' in the code below)
app({
init: 0,
view: state =>
h("div", {}, [
h("h1", {}, state),
h("button", { onclick: (state, event, update) => {
window.setTimeout(() => update(state => state - 1), 1000);
} }, "subtract"),
h("button", { onclick: state => state + 1 }, "add")
]),
node: document.getElementById("app")
}) 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"),
})
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.
But there is worst, the problem with the pattern [state command] is that it doesn't work well with async method, because at the time the command is called, the state which is passed alongside the command and the state maintained by Hyperapp may be different.
With your example, the issue is that Decrement may be called on a previous state and not on the actual state.
The idea of the updater is to provide the function that takes the transition function as parameter, so delay will be written that way
function delay(updater, timeout, fun) {
window.setTimeout(() => updater(fun), timeout);
}
h("button", {
onclick: (state, _, updater) => delay(updater, 100, Decrement),
}, "subtract")
and if you want to decrement the state using the state at the time the user click
h("button", {
onclick: (state, _, updater) => delay(updater, 100, _ => Decrement(state)),
}, "subtract")
---
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...
And if i want to get the dispatcher directly, i can write a helper function
function effect(fun) {
return state => [state, [dispatcher => fun(dispatcher)]]
}
h(
"button",
{ onclick: effect(updater => setTimeout(() => updater(Decrement), 1000)) },
"subtract"
)
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!
It is simple, easy to understand and easy to reason with. However, I would recommend this only for small apps. As soon as your app's features/complexity increases, you end up writing a lot of biolerplate code that libraries like Vue or Preact already handle you for.
I had sort of neglected it for a while, but during the course of the lockdown, I have started working on a major rewrite - replacing Gulp with Webpack, adding support for Edge, etc. Will release it soon :)
I'd love to hear what kind of boilerplate you had to write that Vue or Preact handle. It can be hard to see these gaps ahead of time so I'd appreciate the benefit of your experience.
I guess it's like working in vertical slices of related logic rather than layers with logic and layers with markup and such.
That has its problems tho, that for sure.
Hyperapp does outperform React in most benchmarks (along with many other frameworks). Not sure how the "2x" was measured, though.
On topic: This looks interesting and I Will be giving it a try. Well done!
Maybe the person that said Svelte was more declarative was only familiar with an older incarnation of Hyperapp that wasn't completely based on functional principles, or maybe they're using a more loose but inaccurate definition of declarative (kind of like how people often say "theory" when they actually mean "hypothesis").
Some time after that I learned about Svelte and very quickly concluded that this would be my choice, everything just feels right about it. For the record, I've only done a small project in Svelte.
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.
Definitely not planning to remove the current state or anything haha.
People starting with Elm, love the idea, but not the ecosystem, and come back to JS in the end.
That's how Redux was created.
"Surely, you couldn't use an actual arrow here... right?"
I find myself having to copy and paste the text to find out for sure.
I don't need a non-ui piece of software to have the slickest site... but no lorem ipsum please.
I've seen some incidents before where backend frameworks were posted before they had things like authentication ready.
Maybe the Web should be reinvented, slightly at least. Maybe it would be a good thing if Web Assembly in conjunction with HTTP3 or something akin to it ate the whole beast, ecmascript and all.
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.
Wtf are you doing man?
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.