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.
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.
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.
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’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?
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.
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.
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.
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.
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").
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.
[+] [-] PufPufPuf|5 years ago|reply
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)
[+] [-] foobarbecue|5 years ago|reply
[+] [-] jorgebucaran|5 years ago|reply
[+] [-] ricardobeat|5 years ago|reply
Also server-side routing is broken and that link will not work.
[+] [-] HHalvi|5 years ago|reply
[+] [-] HumblyTossed|5 years ago|reply
What does this mean?
[+] [-] AndrewUnmuted|5 years ago|reply
> this site is a wip, stay in touch!
[+] [-] mr0010110fixit|5 years ago|reply
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.
[+] [-] mrozbarry|5 years ago|reply
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.
[+] [-] franciscop|5 years ago|reply
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.
[+] [-] carapace|5 years ago|reply
[+] [-] paultannenbaum|5 years ago|reply
[+] [-] beders|5 years ago|reply
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.
[+] [-] jorgebucaran|5 years ago|reply
[+] [-] Shish2k|5 years ago|reply
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/...
https://scuba.shish.io/#screen=MaxOperatingDepth
[+] [-] ptu|5 years ago|reply
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.
[+] [-] queuep|5 years ago|reply
Looks like som obfuscated JS-code..
[+] [-] pjmlp|5 years ago|reply
[+] [-] raziel2p|5 years ago|reply
[+] [-] tobr|5 years ago|reply
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?
[+] [-] deergomoo|5 years ago|reply
[+] [-] lf-non|5 years ago|reply
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...
[2] https://github.com/kentcdodds/babel-plugin-macros
[+] [-] ollysb|5 years ago|reply
[+] [-] scrump3y|5 years ago|reply
[+] [-] jorgebucaran|5 years ago|reply
[1]: https://www.npmjs.com/package/@hyperapp/html
[+] [-] runawaybottle|5 years ago|reply
[+] [-] riquito|5 years ago|reply
[1] https://github.com/developit/htm
[+] [-] dang|5 years ago|reply
2018 https://news.ycombinator.com/item?id=17126670
2017 https://news.ycombinator.com/item?id=15467819
2017 https://news.ycombinator.com/item?id=15264053
2017 https://news.ycombinator.com/item?id=15178535
2017 https://news.ycombinator.com/item?id=14629414
[+] [-] bshimmin|5 years ago|reply
[+] [-] jorgebucaran|5 years ago|reply
https://github.com/zaceno/hyperlit
[+] [-] d0m|5 years ago|reply
[+] [-] davydog187|5 years ago|reply
[+] [-] czechdeveloper|5 years ago|reply
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.
[+] [-] bharani_m|5 years ago|reply
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.
[1] https://www.emailthis.me
[+] [-] richeyryan|5 years ago|reply
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.
[+] [-] jorgebucaran|5 years ago|reply
[+] [-] shash7|5 years ago|reply
[+] [-] pgt|5 years ago|reply
[+] [-] jorgebucaran|5 years ago|reply
[+] [-] wackget|5 years ago|reply
[+] [-] Glaeqen|5 years ago|reply
[+] [-] drcongo|5 years ago|reply
[+] [-] manx|5 years ago|reply
[+] [-] ancarda|5 years ago|reply
[+] [-] shroom|5 years ago|reply
On topic: This looks interesting and I Will be giving it a try. Well done!
[+] [-] jorgebucaran|5 years ago|reply
[+] [-] nailer|5 years ago|reply
[+] [-] jorgebucaran|5 years ago|reply
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").
[+] [-] onetom|5 years ago|reply
[+] [-] schwartzworld|5 years ago|reply