Mais quand j'ai l'air, je me suis dit que c'est une abstraction qui me fait sentir vraiment malade.
Je veux construire tout un app, comme ceci depuis maintenant.
Si je me sens comme ça, peut-être que d'autres gens vont aussi.
Donc peut-être que ça veut être un framework.
Et c'est comme ça que j'ai commencé.
Bonjour, bienvenue à DevTools FM.
C'est un podcast sur les outils de développeurs et les gens qui font les choses.
Je suis Andrew et c'est mon co-host Justin.
Bonjour tout le monde, nous sommes vraiment heureux d'avoir Ansem avec nous aujourd'hui.
Ansem, vous êtes le créateur de JazzTools.
Nous avons été un peu plus élevé que nous,
tous les autres, à la première conférence de la localité au Berlin,
et puis, encore une fois, à l'Ink & Switch en conférence et à l'LA.
Je suis vraiment heureux d'avoir vous sur pour parler de ce que vous faites.
Mais avant de nous dévouer,
Would you like to tell our listeners a little bit more about yourself?
Bien sûr, oui, vraiment heureux d'être part de ce que je suis en train de parler
et de parler à plus de l'audience de DevTools pour un moment,
parce que Jazz a été un peu négatif.
Pour moi, je pense que le meilleur moyen de me caractériser est
que je travaille beaucoup comme une consulte de full stack,
et la plupart de mon carrière.
En particulier, je prends beaucoup d'apps de 0 à 1
et je suis en train de voir tous les joueurs de la répeat
à travers des diverses appes, des différents industries.
C'était quelque chose qui m'a toujours évoqué,
mais je n'ai jamais eu la solution
jusqu'à ce que je découvre qu'il a été Jazz.
C'est mon histoire, et c'est un histoire de très vite origin.
On peut plus le voir plus tard.
D'autres que ça, je suis un peu un peu de la hybrid entre le design
et le développeur.
Ma mère était un design graphique,
et j'ai toujours voulu vraiment l'application de ces choses.
Et je pense que quand c'est par la suite de DevTools,
je suis vraiment heureux d'avoir maintenant ce terme de l'expérience de développeur
et de ne pas faire de l'argent.
C'est toujours une grande mission pour moi,
particulièrement en termes d'assurer que plus de gens soient développeurs
et de plus de gens différents.
Je pense que le monde a vraiment besoin de ça.
C'est quelque chose que je suis vraiment passionné.
Qu'est-ce que l'a été le spark qui a été créé pour Jazz?
C'est ce moment de la jante.
Je pense que c'était vraiment un projet de site
que j'ai commencé à travailler sur,
un jardin qui est essentiellement un cône de notion.
J'ai vu une notion pour la première fois,
j'ai vu Figma pour la première fois.
J'ai été vraiment excité par ce que je pourrais dire,
une nouvelle classe d'apps qui ont juste été multipliées,
bâtées et sur un niveau très fondamental.
J'étais comme, comment pouvons-nous prendre ça?
J'avais des idées de mes propres,
et j'ai commencé à construire cette app.
C'était partie de l'environnement de la language visuale,
d'insérer quelque chose comme une notion.
J'ai beaucoup d'idées de craquettes,
mais j'ai vraiment commencé à focusser
sur l'infrastructure base de comment je vais vraiment bâtir en multipliant.
Et j'ai aussi voulu être en train d'être offline,
et de s'insérer entre les devises.
Toutes ces choses que nous savons maintenant
comme local, je n'ai pas vraiment compris le terme,
je n'ai juste pas vu que j'ai voulu que l'app s'y travaillait.
Et je me suis dit, ok, c'est vraiment incroyable
avec des études traditionnelles et des façons d'établir les app.
Et puis j'ai commencé à travailler dans le terme local,
et j'ai vu beaucoup de postes d'éloignage et de recherche
de switch de l'incense.
Et surtout, leur library auto-merge,
qui était cette première façon
d'en prendre cet concept d'académie,
et d'en faire ça vraiment, vraiment,
vraiment, vraiment, vraiment,
comme Mutable Jason.
Et ça m'a vraiment excité.
J'ai commencé à jouer avec ça,
en utilisant ça pour l'infrastructure base,
mais très rapidement, je suis allé dans les limitations.
En plus, c'était en partie pour la performance,
mais j'ai aussi commencé à penser,
comment... C'est bien pour la part de la Stade,
comment on fait la permission dans une façon locale,
et c'est là que la base est vraiment
une chose unique.
J'ai commencé à jouer avec la cryptographie.
Combiner avec les CDTs pour vous donner ces permissions.
Et quand je l'ai vu, j'étais là,
oh, ça commence à me sentir comme une grande abstraction,
et c'est vraiment nécessaire.
Et je ne veux pas juste construire
cette app de notion,
je veux construire tout l'app,
comme ça depuis maintenant.
Si je me sens comme ça, peut-être que d'autres gens aussi.
Peut-être que ça veut être un framework,
et c'est comme ça que j'ai commencé.
Et en fait, je ne peux pas construire l'app,
et juste me concentrer à 100% sur la construction,
ce qui me semble comme ça.
Mais toujours en mind avec
quelles types de apps vous pouvez construire.
Donc, pour le recap,
Jazz est un framework
pour construire des apps multi-player
qui sortent comme si vous avez un JSON mutable,
et qui a une bonne sécurité,
et qui est construite.
Comment avez-vous travaillé sur ça?
J'ai travaillé pour presque 4,5 ans,
et à la fois,
pendant 4 ans,
j'ai travaillé sur ça,
et puis, comme résultat,
j'ai travaillé avec des gens
de la première conférence de l'Ontario.
Je pouvais en faire du ménage,
et maintenant, j'ai un équipe de gens
qui travaillent sur ça avec moi,
et nous commençons à construire
un producteur commercial,
et j'ai bien entendu parler de ça,
mais pour le plus,
c'était juste moi,
en faisant beaucoup de research,
j'ai vraiment voulu
convaincre-moi
par les caractéristiques de la performance
et de la manière dont on peut
faire ce qu'on a vu,
et comprendre le fait que c'était
très différent.
C'est un point local,
comme beaucoup de hype,
c'est toujours un espace très dur,
c'est comme le plus dur,
c'est juste un problème de systèmes
très dur.
Et je pense que la facture
que vous pensez vraiment,
c'est aussi assez compétentif,
je suis allé au Dock,
et vous dites que
Jazz,
le service cloud,
ou le hosting backend,
ne voit pas
le data qui est venu,
c'est incroyable par les clients.
Vous pouvez parler de votre
approche
pour la sécurité,
et de la façon dont vous avez commencé,
et comment vous avez terminé
là où vous êtes.
Je pense que l'origine était vraiment
très utile,
car le Wo酒


