6 ms·

Wasn't the unwieldiness of render functions the entire reason JSX was created?

michaelcampbell 6y ago
Not sure of the reason, but it's a godsend comparatively. The reaction against JSX I find to be largely by people who've never actually used it. If you keep your components small, as is best practice, whatever gut reaction one feels to it (which IMO is misplaced to begin with) is minimized, and quite readable.
- gnud 6y ago
  My big issue with JSX is that it forces you to use a pre-processor and source maps. If you have to do that anyway, I think I could use JSX instead of "pure" JS.
  - throwanem 6y ago
    Setting up Webpack and Babel isn't so bad, these days, and you really only have to do it one time and then you can reuse the setup in other projects. Plus, once you've done it, Typescript is easy to slot in, and that by itself makes the effort worthwhile.
    - onetom 6y ago
      I can highly recommend you watching this talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... It explains very well why is something being easy shouldn't be the main metric, when choosing some technology. In this case you are advocating to pull in webpack (28MB, 348 packages from 210 contributors), @babel/core (12MB, 54 packages from 60 contributors), typescript (53MB, 11 packages, 4 contributors), to just mention the most obvious and necessary dependencies, not even mentioning the different plugins for integrating them with each other, test frameworks, linters, IDEs (syntax highlighting and auto-formatting) and of course the mountains of type definition boiler-plate. 100MB+ of dependencies which are all a responsibility to learn, teach, configure and upgrade. Versus this ~12000 bytes: https://unpkg.com/hyperapp https://unpkg.com/hyperapp It's like 6 pages of code on a 2K iMac monitor and none of the above... I'm not saying that there are circumstances when you might want to put up with all that cost, but have you consciously considered, whether it really worth the overhead? What's missing from hyperapp, which is only present in the 100MB+ deps? Maybe `htm` (1MB, 11 packages, 4 contributors) is a better compromise between bloat and ease of development? And if you are willing to take on the extra dependencies, wouldn't ClojureScript provide a lot lot lot more benefits? It's also based on the super mature Google Closure Compiler, which supports extremely sophisticated optimization techniques and DCE... Just to mention some recent optimization surprise: https://twitter.com/roman01la/status/1277148232276234240 https://twitter.com/roman01la/status/1277148232276234240
      - throwanem 6y ago
        > [...] have you consciously considered, whether [it's] really worth the overhead? Yes, I have. The overhead of a React/TS stack is considerably less than the overhead of having to hand-build all the stuff that Hyperapp's 12 kilobytes aren't enough to provide, or that using ClojureScript means very few other engineers will want to work with me to build because I'm doing everything in a language and stack they've never heard of. > What's missing from hyperapp, which is only present in the 100MB+ deps? Eleven years! Hyperapp is written in pure ES5, which was finalized in 2009, around the same time PHP 5.3 came out. The world has moved on a great deal since then. (But hey, I haven't had to think about hoisting for like six years now, so that was a fun blast from the past!) That said, those 12 kilobytes of ES5 code are very concise, for sure. They also implement a virtual DOM and a sugar syntax over element creation and nothing else. To compare it based purely on codebase size, with a stack that provides orders of magnitude more functionality, seems at best very incompletely thought through, and at worst deliberately tendentious - although I'm sure that can't be the case. There's a lot of misinformation floating around about the modern Javascript world. A lot of that dates from years back, like the left-pad problem, or that builds aren't reproducible - both of which were true at one time, but have long since ceased to be. Or that using these tools makes it impossible to deliver compact, performant code to the frontend - which, again, hasn't been true in quite a while. It's not false to say that webpage bloat is worse than it ever has been, but it is false to blame the tools for that problem. Of course, I freely grant that it's hard to see these kinds of nuances if you don't have much or any context on what modern Javascript is actually like. What I don't grant is that that ignorance is any kind of worthwhile place from which to pass sweeping comments on the whole field of endeavor.
      - com2kid 6y ago
        If you are doing back compat for old browsers, Babel is necessary anyway. Typescript is a choice independent from anything else. There are alternatives to Webpack, none of which have gained traction, possibly because developers appreciate other features that webpack provides out of the box. But, you are complaining about the developer tools, why? The source code size of emacs/vscode/vi is just as relevant, or the size of the linter, or the complexity of whatever build environment is used to deploy code to production. All of those require upgrading and maintenance, and occasionally have bugs!
  - enobrev 6y ago
    The _only_ reason I use webpack and friends are for JSX and Typescript. For me, those two tools are worth the compilation step. Qs soon as it's possible to stop using compilers while still enjoying the benefits of both, I'll dump them from all my codebases.
- 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."
      - 6y ago
- onetom 6y ago
  ah, and the article also mentioned https://github.com/developit/htm https://github.com/developit/htm which pretty much provides what JSX does, just in a lot less complex way (at the cost of a little run-time)
  - jorgebucaran 6y ago
    If you like htm, check https://github.com/zaceno/hyperlit https://github.com/zaceno/hyperlit too
- deleted 6y ago
  [deleted]

Not sure of the reason, but it's a godsend comparatively. The reaction against JSX I find to be largely by people who've never actually used it. If you keep your components small, as is best practice, whatever gut reaction one feels to it (which IMO is misplaced to begin with) is minimized, and quite readable.

gnud 6y ago
My big issue with JSX is that it forces you to use a pre-processor and source maps. If you have to do that anyway, I think I could use JSX instead of "pure" JS.
- throwanem 6y ago
  Setting up Webpack and Babel isn't so bad, these days, and you really only have to do it one time and then you can reuse the setup in other projects. Plus, once you've done it, Typescript is easy to slot in, and that by itself makes the effort worthwhile.
  - onetom 6y ago
    I can highly recommend you watching this talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... It explains very well why is something being easy shouldn't be the main metric, when choosing some technology. In this case you are advocating to pull in webpack (28MB, 348 packages from 210 contributors), @babel/core (12MB, 54 packages from 60 contributors), typescript (53MB, 11 packages, 4 contributors), to just mention the most obvious and necessary dependencies, not even mentioning the different plugins for integrating them with each other, test frameworks, linters, IDEs (syntax highlighting and auto-formatting) and of course the mountains of type definition boiler-plate. 100MB+ of dependencies which are all a responsibility to learn, teach, configure and upgrade. Versus this ~12000 bytes: https://unpkg.com/hyperapp https://unpkg.com/hyperapp It's like 6 pages of code on a 2K iMac monitor and none of the above... I'm not saying that there are circumstances when you might want to put up with all that cost, but have you consciously considered, whether it really worth the overhead? What's missing from hyperapp, which is only present in the 100MB+ deps? Maybe `htm` (1MB, 11 packages, 4 contributors) is a better compromise between bloat and ease of development? And if you are willing to take on the extra dependencies, wouldn't ClojureScript provide a lot lot lot more benefits? It's also based on the super mature Google Closure Compiler, which supports extremely sophisticated optimization techniques and DCE... Just to mention some recent optimization surprise: https://twitter.com/roman01la/status/1277148232276234240 https://twitter.com/roman01la/status/1277148232276234240
    - throwanem 6y ago
      > [...] have you consciously considered, whether [it's] really worth the overhead? Yes, I have. The overhead of a React/TS stack is considerably less than the overhead of having to hand-build all the stuff that Hyperapp's 12 kilobytes aren't enough to provide, or that using ClojureScript means very few other engineers will want to work with me to build because I'm doing everything in a language and stack they've never heard of. > What's missing from hyperapp, which is only present in the 100MB+ deps? Eleven years! Hyperapp is written in pure ES5, which was finalized in 2009, around the same time PHP 5.3 came out. The world has moved on a great deal since then. (But hey, I haven't had to think about hoisting for like six years now, so that was a fun blast from the past!) That said, those 12 kilobytes of ES5 code are very concise, for sure. They also implement a virtual DOM and a sugar syntax over element creation and nothing else. To compare it based purely on codebase size, with a stack that provides orders of magnitude more functionality, seems at best very incompletely thought through, and at worst deliberately tendentious - although I'm sure that can't be the case. There's a lot of misinformation floating around about the modern Javascript world. A lot of that dates from years back, like the left-pad problem, or that builds aren't reproducible - both of which were true at one time, but have long since ceased to be. Or that using these tools makes it impossible to deliver compact, performant code to the frontend - which, again, hasn't been true in quite a while. It's not false to say that webpage bloat is worse than it ever has been, but it is false to blame the tools for that problem. Of course, I freely grant that it's hard to see these kinds of nuances if you don't have much or any context on what modern Javascript is actually like. What I don't grant is that that ignorance is any kind of worthwhile place from which to pass sweeping comments on the whole field of endeavor.
    - com2kid 6y ago
      If you are doing back compat for old browsers, Babel is necessary anyway. Typescript is a choice independent from anything else. There are alternatives to Webpack, none of which have gained traction, possibly because developers appreciate other features that webpack provides out of the box. But, you are complaining about the developer tools, why? The source code size of emacs/vscode/vi is just as relevant, or the size of the linter, or the complexity of whatever build environment is used to deploy code to production. All of those require upgrading and maintenance, and occasionally have bugs!
- enobrev 6y ago
  The _only_ reason I use webpack and friends are for JSX and Typescript. For me, those two tools are worth the compilation step. Qs soon as it's possible to stop using compilers while still enjoying the benefits of both, I'll dump them from all my codebases.
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."
    - 6y ago
onetom 6y ago
ah, and the article also mentioned https://github.com/developit/htm https://github.com/developit/htm which pretty much provides what JSX does, just in a lot less complex way (at the cost of a little run-time)
- jorgebucaran 6y ago
  If you like htm, check https://github.com/zaceno/hyperlit https://github.com/zaceno/hyperlit too
deleted 6y ago
[deleted]