I have tried Hyperapp some time ago. It's usable for small apps, but the lack of ecosystem makes it unfit for anything larger -- as is usual for all niché JS frameworks.
We're so close to the official V2 release, but there are still issues. I'll make sure to fix most by then. You totally have a point about the lack of an ecosystem, but building one is where the fun is. I am sure we'll get there! Thank you for your feedback.
The quickstart is quite clear, but I'd love to see some slightly larger examples like, how is state passed between components? How do event handlers work? The API page seems sparse as well.
Some problems are hard, common and already solved. Sometimes solving these problems yourself adds no unique value to your product. In that case, you should just use a well-reviewed external ecosystem package.
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.
Lack of libraries, as sibling says. Any libraries that exist are not generally well supported relative to similar libs for popular frameworks. Much smaller community, much less ease at finding others who may have had similar issues. Fewer eyes on, fewer bugs picked up. Fewer contributors, slower fixes/updates. Docs there are tend to atrophy faster.
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)
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.
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.
Hey there, really happy to hear of the success you've had with Hyperapp. I've played with Hyperapp v1 in the past for small toy projects, and it was relatively easy to become productive with. I'm wondering if you have any open toy projects or boilerplate you could share for v2, as I'm looking to jump back on it when I get the chance, and would love to see what a scalable project skeleton looks like.
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:
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.
> "A lot of people have this opinion because they are more familiar with v1's wired-in actions, which can become quite unruly."
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.
Yeah, I should have split things into a reply and a separate thread for the other stuff. That said, I didn't have any comment on the ecosystem - there's definitely a lack of userland things for Hyperapp, and that's for a number of reasons, the biggest being the latest is still in a bit of a transition period from v1, and as a community we didn't think someone would be posting about Hyperapp and make it to the top of hacker news. That really put us on the spot to try and get on here and explain the state of Hyperapp since we're probably more in a release candidate/late-beta situation rather than a full blown release.
Someone got inspired by re-frame, I see :)
I like the approach.
Wondering if there's a way to get ever closer to hiccup (without having to resort to JSX)
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.
Been using this for a while and loving it - it feels like functional programming for GUIs (“describe what you want the end result to look like, and the framework makes it happen” as opposed to “describe what steps to execute”).
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:
I'm a big re-frame fan from the Clojurescript world so this all looks rather familiar. For me it's a great framework and worth learning Clojurescript for.
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.
If I ever need to render HTML from JavaScript, this is my solution, https://lit-html.polymer-project.org/ or tagged templates directly, although I rather prefer straight MVC separation, SSR/Angular/Vue style.
I wouldn't necessarily say we're moving one way or another. React technically released before Mithril. It just so happens React became more popular and JSX is idiomatic in React. But hyperscript is usually compatible w/ JSX (in fact, in Mithril you can choose whether you want to use JSX or hyperscript)
Personally, I think indentation w/ hyperscript tends to look more natural for large sets of props, e.g.
With Mithril's variety of hyperscript in particular there are also some other neat features, such as the ability to pass css selectors as the first argument, e.g. `h('input[type=password].password')` or `const TailwindComponent = '.rounded-lg.md:w-56'; const element = <TailwindComponent />`.
Many projects still predominantly use Hyperscript with the option to use JSX (including Mithril and Hyperapp, and others like RE:DOM, snabbdom to name a few). Even React has an option to use it if you want to skip the JSX compile-step. So I wouldn't say we're necessarily moving away from it.
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.
I absolutely disagree, but I also feel it's unfortunate that HTML, CSS, and SQL aren't first-class citizens in most languages. It's strange to treat things backed by entire standards bodies and with fully developed ASTs as plain-text.
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?
It's an evolutionary constraint. Text templates are initially much more useful than HTML and CSS ones, so people adopt the first, despite a bigger potential usefulness of the later.
The tendency for SQL is even weirder, it's for replacing it with languages that are much less useful for querying data.
Worth noting that ColdFusion actually did components before it was cool :-) (I don't mean ColdFusion components which are really just classes in .cfc files, but custom tags which let you write custom markup)
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?
Not sure of the reason, but it's a godsend comparatively. The reaction against JSX I find to be largely by people who've never actually used it.
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 keep your components small, then using this `h` function instead of JSX doesn't make a lot of difference from readability perspective.
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:
The same is true of JSX. You can abstract and generalize its components with equal ease.
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.
I personally never found much inherent value to JSX outside of making it easier to onboard other developers who are already familiar with HTML, or have seen React before. Otherwise, I found Hyperscript easy to read after about a day of using it, and there's no extra toolchain or compile-step required to use it. Plus it's "just JavaScript."
I do rather like JSX, but I agree Hyperscript isn't difficult to read. As I noted in another comment, though, it also isn't difficult to set up a build step, and being able to use JSX is far from the only benefit of doing so.
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.
But although I really disliked JSX at first, once I tried it a little, I realised that it's about making the code describe what you want rather than how to get it. That mind set shift is actually valuable, even if underneath it's still turning into function calls.
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.
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
> [...] have you consciously considered, whether [it's] really worth the overhead?
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.
If you are doing back compat for old browsers, Babel is necessary anyway.
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!
> But, you are complaining about the developer tools, why? The source code size of emacs/vscode/vi is just as relevant
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.
So...don't use CRA? You don't have to, although it does make a lot of things easier, and it's kind of a surprise to see the claim that Webpack encourages its use. I've never run across anything like that in the docs, and I have found those docs to do a good job of covering how to set up and use Webpack, with CRA nowhere involved.
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.
Okay, that's fair. I certainly can't disagree that setting up a new web app in the modern style, from scratch and without prior experience, is cognitively heavyweight, and that reducing that complexity wherever possible is valuable.
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.
The _only_ reason I use webpack and friends are for JSX and Typescript. For me, those two tools are worth the compilation step. Qs soon as it's possible to stop using compilers while still enjoying the benefits of both, I'll dump them from all my codebases.
ah, and the article also mentioned https://github.com/developit/htm which pretty much provides what JSX does, just in a lot less complex way (at the cost of a little run-time)
Haha, I have spent my fair share of time procrastinating over what a type-safe JSX alternative would look like for React.
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.
Thank you! This is exactly the kind of feedback that we need to improve our presentation. I might just update the tutorial to use @hyperapp/html [1] instead.
Please don't. Not everyone uses these additional libraries or preprocessors, and it was a big hurdle to figure out what was actually being generated behind the scenes in the v1 docs.
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.
Thank you for the feedback. I'll keep this in mind too. I'm definitely not advocating JSX usage. I favor hyperscript myself, but I understand it's an acquired taste.
Idiomatic JavaScript alternatives that don't involve compilation include:
the tutorial is great this way. it's gradually introducing concepts and shows what's possible with very few building blocks.
at the end, it would be nice to mention that at the cost of some extra code and learning a few more functions/concepts, you can gradually make application code either more concise with @hyperapp/html or having a different aesthetic or more familiarity - similar to JSX - with htm or the hyperapp-tailored variant of it, hyper-lit.
but please keep the current didactic of piecemeal introduction of concepts, providing clear reasons for their existence!
In the tutorial it says: "In this tutorial we'll stick with `h` to keep it simple and close to the metal." I'm pretty sure they put that in there just to aggravate the HN crowd.
The `h` function isn't too bad to read if you keep small/manageable components. Obviously, any component, whether JSX or something else, with enough content in it, becomes quite hard to read.
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 have built https://gridjs.io on top of Preact. It's pretty stable and the API is very nice. Supports most events/callbacks that React has (nothing against Hyperapp though)
I read about it but it just did not click as V1 did.
Also I will not rewrite old code just for sake of change and I want all system to be on same framework if possible.
I may actually do my own fork where only difference will be passing root state and root actions in addition to partial ones, which will fix great amount of issues I have.
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."
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.
If we talk about functional API, did you consider providing a push method, like with a Promise, to express the updating of an effect or a subscription ?
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:
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.
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 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);
}
If you want to decrement the state after a delay using the state at that time
The other benefit is that because delay() takes an updater as first argument, it's clear that the function delay does a side effect.
Conceptually, the idea is that instead of trying to hide the side effect, you make it clear to the developer (more like Haskell does).
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.
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
I haven't done a great job at explaining why the current Hyperapp is superior than its previous incarnation, but V2 isn't officially out yet, so I encourage you circle back to it when it is.
I've used this for building the browser extensions for my app [1].
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 haven't used Hyper but I'm looking for something to use for a browser extension I'm making.
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 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 :)
Does modern web development just completely abandon the idea of "separation of concerns"? Looks like content is freely mixed with markup and logic and results in a horrible, difficult-to-read mess of code.
The idea now is not to separate thing by file type (all .js go here, html goes there) but to separate by logical components, thing that work together, go together.
I guess it's like working in vertical slices of related logic rather than layers with logic and layers with markup and such.
There has never been any separation of concern in web development. Just because you put your scripts, HTML and CSS in different files doesn't mean they are separated.
Isn't that the definition of separated? If you want to edit content or markup, you open the HTML file. If you want to edit business logic, open PHP or JS. And so on.
Yeah but then your JavaScript spews out unholy tendrils that mutate the DOM and dynamically add/remove CSS classes and style attributes. Separating HTML/CSS/JS made a lot of sense for web sites but separating by component makes more sense for web applications.
What code are you referring to? Hyperapp has clear separation of presentation, logic, and side-effects. Of course, developers can choose to keep that a clean and distinct separation, or let a bunch of code inter-mingle.
At 1.7K I'm not surprised by this, and I'm not sure why you would be. React is plenty bloated, not saying it's badly coded, but it's a larger codebase than many other SPA frameworks. This one in particular seems to be using as much of native JS code as possible.
Dang, I registered hyperapp domain because I thought it was a good name and wanted to build something cool there. Like all side projects it’s not about the idea but the execution. I’ll put this in my bin together with slackday (Should have registered slack:)
On topic: This looks interesting and I Will be giving it a try. Well done!
This deserves a much better answer, but I'll just say this for now. Svelte is declarative/imperative (but mostly imperative) and also not based on functional principles. React is definitely more on the declarative side. And Hyperapp is essentially Elm in JavaScript, so it's as declarative/functional/immutable as the definition allows for.
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").
What do you think the advantages and disadvantages are? I remember briefly looking into Hyperapp and mostly liking it, but still wasn't sure which JS framework is the best choice (the other one I liked was Vue).
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.
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.
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.
Svelte is more declarative. Svelte is also a compiler, which generates very efficient code for keeping the dependent parts of the DOM up-to-date when the app state changes, effectively moving the vDOM diffing cost from runtime to compile-time.
I put it there, so I apologize for it. We were in the middle of a rewrite while working towards the official V2 release and weren't expecting to be on HN right now haha. Thanks for chipping in!
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.
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: oof, such a mouth-full. Can mean so many things too. So this entire new abstraction is for a front-loaded SPA?
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.
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.
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.
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.
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)