Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Glimmer VM: Boots Fast and Stays Fast

yehudakatz.com

Post reply on HN
Print view View original

21–30 of 92 posts

Re: The Glimmer VM: Boots Fast and Stays Fast

#21

Post by gmfawcett »

matthewmacleod wrote: post #10
analognoise wrote: post #6

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…

All development is just re-solving or extending? That's a sweeping generalization. My own work is definitely the incremental kind, and maybe yours is too --- but surely you'd agree that someone, somewhere in the world is doing truly innovative work.

Re: The Glimmer VM: Boots Fast and Stays Fast

#22

Post by LocalPCGuy »

mercer wrote: post #17

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…

In addition to what others have said, this would have a significant impact in accessibility and break a lot of the tools used for those with some sort of disability or accessibility issue. You are basically talking about what Flash used to do, and that's not a road we want to revisit.

Re: The Glimmer VM: Boots Fast and Stays Fast

#23

Post by steveklabnik »

Touche wrote: post #14
mwcampbell wrote: post #2

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.

Why does it need to generate code at all? Why can't it parse the template, create DOM nodes, listen to the "home" binding and do textNode.nodeValue = newVal whenever it changes. What does the bytecode VM provide?

This is literally what the article is about.

Re: The Glimmer VM: Boots Fast and Stays Fast

#24

Post by abecedarius »

steveklabnik wrote: post #19
chubot wrote: post #15

Earlier quoted context omitted.

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?

> This sounds like something written on top of a JavaScript VM, not a VM itself. 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 mostl…

Thanks. Up to this point I too was scratching my head wondering what the fuss was about -- if this was a JavaScript-in-Typescript VM, or what. It's a custom virtual machine for a domain-specific language for filling templates, right?

Re: The Glimmer VM: Boots Fast and Stays Fast

#25

Post by analognoise »

skybrian wrote: post #11
analognoise wrote: post #6

Isn't this just re-solving a decades old problem, with the (unnecessary) constraints caused by modern web systems?

If you can confirm to those constraints, you can securely ship UI code that automatically runs on computers all over the world, which wasn't a thing before the web.

Smalltalk-80 had a platform independent VM in 1980. If you want to be more recent, Java. Why is there so much confusion about how the web fits into things?

Re: The Glimmer VM: Boots Fast and Stays Fast

#26

Post by steveklabnik »

abecedarius wrote: post #24
steveklabnik wrote: post #19

Earlier quoted context omitted.

> This sounds like something written on top of a JavaScript VM, not a VM itself. 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 mostl…

Thanks. Up to this point I too was scratching my head wondering what the fuss was about -- if this was a JavaScript-in-Typescript VM, or what. It's a custom virtual machine for a domain-specific language for filling templates, right?

Yes, this is a good succinct way to put it. It compiles handlebars templates to its VM, and then as the machine executes, it updates the DOM appropriately. You can think of the Glimmer VM as a VM interface to the DOM rather than the direct DOM interface, and handlebars templates as programs that compile to that VM.

Re: The Glimmer VM: Boots Fast and Stays Fast

#27

Post by okket »

mercer wrote: post #17

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…

Whole websites were done in Flash, not long ago. It was not a good idea.

Re: The Glimmer VM: Boots Fast and Stays Fast

#28

Post by derefr »

recursive wrote: post #3
mwcampbell wrote: post #2

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.

I don't know the details in this case, but very often, any use of eval() prevents a lot of optimizations. That's because for anything the eval() can see, all static analysis goes out the window. In a dynamic language like javascript, there may have been precious little of it in the first place, but a lot of smart people have figured out a way to scrape together some run-time optimizations based on them. The existence…

The parent isn't talking about runtime-eval (where you hit the interpreter with strings over and over in a hot loop), but rather "manual JITing", the technique where you take code that would otherwise be very dynamic (looking up method names using variables, etc.), generate a string containing a function definition of one particular concrete specialization of said code, and then eval that string to get a native function handle—just as if said code had been turned into a blob URI and shoved into a attribute. Those functions will then get statically analyzed just like any other functions.

Re: The Glimmer VM: Boots Fast and Stays Fast

#29

Post by MatthewPhillips »

MatthewPhillips wrote: post #16

I love technical articles about how libraries are built. This is really great! 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 yo…

Thinking about it a bit more I think might know what is going on here. In a traditional KVO view layer (I've worked on a couple of these myself, so my thoughts here are biased) when a property changes it triggers an event. The view layer is listening to this event and so it knows to update the DOM to reflect the changed value.

What this means is that the view layer only works with evented KVO objects. What Glimmer has achieved is the ability to work with other types of data management systems. Knowing that is key to understanding (for me, at least).

So given that, what must be going on is that the view layer gets the value of a property with some interface. That interface implementation is provided by the view model so it differs. For plain objects it might just be `return obj.foo`. This will make getting a value really fast. No notification systems are required.

For updating the view layer there must be some generic way of telling it "hey, the obj.foo property might have changed (or maybe not, shrug), figure it out for yourself". Then using the update VM it is able to figure if it really did change, and only update the subtrees if it did.

Or something, this my interpretation. Sounds smart!

Re: The Glimmer VM: Boots Fast and Stays Fast

#30

Post by analognoise »

coldtea wrote: post #13
matthewmacleod wrote: post #10

Earlier quoted context omitted.

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…

> 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. 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 "fee…

This is what I meant!
Post reply on HN