Closed jorgebucaran closed 7 years ago
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.
Not "breaking JS" is one of the reasons why I like hyperapp. :-1:
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
@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.
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:
I believe removing the hyperx dependency is a logical move.
Now let's see the biggest positive from this move:
@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.
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})
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.
@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.
Closing as this landed in ~@0.2.1.
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.
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.