Integrate jsx about kaiju

[AlexGalays]

2 years ago, we started a project using virtual-dom (one of the very first libs to mimick React in a lighter and more focused way) There were two designers in the project who often helped with implementing views. They always said hyperscript was simple and they didn't miss HTML :)

[AlexGalays]

I thought about it a lot, and even prototyped a JSX integration at some point.
Turns out I'm not a big fan of JSX; I mean, it works; but is it necessary at all?
I think it's a tradeoff between HTML familiarity and everything else (it's only more readable if you have a lot of static content and you're not yet used to hyperscript, it adds another language in the stack whereas JS/TS is very serviceable to declare and compose a dynamic tree of vnodes)

snabbdom doesn't map too nicely to JSX (check snabbdom-jsx where everything have to be namespaced, making it a bit harder to read, which defeats the only point of JSX)
The alternative is to flatten everything and remove namespaces (Like React does) but then you lose some semantics (oh? you went and decided to set this as a property but I really wanted an attribute) check the React source code, they have quite a lot of code to deal with just that.

That said, I'm open to counter arguments (do you think I missed nice JSX properties?) and if you have a nice JSX->snabbdom spec in mind , I would be willing to consider it.

[kritollm]

I've just made me a mini framework with Type Script, snabbdom, snabbdom-JSX, Redux and Page.js. This is the entire framework:

import indexView from './indexView';
import bfEventsView from './bfEventsView';
import page = require('page');
import { createStore, Action, combineReducers } from 'redux';
import { counter, navigate } from '../shared/reducers';
const patch = require('snabbdom').init([
    require('snabbdom/modules/class'),
    require('snabbdom/modules/attributes'),
    require('snabbdom/modules/props'),
    require('snabbdom/modules/hero'),
    require('snabbdom/modules/style'),
    require('snabbdom/modules/eventlisteners'),
]);;

import { Store } from 'redux';

const getStoreProp = (prop: string) => {
    const state = store.getState();
    return (<any>state)[prop];
};

function main(store: Store<{}>, initNode: any) {
    let oldVnode = initNode;
    store.subscribe(() => {
        const navigate = getStoreProp('navigate');
        const newVnode = navigate.view();
        oldVnode = patch(oldVnode, newVnode);
    });
}

const store = createStore(combineReducers({ counter, navigate }));
const routes: [any] = [
    { route: '/Admin/', view: indexView },
    { route: '/Admin/index', view: indexView },
    { route: '/Admin/BfEvents', view: bfEventsView }
];

function init(routes: [any]) {
    routes.forEach(r => {
        page(r.route, (ctx, next) => store.dispatch({ type: 'NAVIGATE', payLoad: { view: r.view, ctx, next } }));
    });
}

function kickOff({base = '', startElement = document.getElementById('app') }) {
    page.base(base);
    init(routes);
    main(store, startElement);
    page();
}

export { store, Action, routes, getStoreProp, kickOff };

I had to add types definitions for classNames and selector so TypeScript should not complain and made a gulp script that used snabbdom-JSX / html instead React.createElemt.

What I thought was that all this had to be ready set up for users. It may well be that you are right and that it's better without JSX. Right now it feels easier to imagine visually using JSX, but that could change when I get used to hyperscript.

[marcusradell]

There's some arguments for static analysis of code (you know that JSX is static) to enable optimizations. But that's pretty advanced stuff to do.

The biggest win for me is that it's easier to get UX & design to help out with real code. With that said, I'm leaning towards non-jsx due to weak support in IDEs and superset languages like typescript. There's always (ok, usually) quirks in 3rd party tools that you need to fix to even get your tools to know that you don't have an unused variable, and that the JSX is valid code in that file.

[dmitriz]

There has been quite a discussion on the subject of JSX vs HS:
jsforum/jsforum#1
as well as more recently on Reddit:
https://www.reddit.com/r/reactjs/comments/5jonxn/why_is_hyperscript_rarely_used_being_less_noisy/

With more convincing arguments in favour of HS as far as I could see.
It seems though that FB has heavily invested in JSX (https://www.reddit.com/r/reactjs/comments/5jonxn/why_is_hyperscript_rarely_used_being_less_noisy/dbitgra/), so they will likely keep promoting it.

On the other hand, HS had made its way into the best (in my opinion) book on React:
survivejs/react-book@2685873,
which is a breeze to use in React with help of https://github.com/mlmorg/react-hyperscript and
https://github.com/ohanhi/hyperscript-helpers