Architecting Web Apps - Lights, Camera, Action! (Chrome Dev Summit 2018)

[@beardymonger]

What a smooth and smart presentation. Boy Google is lucky to have you, Paul Irish, Jake Archibald and many more :-)

[@johnbalvin5401]

boy they are not Paul Irish and Jake Archibald, they are Paul Lewis and Surma

[@Textras]

first Actor :) Thinking the media, security, device capabilities and identity being only exposed on the main thread 'is a bug' means there's hope. Free the API's!!

[@samirsaeedi74]

22:55 are we talking interfaces? (TS has them them.) Maybe throw in a dependecy injection mechanism there while you're at it. Also I don't get the desire to send messages to have the actor choose the right method to call (possibly in a somewhat redundant switch case construct). Why not just call the method directly? If the interoperabolity between different implementations is the concern then interfaces have you covered already. I guessI have to read about the pattern more.

[@dassurma]

Yeah, we are talking interfaces, but rather message interfaces than method interfaces. The reason messages are kinda more preferable is because they are usually easier to serialize to other communication channels. But in the end you are right, it’s all just semantics. As you can see in the examples in the `actor-boilerplate`, I did in deed ditch the switch-case for a direct function invocation: github.com/PolymerLabs/actor-boilerplate/blob/92d986dde57f2269ca9a0351da79fd7584c6abc8/src/actors/storage.ts#L60 As for Dependency Injection, that’s pretty much what hookup/lookup are, just not injected as parameters (you can build that as a layer on top, if you want).

[@SeanJMay]

You won't be able to call the method of an object that is on the server, or exists in a different thread. I realize that's what RPC was all about, but I hope that most of us agree that was a generally not-great idea, which lead to bugs and vulnerabilities. The actor model was based on Carl Hewitt playing pool, and observing how all of the balls interacted with one another on the table. It works like this: I am an actor. I have an inbox. People who have my address know that I will only accept certain kinds of requests. At some point, I will be allowed to pull the first message from my inbox, read it, and perform some action. During that action, I might compute some value, I might send a message to somebody else's inbox (assuming I know their address), I might instantiate another actor (and thus have their address), or I might just decide to do nothing. At some point in the future, I will be allowed to check my inbox again. The reason this works across threads and networks is because the interfaces are for data-interchange, and not for class instances. No RPC required. The actors don't even need to be written in the same language, if the framework is sufficiently awesome.

[@davidjournot1741]

Very useful presentation, thank you! I've been playing around with angular platform-webworker for a while to bring as much code to the webworker as possible but this solution lacks flexibility for importing libraries or lazy loading. I might switch to the actor model.

[@RuairiODonnellFOTO]

How is this different from the dispatcher within something like Redux?

[@davidkhourshid4450]

Asking the wrong question. How is Redux different from the Actor model? ;-)

[@prosperobum2185]

Your making use of web workers instead

[@beknaraskarov553]

Redux can be used as a state machine of an actor

[@dassurma]

Well observed, it’s very much related. But Redux is just a single entity. The actor model is a generalization of this concept. You can implement the actor model with multiple Redux instances, although the cross-thread messaging will get a bit messy.

[@MichaelQuad]

ye, okay, but there is no shared memory between web-worker and the main thread, how to handle thing? it's not convy to send string/ArrayBuffer messages. it will require overhead and another which will implement copy-transfer.. right?

[@emilemil1]

So basically the observer pattern. It's a good model for anything with a responsive UI, though it has the issue of allowing frames to slip between the cracks. You have to take great care to batch your DOM updates so that you don't get frames with half-finished modifications. A simpler way to improve performance would be to have "checkpoints", basically places where you say that it's okay for your JS execution to pause. It could either be a short pause that allows only a single frame (for animations), or it could also allow reflows if future JS won't modify the DOM. Basically you tell the browser to temporarily make rendering JS-blocking, rather the other way around. The main advantage of this method is that it is pattern-agnostic and backwards compatible. Just toss in a few checkpoints in problematic areas and it just works.

[@212astra]

