-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Description
Based on how much struggle I've been having with the VM latetly:
- Add test for conditional on to try to reproduce ember#20647 glimmerjs/glimmer-vm#1563
- Remove support for Partials glimmerjs/glimmer-vm#1547
- [Quest]: Proper ShadowDOM support #20644
- [Bug] 3.28 - Conditionally rendering a modifier throws error #20631
- [Bug] Wrong assertion when dragging a text node #20610
- [Bug] Local helpers and modifiers cause memory leaks #20535
- [Bug]
vendor.jsgrows by 52 KB in production minified build in 5.6.0 compared to 5.5.0 #20628
And with the lack of ability for folks to iterate on implementing language improvements: emberjs/rfcs#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:
-
compat todos are done: Ember.js compatibility lifeart/glimmer-next#10 (we'll see tho if it works with ember-modifier, ember-resources, and bigger projects)
-
faster reactivity technique: Reactivity concept lifeart/glimmer-next#41 (Update-only VM)
-
looks like this is a list of remaining stuff: Explore lifeart/glimmer-next#3
glimmer-next compared with svelte and ember
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:
- this one: https://github.com/emberjs/ember.js
- glimmer-vm: https://github.com/glimmerjs/glimmer-vm
- glimmer.js: https://github.com/glimmerjs/glimmer.js
(which honestly needs to happen anyway)
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.

