Comments (5)
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 :)
from kaiju.
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.
from kaiju.
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.
from kaiju.
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.
from kaiju.
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
from kaiju.
Related Issues (8)
- Can't do msg.send synchronously inside connect() HOT 1
- snabbdom subtree render HOT 3
- Fullpage application problem HOT 10
- Event listeners are not removed when using message.with(newReference)
- Observable.filter has a wrong type signature
- Simplify Message vs DefaultMessage HOT 1
- snabbdom modules parameter in startApp is redundant HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kaiju.