Hyperapp: RFC: Should we drop JSX support? 🤪🤯

[jorgebucaran]

EDIT: Thank you everyone for your enormous feedback! For the looks of it, a lot of people around here don't use or don't care about JSX or are ready to learn better ways! 😏🙏

Good for us for you! I mean it. I think I am not ready to remove JSX from core and start asking people to get a dependency to support JSX. For every comment and thumbs up, there are more lurking eyes and thumbs that go unnnoticed and I am willing to bet they don't hold the same courageous opinion.

I feel that I would end up alienating and disuniting more than uniting with a move like this. So, I am happy to close this. 🎉

---

Should we drop built-in JSX support? Yes or No?

This involves modifying (simplifying really) how hyperapp.h works, by making it monomorphic (single signature) instead of the current implementation that supports multiple varargs (arguments are slow!).

Pros

• Better performance.
• More liberty in how components are used / instantiated.

Cons

• No JSX. Or at least not until https://github.com/babel/babel/issues/2034 is resolved.

[Swizz]

For JSX lovers, here is how to add JSX support back to Hyperapp if stripped out.

function jsx(type, props, ...children) {
  return typeof type === "string"
    ? h(type, props, children)
    : type(props || {}, children)
}

[selfup]

I vote we keep JSX. It makes building frontends very nice. This is what makes me really enjoy Hyperapp 😄

JSX is an attractive feature for a lot of folks. And would keep with the Keep it Simple construct Hyperapp seems to have.

From editor support (syntax highlighting, etc..) and plug and play for things like Codepen, etc.. I can't imagine not keeping JSX as a core feature. This feels like more than a breaking change 🤔 This is a change in audience, newcomers, etc..

From a performance standpoint, we are in a good place, so I am not worried about it 😛

[lukejacksonn]

I've always found that JSX detracts from the simplicity and purity of hyperapp somewhat. We are pursuing and encouraging, to a degree, a pure and functional approach to building apps. JSX obfuscates and kind of contradicts this intention. WYSIWYG code is good, vanilla JavaScript is good and functions.. are good.

• It is a proprietary markup language
• Another thing to learn
• Demands compilation
• Messes with syntax highlighting
• Less terse thanh syntax
• Negatively impacts performance
• Limits the potential of component progression
• It is another way of doing the same thing

We are not alone in doubting it's usefulness https://news.ycombinator.com/item?id=11290827

As you know, I hate typing and boilerplate.. so I like to imagine how things scale where there are 10 of something for instance, props:

<Component propA={propA} propB={propB} propC={propC} propC={propC} propD={propD} propE={propE} propF={propF}/>

When you can do exactly they same, with just vanilla JS:

Component({ propA, propB, propC, propD, propE, propF })

There are, of course, more intricate niggles and inconsistencies like className etc. but we are all aware of these so I won't list them.

$0.02

[selfup]

Yea I hate typing extra as well, so I typically call comps as funcs because the prop syntax is meh (thankfully you can do that inside of JSX). I am just trying to see how we can make Hyperapp grow in the JS community. Not have an Elm like barrier to entry 💥

I think this day and age, a compile step for a modern frontend is necessary regardless. So YMMV on how one feels about that 😂

I dunno, this will end up being the Vim vs Emacs debate forever 😭

---

At the end of the day, whatever is picked I'm cool with. It'll just be interesting to see what happens 🎉

[jorgebucaran]

On the other hand, even if we simplify h() to "remove" JSX support, you could still compile JSX to h() using https://github.com/substack/babel-plugin-jsx-factory. 🤔

[SkaterDad]

I'm all for dropping the JSX support. I don't use it, and the current h() function is definitely overcomplicated because of it.

[mecurc]

Sorry, but i belive hyperapp will use some es6 features like (type, props, ...args) and it not will be slow.

[lukejacksonn]

Unfortunately, this. I am also worried about it. Maybe "the world" is not ready to go vegan..

@JorgeBucaran if this is your mindset, then why raise this issue? What data will convince you otherwise? We are never going to be able to survey every dev to get a conclusive answer, especially those who are yet to adopt or even follow hyperapp.

Are we here to be popular, or promote the _hyperapp_ way of doing things.. with simple functions?

What if we just don't treat it as a first class citizen.. but provide a function like @Swizz suggests or babel-plugin-jsx-factory.. to be like "if you are not ready to drop JSX then use this" but provide demos and examples in h or @hyperapp/html for brevity and conciseness.

JSX: “it’s looks familiar, like HTML”
…Correct. Inertia against learning better ways is the only reason to use JSX.

@staltz

[jorgebucaran]

@lukejacksonn

That example shows very well that passing several props to a component using JSX syntax is tedious and repetitive, you made an excellent point, thanks.

Just one thing, and I don't really want to derail the thread, but clarify that typing or boilerplate has _nothing_ to do with scalability.

Vertical scalability: it means that the application program can input more data, work on it, and produce result with minimal or no degradation in performance when basic resources (processor, RAM etc.) are increased in proportion to input data or complexity of the problem.

Horizontal scalability: it means that the application program can input more data, work on it, and produce result with minimal or no degradation in performance when parllalization (multiple threads, processor cores, or sometimes even compute nodes) are increased in proportion to input data or complexity of the problem.

