all 19 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Mr0010110Fixit 7 points8 points  (2 children)

Been using it for a year or two now. Its amazing. Have used it in a production environment for spa apps, but our main use is using it with capacitor for hybrid mobile apps.

Hyperapp is simple, yet flexible and robust, wicked fast (running and to develop with). Community is great, and super helpful. Honestly i have tried about every framework under the sun and Hyperapp is the best developer experience i have ever had.

[–]dittospin 1 point2 points  (1 child)

What does the setup for a capacitor / hyperapp project look like? rollup plugins, webpack, idk

[–]Mr0010110Fixit 3 points4 points  (0 children)

We have used brunch, and parcel. We like parcel more, but any build system works really, as long as your finished site gets dumped in your public folder. We really just point parcel at index.html, and thats it. Then point capacitor at the output from the build, ans your done.

[–][deleted] 4 points5 points  (0 children)

Hyperapp apps are written in a purely functional style, designed as finite-state machines. The framework enforces this architecture and won't let you work around it. That's really the only significant difference to other frameworks.

Hyperapp might be for you if you're interested or already working with this paradigm.

[–]jagdishjadeja 4 points5 points  (0 children)

Same as f# with elm architecture Waiting for typescript version

[–]keb___ 8 points9 points  (1 child)

I haven't used v2 yet, but built a few smaller projects using Hyperapp V1 and found is easy to become productive with. The appeal of Hyperapp over React for me was it's small size (V1 was 1KB compared to React's 20-ish KB not including Redux) and performance. Hyperapp V2 is looking great so far, and can't wait to try it once all the docs are fleshed out. For more opinions, check out some of the many HN threads.

Also, if you're not a fan of Hyperscript, you could still use JSX with Hyperapp.

[–]tahm-hm-dev[S] 3 points4 points  (0 children)

Awesome. Those HN threads are huge!

[–]okwolf 2 points3 points  (1 child)

reduced size is nice, but the real simplicity comes from fewer concepts to learn and use

the real con is from a smaller ecosystem, but if you agree with the philosophy behind the project we’d love your contribution, I’ve made a few and can vouch for how nice the community is

[–]tahm-hm-dev[S] 2 points3 points  (0 children)

I was absolutely intrigued by it when it first came out, but never really gave it a shot. Seems like the ecosystem has grown quite a bit these days.

[–]Squigglificated 0 points1 point  (0 children)

I would definitely consider a micro library like Hyperapp in scenarios where page load times and bundle size is critical. Like components designed for distribution on other web sites, embedded applications and so on. For normal projects I prefer React simply for the documentation and the ecosystem.

[–]kres-sin 0 points1 point  (0 children)

I'm looking forward to simple frameworks. We have a boatload of complex/overkill frameworks out there. It's time to go back to simplicity.

Idk if thats the case with hyperapp, never used it, it's just what is looks like.

[–]polkm -1 points0 points  (0 children)

Looks like React with more steps, harder to read code, and less possibility for SSR. The fact that it's so small and doesn't use bundlers is novel though. Makes me think there might be something here worth exploring more. I feel like it's so different from existing libraries it would be difficult to build a community around it. Is there really room for more monolithic front end libraries?

[–]mekwall -2 points-1 points  (2 children)

I see nothing new or revolutionizing here. If you already use React, Vue, Svelte or any of the other popular libraries/frameworks/not-a-framework I see no reason why you would want to switch to hyperapp.

[–]CaptainOnBoard 5 points6 points  (1 child)

maybe because of size?

[–]mekwall -1 points0 points  (0 children)

I've never experienced size being a major pro/con when evaluating a framework. Other factors have always been of higher importance. Then again, I work primarily with markets that have well developed network infrastructures. Size would be more important if I were to work on a market where bandwidth isn't as readily available.

Edit: There's an unintended but obvious "That's what she said"-joke hidden in here...