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

71–80 of 92 posts

Re: The Glimmer VM: Boots Fast and Stays Fast

#71

Post by always_good »

Pxtl wrote: post #50
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…

Yes, but the point here seems to be that once again, the web platform is obstructive and forcing us to build abstractions on abstractions.

As opposed to what, exactly? "abstractions on abstractions" defines all of computing.

As said above, it's not a distinction, thus it's meaningless.

Re: The Glimmer VM: Boots Fast and Stays Fast

#72

Post by pjmlp »

pcwalton wrote: post #68
pjmlp wrote: post #46

Earlier quoted context omitted.

It is a matter of implementation. It was native on the Alto, as the primitives were implemented in microcode, which could be a FPGA nowadays. Also Squeak and Pharo are implemented in Smalltalk.

When people complain about "Web" vs. "native", they are not talking about the Web versus the Xerox Alto.

Well I wish that web was able to achieve those boring native hypermedia systems from Xerox PARC, instead of squeezing a VM into a document platform.

Re: The Glimmer VM: Boots Fast and Stays Fast

#73

Post by MatthewPhillips »

tomdale wrote: post #62
MatthewPhillips wrote: post #29

Earlier quoted context omitted.

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 ha…

Yep, this is pretty spot on! At a high level, the Glimmer VM is built on top of two primitives: 1. References (as you describe, an interface implementation to provide the underlying value) 2. Tags, an interface that communicates "is it possible this value has changed?" Every reference has an associated tag, so once you have a reference, at any time you can ask: Is it possible this thing has changed? If so, what is it…

Thanks, this explanation is very helpful. One last question, when you say:

> Because this is just an integer comparison, it's very very fast on modern JavaScript VMs, even if you have lots of data on screen.

I don't follow, what is an integer comparison? Don't you have to compare the reference's value to the previous value? Meaning you need to get that reference's value. That reference could be somewhat expensive. Imagine if it is a property getter that calls into a few more functions.

This seems like the disadvantage of not using KVO, you don't know a property's value without asking for it. with KVO the value is cached and only changes when the underlying dependency tree changes. Of course vdom works without this, so it can't be that bad.

But I'm guessing you've found a clever way to avoid having to call out to get the reference's value to compare, so what is it? :-)

And I'll definitely read me in those docs, thanks!

EDIT: Probably should have read the docs first. A global counter id! Very clever... I wonder if you could get away with just a lastModified though. The view layer could keep track of the last time it updated and then just compare lastModified, if something has changed since the last time it updated then it must have changed too.

Going to think some more about this, thanks for the puzzle!

Re: The Glimmer VM: Boots Fast and Stays Fast

#74

Post by sixdimensional »

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…

Actually, I'd challenge us to ask ourselves, what do we think emulating HTML elements on a pixel-level actually is exactly? A client-side application rendering layer like X, or Wayland, etc.?

Think of VNC or remote desktop. This is basically an interactive moving image representation of server-side state and logic, which takes inputs from the user in the form of clicks, mouse movements, keyboard input etc. and pipes it to a server which is doing all the rendering and feeding images back to the client.

Now, if you are simply rendering images in the browser that are as good as HTML elements, the only difference between that and VNC really is the presence of client side state, client side event management and response, and somewhat increased interactivity of the client side with the local machine. Otherwise, you are simply collecting user inputs and producing outputs as a function of client/server state interactions and behaviors.

Personally, I see an interesting trend. For example, React seems to be about custom components that have client side local state and event handling, whereas things like Redux seem to be about gracefully handling the interactions between client/server state and behaviors. This same pattern appears in some way in Angular, Vue, etc. - two-way databinding, injection of services representing server-side objects, etc.

Also, consider things like WebAssembly, which will essentially provide an optimized VM in the browser closely linked to Javascript. What do we get when we cross improved client/server side state and behavior interactions plus optimized run-time environment in the client?

I think it's basically like the UI of the application runs in the client (whereas VNC was just an image of the application running), the client handles some of the processing logic and the server handles the rest, often manipulating the view of the user and coordinating that with the user's input.

All this, and it only takes a server, server application, server protocol, client application, client VM, client app/scripting language and client styling.

Looking into the future, this architecture seems to be presented as something that is the future - for example, look at Electron apps or WPF - they actually have a lot in common in some ways. Electron - node, Chrome, HTML, CSS, JS. WPF - UI host/application main loop, XAML, styling, C#...

