Live data from Hacker News

Hyperapp – A tiny framework for building web interfaces

hyperapp.dev

101–110 of 198 posts

Re: Hyperapp – A tiny framework for building web interfaces

#101
post #41

Earlier quoted context omitted.

My big issue with JSX is that it forces you to use a pre-processor and source maps. If you have to do that anyway, I think I could use JSX instead of "pure" JS.

Setting up Webpack and Babel isn't so bad, these days, and you really only have to do it one time and then you can reuse the setup in other projects. Plus, once you've done it, Typescript is easy to slot in, and that by itself makes the effort worthwhile.

I can highly recommend you watching this talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

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

Re: Hyperapp – A tiny framework for building web interfaces

#102
post #78

React was made in 2013 and is pretty old at this point. How does Hyperapp compare to current tech like Svelte?

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.

Re: Hyperapp – A tiny framework for building web interfaces

#104

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 think they use "Close to the metal" as a way to say "Less abstractions"

Re: Hyperapp – A tiny framework for building web interfaces

#105
post #20

Haven't been using react because of the JSX, but is this really where we are heading? https://hyperapp.dev/tutorial#rendering-to-the-dom Looks like som obfuscated JS-code..

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. [1]: https://www.npmjs.com/package/@hyperapp/html

A nice flourish would be to have every example with both, and have a global switch to pick which one you prefer.

Re: Hyperapp – A tiny framework for building web interfaces

#106

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. 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 )

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.

Re: Hyperapp – A tiny framework for building web interfaces

#107

Earlier quoted context omitted.

It's all client-side. When I click that link, it opens the site as usual.

Click the link directly: https://hyperapp.dev/ecosystem As the parent said, you don't have a catch-all route. That is why!

That's what it is, thank you for clarifying.

Re: Hyperapp – A tiny framework for building web interfaces

#108
post #88

Earlier quoted context omitted.

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. [1]: https://www.npmjs.com/package/@hyperapp/html

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:

- https://github.com/zaceno/hyperlit, and the aforementioned - https://www.npmjs.com/package/@hyperapp/html

Re: Hyperapp – A tiny framework for building web interfaces

#109
post #94
post #20

Haven't been using react because of the JSX, but is this really where we are heading? https://hyperapp.dev/tutorial#rendering-to-the-dom Looks like som obfuscated JS-code..

Elm defines separate functions for each element type which in js would look like view: () => div({id: "app", class: "container"}, [ div({class: "filter"}, [ " Filter: ", span({class: "filter-word"}, "ocean"), button({}, "\u270E") ]), I'm admittedly used to this from years using Elm but to my eye I'd far rather use this than JSX.

100% agree, that's exactly what @hyperapp/html package attempts:

- https://www.npmjs.com/package/@hyperapp/html

Post reply on HN