Extract Hyperx from core

[jorgebucaran]

Depending on https://github.com/substack/hyperxify/pull/8 to be merged to move forward is not reasonable. But the truth is that even if it's not merged, hyperxify can still be used with HyperApp, it's just a little more laborious.

const { h, app } = require("hyperapp")
const hyperx = require("hyperx")
const html = hyperx(h)

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

browserify -t hyperxify index.js -g uglifyify | uglifyjs > bundle.js

HyperApp is officially neutral in the Hyperx/template functions VS JSX debate (although the README is biased in favor of JSX on the premise that it looks "cool"), so extracting Hyperx seems a natural move.

I'll update online examples still using html via HyperApp and write the docs.

[tunnckoCore]

I was thought same thing. If we are just elm architecture + virtual dom + JSX, it jsut enough. It looks fancy and everyone seems to use JSX haha.

[FlorianWendelborn]

Not "breaking JS" is one of the reasons why I like hyperapp. :-1:

[tunnckoCore]

everyone can include hyperx and pass our h to it so he won't break HIS JS for his project :D

I was against JSX, but kinda like it now. Not sure enough, except that it is hard to write because is html :D no matter even if you have some snippets or "lanugage-*" or etc stuff on you editor. :D

it would be cool if they support Jade/Pug :D it will go more crazy :D

[jorgebucaran]

@dodekeract Extracting hyperx doesn't mean HyperApp can't use template functions. The reason I want to remove hyperx is because of maintenance, hyperxify won't likely ever work with HyperApp out of the box (forcing me to fork the repo or create my own transform and tell everyone to use it).

Extracting hyperx is arguably trueer to the minimalist nature of hyperx.

With regards to breaking JavaScript

I've become ambivalent towards the debate. HyperApp lets you use whichever you like.

[jorgebucaran]

True, you will no longer import { html }, which was neat, but on the other hand using hyperx out of the box makes HyperApp opinionated about two things:

• using template functions (HyperApp is neutral, use what you want)
• using the hyperx module (what if someone writes a new html parser template function better than hyperx, should we switch? use both?)

I believe removing the hyperx dependency is a logical move.

Now let's see the biggest positive from this move:

• You can start using Hyperapp in production right now, because we finally have a build setup that works and no longer need to wait for my PR to be merged (assuming it will be ha).

[jorgebucaran]

@tunnckoCore Jade/Pug

Let's write a Jade/Pug parser as a template function, https://www.npmjs.com/package/pugx.

Then you can use it like this:

const { h, app } = require("hyperapp")
/** @pugx h */

app({
    model: "Hi.",
    view: model => pug`h1 ${model}`
})

Haha.

[tunnckoCore]

Haha. Interesting and still be a cool thing to have tagged template fn for pugx instead of what hyperx returns. But i meant instead of writing raw html as JSX, to write raw pug :D, But yea space sensitivity can be awful sometimes.

Something like

/** @pugx h */
const { h } = require('foobar') 
const mainView = (model, actions) =>
  section.hello
    h1 {model.title}
    p Hello {model.name}

app({
    model: {  name: 'Charlike', title: 'Hello World' },
    view: mainView
})

edit: The crazy thing and coolest thing is that Pug itself is template engine even language, so it will be able to do some very interesting crazy things.

edit2: Anyway, don't think the time for such thing is came yet :D

edit3: event more crazier with components

const mainView = (model, actions) =>
  Foo.hello(src={model.name}) 
    a(href={model.link})

[liadbiz]

agree with removing hyperx. actually it's wired to use tag template string to build virtual-dom. not easy to write, also not easy to write. however, jsx is is not bad, at least so many people ar using it, but also not good enough, because it's also kind hard to write. and bearking html with js is not problem for me. btw, pug is a good idea, i like it for that it's quit easy to write.

[jorgebucaran]

@liadbiz Hyperx is not wired to use virtual-dom only, you can use it with HyperApp too.

The problem with Hyperx is its tooling, hyperxify is wired in a way that makes it impossible to use it when exporting Hyperx via HyperApp (like we were doing before).

In other words, Hyperx works better when used directly by the consumer, so it was only logical to extract it from core.

• HyperApp+Hyperx+Browserify
• HyperApp+JSX+Browserify

[jorgebucaran]

Closing as this landed in ~@0.2.1.