where's the supercharged T_T

[@datsteves]

i actually build my own package for that because of this presentation :D which we use in our new app at work that we will roll out in to production soon :) split it up even further though, that anyone in the system can talk to a single component in the UI. so for example you can have a long running task in a worker (maybe even on the a worker_thread via electron) that yields every few seconds its progress to a process manager ui component that will display that state. Or simpler, any button, hotkey or command palette component could say "open edit task edit modal with ID: 123". This helped a lot, as we now can move the upload process, the thumbnail generation and so on to a webworker, without having to change almost anything. just the bit that connects the two systems has to be a little different. Which is just like 2-3 lines of code :D you can even query things from those actors, if you await an dispatch and the actors responds to the message you get that value back, which is nice :) anyone who is interested can look at github.com/datsteves/actorize its still more like in an alpha version, so apis can change and probably will, as we at work get more experience at working with that package with what works and what doesn't. Thats why for example there is a React hooks integration :)

[@cucco1]

Really looking forward to try some implementations of this.

[@dassurma]

Well, then go take a look at github.com/PolymerLabs/actor-boilerplate

[@cucco1]

@@dassurma Neat! That was an interesting and well done presentation. Any chance we might see frameworks like Angular implement aspects of this model?

[@davidrivers7667]

Watching with Grace my daughter 7yrs old who designs PWA apps for kids

[@UliTroyo]

Pieter Hintjens was the first person from whom I heard of the actor model and state machines. R.I.P.

[@danbilokha]

Love it, thank you guys

[@VladimirBrasil]

Very engaging project. Huge congrats. At the 11:36 slide switch(this.state.value) is used inside onMessage to handle state transition. This is the "coupled way" to use xstate, as shown at statecharts.github.io/how-to-use-statecharts.html#decouple-the-component-from-the-statechart Do you have any opinion about using the decoupled versus the coupled way when you need to build the relation between components and the statechart? In a decoupled scenario, this.state (xstate, statechart) would explicitly tell the component what to do, using the actions/activities capabilities built into xtate/statechart. At what measure do you think this is not a good idea? Or is a good idea? What about guards - also a capability built into xtate/statecharts? Do you think your very engaging new way of thinking would benefit from letting the state use guards? If I want the non-ui components to be easily changeable, and also the statechart to be easily changeable, this.state leaking into the Clock component - inside switch(this.state) - could be a increasing mess to manage, couldn't it? Where am I wrong? What am I misunderstanding? A scenario: if I wanna change the statechart, changing a state name, I probably need to change clock.js as well. Is this an issue? Even for a big project? Can we facilitate this scenario of changing a state name when the project is already big enough? I am all ears, hoping to learn where I am wrong, because I can foresee that you already thought about this scenarios, it’s only me that am a little bit yet confused (sorry for my possibly silly questions, in advance!).

[@abaidooprince9813]

can somone help with how this could be implemented with vue and vuex

[@cedpoilly]

Love it!

[@RahulPradipPatil]

Amazing.. useful

[@JoshuaMoreno]

So is Paul back?

[@AlessandroMenduni]

My God, does this mean I oughta reopen Twitter? Paul was the only reason I used to connect (well that was a bit over the top)

[@malipetek]

I appreciate 60fps

[@B1FREQUENCY]

Please Talk about How to Remote Control via Threads to Turn on DEVICE COMPONENTS....PRIME EXAMPLE...."HOW TO TURN ON FACE CAMERA"

[@Booyamakashi]

Is this redux under different name?

[@saa442]

I felt the same. exactly

[@aammssaamm]

It's jquery.trigger under different name :)

[@amitkarmacharya4493]

The back and forth between the speakers was reallyannoying.

[@neilsumanda1538]

i admit.. when they said "RUsh Hour" i thought they are talking about the movie...

[@nando4070]

:D

[@davidjournot1741]

Very useful presentation, thank you! I've been playing around with angular platform-webworker for a while to bring as much code to the webworker as possible but this solution lacks flexibility for importing libraries or lazy loading. I might switch to the actor model.