search

emberjs / ember.js

Ember.js - A JavaScript framework for creating ambitious web applications
https://emberjs.com
MIT License
22.45k stars 4.21k forks source link

[Feature] Swappable renderer #20648

Open NullVoxPopuli opened 7 months ago

NullVoxPopuli commented 7 months ago

Based on how much struggle I've been having with the VM latetly:

And with the lack of ability for folks to iterate on implementing language improvements: https://github.com/emberjs/rfcs/issues/816 (not due to lack of trying, but due to how the VM is hard to work with / maybe has a lot of baggage)

And with the amount of progressing happening on an alternate renderer:

And with the desire to use Starbeam in the future, tho no one is really working on that as I write this

And with how we don't score whell in https://github.com/krausest/js-framework-benchmark (like it or not, this is how we are judged, so we must play the game)

And since we kinda need to migrate away from a pure-JSON representation of the complied templates so that we can explore more expressive syntax (something glimmer-next is already prepared to enable)

And with the ovelwhelming effort it feels like it would take to merge the 3 repos:

I've been wondering if we can work out a minimal public/intimate API for completely swapping out glimmer-vm / runtime such that folks can better experiment with improvements to ember.

As a quickly, barely thought out psuedo API, it could look like this, to support what we have today

import { registerRenderer } from '@ember/renderer';
// idk if these are real, but not the point
import { render } from '@glimmer/vm';
import { runtime } from '@glimmer/runtime';

registerRenderer({ render, runtime });

which could allow for someone to easily choose to use glimmer-next without forking ember-source.

import { registerRenderer } from '@ember/renderer';
// idk if these are real, but not the point
import { render, runtime } from 'glimmer-next';

registerRenderer({ render, runtime });

Or could allow someone to work on developing a native renderer for iOS and Android.

import { registerRenderer } from '@ember/renderer';
// idk if these are real, but not the point
import { render, runtime } from 'glimmer-android';

registerRenderer({ render, runtime });

One may consider that we have a lot to do, and we don't have enough steam to work on anything like this (like a native renderer).

I think we have people who currently aren't contributing as much, but would if they were able to, so we could enhance our parallel efforts -- widen the pipe, so to speak

Note as well, this issue could also be a call-for-help to have someone dedicate a bunch of time to improve the existing glimmer-vm.

NullVoxPopuli commented 7 months ago

Starbeam's vanilla renderer would be a good candidate here as well: https://github.com/starbeamjs/starbeam/issues/152

NullVoxPopuli commented 6 months ago

Another use case: Terminal UI renderers -- similar to Ink https://github.com/vadimdemedes/ink (I bet we could use way less memory pressure tho)

NullVoxPopuli commented 5 months ago

Looks like the place to implement this is in setupApplicationRegistry here:

https://github.com/emberjs/ember.js/blob/main/packages/%40ember/-internals/glimmer/lib/setup-registry.ts#L41

  registry.register('renderer:-dom', Renderer);

This is called from buildRegistry here: https://github.com/emberjs/ember.js/blob/main/packages/%40ember/application/index.ts#L226

And that's called from init in the Application's suprer class, Engine, here: https://github.com/emberjs/ember.js/blob/main/packages/%40ember/engine/index.ts#L335

  init(properties: object | undefined) {
    super.init(properties);
    this.buildRegistry();
  }

And we know application init occurs during boot with the Application class we create in app/app.js/ts.

So, we should be able to override the static buildRegistry and setup our own renderer:-dom.

So now it's a question of how much of Renderer is public API / (though, realistically, probably none of it, and we'd discover what should be public API through this process)

NullVoxPopuli commented 4 months ago

woah, look at all the renderers React has: https://github.com/chentsulin/awesome-react-renderer

there is certainly demand for this.