Live data from Hacker News

Hyperapp – A tiny framework for building web interfaces

hyperapp.dev

111–120 of 198 posts

Re: Hyperapp – A tiny framework for building web interfaces

#112
post #49

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

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)

If you like htm, check https://github.com/zaceno/hyperlit too

Re: Hyperapp – A tiny framework for building web interfaces

#113
post #98

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!

Do you happen to own hyper.app?

Re: Hyperapp – A tiny framework for building web interfaces

#114

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.

IMHO, yes. This is why some folks (like myself) find it hard to wholeheartedly embrace JS for building entire apps.

Re: Hyperapp – A tiny framework for building web interfaces

#115

This page does not inspire confidence in the framework. I don't need a non-ui piece of software to have the slickest site... but no lorem ipsum please.

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!

Re: Hyperapp – A tiny framework for building web interfaces

#117

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.

That has its problems tho, that for sure.

Re: Hyperapp – A tiny framework for building web interfaces

#118
post #78

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

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

Re: Hyperapp – A tiny framework for building web interfaces

#119

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.

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.

Re: Hyperapp – A tiny framework for building web interfaces

#120

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.

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.
Post reply on HN