Status of this project

[devinrhode2]

I'd love to try using this plugin to see how it impacts the performance of our react app.

I tried throwing it into my react 16.8 app (which was recently upgraded from 15) and got this error:

https://user-images.githubusercontent.com/539816/66258066-78bf6380-e766-11e9-950c-8f20a0cfac0a.png

I think it's failing as soon as it hits some jsx.

So it looks like this project is not ready for prime time - is there some new technology that makes using iDOM+jsx not very fruitful endeavor?

Note that I'm using CRA+craco

Nowhere in my codebase do I read the property "imports"

This is my .babelrc

{
    "presets": [
        "react-app"
    ],
    "plugins": [
        "transform-incremental-dom",
        // should already be included but was having issues with scope macro
        // "macros",
        // do expressions are cool, but have issues with using types
        // "@babel/plugin-proposal-do-expressions",

        // prefer to use window.safeGet (hand written in polyfills.js)
        "@babel/plugin-proposal-optional-chaining",

        // foo.bar.baz ?? 'fallback' IS better than: foo.bar.baz ? foo.bar.baz : 'fallback'
        "@babel/plugin-proposal-nullish-coalescing-operator",

        // I'd love to be able to see the lint number of <div's in the dom... but this just doesn't seem to work...
        "@babel/plugin-transform-react-jsx-source"

        // CRA actually includes this by default:
        // [
        //     "babel-plugin-named-asset-import",
        //     {
        //         "loaderMap": {
        //             "svg": {
        //                 "ReactComponent": "@svgr/webpack?-svgo,+titleProp,+ref![path]"
        //             }
        //         }
        //     }
        // ]
    ]
}

I would share my app.jsx but that's proprietary company source

[jridgewell]

Without seeing an example that throws, I'm not sure I'm going to be able to help.

Status of this project

As for the status, I haven't worked on this some time. The underlying incremental-dom project itself isn't well maintained as an open source project. The only updates incremental-dom gets are when the internal project needs something.

[devinrhode2]

you know, the ember community may take real interest in supporting jsx as an alternative to handlebars. But then we might start talking about trying to create a common component model, potentially using web components, which starts to get pretty complicated

However the react community is huge and thriving... don't you think the react community would be interested in the glimmer/iDOM approach to rendering? Do you think the difference in performance would be comparable to glimmer vs react?

I'm just trying to pick your brain to understand the ultimate value that lies here

[jridgewell]

However the react community is huge and thriving... don't you think the react community would be interested in the glimmer/iDOM approach to rendering?

I think iDOM is actually drastically different than Glimmer. Regardless of the templating system (mustache vs jsx), iDOM tries to do naive patching of the DOM tree while Glimmer tries to understand what the dynamic portions are and only patch that. iDOM is a low-level patching library, where Glimmer is a template library. iDOM can be made to do that, but that requires building something on top of it.

I originally like this about iDOM, but I don't anymore. I think template based libraries will always be smarter, it's just up to us to make them fast and low-memory.

There's another project called lit-html that I also contribute to. It uses the DOM's <template> element to do templating, and has the same "only patch the dynamic parts" approach as Glimmer.

Do you think the difference in performance would be comparable to Glimmer vs react?

And that's why there's such a huge difference. Glimmer fully embraced its template, while JSX pretends to not be a template (even though it is!). I've actually been working on a new JSX implementation that embraces templates. The goal is make all of React faster with 0 code changes necessary in applications, it's a purely framework level optimization.

If Ember is interested in using that as it's templating system, I'm sure it could share the same babel transformer. It just needs to be aware of the format.

[devinrhode2]

The best way I can think of getting ember into the mix, is creating something that enables jsx inside ember apps, a drop in replacement for glimmer/handlebars - this could lead to a situation where everyone starts massively adopting jsx instead of handlebars (cause.... it's like wayyyy better yo) and then the best code to help the ember->jsx movement could be a codemod for converting handlebars templates to jsx.

I'm not really into ember a whole lot anymore, since I see react as clearly better than ember. (So not really interested in bringing jsx to ember)

I believe it should be possible to map jsx to handlebars code. Therefore, it should be possible to compile jsx templates to glimmer "bytecode"? But, it may be better to fully admit that it's better to target public api's. Therefore, if my view that jsx is nothing more than a more ergonomic handlebars can hold up, you could in theory just rewrite jsx as handlebars and then let glimmer do the rest, connecting the end product to react in some way. It gets tricky when you get to handling Components. Ember Components and React Components are largely the same... but there's more than likely some key differences that would have to be amended with this approach.

I think the better engineering approach could be to compile jsx to glimmer's bytecode. It might actually be a more stable 'api' than handlebars.

====

I just watched this video on glimmer https://www.youtube.com/watch?v=KeYJ0gHQb14 and it's honestly so f*cking advanced that's it's probably a better idea to compile to some intermediate target "below" handlebars. Rust+wasm?

There is glimmer native thing going, but it's in an all caps ALPHA state.

Glimmer is so fast it makes web competitive with native. Of course, react native probably gives you a more responsive native experience, but presumably glimmer native could make for an even more responsive native app. The glimmer and react could really benefit from each other...

[oravecz]

I think the problem the OP is experiencing is caused by changes in Babel 7.

[devinrhode2]

@jridgewell Care to elaborate more on why you think templates will always be superior to jsx? lit-html seems pretty cool, but I think svelte might win over and in the process solve this vdom inefficiency