And with regards to:

...then why raise this issue?

I'd like to start a discussion about it, that's all. I've found myself using hyperapp/html and liking it, but I am not sure if we are ready to drop first class JSX support, even thought I'd want to.

[depoulo]

Coming from Choo to HA, I started out using template literals (being used to React+JSX from my dayjob), but quickly went to love the built-in JSX support, because:

1. HA supporting it makes it less proprietary, demonstrating with how little code you can replicate big portions of what is good about React+Redux.
2. Coding assistance (highlighting, linting) - this will never be as good for template literals: while JSX is an "industry standard" with good tooling around it, template literal tag functions could be used for any transformation.
3. https://facebook.github.io/jsx/#why-not-template-literals

[lukejacksonn]

@JorgeBucaran yeh I realise that might have sounded confrontational, so sorry for tone 🙇 I never claimed boilerplate has a positive or negative impact on scalability.. I'm just a slow typer and like to type less. I do think, however, it has _some_ impact on comprehension and digestibility.. less is more, if it does the same thing, but perhaps that is opinion too.

Supporting JSX doesn't technically bother me too much; as don't use it.. I can side step most of the pitfalls. It is more a pedagogical peeve than anything else. We don't _need_ JSX to make hyperapps. When we give examples in JSX, we assume you "know" JSX, which is a bold assumption, especially for people not coming from react.

I have talked to a lot of experienced purescript/haskell/reason/elm developers who are taken by the simplicity and purity of hyperapp and almost excited to build within this paradigm on the frontend, in just JS.. but who are almost immediately turned off when they see JSX. So I guess it works both ways. Personally I don't think we should dilute our thinking/teachings/discussions with a markup language that is non-essential to the building of hyperapps.

@depoulo have you tried using just h functions? Or perhaps @hyperapp/html or hyperscript-helpers or JSnoX. I don't think anyone is championing template literals as an alternative. They are, at least imo, riddled with the same, if not more inconsistencies/issues.

This is all I have to say on the matter now, I think.. it is taking up too much time writing essay length responses to this thread! 😅

[depoulo]

@lukejacksonn Valid point about the alternatives - to be honest, since JSX is even used in HA's readme hello-world example, I hadn'd stumbled upon them recently. They look useful, and in some cases even more terse than JSX, but to argue that JSX is

Another thing to learn

Well, I don't know. IMHO it is more a matter of very different taste - to template or not to template.
Like most template languages, JSX looks a lot like HTML and is as such very easily parseable by the reader. The functional alternatives are for people who dislike templates and consider them

weird XML dialect in the middle of your JavaScript

So it's all about defining HA's target group. The current approach supports a wider target group than the one without JSX.

[mecurc]

Hm. drop it.

It can be separate package.

@hyperrapp/jsx

[whaaaley]

Unfortunately, this. I am also worried about it. Maybe "the world" is not ready to go vegan/JSX-less yet.

The world doesn't change if no one changes it. I vote drop JSX. 👍

[cjh9]

I'm also for dropping JSX if it increases performance.

[ludoviclafole]

I use JSX with hyperapp but, reading all the discussion it seems pretty easy to support on userland.
Perhaps document how to use JSX for those that are interested in it ?

So for me nothing against dropping it :+1:

[leifoolsen]

In larger projects, it is not uncommon to have dedicated interaction designers and/or graphic designers with good HTML knowledge. My experience is that these people often have limited JavaScript knowledge, but may relate ok to JSX as this is relatively similar to HTML. I can not see that it's a good thing to drop JSX support completely - so as a minimum it must be possible to add a plugin to get support for JSX. For my part, there will be no alternative to developing components in JSX.

[jorgebucaran]

Thank you everyone for your enormous feedback! For the looks of it, a lot of people around here don't use or don't care about JSX or are ready to learn better ways! 😏

Good for ~us~ for you! I mean it. I think I am not ready to remove JSX from core and start asking people to get a dependency to support JSX. For every comment and thumbs up, there are more lurking eyes and thumbs that go unnnoticed and I am willing to bet they don't hold the same courageous opinion.

I feel that I would end up alienating and disuniting more than uniting with a move like this. So, I am happy to close this.

[lukejacksonn]

Some closing thoughts on this matter:

Supporting JSX doesn't technically bother me too much (I don't use it.. I can side step most of the pitfalls). It is more a pedagogical peeve than anything else. We don't need JSX to make hyperapps but when we do demos/examples in imply that it needs to be known/used which detracts from the purity and simplicity of hyperapp.

Supporting it is one thing.. endorsing it is another. Especially when it constrains our h implementation.

@Swizz has some good thoughts on the matter https://hyperapp.slack.com/archives/C42RQKF8E/p1512563784000244?thread_ts=1512532533.000127&cid=C42RQKF8E

I think we need to think that h, html, jsx and lit are all helpers that helps users to create a vnode pojo at their discretion with ease.

By making h at the same level at the others, we can have a clear mind about the fact that the dependency between jsx and h should be only composition and not support.

But ATM we made h support jsx and this is the wrong way.