3 ms·

If you keep your components small, then using this `h` function instead of JSX doesn't make a lot of difference from readability perspective. Also, don't forge

by onetom 6y ago

If you keep your components small, then using this `h` function instead of JSX doesn't make a lot of difference from readability perspective. Also, don't forget that `h` is just a function, so nothing prevents you from creating your convenience functions, which allow more concise/readable code, eg: const div = (...args) => h("div", ...args) const span = (...args) => h("span", ...args) (or something along those lines) I've experimented with this approach before (in ClojureScript) and you can get pretty far with it: https://github.com/enumatech/cljs-abi-viewer/blob/state-channels/src/cljs/dom.cljs#L36-L68 https://github.com/enumatech/cljs-abi-viewer/blob/state-chan... In fact the Hoplon (https://hoplon.io/ https://hoplon.io/) framework as already doing this many years ago, even just using the DOM directly.

throwanem 6y ago
The same is true of JSX. You can abstract and generalize its components with equal ease. I agree with another commenter that a lot of the common objections to JSX and React more generally, especially on HN, sound like things that people who've never used it but only seen a few examples would say. It's a shame, because with a little more experience those people could complain about stuff like how the complex form logic story in React just isn't really there yet, or how you can't really provide a lot of the subtle touches that go into making a really polished form UX without having to wrap an uncontrolled component inside a controlled one and handle all the state interactions manually. Forms are boring, I know, and everybody hates it when they have to be complicated. But they exist and are used for a reason, and I wish someone with fewer deadlines than I have right now would take the time to really nail down some of this stuff.
- keb_ 6y ago
  I personally never found much inherent value to JSX outside of making it easier to onboard other developers who are already familiar with HTML, or have seen React before. Otherwise, I found Hyperscript easy to read after about a day of using it, and there's no extra toolchain or compile-step required to use it. Plus it's "just JavaScript."
  - throwanem 6y ago
    I do rather like JSX, but I agree Hyperscript isn't difficult to read. As I noted in another comment, though, it also isn't difficult to set up a build step, and being able to use JSX is far from the only benefit of doing so. The point about onboarding deserves more consideration than it receives, too. I'd have an easier time finding good devs to work on a React/JSX project than one in Hyperapp, just because of the latter being unusual. The syntax isn't so much at issue here; Hyperscript could as well be sugar over React.createElement calls, just as JSX is. Anyone familiar with the DOM can look at it and see what it's doing quickly enough. What would concern me more would be the underpinnings; Hyperapp brings its own VDOM and ancillaries, parallel to React's, that anyone wishing to work on a Hyperapp project needs to learn to reason about - and that will have their own bugs, infelicities, and performance issues, just as React's does. But React's are generally very well known and not too hard to design around, even if actually designing around them can be a pain on occasion. No shade on the team, and I'm not trying to turn anyone off the project - I used to be much more of an early adopter until I got badly burned that way a few times, and these are the sorts of considerations that result from that kind of experience. I'll definitely be interested to see how Hyperapp holds up, and what kind of profile it achieves, over the next year or so.
kybernetikos 6y ago
When I'm not using JSX, I often do something like this const define = (componentDefinition) => (props, ...children) => isReactNode(props) ? React.createElement(componentDefinition, {}, props, ...children) : React.createElement(componentDefinition, props, ...children); const elements = new Proxy({}, {get: (target, tagName, _) => define(tagName)}); // ... const {div, h1, button, input} = elements; But although I really disliked JSX at first, once I tried it a little, I realised that it's about making the code describe what you want rather than how to get it. That mind set shift is actually valuable, even if underneath it's still turning into function calls.

by onetom 6y ago

throwanem 6y ago

The same is true of JSX. You can abstract and generalize its components with equal ease. I agree with another commenter that a lot of the common objections to JSX and React more generally, especially on HN, sound like things that people who've never used it but only seen a few examples would say. It's a shame, because with a little more experience those people could complain about stuff like how the complex form logic story in React just isn't really there yet, or how you can't really provide a lot of the subtle touches that go into making a really polished form UX without having to wrap an uncontrolled component inside a controlled one and handle all the state interactions manually. Forms are boring, I know, and everybody hates it when they have to be complicated. But they exist and are used for a reason, and I wish someone with fewer deadlines than I have right now would take the time to really nail down some of this stuff.

keb_ 6y ago
I personally never found much inherent value to JSX outside of making it easier to onboard other developers who are already familiar with HTML, or have seen React before. Otherwise, I found Hyperscript easy to read after about a day of using it, and there's no extra toolchain or compile-step required to use it. Plus it's "just JavaScript."
- throwanem 6y ago
  I do rather like JSX, but I agree Hyperscript isn't difficult to read. As I noted in another comment, though, it also isn't difficult to set up a build step, and being able to use JSX is far from the only benefit of doing so. The point about onboarding deserves more consideration than it receives, too. I'd have an easier time finding good devs to work on a React/JSX project than one in Hyperapp, just because of the latter being unusual. The syntax isn't so much at issue here; Hyperscript could as well be sugar over React.createElement calls, just as JSX is. Anyone familiar with the DOM can look at it and see what it's doing quickly enough. What would concern me more would be the underpinnings; Hyperapp brings its own VDOM and ancillaries, parallel to React's, that anyone wishing to work on a Hyperapp project needs to learn to reason about - and that will have their own bugs, infelicities, and performance issues, just as React's does. But React's are generally very well known and not too hard to design around, even if actually designing around them can be a pain on occasion. No shade on the team, and I'm not trying to turn anyone off the project - I used to be much more of an early adopter until I got badly burned that way a few times, and these are the sorts of considerations that result from that kind of experience. I'll definitely be interested to see how Hyperapp holds up, and what kind of profile it achieves, over the next year or so.

kybernetikos 6y ago

When I'm not using JSX, I often do something like this const define = (componentDefinition) => (props, ...children) => isReactNode(props) ? React.createElement(componentDefinition, {}, props, ...children) : React.createElement(componentDefinition, props, ...children); const elements = new Proxy({}, {get: (target, tagName, _) => define(tagName)}); // ... const {div, h1, button, input} = elements; But although I really disliked JSX at first, once I tried it a little, I realised that it's about making the code describe what you want rather than how to get it. That mind set shift is actually valuable, even if underneath it's still turning into function calls.