8 ms·

This actually already exists as a library. This type of syntax is called Hyperscript[1], and it's existed (at least) since 2012. [1]: https://github.com/hyperh

This actually already exists as a library. This type of syntax is called Hyperscript[1], and it's existed (at least) since 2012. [1]: https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript (Although this library does not look maintained anymore)

glutamate 6y ago
Cool! I was looking for something like this but couldn't find it. Oh well, building my own kept me sane during lockdown. I think combinator libraries like this and one I'm building are definitely better than templating languages, although JSX can also work really well, in particular because it retains the HTML syntax making it easy to copy from the browser into code.
- wilsonfiifi 6y ago
  You can also take a look at mithril.js implementation of hyperscript [0] [0] https://github.com/MithrilJS/mithril.js/blob/next/render/hyperscript.js
  - holtalanm 6y ago
    was about to mention Mithril. solid framework, but not great for large applications.
    - brlewis 6y ago
      What issues have you encountered that make it not great for large apps?
      - holtalanm 6y ago
        it has been a few years, so maybe these issues have been addressed at some point since I used it last, but: 1) there were multiple issues with deeply nested object models not being reactive within the UI code that cause me to explicitly call m.refresh (can't remember the exact api, as it has been a while, but the function that was called forced a virtual dom refresh, which was _not_ good for performance). I ended up writing a debounce function that would make sure the m.refresh function only got called once per paint at the most, which helped, but it was just a band-aid over the underlying problem, which was that the framework was not detecting reactive property changes within deeply nested models. At the time I was using it, there was no other remedy according to issues that had been brought up on stack overflow. 2) this is probably personal opinion, but the hyperscript model for structuring html, while it looks good on paper, lends to a really tedious process of writing html-generating javascript. I guess I didn't need a numbered list. Those were my main two gripes.
        brlewis 6y ago
        For (1), m.redraw() is async; I don't think you have to debounce anymore. The autoredraw system may be more sophisticated than when you used it, too. https://mithril.js.org/autoredraw.html https://mithril.js.org/autoredraw.html For (2), I've been using JSX with Mithril the whole time. My team and I didn't like deeply nested hyperscript either. (At my employment we're in the process of moving away from Mithril, but I'm still using Mithril 2 in a side project)
    - lhorie 6y ago
      Curious why you claim that. It can be used the same way as React is used, and React is largely touted as something that is fitting for large apps.
ChristianBundy 6y ago
Yup, it's almost exactly the same syntax if you use Hyperaxe (built on top of HyperScript): https://github.com/ungoldman/hyperaxe/ https://github.com/ungoldman/hyperaxe/
schwartzworld 6y ago
hyperscript itself is basically Elm without the Elm language

glutamate 6y ago

Cool! I was looking for something like this but couldn't find it. Oh well, building my own kept me sane during lockdown. I think combinator libraries like this and one I'm building are definitely better than templating languages, although JSX can also work really well, in particular because it retains the HTML syntax making it easy to copy from the browser into code.

wilsonfiifi 6y ago
You can also take a look at mithril.js implementation of hyperscript [0] [0] https://github.com/MithrilJS/mithril.js/blob/next/render/hyperscript.js
- holtalanm 6y ago
  was about to mention Mithril. solid framework, but not great for large applications.
  - brlewis 6y ago
    What issues have you encountered that make it not great for large apps?
    - holtalanm 6y ago
      it has been a few years, so maybe these issues have been addressed at some point since I used it last, but: 1) there were multiple issues with deeply nested object models not being reactive within the UI code that cause me to explicitly call m.refresh (can't remember the exact api, as it has been a while, but the function that was called forced a virtual dom refresh, which was _not_ good for performance). I ended up writing a debounce function that would make sure the m.refresh function only got called once per paint at the most, which helped, but it was just a band-aid over the underlying problem, which was that the framework was not detecting reactive property changes within deeply nested models. At the time I was using it, there was no other remedy according to issues that had been brought up on stack overflow. 2) this is probably personal opinion, but the hyperscript model for structuring html, while it looks good on paper, lends to a really tedious process of writing html-generating javascript. I guess I didn't need a numbered list. Those were my main two gripes.
      - brlewis 6y ago
        For (1), m.redraw() is async; I don't think you have to debounce anymore. The autoredraw system may be more sophisticated than when you used it, too. https://mithril.js.org/autoredraw.html https://mithril.js.org/autoredraw.html For (2), I've been using JSX with Mithril the whole time. My team and I didn't like deeply nested hyperscript either. (At my employment we're in the process of moving away from Mithril, but I'm still using Mithril 2 in a side project)
  - lhorie 6y ago
    Curious why you claim that. It can be used the same way as React is used, and React is largely touted as something that is fitting for large apps.

ChristianBundy 6y ago

Yup, it's almost exactly the same syntax if you use Hyperaxe (built on top of HyperScript): https://github.com/ungoldman/hyperaxe/ https://github.com/ungoldman/hyperaxe/

schwartzworld 6y ago

hyperscript itself is basically Elm without the Elm language