7 ms·

Haven't been using react because of the JSX, but is this really where we are heading? https://hyperapp.dev/tutorial#rendering-to-the-dom https://hyperapp.dev/tu

• deergomoo 6y ago
  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]
• scrump3y 6y ago
  that is pretty much how React looks like after JSX is compiled to "pure" Javascript.
• raziel2p 6y ago
  Mithril was doing this exact thing before React became big - it's what we're moving away from (with JSX), not where we're heading.
  • pjmlp 6y ago
    Going back to PHP and ASP you mean.
    • jrwr 6y ago
      Hay! There is some power in being able to bang out a page with <h1>Hello <?php echo "World"; ?></h1>
      • pjmlp 6y ago
        Agreed, the problem is when that page gets to a book size.
        • cercatrova 6y ago
          That's why there are components that you put together, so that no one component is very large.
    • lyjackal 6y ago
      *improving on PHP and ASP
    • mhd 6y ago
      With thing like GraphQL, I get a definite ColdFusion vibe, too.
      • runawaybottle 6y ago
        We are definitely in ColdFusion territory: https://github.com/seancoyne/awesome-coldfusion#application-frameworks https://github.com/seancoyne/awesome-coldfusion#application-...
• pjmlp 6y ago
  If I ever need to render HTML from JavaScript, this is my solution, https://lit-html.polymer-project.org/ https://lit-html.polymer-project.org/ or tagged templates directly, although I rather prefer straight MVC separation, SSR/Angular/Vue style.
• runawaybottle 6y ago
  JSX evaluates to code that looks like that anyway. Not sure why we’d want to go backward on this front.
• jorgebucaran 6y ago
  Thank you! This is exactly the kind of feedback that we need to improve our presentation. I might just update the tutorial to use @hyperapp/html [1] instead. [1]: https://www.npmjs.com/package/@hyperapp/html https://www.npmjs.com/package/@hyperapp/html
  • hellcow 6y ago
    Please don't. Not everyone uses these additional libraries or preprocessors, and it was a big hurdle to figure out what was actually being generated behind the scenes in the v1 docs. A good approach is to show us what we need to do with no other dependencies (i.e. just as you're doing now with this h() function), and link to alternative syntaxes/libraries that may be optionally used instead.
    • jorgebucaran 6y ago
      Thank you for the feedback. I'll keep this in mind too. I'm definitely not advocating JSX usage. I favor hyperscript myself, but I understand it's an acquired taste. Idiomatic JavaScript alternatives that don't involve compilation include: - https://github.com/zaceno/hyperlit https://github.com/zaceno/hyperlit, and the aforementioned - https://www.npmjs.com/package/@hyperapp/html https://www.npmjs.com/package/@hyperapp/html
  • tobr 6y ago
    A nice flourish would be to have every example with both, and have a global switch to pick which one you prefer.
  • onetom 6y ago
    the tutorial is great this way. it's gradually introducing concepts and shows what's possible with very few building blocks. at the end, it would be nice to mention that at the cost of some extra code and learning a few more functions/concepts, you can gradually make application code either more concise with @hyperapp/html or having a different aesthetic or more familiarity - similar to JSX - with htm or the hyperapp-tailored variant of it, hyper-lit. but please keep the current didactic of piecemeal introduction of concepts, providing clear reasons for their existence!
• ollysb 6y ago
  Elm defines separate functions for each element type which in js would look like view: () => div({id: "app", class: "container"}, [ div({class: "filter"}, [ " Filter: ", span({class: "filter-word"}, "ocean"), button({}, "\u270E") ]), I'm admittedly used to this from years using Elm but to my eye I'd far rather use this than JSX.
  • jorgebucaran 6y ago
    100% agree, that's exactly what @hyperapp/html package attempts: - https://www.npmjs.com/package/@hyperapp/html https://www.npmjs.com/package/@hyperapp/html
• tobr 6y ago
  > obfuscated I’ve heard this reaction before when people see hyperscript-like APIs. I don’t understand it. Isn’t it abundantly clear what is going on if you know DOM and JS? What is your suggestion if you don’t like hyperscript and don’t like JSX? Parsing string templates at run-time?
• lf-non 6y ago
  Haha, I have spent my fair share of time procrastinating over what a type-safe JSX alternative would look like for React. The most ergonomic solution (well, atleast for me) has been their old factory API upon which I layered a set of convenience utilities [1]. I have been trying it out in a hobby project and I find the reduction of className boilerplate, elimination of closing tags etc. quite productive. And unlike alternatives like react-pug etc. I don't have to compromise with type checking of attributes. I'll probably release it as a library after doing some performance evaluation and if needed, wrapping it in a babel-macro [2] that eliminates the runtime overhead. -- [1] Example in CodeSandbox: https://codesandbox.io/s/pedantic-shape-lq9q9?file=/src/react-elfac.ts:0-18325 https://codesandbox.io/s/pedantic-shape-lq9q9?file=/src/reac... Code in github gist: https://gist.github.com/lorefnon/53377e4d6a6b13adbcfa155f486946a3 https://gist.github.com/lorefnon/53377e4d6a6b13adbcfa155f486... [2] https://github.com/kentcdodds/babel-plugin-macros https://github.com/kentcdodds/babel-plugin-macros
• riquito 6y ago
  htm [1], mentioned in the paragraph that you linked, is a very clever alternative, similar to jsx but in pure javascript [1] https://github.com/developit/htm https://github.com/developit/htm