There's some comparisons here[0]

As far as I can tell, where it falls somewhat short is in template dynamism, e.g. keyed arrays in React (which entails that drag/drop might also potentially be tricky), fractal structures like generating HN comment trees from JSON (vue, for example, used to have perf issues in the early days in this area due to recursive-descent rendering instead of batching), etc.

It seems to dabble a bit into normal control flow structures[1] but once you're at that level of language complexity, I'd probably prefer using a more established framework over this natural language DSL. The HN comment tree use case, for example, doesn't seem very easy to optimize if it turns out to be implemented in terms of reading the DOM to trigger subtemplate creation.

I think it's certainly interesting that there's now interest in alternatives to compiled stacks (e.g. React, due to JSX, anything using Typescript, etc) that are mindful of compile time creep and aim to bring development speed back into the limelight, but I fear that projects like this might be making the original "mistake" of shoving the perf pitfalls back to the runtime (where the users care). Personally, I think the future is going to be better compiler infrastructure e.g. esbuild, swc and the projects built on top of them (vite, etc).

[0] https://hyperscript.org/comparison/

[1] https://hyperscript.org/commands/repeat/

Just a shout-out to esbuild:

I've been working with it and, while it does have a few rough-spots occasionally...in addition to how fast it is, I love how easy it is to work with and write unique behavior for as necessary.

I never really fully digested Webpack, and I think part of that was because of the way it pushed its plugin ecosystem. By contrast, esbuild's plugin system is super easy to understand and placed front and center with the ecosystem off to one side, so if you write a esbuild script (in js OR Go), it's really easy to just write code to do what you want to have done instead of hoping that a bunch of third-party plugins can work together in the way that you want.

Anway, I haven't used swc, but I agree with your assessment. I look at all of the projects that are being worked in that rely on esbuild and swc and they all point to really pleasant development experiences that also have the capability of producing performant code.

What I haven't looked at recently is some of the other language specific pipelines. Is anyone here using non-TypeScript compilers to target JavaScript (like Kotlin, Scala, ClosureScript, ReasonML/Bucklescript) that could speak to the dev experience of the toolchain in 2021, as well as the resulting performance of the js? I'm pretty happy with TypeScript and get happier with each new release, but I'm also really interested in hearing other perspectives about language toolchains targeting js, and what folks are building with them.

Well sure, but this isn't for applications. It's to quickly and simply toggle a class or throw some AJAX functionality onto a page, which is all the vast majority of sites ever need to do. I can see it being super popular with the WordPress crowd.

> Show us an AJAX call that GETs data

    <button class='btn primary' _="on click fetch /clickedMessage 
                                            put the result into me 
                                            wait 2s
                                            put 'Click Me!' into me">
      Click Me!
    </button>

More here: https://hyperscript.org/docs/

I saw that, it leaves out a lot. In production you'll need something that formats the response and handles errors, which means defining a custom Event Source. It seems like the functionality quickly returns to traditional javascript when any normal amount of complexity is required.

As one of the other replies mentioned, the fetch will throw an event that you listen for. The server is the response formatter. The piece of the puzzle that you're missing is that the intent is that this library is used with the author's other library, htmx[0]. With htmx, the expectation is that you're always returning HTML as the response (though there are extensions available so you can return JSON that could be processed against a client-side handlebars template).

[0] https://htmx.org

Apparently when the fetch fails, it triggers an `fetch:error` event[1], which can (probably) be handled somewhere. No idea about formatting the response, though.

I think it's quite natural for there to be large gaps in functionality provided: it looks like a rather young and unpopular project, so the additional code needed to handle more situations from within the language still needs to get written. jQuery also didn't have a whole universe of plugins from day 1, but was useful enough anyway. Not saying this project has a chance to become another jquery, just that it too can be useful even in a far-from-complete state.

[1] https://github.com/bigskysoftware/_hyperscript/blob/master/s...

Yep, you can have an `on fetch:error` clause in the element's script.

Wrt. formatting the response, I'm experimenting with a hyperscript template language [1]. However, we don't yet have a design for imperatively building DOM trees (other than just doing it the same way you would in JS).

[1]: https://dev.hyperscript.org/commands/render/