
episode of funfunfunfun funds angular
node based JavaScript development with
me Matias you handsome today we’re gonna
talk about it’s gonna be great
let’s get started and I have a special
guest with me today
Eric Ryman my Swedish friend hello who
likes I don’t know what you like making
far less serious things back fun little
games and stuff like that indie stuffs
all right so this is kind of like a semi
my vacation episode like thank you it’s
it’s Christmas and stuff so let’s not
make four episodes like just make some
have some fun some questions and answers
that’s right yeah so this is Eric you
like you might have watched the previous
episode where we pair program on Eric’s
game clothes drone and the danger so and
Eric is from Sweden as well as I so it’s
home over Christmas and we’ve spent the
New Year’s together and we’re basically
just bit hangout hungover I guess oh my
god I’m gonna make an episode and like
continue like can’t we just answer some
questions and answers together and it’s
I will answer all your questions about
what the best angularjs nodes are yes
all the notes the notes and whatnots I
love your work Happy New Year Happy New
Year to you too yes but that’s not a
question
that’s not a question but thank you Mike
what do you think of a frumpy I have no
idea what that is functional reactive
programming oh that’s very cool
I could explain it to me as if I was a
child who has never programmed
functional reactive programming like
it’s functional reactive programming is
basically the observable pattern and
then a lot of marketing oh yeah yeah
that’s a good pattern yeah it’s like
yeah yeah yeah you dispatch an events
yeah people listen to it yep and but you
know yeah exactly yes bad sure does not
know who is listening to it yeah
creating a nice sort of flow of
information yeah oh the observer will be
like it’s uh so you know the observable
part there is a thingy that you can
subscribe to I think I can observe it
yeah and functional reactive programming
is that you stuff like a chain of
functions after the observable like for
instance like at the upper part it might
be like a function that points down to
an observable and it’s just a chain that
observes each other so the interface
constantly reacts so basically it’s
interesting that you how you describe it
so basically it sounds like there is
something being observed and I’m
guessing so what so one of the patterns
that come up all the time it’s like
model-view-controller yeah I hate this
pattern but it is usually should talk
about well in game programming yeah but
but it’s a useful pattern I think just
for talking about you know clarifying
what you’re talking about like even if
you don’t use it yeah
for example the thing that’s often be
observed in it is the model right yeah
that’s the thing where you know that’s
where your data is that’s where the
truth of what is happening you know is
based and like a value changes or
something like that and then like it
cascades to yeah you know the system
reacting to it right yes so so it sounds
like what functional reacting are the
reactive programming is all about this
foot is like is part of the key kind of
cool thing
as is it that you sort of data drive or
specify in some sort of high-level way
how are you gonna react to this
observable change or is that just it’s
kind of like the promise of it is that
you can program a lot more Detlef it
declaratively like there is state and
you just depending on what the state
looks like I have rendered this IC so I
think that I have this I have a
colleague that Philippe that meant
yesterday he talks a lot about how
people don’t understand that the
observable pattern is an optimization
it’s not an architecture like because in
you know in getting programming where
you have in game programming the way I
understand it and we’ll put like it’s
very much and much focus around the run
loop like the necessarily true and I
think I think beginning programmers or
like beginning game programmers it’s
like yeah you have a run loop and you
imagine it’s just being like one big
loop yeah but that’s not how you write a
game though Oh interesting I mean it’s
like you have you know the same concept
of oh you know there’s like an object it
starts there’s an update function like
that’s the that’s the loop part of it
yes I see it has the update function
that runs all the time oh right yeah but
it’s like there’s a million objects and
they each have their own update yes I’m
sure worst they are executed after life
yeah but that’s my that’s what you man
yeah yeah I understand that it’s not
just one big rendering function in the
in like the main but like in in
JavaScript there’s a dome right yes it’s
like an object that you mutate so it’s
not like you have an update you often
don’t have an update function that does
not access but it’s kind of like oh this
happens then I change this yeah yeah
like so I see so so the reactive part
here is that you change something and it
cascades in like yet stuff reacts to it
and other things happen as a result
exactly on the
is the functional part of it is that
it’s just pure functions right it’s just
it gets in the state-mandated renders
renders and output all the time so it
doesn’t really it doesn’t really mutate
anything it always like given a saying
what the state changes and this is like
just how we’re presenting to change
exactly
so sort of like the way this or like an
update function so so in your reactive
functions though can those functions
make changes to the underlying state or
is that frowned upon
yeah that’s frowned upon Oh like that
that will break the entire point of the
pattern but got it but you the thing is
like the observable at the end like the
point of an observable is that the only
dispatches like unchanged right away
need actually has changed right and it
doesn’t know about the rest of the
system yet mech for me I use the
observable observer observable pattern
all the time in that game programming as
well yeah but I mean a lot of the time
the main benefit is that you can have
the observable not know about like say
you have a health bar for a sample yeah
you have a player and the player has
helped I’m going to help changes to
health bar goes down a bad thing to say
would be to say in the player code oh
you know health changed find a health
bar oh yeah that would be terrible it’s
better to be like hey everyone my health
changed I’m a character and I like the
health bar is like Oh someone’s helped
changed it was to player I’m gonna
update myself yeah but the health bar
doesn’t have to be there if it’s not
there just like there’s no
nullpointerexception I’m sure
like that yeah it’s a broadcast right
exactly instead of telling things yeah
and I you know that way you can you know
everything is separated and you can
write really this nice but now that
events like I get that that is awesome
but I don’t think that that is a trait
of the observer per se it’s like that is
that is just you creating a like broad
cost so what I mean like the observer
like the point of the observer
is that it only dispatcher’s changes
when like when it’s actually changed
it’s like for instance looks like you
could implement that pattern by just
updating the state like say like the
health like I got just update the house
here and then anybody who is interested
can just look at that health right it
doesn’t know the you could then have
just this update function that runs
every frame well I’m not sure and then
just looking at that and updating right
problem is that that is extremely
expensive yes you do that sometimes and
then you add the observable in order to
get that to only be rendered when the
state has actually been changed right
and this is this is very popular in in
JavaScript and a web application
specifically because mutating the dome
is experience is expensive like right a
lot more expensive than just pushing
things to OpenGL and programming but I
think that there’s a misconception among
programmers that the observable is an
architectural pattern well what not I
mean maybe this is getting into
semantics but what do you mean by an
architectural pattern what is what is
the difference between a pattern this is
an architectural pattern and a pattern
that is just I don’t know sort of like a
hobo pattern I know you’re like I think
that a lot of people have the
misconception that the observable
pattern
structures your code like but it’s it’s
not like the structure is like that’s
separate from the observable the
observable is it’s there in order to
optimize your code and make it faster so
that you don’t run code unnecessarily
it’s interesting I think that maybe it’s
fair to say that it being faster is one
benefit of using this pattern but I
imagine that you know like as I
mentioned earlier another benefit is
that you’re essentially decoupling the
observer from the observable like or
rather your decoupling the observable
the observer sure like yes it is wrong
to say that either of those things are
true yeah
but as if any programming pattern if you
think that using it will automatically
make your code you yeah well then you
are a beginner and you have to think
more about suffer architecture yeah sure
like the point is like yeah the observer
pattern might might lead to you
decoupling your code we’re like
decoupling the yeah the knowledge about
the rendering and that is great but I
think that the primary that you can
achieve that without the observable
pattern absolutely has its this
specificity about it being oops
like that you can observe and get the
change whenever that is changed right
that exists only for performance reasons
that specific part so this is really
interesting because I don’t do much
JavaScript but I still know this pattern
the observer observable pata sucia and
it sounds like in the realm of
JavaScript the main benefits that
overwhelming benefit is performance but
I think if you bring up like the Gang of
Four kind of patterns in software
architecture I think the opponent is
from going on again right I think so
like it’s this a component of
model-view-controller it’s like a sub
pattern off that pattern so it’s like a
very well-known pattern yeah yeah like
it’s this far you know the view observes
the model yeah okay pretty much that’s
how I was taught it anyway yeah and you
can argue
oh that’s I think but yeah one of the
main kind of things I find interesting
about software development is that these
patterns that you have have you know
they have advantages and disadvantages
and it sounds like in the realm of
JavaScript the main benefit is
performance in the interim of game
programming I mean yeah it’s a small
performance game sure but it’s not that
expensive on update just look at the
model you have a you know you have like
a pointer to the model it’s like an
integer or something you can just look
at it it’s not that expensive to read it
and
an if statement it says if it is
something right or you know yeah it’s
not that bad
um it’s more like benefiting game
programming is more about decoupling the
code but I can mention there’s a
probably another realm of software
development
I don’t know medical robot programming
or something where the observer
observable pattern is maybe it has some
other benefits or drawback that makes
them use it or not like you know a
heartbeat monitor might use it for
example I have no idea what that would
look like because I don’t do that but my
overall whole point is that it is always
a risky move to declare that a pattern
is like primarily not centered around
one benefit because they might be like
depending on the cone yes like pencil
here is the one benefit might overshadow
another but yeah and the focus might lie
elsewhere yeah and I mean I’m not gonna
go into our rant right now but some of
the worst code bases that I’ve seen
professionally in the game industry
they’re you know they’re really over
architected ones they tend to come into
existence because people focus on the
benefits of some pattern but then they
fail to consider the context or the
knock-on effects of like of like using
this pattern and deriving this benefit
model-view-controller is a good example
it is often you know it has benefits
separates concerns change to logic maybe
is good for performance but it also
makes it harder to write you know small
simple primarily like graphics or
physics interactive classes in a
beautiful sort of straightforward way so
it ends up being slower to do that and
ultimately probably not the best idea
but again it depends on the context
sometimes it is the best idea sometimes
it’s not I want to make a tangent to the
fact that this is a generic patterns
even though we are completely different
programmers we can still reason about
the
like we have all different dialects and
viewpoints of the time but I still both
know the pattern we still both use the
pattern yeah and there was this other question about