Get to Know the Actor Model with JavaScript
monades.roperzh.com
Get to Know the Actor Model with JavaScript
1–10 of 52 posts
Re: Get to Know the Actor Model with JavaScript
#2How does this differ from a Redux-type store besides being able to instantiate them on demand instead of having a global state?
> It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful.
Object.freeze() can help prevent this.
Re: Get to Know the Actor Model with JavaScript
#3How does this differ from a Redux-type store besides being able to instantiate them on demand instead of having a global state? > It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful. Object.freeze() can help prevent this.
I'd also have liked to see destructuring used to set the new state:
return {
...state,
count,
}
Re: Get to Know the Actor Model with JavaScript
#4The actor model deals with concurrent computation.
The threading models on node and browsers do not allow concurrent computation, except for the case of web workers, and the proposed threading additions of JavaScriptCore.
Because of this, the actor model can be overkill when you have no threads. More specifically, you may introduce queuing where no queuing (or other type of synchronization) is necessary. This is because an actor is basically a worker with a work queue (aka mailbox).
For the most part promises can solve most of your async issues. Event emitting/message passing is valuable, but queuing is optional in many cases.
Re: Get to Know the Actor Model with JavaScript
#5The actor model deals with concurrent computation. The threading models on node and browsers do not allow concurrent computation, except for the case of web workers, and the proposed threading additions of JavaScriptCore. Because of this, the actor model can be overkill when you have no threads. More specifically, you may introduce queuing where no queuing (or other type of synchronization) is necessary. This is beca…
Hey, article author here, thank you for passing by!
This is correct but misses the point of the article. The idea is to introduce the Actor Model to people unfamiliar with it, using one of the most popular languages out there.
Re: Get to Know the Actor Model with JavaScript
#6yes,I like this design,and my system has applied it.I feel this theropy just like the domain-specific languague or system thought(the_Fifth_Discipline).
best regards
Re: Get to Know the Actor Model with JavaScript
#7How does this differ from a Redux-type store besides being able to instantiate them on demand instead of having a global state? > It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful. Object.freeze() can help prevent this.
It’s a pattern. It’s not supposed to be Redux/whatever library. It’s a pattern of writing code (like MVC, or Pub/Sub, etc)
The Actor model strongly influenced protypical classes like Smalltalk and therefore also JS.
It’s a 45 year old software design pattern so really it’s better to ask: how does Redux differ from the Actor pattern?
Re: Get to Know the Actor Model with JavaScript
#8How does this differ from a Redux-type store besides being able to instantiate them on demand instead of having a global state? > It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful. Object.freeze() can help prevent this.
It’s a pattern. It’s not supposed to be Redux/whatever library. It’s a pattern of writing code (like MVC, or Pub/Sub, etc) The Actor model strongly influenced protypical classes like Smalltalk and therefore also JS. It’s a 45 year old software design pattern so really it’s better to ask: how does Redux differ from the Actor pattern?
Sure, that's fine too. My point is more that it would've been nice to get a summary of the differences instead of requiring the reader to dig through the article, since Redux is much more prevalent. Even after digging, I still can't tell if there is a difference. If there is none, it would've helped greatly to explicitly say this.
Re: Get to Know the Actor Model with JavaScript
#9> "If this sounds to you a lot like Object-Oriented Programming (OOP), you are right."
This sounds like Alan Kay's aspirational viewpoint of independent "computers" interacting through messages. Not the object-orientation invented by Nygaard and Dahl in Simula, that introduced objects, classes, subclassing and virtual functions. Kay's vision is not reflected in modern object-oriented languages, while Nygard and Dahl's remain paramount.
The argument that the Actor Model is really a form of object-oriented programming is an unrequired appeal to credibility.
Edit: grammar
Re: Get to Know the Actor Model with JavaScript
#10How does this differ from a Redux-type store besides being able to instantiate them on demand instead of having a global state? > It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful. Object.freeze() can help prevent this.
I'd also have liked to see destructuring used to set the new state: return { ...state, count, } I realize that it's superfluous when count is the only property on state, but it makes the code both easier to understand and to maintain as state gains new properties over time.
I've more often seen that called "property value shorthand", but it does compliment destructuring