ReactiveConf 2017 - Tom Dale: Secrets of the Glimmer VM
ReactiveConf1 HN recommender · recommended in 1 month, 2018-2019
3K views · 8 years ago · talk · dated
Tom Dale explains the internals of the Glimmer VM, Ember's rendering engine, which compiles templates to opcodes. The talk includes a performance benchmark demo.
HN points to it for understanding Glimmer and Ember's view layer, and as a reference for opcode-compiled templates.
54:58Keynote - JSON Graph: Reactive REST at Netflix
Association for Computing Machinery (ACM)
41K views • 11 years ago
31:17React.js Conf 2015 - Hype!
Meta Developers
108K views • 11 years ago
28:39Netflix JavaScript Talks - Async JavaScript with Reactive Extensions
Matt Marenghi
69K views • 12 years ago
1:11:55ElixirConf 2019 - Day 1 Morning Keynote - Brian Cardarella, Luke Imhoff, Paul Schoenfelder
ElixirConf
8K views • 7 years ago
4:40React.js Conf 2016 - Lightning Talks - Elie Rotenberg
Meta Developers
4K views • 10 years ago
40:55"Controlling Time and Space: understanding the many formulations of FRP" by Evan Czaplicki
Strange Loop Conference
69K views • 12 years ago
33:25Dan Abramov: Beyond React 16 | JSConf Iceland
JSConf
139K views • 8 years ago
55:28Erlang Factory SF 2016 Keynote Phoenix and Elm – Making the Web Functional
Erlang Solutions
23K views • 10 years ago
35:15Solid Ground // Saša Jurić
EMPEX Conference
14K views • 9 years ago
57:50ElixirConf 2018 - Keynote - Chris McCord
ElixirConf
32K views • 8 years ago
1:18:42Web Development in Emacs, Common Lisp and Clojurescript - Emacs SG
Engineers.SG
14K views • 10 years ago
1:21:25Let's prototype a JavaScript JIT compiler!
Andreas Kling
49K views • 3 years ago
29:47The Truth about Rust/WebAssembly Performance
Greg Johnston
218K views • 3 years ago
37:11CheerpX: a WebAssembly-based x86 virtual machine in the browser, Yuri Iozzelli
WebAssembly NA
7K views • 6 years ago
36:45Jordan Walke - React to the Future
ReasonConf
48K views • 6 years ago
45:05Servo Architecture: Safety and Performance
linux conf au 2017 - Hobart, Australia
12K views • 9 years ago
44:36Hacker Way: Rethinking Web App Development at Facebook
Meta Developers
900K views • 12 years ago
31:48Lin Clark - A Cartoon Intro to Fiber - React Conf 2017
Meta Developers
216K views • 9 years ago
36:31Hey Underscore, You're Doing It Wrong!
InfoQ
141K views • 13 years ago
35:12Jake Archibald on the web browser event loop, setTimeout, micro tasks, requestAnimationFrame, ...
JSConf
808K views • 8 years ago
3 comments from Hacker News
This is a good development. Honestly one thing I very much think is a downside about React is the fact that your template is also JavaScript. Don't get me wrong this is incredibly powerful and can be very expressive, but it comes at a cost. That cost has the same cost as other JavaScript - it's blocking, cannot be paused and has all the possibilities of de-optimizations that might occur in the JIT. The Ember team faced a similar problem in the past and I find their solution to this problem quite intriguing, even in it's obscurity. Instead of compiling their templates to JavaScript they instead compile them to opcodes in a binary format which is executed by a virtual machine. This has several advantages. Since the template file is represented as an optimized binary the size of the file itself is incredibly small, excellent since templates can be a large part of your eventual code. Not only that but since the instructions are opcodes, this mean the VM can pause at a moment when the browser is too busy with other stuff. Since a large part of your templates is probably static and not prone to any changes the template file also indicates which parts of the instructions are dynamic and which are static. This allows the VM to generate a separate set of instructions just for subsequent updates, only updating those parts which are dynamic. Now I am not saying this is a silver bullet, it is however an interesting and fresh approach. In case you're interested in this check out the Glimm
Yes, the runtime needs to be JavaScript. It’s not obviously faster, but it’s been benchmarked to be faster. ▶ this video You can skip to 29:34 for the performance demo.
Ember is the PostgreSQL of JavaScript frameworks. Similar to the way Postgres has deep roots that trace back to Ingres[1] in the days before SQL was a solidly established standard, Ember traces it roots back to SproutCore[2] in the JS framework pre-historic era of 2010. And the same way PostgreSQL was seen as a second-tier or only "historically significant" open source database, the PostgreSQL team just kept at it, toiling away year after year, steading churning out awesome code and excellent documentation, getting better and better with each release. Like clockwork. In the same way PostgreSQL is now, finally, enjoying more popularity and getting the recognition (long overdue in my opinion) for the awesome platform that it is, I expect that in time more developers will come around to appreciating Ember. The Ember leadership is definitely approaching the project and the processes around it like they intend to be not just relevant but pushing the boundaries for a long time to come. For one example this boundary pushing, you should not miss @tomdale's talk at ReactConf about GlimmerJS (the view layer extracted from EmberJS). It is, in my humble opinion, simultaneously mind-blowing and and inspiring.[3] [1] link [2] link [3] ▶ this video