par le baseline.




rick.
public key cryptography.
I use pretty standard stuff.
They're the only new stuff is really like,
how do we make that compatible with
something that changes as dynamically
as like multiplayer state.
And what I realized over time just starting
to think about things more pragmatically
like realistically, most people don't
really care about that stuff.
They just want to build an app.
They might even build an app with a traditional
trust model where the users trust
the provider of the app with the data and
that's fine.
But it's still a really good abstraction
for just having expressive
permissions that you don't need to enforce
on the back end. The fact that you can
do it on the client makes the architecture
way simpler. Plus, then you get this
benefit of
if I want to be a service provider in addition
to the open source framework and do the
sync and storage for you.
Now it's end to end encrypted, at least
in the sense that you as the
app developer don't need to trust me
and you users don't need to trust me.
They might trust you, but neither of you needs
to trust me and it truly becomes
a generic service that doesn't need to know
anything about your app, which is very different
from the cloud services we traditionally consume.
We'd like to stop and thank our sponsor
for the week, MUX.
If you haven't heard of MUX, you're in luck
today because MUX makes it easier
than ever to ship a video
based platform. In the past
you had to worry about so many different
things when setting up video for
your product. Whether it's uploads,
hosting, optimizing
or even playback.
There's so many different things to worry
about and it's really such a hard
thing to deploy. Your product manager
won't understand when you tell them
it'll take you months, but with MUX
that isn't an issue. MUX provides
a whole bunch of different SDKs,
toolkits and components
to make sure that you can ship video
in your product as fast as you need to.
Use as much or as little of them as you want
but where you do use them
you'll be hiring video experts
to make your app sing.
They do so many cool things that make the
video playback better for your users
that you won't even have to notice that
they're doing them. One that I really like
is they'll do adaptive streaming
based on the user's network
conditions. You can even, based on
the video content yourself, control
how high of a bitrate you stream at
directly affecting your costs.
So if you want to add video to
your product and you've been held up in the
details, go check out MUX today.
With that let's get back to the episode.
So what does using jazz look like?
We know that it's
a nice layer that makes it easy to sync
data and it's nice and secure.
But how does that actually translate to me
writing apps with it?
So to put it in its most radical way
basically you build a new app
but you throw away your backend and your
database. All you do is
you start by defining a data model
and something that kind of looks like
database
schemas or like a graph gel schema.
And then as soon as you have that schema
you can start creating objects
locally and you can start creating
permission structures locally. They're called
groups in jazz. You can add accounts
with different writes and then you create
an object within a group and it inherits
the permission rights. That's kind of the
mechanics of it. But you can do all of this
on the client. Like you can literally
create objects in a button on click
handler. You can create a group
in a invite button on click handler
and it immediately exists locally.
You can mutate it
synchronously and that's
the only thing you really have to think about.
You have this mutable local state that you can start
building your app around by basically
just building the UI for the features
that you want. And then
you get accounts
and sharing as first class
abstractions from jazz. Again, you just
need to build your UI around these and as soon
as you combine all of that you have a
fully working multiplayer
app that's also offline first.
That's
kind of how it works most of the
time. Some apps might want
to interact with existing systems
like a traditional database or like
a third party API.
And what you can do there is
use a package called jazz. Not jazz
for example, where you have a little
server worker that also
just becomes a client to the
sync and storage infrastructure. And it
actually has its own little account
just like users do and you need to
explicitly share data with it for it to be
able to either read it or write it whatever
you want it to do.
But once you do that, you get this really cool
setup where you don't need to make requests
to an explicit endpoint anymore.
You basically just, you talk about the shape
of data that exists in your app and the
concepts that really make sense for your app.
And you've got browser clients
or native app clients kind of
mutating that state and listening to it
and maybe you have some server workers also
listening to it and mutating it and it
all just gets synced without them really
knowing about each other explicitly.
That's like the
core picture of
the kinds of apps you can build with jazz and what that would feel like.
In some ways this reminds me
we were talking to Maas
from Linear about
their development process
and because they have a sync engine
that drives Linear, a lot of times
when a product engineer is coming in
and working on a product, they're really just
thinking about the models on the front end
the shape of this
object that you're working with
and not so much thinking about
how does this need to translate
into a SQL query or whatever to store this
on database. This is really hyper
focusing on that and then sync
is sort of taken care of as a matter of course.
So this is exciting
but I also think that this
layer that you're talking about of
okay we have to interact with an external
service and we need a bridge
to bring that external service
into our local first world is a part
that also I feel like is missed
a lot of times in the local first space
because it's not all
just the data that you have at your fingertip
it's all this stuff that's still out
in the real world. So it's cool
to hear that
you've got a solution for that
or thinking about it. Maybe it's sort of like build on this conversation
let's go a little bit deeper
and talk about some of the primitives
that you have
in jazz. So I was
reading through the docs again and you have this notion
of co-values or collaborative values
and
there are things like comap and co-list
and that are data structures that you
sort of like build your scheme out of.
So what other sort of like primitives do you
have or those are the main ones and
when you use these like what does that sort
of enable like what is that doing under the hood?
Yeah so these are really your main
contact point with jazz
and to be precise here jazz
is actually a framework on top
of a protocol called co-jason
like collaborative jason
and that's where most of the logic is actually implemented
and co-jason
gives you these different kinds of co-values
like you mentioned comap and co-list
these are the two most important ones
you can really think of them as your bread and butter
data structures just like objects
and arrays are the most important data structures
in jason itself
and you can represent almost anything with that
and then the way the co-values work
together is that the
fields in a comap or the items
in a co-list can either be jason primitives
like a string or a number or a boolean
or they can be references
to other co-values
internally they're just represented by storing
the id to the other co-value
but what jazz does as a framework
is it resolves these references
for you transparently so instead of
seeing an id you see
either loaded or unloaded
instance of that other
co-value and finally jazz
gives you the schemas to precisely define
what types
the different fields have
in your comaps or co-values
so you can really think of it as like
co-jason gives you dynamic jason
where you might have any kind of data
and then jazz gives you type schemas on top of that
plus the resolution magic
there are other co-value types
one is called
co-streams we'll probably soon rename it
to co-feeds because that makes more sense to people
and that's kind of a
map from account
to an append-only log of arbitrary items
and that's really really useful
for something like user presence
because each user on each device
just pushes the current state
like cursor precision and then you can
really easily get the current cursor precision
or the history of all cursor positions
which brings me to another really interesting
property of the co-values
by default they present
a view of the current state
like the eventually consistent current state
according to your local knowledge
but what they actually
are under the hood is the history
of all edits that ever happened to them
which means that you can
very easily time travel and ask it
what did this value look like 2 hours ago
or you can go and really
detail and see like
who edited this field
at this point in time and see
every little edit in there
there are other co-value types
one we already have that is really important
is binary co-streams
they are kind of just like co-streams
that you store chunks of binary data
but what that lets you do is store
files or even video streams
in jazz and so on
so now you don't even need blob storage anymore
they get synced just like all of your structure
data and you can reference
images or yeah any kind of
binary file like a pdf
directly from your co-values and again
something that is for some reason traditionally
very hard like file uploads
or image uploads are suddenly super easy
and just another thing you can play with
really important co-value types
that are still coming are
co-plain text and co-rich text
where co-plain text is basically
just a co-list of characters
and that's how you represent collaborative plain text
with like concurrent
insertions of people working the way you would expect
and then co-rich text
is a particularly interesting one
because even with CRDT
if you implement rich text in a kind of naïve way
where you represent a dom tree
you can end up in really hairy situations
and really crazy
conflicts where even the
automatic conflict resolution
of the CRDT does end up with
like eventually consistent state
but it's nowhere near what you would expect
semantically and you have all of these little pieces
of duplicated text
and broken formatting
and the way jazz will
and co-jason will represent rich text
is where you have to play in text as a list of characters
and then
you have what is called markup ranges
that point to like movable positions
in the CRDT
where the intent is captured by default
in a much more high fidelity way
and the conflict resolution does
exactly what you would expect
even in quite complex scenarios
which I think is really important for
well
every app that needs rich text
which is actually like a lot of collaborative apps
this is like and that's probably going to be
all of the co-value types
ever you can do a lot with those
and building your app is really just like
how do you combine
the different co-values into a shape
that represents the data of your app
and what is the permission structure
of groups that each of the co-values needs to be
and to represent how
sharing and permissions work in your app
yeah so that's one thing
that stands out a lot to me is like right when you
create these co-values you just say
this is just for me this is for this group
I feel like that's super cool
is there any other stuff that you do
at the declaration site
of a co-value that is like a unique feature
like that?
I don't think so and that's kind of all you need
what's the shape of it
who owns it
one thing we want to try in the future maybe
but I can't really promise that is to
pull some of the permission structure
more into the schema itself
because right now it's like when you create a co-value
you say which group it belongs to for example
but even that is pretty ergonomic
and because the groups and who are members of it
are kind of like a very dynamic thing
you typically want to
to use that in the parts of your UI
where you implement like a sharing flow
for example
so you said that the whole back end
is encrypted which is another
super cool property of it but does that make
debugging harder like if
you have a user that's having some trouble
and you want to go look at
a table or something just to like see what
the state is can you just not do that
in a jazz app?
Kind of by default no but what you can do
we have something called a jazz inspector
where like if the user trusts you
with their account credentials
you can just look at data
as them and you have access to everything
as they do and that's what you use
for debugging and just makes that initial
step of them having to give you
their account credentials a bit more explicit
and probably
will offer kind of a default
way of doing that where like
if and to be precise
I mentioned earlier that like
you can build traditional apps that are
end to end encrypted in the sense that my sync server
doesn't DCO data but you can of course
also use jazz
in a way where it's fully end to end encrypted
and you can't see user's data like you just mentioned
so
I think in our kind of like cloud
slash developer dashboard that we're working on
we'll probably
have that as an option where you're like
look I'm a trusted app
my users trust me
from some off methods
like if you use clerk or something
like all zero the way it works is that
the jazz credentials like the key pairs
literally stored in the metadata of the user
so by default
admins already have access to that
anyways and then that way
if your users already trust you you might as well
give the developers the full
debugging experience of being able to look into
every individual user but
it's no longer a default
it's no longer something that's the only possible
thing
you can build end to end encrypted apps and then
it's harder to debug but with individual
users you might just ask them for their account credentials
yeah that makes a lot of sense
there are definitely usability tradeoffs in there
but it's nice to have the option
to be completely hands off especially
and you can think of scenarios of
like health data
for example it's like
there's a lot of liability to having access to health data
so if you can say
we have no access
that's a really nice property
one of the things I wanted to chat about
this is a part
in the locals first base that I felt a lot about
is that there's this common problem
because you have these distributed apps
that are like syncing data
across devices if you
change the schema
of an app that can cause
a ton of problems
this is like what I think of as one of the hard
mostly unsolved problems
in the space but I'm curious
how you think about that
how do you think about schema changes
and how that impacts
like synced data over jazz
yeah I mean
as any local first framework
developer will tell you like yes
that's literally the hardest part of local first
and even to complete new commas
to local first the way I sell it to them
is like look it makes all of these really hard things
really easy but there's one thing
that's kind of cursed now which is migrations
and
what we've realized and practice
by building apps ourselves with jazz
and with our early adopters helping
them evolve their apps as they start
to need their first migrations
first the way it looks in jazz is that migrations
are attached to an account so
on the client before it launches
into your app it sees
if there are any migrations that needs to run
on the data kind of rooted
in your account and that's a chance
for you to define those
and right now it's kind of
a bit wild west you can do
any kind of mutation in the migration
it's up to you to do it in a way
that won't cause problems
and the main pattern to follow
here really is kind of think about it
not as a centralized database migration
would I like you stop the world
you make sure it's the same everywhere
but think of it as protocol evolution
particularly if you're familiar with something like
protobuf or even graphql schema
where the philosophy is kind of
you never remove fields, you only ever add new fields
if you do that with jazz
you typically don't run into any
problems and even if you have some old
clients that haven't done the
migration yet the interop is still
as best as it is possible
theoretically so over time
as we see more and more apps
and really crystallize these patterns
we will probably provide
guardrails where like maybe
with some typing help we make sure
that you can only do migrations that have these
properties and so on but right now it's just
up to you and obviously we help you
with it.
So the exciting part
to me about jazz when I read the docs
is it kind of reimagines what a back end
could be the feature that
really exemplifies that for me
is file uploads as you said
there's literally like people are creating whole
services just to like make file
uploads easy because they're just so
hard which is kind of crazy
since it's like one of our default actions on
the web but what other parts
of the back end do you want to like consume
into this platform that is jazz
so obviously it
needs to do
more things that databases traditionally
do a big one is kind
of queries and search
indices where right now
one of the surprising things is that
very often because it is such
a like user first perspective
you can actually load
all of the data of a user
or even a whole org into the client
again caveat here one of the special
things about jazz is you don't have to
it has very granular sync that's something
we can get into it kind of sets it apart
but still over time as
you load everything in your org by like looking
at it you can actually
have all of that on the client and very often
what would traditionally be a database query
with an index is literally
like a brute force
JavaScript dot filter
dot map over everything
and that's still super fast
but as we're starting to see
local first step where you are dealing
with hundreds of thousands or millions of objects
you do want
search indices
over those where you can quickly look up items
by their properties everything that you would expect
from a traditional database index
the fun thing is we can just
pull that into jazz as well
clients and
or server workers could
collaboratively maintain the index
and then index gets synced
as an object just like everything else
you get some really fun properties there
and over time
I want jazz to be more
and more what looks like
a distributed database that's kind of
exploded into its part that does
everything you need and you kind of pick and
choose what you want
to build in a sense it might feel a bit
like redis
where like redis doesn't really give you a full
blown database it gives you like the building blocks
for a database and then you kind of assemble
those into what you need for your app
and that's probably how like
search indices will feel like in jazz
obviously part of that
these days is also being able to
do vector search so we're like
what is
every feature that people need
from a database
and similar systems like blob storage
nowadays and how can we make that work
with the covalues so far
the indication seems
to be that surprisingly you can just do all of it with jazz
and
I feel like philosophically
there's a good reason for it because
the way I started seeing
traditional stacks is they're just a very
manual way of creating
shared state for like
structured and unstructured data
between users and devices
that just follows this established
pattern of like you have a backend
you have a database and you have clients
but there's kind of no
fundamental reason for why it should be structured
like that
and if you turn the problem around
and you're like what's an abstraction
for sharing state
and making sync your main way to do that
suddenly everything that you need
can fit into that model
so that's what we're trying to do with jazz
and
not just like theoretically but
including all the batteries and pragmatic
like bindings that you might need
to actually get your app off the ground
c'est cool, you can find solutions
like that where it's like you just have this encrypted
file store that's automatically synced
I can do a whole lot for you
Exactly
One of the things as you're talking
through this, one of the things that I think is
interesting to
touch on is like the limitations
so
local first, typically local first
apps are typically very
user centric, it's like a database
per user, usually they're
working with smaller sets of data
and that gives us
a lot of leeway
to experiment with ideas
that just aren't performant at a scale of
like 10 million users or 100 million users
or whatever
but as you're talking about like more distributed
database stuff, scales
become an issue, so
what problems do you think that jazz
is going to be like well suited for in the
space and like at what point do you say
ok
this is like a little bit beyond jazz's
scale or like not a problem
that we're trying to solve
So two things come to mind
and again I'm very radical here
in the sense that I want jazz to do as much
as possible, like really
One is that right now
it's best suited for
green field apps just because we haven't
really explored the like
syncing jazz state with a traditional
database very much which I think you need
in almost all cases where you want to
gradually adopt jazz
you could build that by hand
right now and we would be very happy to help
you too just so far we found that the people
who try out jazz and adopt jazz
they're building something completely new
where they can really do everything
with jazz and then obviously we have
features to catch up with there in terms
of un blocking different kinds of apps
The other thing is
and I want to be really precise here because
developers are very keen to
optimize and this is usually
the part that sounds scariest to them but jazz
does keep the full edit history
of everything you ever do to a covalu
The performance limit of that is way
higher than you think it is
So for example
something like user presence
where you like record cursor movement
into a covalu
It's like by default
a lot of other frameworks create
a separate abstraction for like ephemeral
state where it's basically just publish
subscribe and then you never hear of it again
The reason we say it's fine
and jazz to keep all that history is because
even if you record cursor movements
for a whole year continuously it's not
that much data it's like a couple megabytes
and it might actually be useful
to keep it around
if you want to have like a call
recording feature or something like that
in your app. So that's kind of one thing
where we're really expanding people's
conception
of what you can do on modern computers
The one thing
where I'm like no you absolutely can't do that
with jazz is people asking me
if they can build like real time simulation
games and store the state of that
in a covalu where like
if it's a turn based game absolutely
easily fits but if you have
like a 3D world with physics
don't try to build a multiplayer game with jazz
you couldn't theory but you would run into
scaling issues there that's like the main one
Other than that almost any type of app
should be fine and if you run into performance issues
I consider that a bug
and we have we've been lucky to
already have really diverse early adopters
so far where
for example one of them is literally
building kind of a social network
so they have something like
close to a couple million
visitors each week and I
don't know exactly how tightly
interacting they are
but that's something that's very
out of scope for the default
assumption of what people have for local first
they're basically just using jazz
like a traditional database to
I should probably
say what it is it's like a
learning platform that's kind of structured
a bit like reddit where people can
in a user generated way
collect good links and materials if you want
to learn like for example rust or how to
play the guitar or whatever
and they get from SEO
lots of first time users and then
they like render this page of lots of material
out of jazz
for this user one time they might not even ever
come back but that's very
a very different usage pattern from what
you would expect from a typical local first
apps where you have small teams that
interact mostly with the same data again
and again that they keep locally
and we had to stretch jazz a little bit
but it only took us
a week to basically optimize it for that
use case and that's that's the approach
we will take and that's only possible
because of what I briefly mentioned earlier
that jazz takes the default route of
granularly loading data
and not making you
define ahead of time as a developer
what is like a box of content that we
can load as a unit like
it's with a lot of other frameworks
it's either database
per client organization
or you have to come up with some like
delineation of like what is a document
in our app and then that's the unit of what
you can sing
as I mentioned when I
described the covalues it's
specifically built as like this
giant infinite graph of covalues
that can reference each other and
that means that the individual
covalues can actually be quite small
and that's what makes it more scalable as well
and then like you just resolve those
references for as deeply as
you need for like each particular
view of the UI so the same
optimization patterns
like pagination work exactly the same way
and in addition to that you could explicitly
choose what you always want to keep
offline to make an app
work offline well but because of that granularity
the scalability
actually is already quite good
even though the code is like horribly
unoptimized at the moment.
So a thing with React apps is having like
local versus global state in a jazz
world do I just like kind of default
everything to jazz since that's like
the nice base layer.
Yeah that has two really fun properties
where it turns out like
even just UI state management
is a huge topic in and of itself
and there's like hundreds of frameworks
around it. With jazz
if you just build everything around covalues
you can do something very fun where like
literally like leave components
can subscribe to different covalues
by ID and you could subscribe
to the same covalue from a hundred different
places in your UI without having to
coordinate between those. Under
the hood jazz deduplicates
that for you and just attaches these
as different subscribers to the same covalue
and that actually makes it a lot easier
to build front end code which
means that you're more likely to use it for
more stuff in your front end which
means that stuff that you
would never have thought of even
thinking before like
how far down did you scroll in this document
and maybe you want to sync that to other devices
you now have the option to do that and jazz
is actually funnily enough
more convenient to use
than good old local state
that's not even synced.
That's a really fascinating
concept
especially I'm thinking about like historical
like usage data, suddenly you get like these analytics
use cases falling out.
Sorry one more point as well
because you framed it as global state
one slogan that I really like is that
the problem with global state is actually
that it's not global enough and we're making it
even more global.
I want to transition the conversation
a little bit and talk about jazz
the business.
Jazz is an
MIT licensed project
or at least the main repo is.
We've had a lot of people
on the podcast talking about what it means
to build
a business with a large open source component
we've talked to people in the open source space
or in the local first space I should say
about the challenges
of building local first businesses
so I'm curious about your take
on this. How do you think about
how you license jazz
code, what needs to be open source
what doesn't
and sort of like how you
ultimately monetize this project in a successful way.
Yeah so I'll start
by just kind of precisely describing
the current situation where like yes
the framework and all of the packages around it
are open source.
There's an open source version of the
single storage server you can run yourself
and
again just to be completely transparent here
it's easy to run that on a single server
if you want to scale it across multiple servers
we don't really
like help you with that much
but if you're smart you can totally figure it out
and you can basically build a clone
of jazz cloud and that's very
intentionally so. We're starting
to build convenience features
around that into the commercial hosted
version of jazz cloud
which again is the single storage as a service
where like you get a nice dashboard
and you actually get these like
weirdly precise but anonymized
analytics about what users are
doing in your app without any extra instrumentation
and that's probably where
a lot of the commercial value
in the product will come from but
because we're a startup and because this is a
super weird new way of doing
things we're very aware that like adding
vendor lock into that would be like fatal
for people adopting it so
the nice thing is it has all the local
first property so the users already
own the data and by you
having the option to
run your own sync server or even
have a hybrid setup where you have your own
sync server as a backup that's connected
to jazz cloud and if we mysteriously
disappeared you could just re-root
your clients to your instance
of the sync server you
keep all of your data and you don't have
to change a single thing about your app
that's a really important property for us
and one that we will maintain for that
reason and in
that sense I think I'm actually really lucky
because a lot of
other open source frameworks
with a commercial offering have a much harder
time delineating what are like open
source versus enterprise features
and for us the incentives just seem
much more clearly aligned it's very easy
to separate it's a very easy
sell to individual
developers to businesses why
they should use jazz cloud
it's mostly about
the convenience of it versus
running your own one you really don't want
to be running your own
real time infrastructure like that
and itself a super hard that's something that we can
figure out at scale
and again the special properties
of jazz come in really handy here because
of the encryption we talked about earlier
you don't need to trust
our infrastructure so that's inherently
already a different kind of relationship
to it as a service and the other
thing is because of the encryption
we don't necessarily need to run
a typical multi tenon setup
where you get your own instance we can actually
just use really beefy servers
for all of the jazz apps because
the data like doesn't ever touch each other
because of the encryption and
that's just again makes this
an even easier sell and
even easier setup for us
what's actually challenging and something that
we want to help our adopters find out
is how do you sell
local first apps
and I think part of
it is exploring new ways of
paying for apps if people
are really buying into
that idea of users on the data
and you charge for access to updates of the app
but we also want to support
more traditional models and again in the sense
of being batteries included
the way that that would look like is that
we as
a developer who's using jazz cloud
give you really high fidelity
analytics
per user and
dials to kind of be like
well if they cancel their stripe subscription
you stop syncing specifically
their account
and then for all intents and purposes
they don't cost you anything anymore
they don't get most of the value
of your app anymore
but we're actually in this nice world where they still
have all of their existing data that they had locally
and I think that
that can be something where we might
end up
in a situation where it's even easier
for developers to integrate payments
and we really want to make that easy
and help people adopt that because obviously
we want our awesome local first
app builders to be really successful
with the apps and at the same time
it empowers users more. I'm
very optimistic about that part.
Yeah, when we talk to other founders
it seems like it's we will ask
okay now what does the platform do
and it's kind of like they have to like
reach and stretch for like oh
we can add some analytics here
you can see some graphs there but
with jazz you're reinventing the whole
thing and it makes sense that like you need
like a whole new tool
set to think about it. I think
how observability and analytics
and these event things just like
are properties of jazz
basically that you don't have to
worry about is super powerful
like here at Descript we have
a set of like six different tools
that are a nightmare to integrate
to get all of this
stuff when it's just like oh that's
just like part of the data now. Exactly.
A trend that we've definitely seen
and I think I hear more
as I talk to people is that
it seems like teams are pushing
to like do more with less people
and they want less like
overall expenditure less tools less
complexity. I think it's
part of the sort of like
crunch mode of the industry right now
but I mean it does seem like
tools like jazz make
provide a really good opportunity is like
if you have less overhead
and you can pull out more of these features
I think it'll be interesting to see
where you go specifically around
the sort of like product features
of like how do we help
end user developers become successful
cause like that's the big thing about
these like product
like platform plays is like
what is the value
we can add beyond just
the sort of like basic stuff that's expected
but I'm also excited
this is one of the
probably more mature things
in the local first space
it's still sort of like
very much up and coming
and there's a lot of hard problems to solve
and maybe this is a good next question
what, so we talked
about the schema problem earlier
about like that's one of the big
big hard
problems in the space
what do you think the other challenges
of the local first space are
what do we have left to solve
I think the biggest problem is
honestly just getting people to think
in that way even like adopting
a completely new way of building things
that's like always the hardest part
but I think in terms of like
what happened over the last
20 years which is roughly like
my awareness as a programmer
this is the most radical shift
that I've seen it's like
in the front in sense it's
as big as rails and react
but in the back end
sense like we haven't really
moved from the traditional model at all
it's still database client
server and we've gotten more advanced
about like how we
structure apps, how we orchestrate it
but it's been the same like all the time
this is the first really different way of
doing things
so
the biggest challenge
is just educating people
finding ways of framing
that are either like familiar
or like at least not scary
and the nice thing about this is
that that's very much a collaborative effort
because there is a bunch of local firsts
so it's in some sense we're competing
and in some sense we're like different approaches
to the same thing but the challenge we all share
and where we can all work together
is to even get people to consider
maybe we should build apps in a different way
and
that's what I spend a lot of time thinking about
and we're super
early with docs and
don't even have any blog posts yet
so far the people who find this
they already get it, they get local first
and they will work around all the rough edges
because they really need it
or they really see the nice
properties of it
in my experience
introducing front end developers to local first
they get it as well
because for them it's kind of the same cell
as a backend as a service
it obviously works very differently
under the hood but in effect it gives you the same thing
plus all of these extra nice things
and they love the idea that they can now
build whole apps without a backend
and this story becomes even more interesting
which is something that I actually hadn't anticipated
when I started out with Generative AI
because turns out
Generative AI is pretty good at
like chucking together front ends
well
if that's now all it needs to do to build whole functioning apps
you can suddenly move
really quickly with way fewer people
and I'm excited about both what that means
for individual developers
or people who I would call almost developers
like designers who code a little bit
who can now confidently
build whole apps
you can suddenly make industries out of
what used to be tiny niches of end users
that weren't worth building anything for
either in a commercial or just like
effort sense
on the other hand
big companies
who need lots of people can now suddenly
be more modern again and move really quickly
that's what really really excites me
and the upside of that is so huge
but it's still like
such a challenge to get people to even consider
something new so that's
I think the main thing
I see a lot of parallels here between React
and Jazz where it's like
when React came out it kind of shirked a lot of what
Frontend was about
NVC, MVCC, splitting HTML
CSS
and JavaScript
UI as a function of state
all of those things were super new and I see Jazz
doing very similar things
where it's like ok we had this back end
it was kind of like a fractured lego piece type of thing
what if we just reimagined that
as one cohesive unit
that can easily produce UI
yeah yeah totally and I like the parallel you drew
there because like
the whole like
yeah people used to be super strict about separating
even behavior from UI
and
like now everyone agrees
that obviously the way React does it
is the way to go and a lot of other frameworks
start looking more and more like that
I think signals are now kind of emerging
as like that's obviously the best way
to do reactive state and like
it's similar in a way
but I think it's even more drastic
because it touches not just the Frontend
but the whole stack and reimagines
as like you said
I'm a very optimistic person in general
but I think like
give it 5 or 10 years and we'll look back
and be like how did we ever build
apps like that weird way
that's just so much work
so it's been great getting a lot of insight
into what you're building with Jazz
but your company is garden computing
which you're sort of talking about
the garden app earlier
and Jazz is your sort of first product
what do you think
is the future beyond this
what comes next for Jazz
and what comes next for garden computing
Yeah, so for Jazz
I think one big thing is really nailing
the mobile story we started
the first step there with React Native support
in many ways the whole local first story
makes even more sense for mobile developers
than it does for web developers
I mentioned earlier
rich text and doing that
really well is a major thing
that un locks a lot of different kinds of apps
one other thing I think
that we haven't really talked about before
I think it's starting to be clear
how local first and general and Jazz
specifically solves a lot of data sharing
and permissions problems but I think
as we enable higher and higher
fidelity multiplayer offline
first apps the main challenge
is actually going to be in coming
up with new UX
to represent
partially synced offline
really highly multiplayer state
even the problem of
you've been on vacation for a week
you come back into your company's notion
and you want to know what's happening there
that's really hard and that's also where we want
to provide tools around this rich
history that Jazz has
to help you build these
what are actually new kinds of features
that's a big topic for Jazz
and then something I'm really excited about
is taking this underlying protocol
co-jason and making
like an open standard out of that
that can be implemented in other programming languages
and making it really like
a multi environment protocol
and framework
for garden computing in general
I did mention garden earlier
something that we want to start doing very soon
because as soon as we have rich text
we can start building that again
and we want that to be an end user product
in its own right basically
yeah notion competitor in the beginning
both because like
I want to enable all of this whole
new ecosystem of developers to build
cool apps but we also want to
build cool apps with Jazz ourselves
like that's the whole point right and I think
we're in a unique position there to be like
look this is really the
the bar of quality of
software you can build and it will be like
a product in its own right but also kind of like the flagship
app for Jazz
and yeah in the meantime
we already have a bunch of other ideas of what we want
to try building we're like we're kind of
annoyed by discord it's pretty good but it's also
annoying like and
if you have jazz suddenly it becomes really easy
to build something like that so why don't we
try and build our own discord and see how that goes
and there's lots of interesting things
you can do with AI we're like
based on the schema
offer jazz app you kind of
quote unquote could just add AI
and you get this like automatic collaborator
that just knows how to stuff in your app
and that's something we want to explore
so I think we'll
stay this mix of like
framework and service company plus
some end user apps because I think you can't
really do the framework
without it being really driven and influenced
by the needs that real apps have
and obviously we try to be really
close with our adopters but
I really think the only way to build a good
framework is if you're constantly building
apps with it yourself that's
one thing and then like more generally like
I would like to take the move
that I kind of did with jazz tools which
is like explore these like
new and interesting ideas
from the fringes
of academia like CRDTs
I mean by the point I discovered them they had
been a thing in academia for about 10 years
but these things just really take time
and kind of being this mix of like
a research lab and a really
like product company
where you take these new ideas
you find ways to make really
ergonomic abstractions out of them and then
do everything that's necessary
to bring them into the mainstream including
like the batteries included part
but also how can this be commercially
viable and self-sustaining part
and I obviously don't know
what the next things
of them are going to be like
one topic I've always been really
interested in is simulation but I don't
have any like concrete enough ideas for now
we like focus on jazz and everything that you
can do with that but that's kind of the
kind of company I want to build.
So many cool things unpacking there
if you guys do like
notion is such a good
like product to target cause like
linear is just like oh
we're good Jira and everybody's like oh
of course and like I think notion
is almost in that same place of everybody's
like we like it but it's just like
so terrible sometimes cause
it's so slow and jazz could probably
make that good. The AI part
though that really kind
of just slapped me cause like
since you have all of your state
and UI in this one place
you're right like you could have AI
opening menus for you just cause it knows
where all of the state
is so that's super cool.
That wraps it up for our questions
though thanks for coming on Ansem
this was a amazing
really interesting
talk for me I'm super excited to use jazz
I've been looking for some tool like this for a while
so thanks for coming on the podcast and talking about it.
Yeah my absolute pleasure thanks for
great questions guys.
Yeah
it's wonderful to have you and jazz
is such an incredible framework
so yeah looking forward to trying it out.