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

31–40 of 92 posts

Re: The Glimmer VM: Boots Fast and Stays Fast

#31

Post by zedadex »

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…

If the problems were solved for people on native, there wouldn't be this much focus on reinventing the wheel on mobile.

Clearly for some subset of people, "something" is missing for those native solutions (I can guess - portability, convenient 'moddability', etc) which they believe the standardization-reliant web can better address for them.

Re: The Glimmer VM: Boots Fast and Stays Fast

#32

Post by pcwalton »

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…

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.

Re: The Glimmer VM: Boots Fast and Stays Fast

#33

Post by pcwalton »

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?

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

Re: The Glimmer VM: Boots Fast and Stays Fast

#34

Post by nebabyte »

analognoise wrote: post #6

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

What's wrong with re-solving an existing problem? Isn't that the entire idea of "fearless refactoring" that several process models use to mitigate reliance on/complacence with archaic systems?

I don't think "it's been done before" has ever in the history of progress been a good reason for something to not be reexamined and made better or easier to use.

Re: The Glimmer VM: Boots Fast and Stays Fast

#35

Post by astrobe_ »

zedadex wrote: post #31
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…

If the problems were solved for people on native, there wouldn't be this much focus on reinventing the wheel on mobile. Clearly for some subset of people, "something" is missing for those native solutions (I can guess - portability, convenient 'moddability', etc) which they believe the standardization-reliant web can better address for them.

Obviously the browser has become the universal VM. It solves the same problem as Java, but with Javascript instead of Java. So this decade Java school became Javascript schools, next decade it will be something else.

Re: The Glimmer VM: Boots Fast and Stays Fast

#36

Post by eric_the_read »

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…

I like that one of the opcodes is "FixThisBeforeWeMerge".

Looking this over, I can see why my initial reaction of "why aren't you using WebAssembly?" was facile; this really is a VM optimized for templating languages.

I'm reminded of the Bad Old Days when I was a ClearCase admin; we ended up building what my boss at the time called a Revision Control VM on top of it, so that our developers never really learned ClearCase per se; instead, they learned our system that happened to use CC under the hood. Since then, I've treated the term "VM" with a looser interpretation than usual; clearly, I should have applied that here (though it is, strictly speaking, a VM in the classical sense as well).

Re: The Glimmer VM: Boots Fast and Stays Fast

#37

Post by curveship »

ibdknox wrote: post #7
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.

In this particular case, I believe there are 3 reasons: 1) Size - turning each op into a couple of bytes means that the size of your template is significantly smaller. If each instruction is 4 bytes, I could get ~20 instructions in the space of just one function with a setAttribute call: function t(e) {e.setAttribute("id", "bar")} Size is much more important on the web than it is in other places especially as the nex…

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 that expression, just the "(,,)", so maybe 4 chars that an opcode could save.

As for 3), is that really possible? If you profile most modern frameworks, they're already fast enough that most of the time is spent in rendering, not in javascript DOM manipulation. So even if you cut short your js before 16ms (60fps), you have no idea how long the browser is going to take to render your changes. Plus, the browser will be doing extra work, since it needs to render all the frames in which you've only done part of your updates.

Re: The Glimmer VM: Boots Fast and Stays Fast

#38

Post by astrobe_ »

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.

Smalltalk?

Re: The Glimmer VM: Boots Fast and Stays Fast

#39

Post by pcwalton »

astrobe_ wrote: post #38
pcwalton wrote: post #32

Earlier quoted context omitted.

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.

Smalltalk?

Smalltalk isn't native!

Re: The Glimmer VM: Boots Fast and Stays Fast

#40

Post by unlmtd »

Truly, when it is time for the user of an application to load it with content, then is not the best time to download the application itself. Think of all this 'web app' period as just a great big experiment. One day soon, only content will flow when content is needed. It will be standardized so that everyone can see all the items for sale that match his/her filters, and not just 'this one website' list of articles for sale, along with a download of the entire unique application needed to view this one particular store. Water flows downhill, and the 'web app' days are numbered.
Post reply on HN