Get notified about Andre 'Staltz' Medeiros

Sign up to a email when Andre 'Staltz' Medeiros publishes a new video

okay so hello everybody my name is Andre
and this talk will be return of stream
IO let's see a little bit what is that I
am known for cycle J's fronting
framework that I've been building for
about two years now actually yeah two
years maybe it's more I don't know raise
hands if you have not heard of cycle
jeaious
okay that's kind of a lot okay yeah yeah
so yeah anyway this is not an
introductory talk okay I'm sorry
like I have given that type of talks
before you can check it out on the
Internet and this will be a talk about
like the story of how this framework
came to be and its similarity to this
old thing in Haskell okay um this is
this type of powerful but useless talk
and you know just try to abstract away
with stuff okay but it's still
interesting to people okay so I work at
this European digital agency called
future eyes based in Helsinki Finland
and before future eyes before I joined
future eyes I knew like zero about
reactive program and that never even
heard about it so then it was when I
joined around what two thousand thirteen
or fourteen that I started here things
such as rxjs or bacon Jas or rx Java or
a reactive cocoa a functional reactive
programming and for me all of that was
super new I barely even heard of
functional programming so I started like
researching these things reading about
it and really got curious until I had
the opportunity of working on an Android
project and then I started that with the
gut feeling that I want to use are
extravagant stuff and you know that's
how I learned it the hard way by doing
it in customer projects and it was not
easy I mean I always sometimes I got
stuck and I had this gut feeling that
there has to be this react
the way of doing this and that's how I
discovered how to do reactive
programming and I also scribbled a lot
on these paper notes and did a lot of
marble diagrams and yeah so that was how
I learned it and then after a few months
programming that went kind of viral have
you heard about this maybe yeah a couple
of people's okay that's nice you should
check it out
and then after a few months they kept on
doing stuff about observables and I
released this website called rx marbles
it's basically just a visualization tool
so you can understand how do these stuff
work these streams and their operators
and you know a lot of people like rx
marbles but for me
like there's a lot of stuff that
happened in arts marbles that was kind
of background stuff so I first wrote it
in CoffeeScript and rxjs and jQuery and
then I threw away CoffeeScript rewrote
it in equi script five and then I tried
to put react in it and I was really
annoyed with react so I threw that away
and I used virtual Dom with rxjs and
then I converted to Babel and I
experimented with the ton of different
architectures because I wasn't really
sure how to do this because there's like
there was no such thing as like an
architecture built around rxjs
observables or streams in general for
fronting and that kind of stuff so I
really did a lot of like architecture
drafts and this is me trying to figure
out stuff
I even like called it Oh MVC as an
observable MVC then I renamed it to MDI
and things were crazy and that's how I
sort of released this small tiny library
called psycho jazz and it really
received a lot of feedback from the open
source community and slowly they started
getting shape and by feedback I don't
mean like yeah this is cool I mean like
this is crap you know and I was like why
is it crap me how can I own crap if I it
so then I released a little bit of like
variations and you know I started to
like
really think about this I mean you know
with regard to architecture I think I
redid the whole idea seven times or
something like that so it started
getting less crappy less crappy and then
you know I we got to this point where we
got a nice architecture that people kind
of appreciate using and they they liked
it you know then I also like it I feel
super productive with it yeah so a
little bit after that I think this was
last year May a little bit after that I
saw this there was Eric Meyer in some
video on
I think it's channel 9 or something
where he was explaining about Haskell
and stuff and then he said you know in
the back of the days we used to have
this thing in Haskell and I paused the
video I was like wait a second wait a
second that's what I have that is what I
have and I was like so it turns out that
this thing I've been building is like
has already been there a long time ago
so yeah in 1998 like they wrote these
papers in the university Paul hood AK
and a bunch of other amazing professors
we're researching about you know pre
Haskell so before Haskell came up and
that's a bit like you know how Haskell
started taking shape so you know I'm not
going to I'm going to explain this thing
called stream I oh okay this thing here
that Eric Meyer is talking about but I'm
not gonna show you a paper here and I'm
don't pretend I know everything that
they do because you know in 1989 they
were there in the university research
researching these stuff while in 1989 I
was just like you know fooling around
just doing nonsense so yeah I did my own
reading and I think I know what this is
about and I want to share with you kind
of like the theoretical ideas behind
this so don't be afraid you know it's
gonna be rather easy I'm not going to
show Haskell or Haskell code okay um so
there's nothing funny about the slide
you guys are laughing on the wrong
slides anyway so in short it means that
you know usually you have your programs
have logics and effects mixing okay you
request that's an effect and you have
display pixels that's an effect and you
have logic like you know get the number
multiply it by a hundred that's logic
it's just logic
so what Haskell does is separate those
two says like logic you go to one side
effects you go to the other side but
there's different ways how you can
separate that okay one way that you can
monadic i/o the other way is called
stream i/o and the other way is called
continuation i/o and this is back from
the 1989 paper now it turns out that you
know of all of these three just monadic
i/o survived in Haskell so we're going
to quickly see monadic i/o and stream I
oh but not continuation I know it's kind
of out of scope so um okay I don't
intend to give like a monad tutorial
here on stage now I'm just gonna give a
soft intuition of what is this for
people who are not familiar with it now
if you have ever done Haskell in your
life okay you guys please close your
eyes because I am going to explain this
in JavaScript and you're probably going
to be disgusted okay so yeah this don't
vomit so here's a program in JavaScript
that is really simple okay just says
window confirms it does this pop-up like
that and you can say yes or no and then
it gets the answer is sure if it's sure
say console.log you are sure if not sure
then you're not sure okay really simple
program so I'm going to apply a trick
because this program mixes logic and
effects so the effects are window
confirm and console.log and the logic is
the if and else okay so I'm gonna apply
a trick okay now my program has like
Effect 1 is an array with string and
then I concatenate those two and I get
array with two strings
and that's a output that okay so it's
completely pure because you know once
you call that function you're gonna get
always exactly the same arrays with
strings inside them okay
pure but it happens to be that the
content of the string says window
confirm yeah so some of you might know
what I'm gonna do next I have this
program there this another's function
run which takes each of those effects
strings and runs eval on it okay
now you can kind of see what I'm doing
there huh
yeah and they say that you shouldn't use
eval but that's what I'm doing here so I
call the first string with eval window
confirm and it shows that effect and
then with that I get out a result I keep
store that result there and then I pass
that result to the next string I
substitute the dollar sign okay so
that's what I'm doing here and there we
go you know the main program only has
data okay I encoded effects as data
right it's a trick because the string is
always data but so the string doesn't
yet do the effect it's just like later
something will get that and do that and
that's how you can separate logic from
effects voila
there you go that's kind of like monadic
I oh yeah
yeah house colors please stay in silence
now we're gonna see here a different one
this is called stream i/o it's a
different way of doing this separation
so logic will go into your program on
the left and effects will go to the
right on the operate in the operating
system so the way that we're going to
sit and like make stuff happen in the
operating system or in the real world
like window confirm is we're going to
send a message to the operating system
as if the operating system would be a
server okay
so we're sending a request to the
operating system as if it would be a
server and that request is something
like hey please run console.log
okay and then we're gonna get out or
like let's say please run window dot
confirm and then we're going to get out
a response as if the operating system
would be a server and that response is
the sort of messages that we want to
read from the outside world okay and
that's that's a trick here so how does
it look like in JavaScript again Haskell
errs please don't vomit let's see this
in JavaScript using es6 generators okay
and this just to give an intuition so
first I create there an object that is
my request and I I want to run window
confirm so my request has there the type
is confirmed and the content or the
value is are you sure and then I yield
that object in es6 generators you can do
this you can yield and the way that
yield works is that it freezes on that
object to the outside world and after
that it freezes there and it and then
once it gets back the response it
continues from that spot so it will get
confirmed response it kind of it's this
thing that has this ability to pause and
continue so then once you get that
response from the server or the
operating system you can do if an else
that's our logic right and then you can
say hey here's a request to run the
console and with that content else run
the console with this content and those
are also requests that we're giving
passing to the operating system now the
other side is the operating system how
does that work well we have a function
here that will call your program and it
will get the first request from the
program and it will also do that in a
loop and then it checks if that request
type is of console if it's a console
request then it will perform the console
and if it's a confirmed request then
it's going to perform the confirm and it
will get back the response and it will
feed it back to the program like this
this is just how you do it in es6
generators and then we run that so there
you go
this is how we can get
an intuition of what is monadic IO and
what is stream IO and this is basically
stream idle the diagram so here was a
problem while Eric Meyer was showing
that in the video
he was like yeah this is Stream il this
is how in Haskell used to work but like
then he wipes it away and he says well
it didn't work out so let's just forget
about it and I was like whoa wait a
second like what went wrong with string
IO I mean I was kind of disappointed Tom
so what happened why didn't stream IO
work so take a careful look the Haskell
report on version 1.0 is this file there
do you see any problem check the date
right
April Fool's so they put stream I out
there but it's like April Fool's I've
got to you're supposed to laugh whatever
anyway yeah but seriously why didn't
stream IO work that was I was like
curious like why did this thing work
wise why is there a Kumari wiping it
away so I went to study a bit more and I
come I saw this definition of reactive
system and a definition of a
transformational system and these are
old stuff I mean from the 90s and stuff
so I'm not making this up there are
books about it that we completely forgot
but one of the books said there gave the
definition of a transformational system
it says a transformational system
repeatedly waits for its simple to
arrive carries out some processing and
outputs the result when this process is
done so it's basically it gets some data
some file or something it does some
processing it spits out the results and
it's done basic examples are like your
compiler or UNIX command like move or
rename you know all of these things you
know basic old programs right so that's
a transformational system what is a
reactive system it continuously
interacts with its environment using
inputs and outputs that either
continuous in time or discrete and the
inputs are often asynchronous meaning
that they may arrive whenever and the
outputs may go out whenever so it's kind
of like this it's processing the whole
time
at some point it gets an input and maybe
after two days or after two milliseconds
it sends out that output and it keeps on
going so it doesn't necessarily stop
it's just like this and it may in
parallel get inputs or outputs examples
of that are so the so called real-time
systems like these aviation control
apps or websites fronting that we're
building and servers right okay
so history went like this in the early
90s basically any computer program was a
transformational system a kid asks his
dad dad what is a computer program and
the dad is like well son you know it's
this thing you give a file to it in the
computer it does some stuff and it spits
out another file and then the kid is
like okay okay so at that time these
were the protein dominant programming
languages and those languages were made
for transformational programs I mean
obviously because we were living in that
blue world that's what computer programs
were so the languages were made for that
so for us to see write see is made for
that look at that we have main it takes
the arguments it does stuff in this for
loop and it returns to zero and it's
dies after that okay C was made for that
C comes with a main function and also
you know Java Java is still one of the
top three languages in the world
used and there we go you have this main
just like ANSI take some arguments does
some processing systems
exit zero and it's done it dies so it
turns out that Haskell stream IO was
born out of this time so it yeah it's
from the 90s now the reasons why it
didn't work is that it turns out not to
be good for transformational programs
okay but there's many reasons like one
of the reasons that it was blocking on
asynchronous it was also really easy to
deadlock and you because you had the
circular dependency between requests and
responses in order to have a response in
a request we needed recursive response
so it was complicated it was kind of
easy to do something like I'm waiting
for the second response but that relates
the first request so if you did a like
off by one error then things would just
lock and freeze because it's blocking
and also one of the problems of stream
IO at that time was the whenever you had
a question and answer type programs such
as you know your typical first program
in computer science like please input
your age and then it freezes and then
you input your age get char and then
high your age is this you are young in
my case it's like you're getting a bit
old yeah so stream IO is a bit
inconvenient for that type of question
and answered this that dis that so and
that was a dominant type of programs
reasons it was hard to extend the types
of the IO actions and whatever so they
started studying and they figured out it
was quite good for transformational
programs so then in 1996 and onwards
they started using monadic IO for almost
everything in Haskell and I think you
can't even do nowadays stream IO in
Haskell so it's left dead and just to
give you some context you know in 1996
and around that it was the time when we
started talking about multimedia just
like it's like a buzz word you know just
was like multimedia cd-rom you know yeah
so you remember so so but multimedia was
basically you eyes you know started
having windows 95 and things like that
you know we started getting the feeling
for you eyes and you eyes are reactive
programs okay so we were still a
dominantly blue world of
transformational programs but we started
having a bit of green and in the early
2000s the whole programming community
went through very dark times because you
know like on one hand we had this
foundation of transformational programs
with like C and C++ and Java but on the
other hand we really have to deliver
these multimedia apps and we really need
to get things done
and also servers started being a thing
around this time and those were dark
times because if you remember we had
like a ton of shared memory concurrency
mixed with events and callbacks and
win32 API is an object-oriented
programming and this was fine you know
so yeah and in the front-end world
around let's say 2000 4 or 5 we barely
even had jQuery and any JavaScript app
that you opened from that time most
likely had a lot of callbacks and
mutation of global variables and that
was also fine yeah but now fast-forward
to today 2016 and you name it you know
we live in this green world where all
the programs are reactive so a kid asked
his father daddy what is the computer
program he might not even say computer
says you know it's this thing that is on
your phone or your computer and you can
interact with it and it shows you some
stuff and you do some stuff on it and
that's it you know so our idea of a
computer program is that it's
interactive nowadays so I bet you know
any software that you have seriously
like any of you I could pick any of you
and like you know do you have something
asynchronous uh-huh you know like I
could do this now but yeah like promises
callback streams CSP whatever everyone
has something asynchronous you don't
even like question it and I'm so like
and I bet that also runs continuously
like something interactive right for
instance even compilers today which are
traditionally transformational programs
they are also like interactive so in
typescript we have now this thing called
a compilation server where it's just
running and it may get source code and
check that and produce laut and output
and it's just like a server really so
this is used in editors for instance
visual studio code so that you know
every time anything changes in your
editor and any kind of source code in
your project it will check that for you
and that's that's an interactive
program suddenly and in these days for
concurrency most of the stuff that we're
using for asynchronous and concurrency
is a message passing okay so there's two
types message passing and shared memory
and that's pretty interesting okay
because if you if you haven't slept yet
then I mean if you haven't slept during
this presentation then you were gonna
remember that stream i/o was a message
passing abstraction and that was cool so
it was message passing but in Haskell
they also used lazy lists and blocking
program is so I discovered that if you
just replace lazy lists with streams and
blocking with asynchronous then stream
i/o becomes very useful for message
passing or interactive apps that we
build today and that's why I say stream
i/o with quotes because the Haskell
people won't like me right now because I
changed lazy list streams but the
diagram didn't change okay so when I
changed lazy list the streams the
diagram stay the same I really have a
program that sends out messages and
receives back messages and voila that my
friends is the idea of psycho Jes it's a
JavaScript framework for interactive
apps where you have message passing you
have an input/output gate for logic and
effects and you have streams for
asynchronous programming that's it let's
take a quick look at it again this is
not an introductory talk but just to
give an idea in code as well here we
have some imports at the top just import
library and the stream library as well
and then this is our program sources is
like incoming messages from the
operating system
and then I can do something like this I
can define a stream called increment
stream and that stream is all of the
click events on the increment element
mapped to +1 in other words like if you
abstract a bit it's just I create the
stream you just think event emitter
called increment stream and then I
listen to all the click events on the
increment element and then I dispatch a
+1 on the
increment stream okay that's basically
the same thing as doing map there so
yeah I have many talks about like
careful introduction to a psychologist
in case you want to take a look later so
then we do almost the same thing for the
decrement stream we also merge together
the increment stream with the decrement
stream we make this so-called action
flux and reduxid you can think of an
action like that and then we make a
reducer stream also kind of like in
redux where you get each action and you
map that action to a function and that
function knows how to take previous
state and make new state so then we get
all this reducer functions over time and
we can fold them this is kind of like a
radar adduce same idea as in redux and
then we can finally map each count in
the count stream to a markup and then we
send that back to the dawn so initially
from the Dom we got messages which were
events like clicks and now we're sending
back more messages which are mark so
from the Dom I get clicks into my
program and back to the Dom I send back
mark of what should be shown and then
finally we just run this we run the
program against the operating system
which is the browser and there we go on
the Left we have this program running it
just you know you click the yeah the
counter app but on the right you see our
dev tools and they show the structure of
streams okay and you can literally see
the messages being passed there okay and
this is the idea we have message passing
not just in the boundaries with
operating system but also between your
app you can see the message is passing
okay so the idea is just you have a
stream of Dom events from the outside
world map that's the stream of actions
mapped up the stream of reducers app
that the stream of State and you could
send back a stream of markup so it turns
out that cycle jess has asynchronous
message passing it's good for user
interfaces or any kind of reactive
system and has good separation concerns
there's another talk for that
but one thumbs down here is that it's
not so good for handling question and
answer type of I oh okay just like
stream IO from Haskell was not so good
for a question and answer this is not so
good for that either let's take a quick
look at why so here we have a response
and a request to HTTP through this real
server okay and first of all I have the
response defined first and then I have
the request defined later and that's
already kind of weird right because
usually you define requests before the
response yeah but anyway in fact you can
actually put these in whatever order you
want so that's also kind of weird so how
is this response connected to that
request and they are connected through
this thing called a category or just an
ID okay so I basically send out a
request to the server but I say hey that
then when I get back a response from the
server I checked I checked that that
response has category hello because it
could be any other response I mean I
couldn't be making tons of different
requests to different servers and I want
to know which one is that one so as you
can see I have to have some identifier
here to connect these two things but
what I really wanted to do is just
define I have this request and then my
response depends on this request and
then I don't need to have these hello
identifiers anymore okay again you don't
need to understand all of these details
here is just to say that it's not so
good for question and answer type of in
an interaction and also the I mean you
could do this you can do this but now
we're mixing effects with logic we're
doing the network request inside our
program and you know that has its
problems so does that mean that stream
i/o has this inherent problem that
question and answer type of interaction
is bad well not really there's another
IO model that comes very close to stream
and it's also message driven just like
you know it has sends out messages
literally has a message type
and you receive back no I'm sorry you
receive messages from the operating
system and you send out commands yeah so
what's different about elm does it solve
this question and answer type of thing
well kind of yes it has a thing called
tasks ok and what is a task in elm it's
basically a command or request that your
program is sending to the runtime or the
operating system but this message is
quite big it says like you know I want
you to do this go there and get that and
do this and then that do that and then
result and give it back to me ok so it's
not like a very tiny request like run
console.log it's like do a lot of stuff
and then you get back the result
so again just pretend that you know Elm
like like an advanced user already and
here we have a task which is like first
HTTP GET from that URL and then pick out
all the IDS from all of these hats and
then for each hat I want you to run an
HTTP POST to like that hat ok so we're
doing many requests here but this is
just one task now you might not know Elm
but this is just data it doesn't perform
that task it's not like a promise you
could imagine that this is just a string
ok this whole thing is just a string
saying please do that do this and do
this and do that it's just data and if
you've been paying attention this is
monadic i/o uh-huh that's kind of
interesting
all right so instead of using strings
like you know Elm has these data
structures called tasks so that's kind
of funky because you can put monadic i/o
inside stream i/o so a task is really
like Monica it's just like you're
sending out this message please run this
bunch of instructions and that can run
inside the context of this string of
this thing called stream i/o so it turns
out that we can have transformational
programs inside reactive programs and
that's pretty cool
so message passing is awesome
because it doesn't rule out monadic I
know you can do both and if you squint
you know it's like maybe you can see
message-passing influx and redux as well
because you know you have your store and
that has stuff inside it and you send
back messages which are state objects to
your tree of components and then your
tree of components eventually sends
messages back to your store and those
have messages of State and messages of
actions and you know direction all right
that's where these stuff and that's
where the name kind of confirms but
Redux and flux are not purely functional
because they don't try to do the
separation of logic in effect so you
could do logic and effects inside the
store you could do logic and effects
inside the components yeah so you can
mix them as you wish so that starting me
started making me wondering this message
passing plus a purely functional
approach mean something like stream i/o
with quotes yeah so you know because
flux misses the purely functional part
so it's not exactly stream I know it's
just
unidirectional data flow but you know I
find it quite hard to have those two
elements of message passing and purely
functional and not end up with something
like stream i/o with quotes so my
conclusion is we live in a world where
all of the programs are reactive
programs okay languages have a lot of
heavy inertia okay they take a lot of
time to evolve and be and get adopted
so in 1990s like the languages that were
used were actually created 10 or 20
years before like in the 70s and the
languages that we used in 2010 like
JavaScript and Ruby and Java they were
created also about 10 years before so
the trick is if you want to know quite
accurately what are we going to use in
the next five years you need to look at
right now because you know languages
take a lot of time to be adopted so just
listen you okay this is not an
exhaustive list Elm alexia closure Dart
and all of these languages mention I
mean there's a bunch of others have a
focus on these things they already
assumed asynchronous they're not going
to be like they're not gonna ignore this
in this part they take as asynchronous
seriously so closure has like core async
that takes async quite seriously with
CSP Alex here as well it has an air
laying style action model I'm not gonna
pretend I know that Elm as we saw has
also message passing and focus on
asynchronous programming and Dart
you know it has a beautiful API for
streams that looks like rxjs you should
take a look
dart is usually not mentioned but just
in case you're interested in sort of
like ideas and stuff just take a look at
how a sink is in dart much better than
in JavaScript so there's also a trend
nowadays towards functional programming
so alexia closure have like a focus on
functional programming okay so we can
kind of know that the future is going to
be something like this in fronting the
situation is like this today okay
cycle Jess use the message passing react
and redux message passing Elm it's
passing view jeaious with its flux like
view X uses message passing angular one
with its scope you know that was shared
memory concurrency angular 2 has you
know almost the same thing as shared
memory concurrency but then you have ng
rx which is made for angular 2 and
getting ideas from you ducts it's also
message passing so there's a strong
tendency towards using message passing
concurrency and then also when it comes
to paradigms psycho J's wants to be
functional again and redux and reacts
like Elm is like functional sunglasses
if UJ s is object oriented programming
angular 1 and 2 object oriented
programming ng Rx is like yeah I want to
be functional so there we go
yeah that's why we can rather
confidently say or predict that in the
next few
years programming and front-end
programming will be mainly purely
functional event-driven and
message-passing concurrency thank you so
much for listening and yeah so thanks we
have some question from the app why not
use closure script with core async you
can use go ahead sometimes people ask me
what do I think of what do I think about
closure and I have to answer I have no
idea because I haven't used closure I
mean they use closure maybe for five
hours or something like that and what I
have opinion of closure is what I called
unqualified opinion it means that I
don't know anything about it so you
shouldn't even listen to me you know so
don't listen to people who haven't ever
used stuff and I don't know it's
probably good I don't know okay another
one how do we prevent developers from
creating their own effects without
without using cycle how to prevent
developers from using writing their own
evaluating their own effects without
cycle I guess the question is kind of
like how can I enforce that people are
not making effects in JavaScript and
psychologists you can't like really
enforce there's there's an interesting
es lint plugin or preset that bourdelle
Stokes helped put together that
basically makes JavaScript like you know
you can't use mutation can't use
anything and that's an interesting way
maybe you could use that I have I have
used that with cycle J's and basically
yeah that kind of works it's one way of
enforcing but the idea is really doing
this like having some discipline and
then like maybe I can say a little bit
more that like I have played with the
thought of writing a language that would
be optimized for cycle jeaious it's just
like you know we have elm and we have a
bunch
different lying languages that compile
the JavaScript but it takes so much time
seriously you can't imagine how much
commitment writing the language takes so
I don't think I would jump into doing
that but in an alternate universe I
could maybe do that great having
discussed this with Eric Meyer No
so the thing is like I met Eric Meyer in
person let's say month one and then
after in month seven I discovered about
stream i/o so I I didn't have time to
talk to him but he knows that I like to
make like analogies between the stuff
but I think the key there with stream IO
is that it was blocky and it was lazy
lists so we changed those two parts and
now it's asynchronous and stream so that
makes a big difference I think good how
is bind or slap map implemented bind or
flat map implemented mmm there's like I
I have to assume many things well bind
well I I guess the question is about
bind or flat map in the hacky JavaScript
monadic IO that I talked about but maybe
this is a question that you can ask me
in person it's basically yeah let's talk
about its Haskell not a good language
for reactive UI since its using
monadic IO again I'm gonna play that car
I had a card I had no idea because I
haven't used Haskell for you is barely
used Haskell for almost anything I'm
still learning like how to actually use
it but I know that Haskell has cool
stuff like Fran which is a functional
reactive programming library and this
was also like there's a ton of work that
related to function reactive programming
that was done by Paul hudak who's one of
the main people behind Haskell and those
kind of things function arctor
programming is mainly for user
interfaces so it's mainly for like
reactive programs so I'm quiet
sure that house Co has really nice stuff
for that good
I have planning to migrate the coach
chap script and can we use it with
Ankara - can we use cycle with angular 2
or can we use typescript with angular to
thank them in cycle okay well don't use
angular with cyclone yeah yeah but
you're out migrating the code it's a
subscript yeah please use typescript I
mean you're gonna thank yourself it's
really nice I mean so people think that
there's a lot of like like like things
that you need to do in order to use
typescript
but in reality let's say you can't get
the Taipings for some library you can
just say like you can type this as any
and then you're back to the level of
quality of JavaScript right because in
JavaScript everything is typed as any so
it's like by adopting it you anyway will
have some benefit because in code like
let's say you get a response back from
the server that thing is usually typed I
mean right it has some fields that you
expect to be there there's so much stuff
you can benefit just by using a little
bit of typescript and it's even possible
that you use some files in your project
or JavaScript some files are typescript
but you know this is a whole separate
talk good let me see
why Elm and cycle yes compared to
typescript or pigma script 6 with
reactive GIS ok why l with typescript
what elements cycle D is compared to
typescript with reactive yes
ok I think the question is how does Elm
compare the types great like when you're
using cycle with typescript Elm will be
but much better obviously it's a purely
functional programming language but you
know typescript is better than
JavaScript that's why we started using
script but you can also use JavaScript
if you want but definitely a language
like elm will be much better in this
regards I mean you're gonna have that
confidence of zero runtime errors while
with typescript you have this confidence
of like much less runtime errors than
JavaScript but still some runtime errors