It seems that scrolling is somewhat broken. Scroll position under one route affects position in others.
That was enough to make me not consider using Hyperapp.
Yeah, the site is a WIP, but that should be fixed soon when V2 is officially out.
Hyperapp – A tiny framework for building web interfaces
61–70 of 198 posts
Re: Hyperapp – A tiny framework for building web interfaces
#62I'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. [1] https://www.emailthis.me
Curious to hear what boilerplate you think Vue or Preact already handles for you.
Re: Hyperapp – A tiny framework for building web interfaces
#63Earlier quoted context omitted.
It's been like that for months - seems like the project is not seeing the activity they expected for v2. Also server-side routing is broken and that link will not work.
We are very close to the official V2 release, but right now that page is still a WIP. The link works fine, though.
It’s broken here too.
Re: Hyperapp – A tiny framework for building web interfaces
#64In 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.
There's a a JSX-like ttl for Hyperapp too, check it out:
Re: Hyperapp – A tiny framework for building web interfaces
#65Earlier quoted context omitted.
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: const div = (...args) => h("div", ...args) const span = (...args) => h("span", ...args) (or something along those lines)…
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.
Re: Hyperapp – A tiny framework for building web interfaces
#66Earlier quoted context omitted.
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.
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.
Re: Hyperapp – A tiny framework for building web interfaces
#67Been 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:
https://github.com/shish/divetools2/blob/master/src/screens/...
Re: Hyperapp – A tiny framework for building web interfaces
#68Earlier quoted context omitted.
It's been like that for months - seems like the project is not seeing the activity they expected for v2. Also server-side routing is broken and that link will not work.
We are very close to the official V2 release, but right now that page is still a WIP. The link works fine, though.
The link does not work.
Re: Hyperapp – A tiny framework for building web interfaces
#69Re: Hyperapp – A tiny framework for building web interfaces
#70Earlier quoted context omitted.
Text templates are the technology for web development. They are so much better than anything else that there's no comparison. 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.
Text templates are a good idea, placing them into the middle of JavaScript code, not really.
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?