11–20 of 92 posts
Isn't this just re-solving a decades old problem, with the (unnecessary) constraints caused by modern web systems?
Isn't this just re-solving a decades old problem, with the (unnecessary) constraints caused by modern web systems?
While being technically correct, your statement is pretty much pointless. All development is 'just' re-solving an existing problem with better performance, or 'just' extending an existing algorithm to be more resilient, or 'just' implementing a legacy interface on a new platform. There are lots of very obvious reasons that the web has the constraints that it does and describing them as 'unnecessary' adds literally no…
Isn't this just re-solving a decades old problem, with the (unnecessary) constraints caused by modern web systems?
While being technically correct, your statement is pretty much pointless. All development is 'just' re-solving an existing problem with better performance, or 'just' extending an existing algorithm to be more resilient, or 'just' implementing a legacy interface on a new platform. There are lots of very obvious reasons that the web has the constraints that it does and describing them as 'unnecessary' adds literally no…
Only this is "re-solving an existing problem with worse performance that we had decades ago (on native), but slightly faster than the previous speeds we achieved having it run with its feet tied".
(Where by "feet tied" we refer to the performance penalty imposed by having everything run on the web stack).
What is the advantage of implementing your own bytecode VM rather than generating JavaScript code and using eval()? It seems to me that the latter would be more efficient, since you wouldn't have a VM within a VM.
What IS the glimmer VM? I didn't see any links on the page. Is this it? https://github.com/glimmerjs/glimmer-vm It is JavaScript code or native code?
That is it. It's TypeScript.
Glimmer is a flexible, low-level rendering pipeline for building a "live" DOM from Handlebars templates that can subsequently be updated cheaply when data changes.
This sounds like something written on top of a JavaScript VM, not a VM itself. Is it implemented with VM-like techniques? What does the instruction set look like?
I don't follow the last part of the article though. Specifically this part:
> We accomplish this by (under the hood) allowing every bit of data that goes into a template to separate the process of computing its current value from the process of determining whether the value might have changed.
When you say "bit of data", what exactly do you mean? I assume you mean some field that is bound to a template. Like a property on glimmer component. Using KVO this would be a compute of some kind, that triggers an event when its value changes.
Perhaps you're doing something totally different, but I don't see how? Breaking it down, we have an object like:
{
"foo": "bar"
}
Considering that Glimmer goes quite far in optimizing stuff, at which point would it perhaps make more sense to just emulate HTML elements on a pixel-level?
Or am I vastly underestimating how complex the standard UI elements really are? Or overestimating how much effort went into Glimmer? And if so, as perhaps a more constructive question: are there any areas of 'web' where someone feels a shortcut should be taken?
(On the latter, I'm inclined to feel that WYSIWYG textareas and CSS above class-scope are ripe for 'shortcuts', but perhaps that's opening some cans of whole other worms...)
Earlier quoted context omitted.
That is it. It's TypeScript.
OK, my confusion is why it's called a "VM": Glimmer is a flexible, low-level rendering pipeline for building a "live" DOM from Handlebars templates that can subsequently be updated cheaply when data changes. This sounds like something written on top of a JavaScript VM, not a VM itself. Is it implemented with VM-like techniques? What does the instruction set look like?
Earlier quoted context omitted.
That is it. It's TypeScript.
OK, my confusion is why it's called a "VM": Glimmer is a flexible, low-level rendering pipeline for building a "live" DOM from Handlebars templates that can subsequently be updated cheaply when data changes. This sounds like something written on top of a JavaScript VM, not a VM itself. Is it implemented with VM-like techniques? What does the instruction set look like?
You can write VMs in languages that are implemented with a VM.
> Is it implemented with VM-like techniques?
More than that, it is literally a virtual machine.
> What does the instruction set look like?
IIRC, it's a stack-based VM. Here's the opcodes, I believe: https://github.com/glimmerjs/glimmer-vm/blob/master/packages...
(I have mostly a high-level understanding on this, after talking to lots of people and watching presentations; I don't hack on Glimmer myself.)
Apologies ahead of time if this is a stupid question. I am pretty much the walking stereotype of a web developer with very little experience with anything below javascript/ruby/python/php. Considering that Glimmer goes quite far in optimizing stuff, at which point would it perhaps make more sense to just emulate HTML elements on a pixel-level? Or am I vastly underestimating how complex the standard UI elements really…
Even if this could be done with reasonable performance (and people have tried this), you shouldn't do this in any browser environment. You can't possibly emulate the behavior of every browser in a satisfactory way; you'll end up behaving gratuitously differently, with subtle breakage of platform conventions, browser conventions, user expectations (including potential extensions), hardware requirements, scaling, rendering, and accessibility.