Hyperapp: Using hyperapp without JSX?

[mrozbarry]

So far, I've only taken a cursory glance at hyperapp, so I don't know if this is already possible, has been road-mapped somewhere I haven't seen yet, or just isn't a good idea.

I'm not strictly against JSX, but I do occasionally use js-relatives like coffeescript where using functions can read significantly better.

I suspect this ends up being a larger question to the community, since I'm sure 99% of devs don't care about a no-JSX solution.

[Swizz]

Take a look at the Getting Started Guide, Hyperx or JSX are introduced a far later.

Hyperapp use vdom for view construction. JSX is only a syntactic sugar.

[jorgebucaran]

@mrozbarry Sure thing! The examples in the docs use JSX for familiarity, but you are not required to use JSX with HyperApp :)

Here is a "hello world" using hyperx and ES6 template literals.

Try it online

import { h, app } from "hyperapp"
import hyperx from "hyperx"

const html = hyperx(h)

app({
  state: "Hi.",
  view: state => html`<h1>${state}</h1>`
})

And here is the example again without using external libraries.

Try it online

import { h, app } from "hyperapp"

app({
  state: "Hi.",
  view: state => h("h1", null, state)
})

[mrozbarry]

I guess one comment on this, which I'm not sure if it's an issue for hyperapp vs hyperx, is it would be nice to use dom elements as functions.

For instance, in react, I can do:

{ div } = React.DOM

# ...
myComponent = (props) ->
  div {}, "whatever"

I guess there's nothing stopping me from writing a script that does something like:

{ h, app } = require("hyperapp")

HyperDOM = ["div", "span", "...more here"].map (tag) ->
  (attrs, children) ->
    h(tag, attrs, children)

# ...

{ div } = HyperDOM

app(
  state: null
  view: (state) -> div null, "whatever"
)

[jorgebucaran]

@mrozbarry That's pretty cool, but out of the scope of hyperapp's core.

Now, I'd be happy to allocate a repo in the organization for a 3rd party utility package that does this if someone (including yourself) wants to take on the challenge. I'd be happy to help out as well time permitting.

EDIT: Grammar.

[Swizz]

Here is hyperscript-helpers

import { h, app } from "hyperapp"
import helpers from "hyperscript-helpers"

const { div, h1 } = helpers(h)

app({
  state: "Hi.",
  view: state => 
    div(null, [
      h1(null, state)
    ])
})

You are right, this is more Elm 😄

[mrozbarry]

ohanhi shows up in all the places I check out. It's like I'm stalking him and I didn't even know it!

[jorgebucaran]

@Swizz This is pretty cool. Maybe I should reconsider the scope comment I made.

Imagine:

import { div, h1, ul, li, app } from "hyperapp"

app({
  state: ["Hi", "Hola", "Hallo"],
  view: state => 
    div([
      h1(state), 
      ul(
        state.map(li)
      )
    ])
})

EDIT: Well, maybe not. I'll check out hyperscript helpers again. 😅

[Swizz]

hyperscript-helpers is arround 945 bytes gziped 😕

[SkaterDad]

I just write my view code with h() calls most of the time. Same with the code I write in cycle.js.

hyperscript-helpers is a really cool library. I bet if you ran your code through something like prepack, the extra weight of it would get stripped out at compile time.

Certainly seems out of scope for hyperapp, though. Best served by a user-land library, IMO, which basically already exists fortunately!

[jorgebucaran]

Okay, it seems this issue has been resolved.

[lukejacksonn]

Imagine: import { div, h1, ul, li, app } from "hyperapp"

This is why I created the (experimental) huy library.. primarily it was to cover the tags/functionality hyperapp doesn't support but that there are standard solutions for.. use and internal routing with a[href='/'].

Then I thought like you.. why not cover _all_ the standard elements! hyperscript-helpers looks to have done just that! I'm going to try it out but I already like the idea and would consider the idea of a repo separated from core but maintained by the community hyperapp/dom or something?

[jorgebucaran]

@lukejacksonn Don't know why, but I just has this thought that, for official packages, we could use scoped packages.

npm i @hyperapp/dom @hyperapp/hmr

etc.

[lukejacksonn]

sounds good to me!