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

51–60 of 92 posts

Re: The Glimmer VM: Boots Fast and Stays Fast

#51

Post by bluepnume »

okket wrote: post #48
bluepnume wrote: post #45

I'm a big fan of what I'm seeing in Glimmer so far. I had fun adding support for xcomoponent yesterday, making Glimmer components work as cross-domain components. https://medium.com/@bluepnume/introducing-support-for-cross-... I'd love it if it were a little more flexible to get started with though. Rather than fire up ember-cli, I'd love to just be able to: 1. Load glimmer.js from a CDN 2. Extend glimmer.Component 3…

This is simply not possible with what Glimmer tries to achieve. (Did you even read the article?)

It's not possible to have a slower development build which does template->bytecode conversion on page load?

The point I'm trying to make it, there's already a huge amount of churn around the vast amount build tooling needed to write any javascript these days. Part of making a framework with a low barrier to entry is having the build tooling stay out of your way until you're ready to deploy.

I get that's not necessarily Glimmer/Ember's philosophy, I just think it's a shame that using the framework from day 1 requires buying into all of the technology choices around ember-cli.

Re: The Glimmer VM: Boots Fast and Stays Fast

#52

Post by analognoise »

pcwalton wrote: post #32
coldtea wrote: post #13

Earlier quoted context omitted.

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

Can you explain how "native" solved the problem of performing minimal MVC-style updates to a UI "decades ago"? Decades ago, we had the Win32 API, which didn't even try to solve this—apps had to roll their own.

As mentioned below - Smalltalk. You know, the language MVC was invented on...

Re: The Glimmer VM: Boots Fast and Stays Fast

#54

Post by analognoise »

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.

Modern web is just as shitty, we just have faster computers.

Re: The Glimmer VM: Boots Fast and Stays Fast

#55

Post by okket »

bluepnume wrote: post #51
okket wrote: post #48

Earlier quoted context omitted.

This is simply not possible with what Glimmer tries to achieve. (Did you even read the article?)

It's not possible to have a slower development build which does template->bytecode conversion on page load? The point I'm trying to make it, there's already a huge amount of churn around the vast amount build tooling needed to write any javascript these days. Part of making a framework with a low barrier to entry is having the build tooling stay out of your way until you're ready to deploy. I get that's not necessari…

Minimising time to first render/interaction is on the list what is important for Glimmer. I don't see how this is compatible with moving the conversion engine to the client.

(Not to mention that the app size zealots will eat you alive)

Re: The Glimmer VM: Boots Fast and Stays Fast

#56

Post by bluepnume »

okket wrote: post #55
bluepnume wrote: post #51

Earlier quoted context omitted.

It's not possible to have a slower development build which does template->bytecode conversion on page load? The point I'm trying to make it, there's already a huge amount of churn around the vast amount build tooling needed to write any javascript these days. Part of making a framework with a low barrier to entry is having the build tooling stay out of your way until you're ready to deploy. I get that's not necessari…

Minimising time to first render/interaction is on the list what is important for Glimmer. I don't see how this is compatible with moving the conversion engine to the client. (Not to mention that the app size zealots will eat you alive)

Yeah, that's essential in production. Totally agree. I'm mainly talking about the development experience for first-time users, or for people who just want to throw Glimmer onto one of their apps on localhost and play around with glimmer.Component. The thing that needs to be fast in those scenarios is the developer experience, not the app.

Re: The Glimmer VM: Boots Fast and Stays Fast

#57

Post by okket »

bluepnume wrote: post #56
okket wrote: post #55

Earlier quoted context omitted.

Minimising time to first render/interaction is on the list what is important for Glimmer. I don't see how this is compatible with moving the conversion engine to the client. (Not to mention that the app size zealots will eat you alive)

Yeah, that's essential in production. Totally agree. I'm mainly talking about the development experience for first-time users, or for people who just want to throw Glimmer onto one of their apps on localhost and play around with glimmer.Component. The thing that needs to be fast in those scenarios is the developer experience, not the app.

If you want to play around, have a look at Ember Twiddle:

https://ember-twiddle.com/

(No Glimmer there yet, only full Ember, but you can get a feel for what it can do, how it is like, test a things out...)

Re: The Glimmer VM: Boots Fast and Stays Fast

#58

Post by curveship »

lightblade wrote: post #41
curveship wrote: post #37

Earlier quoted context omitted.

For 1) and 2), some frameworks solve the size issue by creating functions for the basic DOM ops, which then get minimized to single character names in production. So in your example, there might be a setNodeAttribute(node, name, val) function, such that the final code isn't `e.setAttribute("id", "bar")` but just `a(e,"id","bar")`, where `a` is the minimized name of setNodeAttribute. There's really not much noise in t…

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 `[1,"id","bar"]`. So that's only a single char savings.

Re: The Glimmer VM: Boots Fast and Stays Fast

#59

Post by chubot »

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…

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 where this is going but the docs weren't particularly clear to me. If anything it sounds like there are a lot of other components besides the VM, which weren't really described in the blog post, and I couldn't find any links.

Re: The Glimmer VM: Boots Fast and Stays Fast

#60

Post by curveship »

ibdknox wrote: post #47
curveship wrote: post #37

Earlier quoted context omitted.

For 1) and 2), some frameworks solve the size issue by creating functions for the basic DOM ops, which then get minimized to single character names in production. So in your example, there might be a setNodeAttribute(node, name, val) function, such that the final code isn't `e.setAttribute("id", "bar")` but just `a(e,"id","bar")`, where `a` is the minimized name of setNodeAttribute. There's really not much noise in t…

In terms of #3, if you're yielding until the next requestAnimationFrame, the browser is telling you when you have the opportunity to do more work. Is there something that isn't covered by that? > they're already fast enough that most of the time is spent in rendering, not in javascript DOM manipulation That hasn't been my experience, but it's been awhile since I've benchmarked any of the frameworks in common use. Cha…

If I understand what Glimmer is proposing, they want to slice a long update process into a set of batches, so that they can pause in the middle to let the browser render a frame. My points were that a) they don't know how long it will take the browser to render that frame, so it's hard to say when to cut off the batch, and b) rendering intermediate states might increase the overall work, sort of a classic throughput vs latency tradeoff.

Paint and composite are usually fast, but calculate styles, layout and hit test may not be. It totally depends on the complexity of the DOM and CSS, of course, but as an extreme example, the js-framework-benchmark tasks are often 90+% time in render. That's why the results converge on 1.00: 0.95 of that is time spent in the browser rendering the DOM, and the time spent in javascript between a framework at 1.00 and one at 1.05 may be 2x difference (0.05 vs 0.10).

Post reply on HN