I also think isomorphic Javascript concepts (write in one language, this code runs in the client, this code runs on the server) are going to make a massive leap forward when WebAssembly hits (shortly!!!) [1].

Exciting times in my opinion.

[1] https://lists.w3.org/Archives/Public/public-webassembly/2017...

Re: The Glimmer VM: Boots Fast and Stays Fast

#75

Post by Dylan16807 »

pcwalton wrote: post #33
analognoise wrote: post #25

Earlier quoted context omitted.

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?

Java applets on the Web were tried! They failed largely due to performance.

The performance problems were because of the way that specific VM was designed, not because it was a VM. You can easily have sub-millisecond initialization time on a VM if you make it a design goal.

Re: The Glimmer VM: Boots Fast and Stays Fast

#77

Post by skybrian »

analognoise wrote: post #25
skybrian wrote: post #11

Earlier quoted context omitted.

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?

The Smalltalk-80 VM is certainly interesting but as far as I know it wasn't allowing users to run untrusted, possibly malicious code. Taking security seriously came later.

Java was a pioneer with shipping untrusted code to users in a sandbox, but it turns out its sandbox wasn't secure, and there were other UI issues as well. (Similarly with Flash, though that was more of a mobile performance issue.)

To be fair, the early web had a lot of security problems. What we have now is what's left after a lot of hardening. And we still have a lot of security issues.

But anyway, if you use JavaScript this isn't really your problem. Browsers take care of sandboxing and deployment for you. Nothing wrong with building on the hard work of others.

Re: The Glimmer VM: Boots Fast and Stays Fast

#78

Post by chubot »

steveklabnik wrote: post #67
chubot wrote: post #59

Earlier quoted context omitted.

OK so I guess the VM outputs a virtual DOM tree from a handlebars template, rather than text? I don't really see why you can't do that with a simple tree interpreter, but sure why not. I've implemented template languages in multiple languages. I've also thought of compiling different languages to the same VM with string instructions (IIRC the old Cheetah template language compiles to Python bytecode). I sort of see w…

> so I guess the VM outputs a virtual DOM tree from a handlebars template, rather than text? As the article mentions, this technique is distinct from virtual DOM. The article is light on what specifically it does though. From the article: > I'll describe the details of this approach in another post, but the short version is that we compile templates into "append-time" opcodes for a bytecode VM. The process of running…

OK thanks, that helps. It sounds potentially interesting but in its early stages.

Re: The Glimmer VM: Boots Fast and Stays Fast

#79

Post by swsieber »

curveship wrote: post #58
lightblade wrote: post #41

Earlier quoted context omitted.

Well, Glimmer actually compiles opcodes to just numbers. So it wouldn't be `a(e,"id","bar")`, it's actually [1,'id','bar']. Opcodes' wire format is an array. I haven't see it being a tree yet. If this is the case, stream parsing is definitely possible.

Yeah, I was just looking at the Glimmer opcodes format. I'm a bit surprised it's an array of arrays, rather than a flattened array. It looks like it goes `[[1,"id","bar"],[2, ],...]` rather than `[1,"id","bar",2, ,...]`. Wonder why? Monomorphism, or faster dispatch by not having to pass a pc index around? Interesting. The `a(e,"id","bar")` format is what other frameworks produce. It sounds like in Glimmer it would be…

Ah, but you can pass it as json and have it render much faster. (If I've understood this thread correctly. Please correct me if I'm wrong)

Re: The Glimmer VM: Boots Fast and Stays Fast

#80

Post by steveklabnik »

chubot wrote: post #78
steveklabnik wrote: post #67

Earlier quoted context omitted.

> so I guess the VM outputs a virtual DOM tree from a handlebars template, rather than text? As the article mentions, this technique is distinct from virtual DOM. The article is light on what specifically it does though. From the article: > I'll describe the details of this approach in another post, but the short version is that we compile templates into "append-time" opcodes for a bytecode VM. The process of running…

OK thanks, that helps. It sounds potentially interesting but in its early stages.

No problem!

It is and it isn't; that is, all of this is extracted from Ember, so it has had a lot more maturity and testing than you might think at first. Not _super_ so as it's still relatively new, but deployed in lots of big places.

Post reply on HN