Speaker 1: Hello everybody, and welcome to another exciting episode of JavaScript
Speaker 1: jabber Z on Today's Toys. I've always wanted to say
Speaker 1: the Z, but I refrain just letting loose. Today today
Speaker 1: we have with us Steve Yo.
Speaker 2: I'm one of the I guess I'm one of the
Speaker 2: zombies in JavaScript jabber Z. Right, isn't that World war Z?
Speaker 2: Is that what you're going for?
Speaker 1: Well, it's more like vegeta and gohan but close. Sorry,
Speaker 1: they're they're kind of undead. They are undead, they are
Speaker 1: technically undead. They are technically zombies. Uh, I am, I'm
Speaker 1: gonna be your your what No? I host goes last, okay,
Speaker 1: and then Kyle ed get a pie.
Speaker 3: Hello, Hello, everyone, got to be back and I am
Speaker 3: your host today A j O'Neill yo yo yo, coming
Speaker 3: at you from Oh my goodness. I bought this stinky
Speaker 3: thing fly catcher thing, and it's stinking up the whole
Speaker 3: shed and I've got to have the shed door open
Speaker 3: a gen.
Speaker 2: But does it catch flies?
Speaker 3: You know that that?
Speaker 1: I don't know, But the flies haven't been bugging me,
Speaker 1: so I think I think it's uh, it's working. And
Speaker 1: obviously I'm not really a gen.
Speaker 3: I just.
Speaker 1: I just I've been hooked on too much primagen lately,
Speaker 1: and so I you know, not mock imitation is the
Speaker 1: serious form thought it anyway. Okay, so let's get into this.
Speaker 1: First question I have for you is for those of
Speaker 1: you that don't know, no even before that you're now
Speaker 1: get if i X. What was why did you change
Speaker 1: from getti fi to get if i X.
Speaker 3: So I had I still have the getafy account, and
Speaker 3: I just sort of I did a switcheroo where I
Speaker 3: created a new account and then swapped the two user
Speaker 3: names so that the followers that used to be on
Speaker 3: gettifi are now on getifi X. But there is still
Speaker 3: a getify account, so that's not it's reserved so that
Speaker 3: nobody else is using it. What actually happened was employment.
Speaker 3: A couple of years ago. The company that I was
Speaker 3: working for was concerned that I was that I needed
Speaker 3: to make sure to represent them and so or be
Speaker 3: clear in my social media representation. So at that time
Speaker 3: I switched my Twitter handle from getifi to getifi at
Speaker 3: and then the name of that company. And then I
Speaker 3: worked there for ten months or something like that, and
Speaker 3: then I was not working there and I was going
Speaker 3: to switch back to just straight up Getify, but then
Speaker 3: we had already had the rename of Twitter to X
Speaker 3: and I was like, oh, well, let's go with this.
Speaker 3: So I just went back to Getifi X. But again
Speaker 3: I still have that other Getifi account, so one or
Speaker 3: the other, but I mean the active one that I'm
Speaker 3: using is the getifi X account.
Speaker 1: Okay, cool? And I think that's how a lot of
Speaker 1: people know you. But for those that don't know you,
Speaker 1: how did you get to be so famous? And why
Speaker 1: don't they know you?
Speaker 3: Why? Why? Why? Well, so if we go back to
Speaker 3: a long, long time ago, in a land far away
Speaker 3: mid to late two thousands, like two thousand and seven,
Speaker 3: eight nine, that timeframe, that was kind of the first
Speaker 3: rise of JavaScript. We'd had frameworks like MuTools and Dojo,
Speaker 3: and then j Querry came along and Doug Crockford wrote
Speaker 3: a book in two thousand and eight called JavaScript The
Speaker 3: Good Parts, and we began to see kind of a
Speaker 3: renaissance re imagining of JavaScript around that time. I had
Speaker 3: made an earlier bet, many years before that, that I
Speaker 3: was going to want to be an expert in JavaScript
Speaker 3: because people are going to want expertise, And that was
Speaker 3: going to be a good career path. That turned out
Speaker 3: to be a good bet, But I made that early
Speaker 3: bet on JavaScript started focusing on that, and so by
Speaker 3: that time that JavaScript started to take over in the
Speaker 3: more public sense, and we started to have you know,
Speaker 3: JS comp I remember in two thousand and nine the
Speaker 3: first JAS comf in DC. We started to have conferences
Speaker 3: around JavaScript, and there started to be job descriptions around JavaScript,
Speaker 3: and I had some pretty strong thoughts. Having already spent
Speaker 3: quite a bit of time with the language, I had
Speaker 3: some pretty strong thoughts about it, so I started trying
Speaker 3: to participate. The first thing I was known for was
Speaker 3: a dynamic scriptloader called lab jas that came out in
Speaker 3: early two thousand and nine and got pretty big. Was
Speaker 3: used on quite a few big sites like Twitter and
Speaker 3: Vimeo and Zappos and a few others, and so that's
Speaker 3: kind of the first way that people knew me. You
Speaker 3: fast forward another couple of years and all the fame
Speaker 3: of a tiny two kilobyte library had faded. I'm saying
Speaker 3: that tongue in cheek, but that had faded. I had
Speaker 3: started to do some conference talks around various JavaScript and
Speaker 3: performance aspects, but I really felt like, I had some
Speaker 3: things I wanted to say about the language itself, and
Speaker 3: I started writing the you Don't Know JS books, and
Speaker 3: that is how most people have heard of me. Is
Speaker 3: the sixth volume set, the sixth volume of the first edition.
Speaker 3: Second edition is a little more complicated in its status
Speaker 3: and length. But I came back, So the first edition
Speaker 3: was released in twenty fourteen and twenty fifteen. Then I
Speaker 3: came back in twenty twenty and started the second edition,
Speaker 3: and those are kind of on the shelf now, not
Speaker 3: really actively being developed. But that's yeah, two editions of
Speaker 3: a six book series. Basically, okay, cool, all right, Yeah,
Speaker 3: and say I should say specifically just so that people
Speaker 3: are aware if you haven't heard me say this before
Speaker 3: the title of the book series obviously has several different
Speaker 3: layers of meeting. There's obviously a bit of a tongue
Speaker 3: in cheek kind of joke about the old you Don't
Speaker 3: Know Jack trivia game and some other things like that,
Speaker 3: But it was never intended to be an insulting name
Speaker 3: the way many people took it. It was actually intended
Speaker 3: to be a challenge to approach JavaScript with a more
Speaker 3: open mind and a more active I'm going to always
Speaker 3: be learning kind of a thing, which is why the
Speaker 3: second edition added the word yet to it, you don't
Speaker 3: know JS yet, because I wanted to make it even
Speaker 3: more clear that the point of this was actually to
Speaker 3: kind of be hopeful and to spur people to learn
Speaker 3: the language more deeply.
Speaker 1: Yeah. I I totally understood it when it came out
Speaker 1: because that that I think they just transitioned that to
Speaker 1: a mobile slash TV game where you could scan a
Speaker 1: QR code or something. So I totally understood it. But
Speaker 1: I could also see as the you know, Twitter sphere
Speaker 1: has boomed, a lot of the idioms, the English idioms
Speaker 1: have gone awry, you know that things have opened up
Speaker 1: a lot more so I okay, all right, Yeah.
Speaker 3: And then it was a response to again two thousand
Speaker 3: and eight and two thousand and nine, this Cambrian explosion
Speaker 3: of JavaScript around libraries. Not a lot of people wanted
Speaker 3: to learn JavaScript the language. Everybody wanted somebody's library to
Speaker 3: do it for them. It sounds a lot like today, actually,
Speaker 3: But what we had at the time was the JavaScript
Speaker 3: the Good Parts book, and that book essentially said, hey,
Speaker 3: I Doug Crockford have surveyed the whole JavaScript language and
Speaker 3: I've figured out that most of it sucks, but here's
Speaker 3: this tiny little subset that's really good, and you should
Speaker 3: learn that. And I really wrote my book series and
Speaker 3: then the subsequent courses and everything else I've done since
Speaker 3: as a response to that book set to say I
Speaker 3: don't think you should learn only a small subset that
Speaker 3: one I opinionatedly, you know, put a linter for I
Speaker 3: think you should learn all of the parts of javas.
Speaker 1: That's it's really unfortunate that you're so wrong there, But
Speaker 1: I guess we all have our opinions.
Speaker 3: Say, man, I've been I've been wronged a lot longer
Speaker 3: than you were in the industry. I've been around a
Speaker 3: long time, so I'm all right with that.
Speaker 1: Yeah, uh okay. So one of the things that we
Speaker 1: have you on for today was I saw some tweet
Speaker 1: that caught my eye about some local first stuff and
Speaker 1: then later some pass key stuff, and so let's just
Speaker 1: transition over into talking about that and what like what.
Speaker 1: And it seems it seems really timely. I think when
Speaker 1: I first saw the tweet, between the time I saw
Speaker 1: the tweet and we got you scheduled, like it was,
Speaker 1: it was something that was you know, in the nicheness
Speaker 1: of its hype cycle, and now with all these with
Speaker 1: DHH making a stir, I think that some of this
Speaker 1: is actually maybe Local first itself is not on the
Speaker 1: rise yet, but I think that it's going to lead
Speaker 1: to being on the rises. People are talking about performance
Speaker 1: and five dollars a month BPSS and whatnot, So yeah,
Speaker 1: it is.
Speaker 3: Yeah, what I I can kind of set the scene
Speaker 3: for everyone around local first. A small little consulting company
Speaker 3: named Ink and Switch back in I think either twenty
Speaker 3: eighteen or twenty nineteen, they coined the term local first
Speaker 3: and they put out this little manifest. Though it's easy
Speaker 3: to google for the seven principles of local first development,
Speaker 3: I'm not going to go through all of those. You
Speaker 3: can read them yourself if you're interested, but I will
Speaker 3: kind of summarize the one big point of local first,
Speaker 3: and we'll try to distinguish that because there's a lot
Speaker 3: of other things that people think it is or isn't.
Speaker 3: But the main point of local first was to kind
Speaker 3: of tackle head on this very clear trend that has
Speaker 3: moved nearly the entire web and in fact most of
Speaker 3: software around it, towards a cloud centric model. And the
Speaker 3: tackling trying to go out this head first is to
Speaker 3: say that one of the big problems with a cloud
Speaker 3: centric model for architecture is that you make that cloud required,
Speaker 3: and the cloud in this very big amorphos sense, is
Speaker 3: not nearly as ubiquitously guaranteed for every user as we
Speaker 3: might like to believe. There are a variety of reasons
Speaker 3: why my version of an app that's on my device
Speaker 3: and the thing that it needs to talk to up
Speaker 3: in the cloud might not be able to talk. One,
Speaker 3: I might have spotty or no internet. Two, there could
Speaker 3: be some sort of large Internet wide or you know,
Speaker 3: service wide outage in a cloud. Routers, dns. We see
Speaker 3: those things. Yeah, we see these things happen, and I
Speaker 3: think I personally resonate with There's actually probably almost half
Speaker 3: of the Internet's users, at least a third to a
Speaker 3: half of the Internet's users, live in parts of the
Speaker 3: world where both power and internet are not guaranteed unlimited assets.
Speaker 3: These are resources that are quite constrained, they're metered, they
Speaker 3: cost a lot, and they basically can't afford in one
Speaker 3: way or another to be constantly cloud connected and constantly
Speaker 3: sending all of the data back and forth. So what
Speaker 3: Local First did was it came along and said, the
Speaker 3: way to start tackling this one one peg of this
Speaker 3: is to put data. The source of authority for data
Speaker 3: should be on a user's device. And by data, we
Speaker 3: were specifically talking about the data that is relevant to
Speaker 3: or matters to that user. We're not saying that, you know,
Speaker 3: all trillion gigabytes of Amazon's database needs to be on
Speaker 3: everybody's phone, but the parts of that that they need
Speaker 3: should be on their device. And most importantly, I would
Speaker 3: extend that to say, the stuff that I create, or
Speaker 3: the stuff that is created about me, that's the stuff
Speaker 3: that's relevant to me, and that stuff, the source of
Speaker 3: authority for that data should be on the user's device.
Speaker 3: That does not foreclose having cloud servers and having synchronization
Speaker 3: and all of that, but it shifts the whole mindset
Speaker 3: to we start with the user's device and we build up,
Speaker 3: we progressively enhance from there, rather than starting with the
Speaker 3: assumption that everything is cloud based and if you don't
Speaker 3: have connection to the cloud, you're dead in the water.
Speaker 2: Yeah. I'll give you a little more different example than that.
Speaker 2: I did some work for a form Erner platform called
Speaker 2: form I own number of years ago, and I've had
Speaker 2: the founder on here a couple of times, and one
Speaker 2: of the use cases he gives for local first isn't
Speaker 2: necessarily you know, speed or bandwidth available ability, and their
Speaker 2: platform had ability built in where you could do everything
Speaker 2: locally on your device and then when you connect to
Speaker 2: a server and sync up. And the example that Travis
Speaker 2: gave was a scuba diving company who would be out,
Speaker 2: you know, they'd be out on a boat out in
Speaker 2: the water obviously where you scuba dive, unless you're in
Speaker 2: a pool, and you know, you want to be able
Speaker 2: to collect all your customers information and so on and
Speaker 2: get it in there, and then when you get back
Speaker 2: to shore or back within Wi Fi reach or sell
Speaker 2: reach or whatever your technology is, then you can sync
Speaker 2: up with your server and get everything simpty sync up
Speaker 2: that way. So just another scenario where local firsts would
Speaker 2: definitely come into play.
Speaker 3: Yeah, definitely, the the realities of the world being experienced,
Speaker 3: the computing world being experienced in way more places than
Speaker 3: in a fixed office space with a fat Internet pipe
Speaker 3: that you're connected to the world is increasingly more mobile.
Speaker 3: That's not a you know, unusual thing to assert, but
Speaker 3: it's increasingly more mobile and increasingly less online. Actually, there's
Speaker 3: way more of the world that's happening in that spotty
Speaker 3: part of the Internet. And it's been said before that
Speaker 3: spotty or intermittent Internet is actually a much more challenging problem,
Speaker 3: both for developers and users than no Internet at all.
Speaker 3: And so I think we definitely we need to embrace
Speaker 3: the idea that for the Web to truly reach all
Speaker 3: eight billion people in the world, we have to think
Speaker 3: about the residency of data being much closer to them.
Speaker 3: We did have, you know, a brief few years where
Speaker 3: we said, well, if we just put more servers in
Speaker 3: more places, and if we hang giant balloons up in
Speaker 3: the air, and if we have satellite internet like, we'll
Speaker 3: just we'll blanket the world with Internet and that'll be
Speaker 3: the fix. That's the you know, techno billionaire's perspective on things.
Speaker 3: But I think builders of the web need to embrace
Speaker 3: this local first principle of making the server, making the
Speaker 3: cloud optional as opposed to required. And it does bring
Speaker 3: in a whole It solves a bunch of things, but
Speaker 3: it brings in a different set of problems, and you
Speaker 3: mentioned those, the synchronization questions and the whole concept of
Speaker 3: synchronization data structures like CRDT. You know that that's now
Speaker 3: a big thing of discussion where that used to just
Speaker 3: be a niche academic topic, but we have got dozens
Speaker 3: of companies that are trying to build commercial solutions around
Speaker 3: sophisticated synchronization mechanisms. When you have data on a device
Speaker 3: that needs to synchronize with other devices and with cloud servers.
Speaker 2: So how much does that does the local first approach?
Speaker 2: I guess it really doesn't. Maybe it does. Exascer debate
Speaker 2: a little bit. Is the performance issue, So you know,
Speaker 2: obviously the issue with JavaScript versus a server side language
Speaker 2: is that since it's running the browser, that code has
Speaker 2: to be all downloaded to your browser. And so there's
Speaker 2: the ongoing issues that developers face with trying to make
Speaker 2: their code, whether it's using a framework or not, as
Speaker 2: minimal as possible. So that for your third world countries,
Speaker 2: for your places where there's a poor connection, maybe only
Speaker 2: three G instead of five G, et cetera, you've got
Speaker 2: less to download.
Speaker 3: So now.
Speaker 2: You're adding a bunch more data to what you're downloading
Speaker 2: because you're stashing it locally. So that's going to make
Speaker 2: I guess that would make your on device performance when
Speaker 2: it's actually using the code faster because you're not having
Speaker 2: to make your API calls to your server. But at
Speaker 2: the same time then you've got to sync all that up.
Speaker 2: So it seems, as I ramble on here, I guess
Speaker 2: you could say it's sort of minimizing that and making
Speaker 2: it less of an issue because you don't have all
Speaker 2: the data flowing back and forth as much as you
Speaker 2: do with JavaScript. Or is that a join issue?
Speaker 3: Generally speaking, I think a local first app reduces the
Speaker 3: amount of data in totality that needs to go back
Speaker 3: and forth across the wire, but it may very well
Speaker 3: in fact frontload more of that data transfer, especially if
Speaker 3: you're synchronizing an existing user history onto a new device.
Speaker 3: There definitely might be more download, not only download of
Speaker 3: the application itself. Because that's another thing, like if I
Speaker 3: have the app, I really should have a continuing to
Speaker 3: work app even if I have no internet, right That's
Speaker 3: that's the offline first part of this, which is only
Speaker 3: part of the umbrella. But I should have an app
Speaker 3: that continues to function even if the internet connection to
Speaker 3: the web server is down or you know, non existent
Speaker 3: because they went out of business. You know, I should
Speaker 3: be able to keep using that. So there very well
Speaker 3: might be a trade off here where the initial experience
Speaker 3: is a little bit more like an app install experience
Speaker 3: that is not instant on. And I personally think that
Speaker 3: would be better for the web to go back to
Speaker 3: not trying to fake the instant on experience and instead
Speaker 3: embrace the idea that I'm not websites, but if I'm
Speaker 3: choosing to install an app, it really should be a
Speaker 3: thing that I'm willing to wait three, five, ten, twenty
Speaker 3: seconds whatever it takes to get the whole app and
Speaker 3: whatever data I need synchronized onto my device. You know,
Speaker 3: you could take a page out of Google's book, Google
Speaker 3: Crumb's book and put little you know, dinosaur jumping games
Speaker 3: in there while you're waiting. I mean, we can go
Speaker 3: back to the days where we had you know, better
Speaker 3: that better experiences than just those dumb spinners that can
Speaker 3: engage people and let them do things. But another point
Speaker 3: to this is that a local first experience should work
Speaker 3: even if if you don't have even if you don't
Speaker 3: yet have your data. So honestly, maybe having an instant
Speaker 3: on experience as soon as you get the code, you
Speaker 3: should be able to start creating data, even if all
Speaker 3: of the data that it's going to merge with has
Speaker 3: not yet downloaded. So I think there's a lot of
Speaker 3: complexity in terms of those trade offs, but it is
Speaker 3: being intentional about saying that users should be able once
Speaker 3: they have a piece of data and they have an
Speaker 3: app to work on that data, they should be able
Speaker 3: to continue to do what that code and data enabled
Speaker 3: no matter what from here on forward. My best use
Speaker 3: case to describe this, it's just one personally, but when
Speaker 3: we think about bank account apps, generally people think about
Speaker 3: bank accounts. Is the only use case is I want
Speaker 3: to know right now, instantaneously what is my current available
Speaker 3: balance in my bank account. But there's a tremendous amount
Speaker 3: of information in my bank account that has nothing to
Speaker 3: do with what the latest thing that I bought at
Speaker 3: the grocery stores. And that data is on my device.
Speaker 3: I can see it, I can interact with it, I
Speaker 3: can search it. Except when my internet goes away, Now
Speaker 3: all of that's completely gone. I can't go back and
Speaker 3: look at what I bought at the grocery store last week.
Speaker 3: Because they make the assumption when they build the banking
Speaker 3: app that the only way that I want to use
Speaker 3: this app is to see current incident. If they can't
Speaker 3: give me that, they don't give me anything, well, that's bonkers.
Speaker 3: I think that's my data, very clearly my data, and
Speaker 3: I have an app that's able to render and work
Speaker 3: with that data. So a local first app would say
Speaker 3: you can continue to look at all of your previous
Speaker 3: bank account transactions and read them and search them and
Speaker 3: categorize them and do whatever you want even if you
Speaker 3: don't have an Internet connection to look at your live
Speaker 3: account balance. That's I think what we're missing is that
Speaker 3: we just assume that live everything is the only use
Speaker 3: case that matters, when actually there's a ton of use
Speaker 3: cases that don't require that live connection.
Speaker 1: All right, So I'm going to push back on this,
Speaker 1: right and I actually like morally, morally I agree with you,
Speaker 1: but practically we have to look at what, you know,
Speaker 1: what the reality of the situation is. So most most
Speaker 1: web businesses are not profitable businesses. They are growth businesses.
Speaker 1: The way that people make money is that for the
Speaker 1: first ten years or so, they just hand off the
Speaker 1: business from one investor to another as they go through
Speaker 1: seed round this A B C, D E, F G
Speaker 1: H I J K lemono, you know, and then and
Speaker 1: then after thirteen billion dollars, maybe maybe they become profitable,
Speaker 1: but most likely they just they just flyn So why why,
Speaker 1: like what what's why would anybody care about, you know,
Speaker 1: the people in these spotty internet areas because you know,
Speaker 1: they have no money to pay for the product. So
Speaker 1: in terms of growth users, like, yeah, I guess you could.
Speaker 1: You could make an argument for say, yeah, there's a
Speaker 1: lot of people out there with spotty internet. You could
Speaker 1: get them onboarded as users if you're the only one
Speaker 1: that's actually trying to onboard these users, But then you
Speaker 1: can never count them in a metric as like potential customers.
Speaker 3: So yeah, I totally disagree with that. I think that's
Speaker 3: a complete false dichotomy that people with spotty internet have
Speaker 3: no money. There's lots of lots of use cases that
Speaker 3: we can imagine you were referring. You know, we've talked
Speaker 3: a little while ago about the diving company that's out
Speaker 3: that's that's a high end hobby that people are spending
Speaker 3: a whole lot of money on and they just happen
Speaker 3: to be in an area where they don't have Internet
Speaker 3: at that moment where they're collecting and experiencing the data.
Speaker 3: There's use cases around uh, construction and survey companies that
Speaker 3: are out in the field and they're nowhere near where
Speaker 3: Internet is. They're collecting tons of really useful and very
Speaker 3: expensive data that they need to sell to other people
Speaker 3: or synchronize with their company. But you know, we don't
Speaker 3: even have to get into the big companies. There are tons,
Speaker 3: literally millions and millions of people in the world, tens
Speaker 3: of millions of people of the world who are a
Speaker 3: one man, one woman business, a one person business, uh.
Speaker 3: The fish farmer in somewhere rural. They may be collecting
Speaker 3: hundreds of thousands of dollars worth of product that they're
Speaker 3: going to take to market. They are very much somebody
Speaker 3: that you can monetize and treat as a customer. But
Speaker 3: when they're out there collecting all of those fish and
Speaker 3: they're not yet at the market with it, they're not
Speaker 3: somebody who has Internet, but they still absolutely have tons
Speaker 3: of potential and should be treated as a valuable customer.
Speaker 3: And that's not to even get into the larger moral
Speaker 3: question of we ought to treat everybody's access to the
Speaker 3: Internet as an important human right I believe, as opposed
Speaker 3: to only a right that comes if you're willing to
Speaker 3: pay for it.
Speaker 1: But I don't know that I think about a yeah, sorry,
Speaker 1: it's all right, go ahead. I was just saying, I
Speaker 1: disagree that it's a human right. It's something that's very modern.
Speaker 1: It's something that's only existed for literally decades out of
Speaker 1: thousands of years of human history. So to call it
Speaker 1: a human right is on a like that's that's a
Speaker 1: bridge too far from me. But I agree, like I
Speaker 1: would love a world that is like what you're saying.
Speaker 1: I get frustrated all the time. I mean, living here
Speaker 1: in Utah, things have gotten a lot better in the
Speaker 1: past ten years. But it used to be sometimes when
Speaker 1: I was going between cities because there's these little cities
Speaker 1: like Mapleton or Pleasant Grove is kind of booming, but
Speaker 1: they were really small, you know, and so I'd be
Speaker 1: going going between cities and not having phone, like really
Speaker 1: good phone reception back when I was in college. Now
Speaker 1: now it's you know, because of all the tech booms
Speaker 1: that have happened, like all the past years, are being
Speaker 1: brought up and turned into business parks. A lot them
Speaker 1: are just sitting there empty, but they're there nonetheless, and
Speaker 1: and yeah, so it's it's a it's a bit better.
Speaker 3: So I like that.
Speaker 1: Idea, but I just I think it's a hard sell
Speaker 1: to talk with someone and say, hey, if you're if
Speaker 1: you're actually a legitimate startup trying to be profitable, how
Speaker 1: are you going to spend all this extra time to
Speaker 1: do something that's not an industry standard. There is no
Speaker 1: playbook for it, which I guess maybe that's part of
Speaker 1: what you're trying to fix. And and these are one
Speaker 1: off experiences from you know, the one percent of your customers.
Speaker 1: And let's say that we agree these are actually going
Speaker 1: to be customers, not users. But you know they're the
Speaker 1: one percenters, or it's the one time they're out there,
Speaker 1: you know they don't have another option anywhere. They're really
Speaker 1: going to be that upset that, Okay, while they're skydiving,
Speaker 1: they can't use your app. I mean, maybe it's not
Speaker 1: safe to use the Apple skydiving.
Speaker 3: There's another angle that I think we should point out,
Speaker 3: which is there's play of justification to attract businesses to
Speaker 3: create apps in this way that really has nothing to
Speaker 3: do with whether they ever charge their user anything, right,
Speaker 3: there's tons of apps out there that never charge a
Speaker 3: penny to any of their customers. They're just selling their data.
Speaker 3: They're selling them advertising or whatever. And there's plenty of
Speaker 3: reasons why those companies can benefit from local first apps.
Speaker 3: One of the biggest reasons is that if you long
Speaker 3: term reduce the amount of churn of data going back
Speaker 3: and forth across the wire. In fact, potentially you might
Speaker 3: even completely eliminate the need for these big centralized stores
Speaker 3: of your data. You drastically reduce the footprint that you
Speaker 3: need in the cloud, perhaps even to zero, but certainly
Speaker 3: significantly less. Are there things that you'll still always do
Speaker 3: in the cloud. Yeah, you'll host giant video files and
Speaker 3: other CDN things. You'll do really complex compute out in
Speaker 3: the cloud with AI training. But there's a ton of
Speaker 3: the generalized CRUD stuff that we do out in the
Speaker 3: cloud right now because it seems easiest to do it there,
Speaker 3: and we pay tons of money to those cloud providers
Speaker 3: to do that. There's a lot of that that can
Speaker 3: actually be shifted to the user's devices. We see potential
Speaker 3: growth in peer to peer device communications through various different protocols,
Speaker 3: both web and native that can reduce the stress and
Speaker 3: the footprint that you need in the cloud. And like
Speaker 3: we were mentioning in the in the pre show, people
Speaker 3: like DHH you know, and the thirty seven signals folks,
Speaker 3: and the things that they're doing, they're not they're not
Speaker 3: bastions of those, you know, they're not leaders in the
Speaker 3: local first community per se. But what they are saying is, hey,
Speaker 3: is the cloud really required? Or can the cloud actually
Speaker 3: be optional? Are there other architectures there where we can
Speaker 3: move back down to You have an app, you own
Speaker 3: the app, you host the app, and you host your data.
Speaker 3: And I think that's going to lead to companies starting
Speaker 3: to ask those questions, Wait a minute, do I really
Speaker 3: need to pay hundreds or thousands or tens of thousands
Speaker 3: of dollars to a cloud provider when I could offload
Speaker 3: a lot, if not all, at least a lot of
Speaker 3: what I was doing and reduce the cost. I think
Speaker 3: there's a huge business benefit to embracing local first. And
Speaker 3: just like with any other movement, you said, true, it's early,
Speaker 3: it's nascent, there's not a lot of standard, but that
Speaker 3: offers huge upside potential for the companies that decide to
Speaker 3: be early movers in that space, and it's always been
Speaker 3: the case that early movers have had huge upside potential. Yes,
Speaker 3: huge risk, but huge upside potential. It comes with the.
Speaker 1: Okay, So one thing that I think is pretty well established,
Speaker 1: and I would love to be corrected on this, but
Speaker 1: I think it's pretty well established that state management is
Speaker 1: more difficult on the front end than it is on
Speaker 1: the back end. Like there's just that it's a higher
Speaker 1: level of abstraction. There's more thing that you're not in
Speaker 1: control of that can go wrong. State management on the
Speaker 1: front end is a nightmare. And React came in and promised, like,
Speaker 1: you don't have to worry about state management anymore because
Speaker 1: we're just gonna re render the whole page. And we've
Speaker 1: seen how that's gone. You know, it's not been like
Speaker 1: this shining star of Oh, state Management's not a problem anymore.
Speaker 1: It's been another game of hot potato where well, actually
Speaker 1: we do need state management, but it's going to live
Speaker 1: in this this component now, Actually it's gonna live in
Speaker 1: this library. Actually we're gonna put it back on the server.
Speaker 1: Actually we're gonna stream it down to the client. And
Speaker 1: you know, it seems like every six months to year
Speaker 1: and a half sixty eighteen months, React completely gets like
Speaker 1: a whole fundamental redesign, and then instead of calling it
Speaker 1: some other framework, they just call it React seventeen or
Speaker 1: eighteen years ye, right, which is just like one of
Speaker 1: the most that's like the best brand thing that has
Speaker 1: ever happened in the universe in terms of front end frameworks.
Speaker 1: Release a completely different framework that shares almost none of
Speaker 1: the principles of the previous one other than the syntax,
Speaker 1: and call it the same thing.
Speaker 3: But with that said, it's working companies that are behind React.
Speaker 1: How are people supposed to They can't even figure out
Speaker 1: what they're doing right now, right like, they can't even
Speaker 1: figure out the state management problems that they have right now?
Speaker 1: How are they going to handle all the additional state
Speaker 1: management problems of local first? And maybe there's a snuck
Speaker 1: premise there that needs to be disbanded. But well, yeah,
Speaker 1: so here's what I would say. First of all, a
Speaker 1: tremendous amount, not all, but a tremendous amount of the
Speaker 1: current complexity in modern front ends is directly related to
Speaker 1: the choice that we made to centralize architecture on a
Speaker 1: cloud first model and then also try to tell everybody,
Speaker 1: even though all of that data and all of that
Speaker 1: code lives not on your device but out in the
Speaker 1: you know, in the ether somewhere, we're going to make
Speaker 1: it look as if it's as close to instant on
Speaker 1: as possible. Those two things have conspired together to create
Speaker 1: an entire, multi billion dollar industry of web performance optimization
Speaker 1: and literally dozens and dozens of these complexities that you're
Speaker 1: talking about, most recently the shift back to server side
Speaker 1: components and server side blah blah blah whatever. Most of
Speaker 1: that I think is chosen complexity, not necessary complexity, but
Speaker 1: it's been a choice that we've been continuing down that route.
Speaker 1: And Local First says, actually much of that, not all
Speaker 1: of it, but much of that is not actually necessary.
Speaker 1: If the code is resident on somebody's device, If we
Speaker 1: build an experience where it's very durable and very stable
Speaker 1: instead of it's constantly changing every five minutes on every page,
Speaker 1: load a durable and stable experience, and we put the
Speaker 1: data where somebody needs it to reduce the amount of
Speaker 1: the need of all of that back and forth. What
Speaker 1: what you're basically doing is you're saying all of the
Speaker 1: complexity that we have around eventual consistency, which is I
Speaker 1: think one of the worst terms we ever invented as
Speaker 1: technologists because there's absolutely no consistency anywhere. It's a total farce.
Speaker 1: It's a never consistency model.
Speaker 3: If you think about what is the source of authority
Speaker 3: for Amazon's e commerce database, there are literally hundreds of
Speaker 3: thousands of sources of authority for Amazon's database. There is
Speaker 3: no one snapshot that says this is the true source
Speaker 3: of truth for what's going on with Amazon as a business.
Speaker 3: So what we're saying is they're already have the built
Speaker 3: in complexity of managing effectively with crdts, very bespoke internal
Speaker 3: to their business logic and their cloud back ends. They're
Speaker 3: already having to deal with massive amounts of complexity of
Speaker 3: all of that state management. And I think I think
Speaker 3: that's the hidden complexity that you weren't talking about. We
Speaker 3: have all this front end complexity, but the balance of
Speaker 3: that is all of that hidden complexity in our back ends,
Speaker 3: and we have tons of giant frameworks and messaging systems
Speaker 3: and all that that try to manage all that stuff
Speaker 3: of database architecture complexity with replication and all of that,
Speaker 3: and basically local firstus saying we could eliminate most of
Speaker 3: that if we stopped trying to pretend that the only
Speaker 3: way for this experience to happen is to require a
Speaker 3: round trip. We can have round trips when we need them,
Speaker 3: but we don't have to require that to gate the
Speaker 3: user's experience. We can install an experience for them. We
Speaker 3: can put data there that they need most frequently, and
Speaker 3: we can put the logic there that makes that data
Speaker 3: do what that user expects and stores whatever they've changed,
Speaker 3: and then in the background synchronizes that to wherever it needs,
Speaker 3: whether that's peer to peer to another device, or whether
Speaker 3: it's through a traditional sending some synchronized data back up
Speaker 3: to a cloud server, which is what many of them
Speaker 3: are doing. But we're just simply saying that user does
Speaker 3: not have any anywhere near that amount of complexity. So
Speaker 3: this is a very different way of building applications. Does
Speaker 3: it have its own complexity, of course it does. Nobody's
Speaker 3: saying this is the silver bullet and it's just two
Speaker 3: lines of code and it's all done. But I actually
Speaker 3: think if we were if we went forward five years
Speaker 3: and then we're to take a really good local first
Speaker 3: app and there are several out there, linear and some
Speaker 3: of those others. If we were to take their code
Speaker 3: bases and compare them to the equivalent cloud centric code bases,
Speaker 3: I really do, genuinely believe that the overall complexity, the
Speaker 3: overall number of moving parts goes down when you embrace
Speaker 3: these principles.
Speaker 1: Okay, I I would love to agree with you. I'd
Speaker 1: need to see how, because again I'm just hung up
Speaker 1: on Fundamentally, caching on the front end is front end
Speaker 1: people are asked to do too much. They're expected to
Speaker 1: do CSS, which is essentially a design mindset, or they're
Speaker 1: copying design. They're either creating or copying design in CSS.
Speaker 1: They're expected to understand the DOM which is very engineer
Speaker 1: oriented data internals to event loops in a browser and
Speaker 1: rendering processes. And they're expected to also be a programmer
Speaker 1: in JavaScript, where they need to have developed the acumen
Speaker 1: for writing programs. And these three things are literally they're
Speaker 1: all opposed to each other. CSS has nothing to do
Speaker 1: with programming being Honing your skills at CSS means that
Speaker 1: you have to give up honing your skills somewhere else,
Speaker 1: like in programming JavaScript. Honing your skills and your understanding
Speaker 1: of browser mechanics and eventful paints and uh, the dom
Speaker 1: APIs you know all that C plus plus context switching.
Speaker 1: You know that that's that's systems level programming and and
Speaker 1: and that's very different from application level programming. And so,
Speaker 1: you know, like front end developers are just being asked
Speaker 1: to do too much, and I think that's why they're failing.
Speaker 1: And asking them to then also be good at data
Speaker 1: transformations and etl. I just I think it's too much
Speaker 1: because they're already burdened. Either we need to split up
Speaker 1: and say you're a front end programmer and you're a
Speaker 1: front end designer, or your front end programmer and you're
Speaker 1: a front end uh layout manager or you know whatever,
Speaker 1: so that they can actually focus and become good at
Speaker 1: those areas of skill and really be excellent, or or
Speaker 1: we have to somehow provide something to reduce the complexity,
Speaker 1: which again I think is the allure of React, because
Speaker 1: it's kind of saying, Okay, we're going to take care
Speaker 1: of the CSS, and we're going to take care of
Speaker 1: the the the DOM life cycle, and we're going to
Speaker 1: take care of obscuring away that you know, the JavaScript
Speaker 1: for this this new the the r S R R
Speaker 1: S X now what jas X language, you know, So
Speaker 1: there's it just seems like there's a lot there, and
Speaker 1: I'm very I want it to happen. I'm just very skeptical.
Speaker 1: Show me the path. How do we how do we
Speaker 1: add more data manipulation on someone's plate and make their
Speaker 1: life simpler.
Speaker 3: So what I think is really going to happen is
Speaker 3: the providers that are currently in this the local first space,
Speaker 3: that are trying to push for uh these synchronization engines
Speaker 3: and these these rather sophisticated uh CRDT mechanisms for you know,
Speaker 3: there's there's actually a lot more to It's not simply
Speaker 3: you know, last change winds. There's a whole lot of
Speaker 3: complexity about merging change, the live changing system across device
Speaker 3: and all of that, and there's a lot of different
Speaker 3: trade offs that are being made. And so the people
Speaker 3: that are designing those engines are starting, at least from
Speaker 3: what I can see, I'm talking about things like replicash
Speaker 3: and a few others that are out there. So there's
Speaker 3: some things that you can google. There's a number of
Speaker 3: solutions out there in the local first space and what
Speaker 3: they what many of them that I've talked to or
Speaker 3: heard from are saying is we do actually have quite
Speaker 3: a bit of industry experience around building the back end
Speaker 3: logic that knows how to talk to rms that are
Speaker 3: backed by relational databases. So if we can build the
Speaker 3: replication logic and the the merging logic into those types
Speaker 3: of abstractions, we don't have to get people to learn
Speaker 3: an entirely new way of programming that type of what
Speaker 3: we would call back end logic. And I'm actually I'm
Speaker 3: using the air quotes around back end because I'm going
Speaker 3: to self service myself here for a minute and call
Speaker 3: back to a term that I invented back in two
Speaker 3: thousand and nine and twenty ten called middle end. What
Speaker 3: sits between the front end and the back end is
Speaker 3: the middle end. The way I originally conceived of the
Speaker 3: middle end was it was all the plumbing in the
Speaker 3: bottom ten percent of your front end application and all
Speaker 3: of the plumbing that was in the top ten percent
Speaker 3: on your server. And what makes those two things work
Speaker 3: together and talk together, whether that be templating or casing,
Speaker 3: or headers or session management or any of the data formatting, validation,
Speaker 3: all that stuff. That's what I call the middle end.
Speaker 3: But what I think is going to happen with local
Speaker 3: first is that there will in fact be a specialty.
Speaker 3: Whether we call it middle end and I get any
Speaker 3: credit for it remains to be seen, but I think
Speaker 3: there will be a specialty for the back of the
Speaker 3: front developer or the middle end developer who builds a
Speaker 3: significant portion of the back end of that application. They
Speaker 3: move it out of what they would traditionally host in
Speaker 3: a cloud server and they put it into the app,
Speaker 3: and they build it around these abstractions like being able
Speaker 3: to make relational database queries in an app. And even
Speaker 3: if that, you know, like you have a SEQL light
Speaker 3: in the in the client, because we can now do that,
Speaker 3: we can with the advent of WLASM, we can do
Speaker 3: all kinds of things, so we can literally have a
Speaker 3: seql light client in the app. And that's what a
Speaker 3: lot of these companies are doing is basically saying, let's
Speaker 3: layer an o RM on top of an actual database
Speaker 3: so that I'm writing data into a sequel light on
Speaker 3: the device, and I'm also replicating those those right changes
Speaker 3: in the data off to a relational, you know, database
Speaker 3: that may or may not be seqal light up in
Speaker 3: a cloud server, but they're using that ORM layer to
Speaker 3: do this. I think a lot of that complexity that
Speaker 3: you're worried about will be built around that. That's my prediction,
Speaker 3: and I think that there will be people who will
Speaker 3: really like that because they feel really comfortable in that,
Speaker 3: and now they'll be able to move a lot of
Speaker 3: those same skills into the back of the front or
Speaker 3: the middle end development in local first. I think there
Speaker 3: will be some people who will hate that and say
Speaker 3: SQL sucks and relational databases suck and we shouldn't use that.
Speaker 3: But that's why we're going to have lots of different options, right,
Speaker 3: So you may have a you know, a group of
Speaker 3: providers that choose to build that around relational databases, and
Speaker 3: others that are going to make something that's going to
Speaker 3: look a little bit more like graph ql, a little
Speaker 3: bit more free form. I think we'll see that and
Speaker 3: a half dozen others that I haven't conceived of yet.
Speaker 3: But I don't think you will ask app developers to
Speaker 3: start becoming experts on the deep academic theory around CRDT.
Speaker 3: I think that's what these providers are going to solve.
Speaker 3: They're getting close to solving, and they're working on hard
Speaker 3: trying to solve.
Speaker 2: So you touched on one issue there, and that's the
Speaker 2: term of the local data storage. You know, I think
Speaker 2: the default at least one I always here thrown around
Speaker 2: versus SQL light or rescue light, you know, because this
Speaker 2: tool that has been around forever very very easy to
Speaker 2: use to embed within an application and store local data.
Speaker 2: So my question is do you see tooling around other
Speaker 2: kinds of databases that can be used locally. So one
Speaker 2: that comes to mind is for a document database such
Speaker 2: as Mango dB. If somebody were to use that on
Speaker 2: the back end, I could see how that could be
Speaker 2: very difficult to convert between a sequl light structure on
Speaker 2: the local and then a Mango database on the back end.
Speaker 3: You know, I could probably wouldn't recommend that.
Speaker 2: I would not recommend it either considering how I work
Speaker 2: with the Mango every day. That would be hellish.
Speaker 3: So I'd say the things that I see right now
Speaker 3: in the client space are sequel Light and post Grace.
Speaker 3: There's a post Grace Light client that's been compiled a
Speaker 3: wows them. You can use the Postgrace SQL flavor if
Speaker 3: you like, or the seql Light seql flavor if you like,
Speaker 3: but those are the two major players for highly structured data.
Speaker 3: I would argue that if you need unstructured, non relational
Speaker 3: data storage, we already have that in the form of
Speaker 3: index dB and json objects and things like that. We
Speaker 3: don't need a Mango dbo RM on top of Jason
Speaker 3: objects if that, if you don't need the relational so
Speaker 3: I think the reason why we get big powerful engines
Speaker 3: like a sequel Light or post Grace Light being compiled
Speaker 3: to the browser is for all that relational stuff that's
Speaker 3: pretty hard for people to go and invent themselves. But
Speaker 3: if you're really talking about uh kind of document level
Speaker 3: storage stuff, there's already actually a pretty good and solid
Speaker 3: way of storing data. We have not only the index dB,
Speaker 3: but a lot of people don't realize we actually have
Speaker 3: fully cross browser the Origin Private File System, where you
Speaker 3: can create files and store arbitrary data and both. In truth,
Speaker 3: it is absolutely true. I've written a library around it,
Speaker 3: so it's absolutely true. I'm act check this, Okay, please
Speaker 3: do if you If you get both index dB and
Speaker 3: OPFs the Origin Private Final System, both of those have
Speaker 3: essentially up to about two thirds of the device's disc
Speaker 3: space that the browser makes available to them. So in
Speaker 3: the old days when we had like local storage and
Speaker 3: it was limited to five megabytes, and nobody could even
Speaker 3: imagine doing anything like, you know, like a real apps
Speaker 3: back end on those things. Now that we have index
Speaker 3: dB and OPFs, and both of them have very solid
Speaker 3: access to disk space, and I just we're going to
Speaker 3: see a big explosion of people building real data storage
Speaker 3: in the client as opposed to kind of stuffing some
Speaker 3: stuff in local storage the way it used to be.
Speaker 3: And I think a lot of people are not didn't
Speaker 3: realize that that happened. But OPFs is absolutely already happened.
Speaker 3: There's there are complexities around it, but you can work
Speaker 3: around those with libraries, which again that's that's what I've worked.
Speaker 2: So let's touch on index dB real quick, just by
Speaker 2: way of explanation, since I always like to or don't
Speaker 2: like to assume that everybody knows when we're talking about
Speaker 2: a tool. So you know, just looking at the u
Speaker 2: NDM page on index it sounds like it is now
Speaker 2: is the actual storage the files is that in the
Speaker 2: browser or just stashed locally on your OS somewhere on
Speaker 2: your device.
Speaker 3: So index dB, again fully cross browser has been around
Speaker 3: for you know, almost ten or fifteen years now, so
Speaker 3: it's it's definitely a reliable system. It's not new like OPFs,
Speaker 3: it's been around for a long long time. So index
Speaker 3: dB is kind of like back in the day, we
Speaker 3: had both index dB and we had web sql. They
Speaker 3: were both trying to vie for the structured data storage
Speaker 3: in the client model. Index dB has a whole bunch
Speaker 3: of complexity around it, and web sql was like this
Speaker 3: higher level, you know, SQL light type of interface, and
Speaker 3: a lot of people said, I don't I don't really
Speaker 3: like the indexdb. So there was this favoring of web
Speaker 3: sql in the early days, but there were some browsers
Speaker 3: that basically said, we're absolutely not going to ever do
Speaker 3: a web sql like Firefox, We're not doing web sql,
Speaker 3: We're only doing index dB. And so whether it was
Speaker 3: the better of the two options is kind of irrelevant
Speaker 3: because Browser's just sort of decided for us that the
Speaker 3: thing that we got was index dB, and everybody then
Speaker 3: agreed and just did it. Now. Indexdb again pretty low
Speaker 3: level API, a lot of complexity around, you know, transactions
Speaker 3: and other things like that. I don't even use index
Speaker 3: dB in that sense. There's a library called index dB keyval,
Speaker 3: IDB DASH keyval that creates a literal key value storage
Speaker 3: abstraction on top of Indexdbuh. It's got millions of downloads,
Speaker 3: it's it's hugely popular. Earlier, I've never dealt with indexdb
Speaker 3: other than to use that library, so I look at
Speaker 3: indexdb as a really powerful key value store.
Speaker 1: Do you know how it compares to local Forage.
Speaker 3: I do know some of the history behind local Forage,
Speaker 3: but the most important thing to point out about Local
Speaker 3: Forage is that, as far as I'm aware, it's no
Speaker 3: longer maintained, IDB q val is actually actively maintained. It's
Speaker 3: Jake Archibald that built that library. It's an actively maintained
Speaker 3: library and still gets a lot of usage. Friend, local
Speaker 3: Forage hasn't hasn't been maintained for quite a while, I think.
Speaker 1: So, Okay, yeah, I've noticed that there's some Yeah, there's
Speaker 1: some issues there. Okay, I'll have to to try this
Speaker 1: out next time.
Speaker 3: So in any case, that that that explains what index
Speaker 3: dB is been around a long time, stabilized, and there
Speaker 3: are a variety of libraries Local Forage, IDB, KVAL and
Speaker 3: others that make working with index dB not as painful
Speaker 3: as its native API is. A lot of people use
Speaker 3: index DV for that, and I would I would make
Speaker 3: the case that index dB should be the default client
Speaker 3: data storage over local storage, not only because it has
Speaker 3: larger disk space access, but also because nxdb can actually
Speaker 3: be accessed from workers and done asynchronously, where local storage
Speaker 3: and session storage cannot be accessed from worker thronts, So
Speaker 3: that makes it a more flexible data storage.
Speaker 1: Now with OPFs, the og I got to fact check you. Okay,
Speaker 1: I do not see baseline support for OPFs. Okay.
Speaker 3: So there's a lot of complexity around OPFs. There's a
Speaker 3: narrow layer that we're drawing here. OPFs has a variety
Speaker 3: of ways that people can envision using it. I'm going
Speaker 3: to talk about it in ways where you want to
Speaker 3: access existing files on the user's system, like something off
Speaker 3: of their desktop. There's that usage of OPFs, and that
Speaker 3: does not have baseline support. It might not ever because
Speaker 3: there's still a lot of security considerations around it. But
Speaker 3: there's the Virtual Private file System of OPFs, which is
Speaker 3: a reserved area of disk space that you can read
Speaker 3: and write files into and its origin locked. That actually
Speaker 3: got much more widespread consensus among the browser vendors, but
Speaker 3: there was performance concerns around it. So people wanted an
Speaker 3: OPFs interface where they could do easy kind of synchronous
Speaker 3: reads and writes from it, and there were performance concerns
Speaker 3: about you can't do synchronous reads and writes on the
Speaker 3: main thread because that could block things and whatever, and
Speaker 3: so what we got was this bifurcation where there was
Speaker 3: an asynchronous API that you could use from the main thread,
Speaker 3: and that one also has not yet achieved this sort
Speaker 3: of baseline parody because notably Safari does not support that
Speaker 3: main thread asynchronous API. However, all of the browsers did
Speaker 3: implement the synchronous read and write from workers, willing to
Speaker 3: take on the complexity of burying your storage logic inside
Speaker 3: of a worker. You actually can do OPFs with synchronous
Speaker 3: reads and rites across all the major browsers. I would
Speaker 3: argue that is actually baseline in that subset.
Speaker 1: That's well, I mean, we can see if it's baseline,
Speaker 1: because it'll have the sticker baseline on it on MDN
Speaker 1: and the other sites that that catalog these.
Speaker 3: I'm just saying that it's there's the nuance and complexity
Speaker 3: may or may not be captured there in the way
Speaker 3: that they're messaging this, which is whether or not you're
Speaker 3: using the asynchronous API or whether you're relying upon the
Speaker 3: synchronous API and doing it in a worker. This narrow
Speaker 3: do it with synchronous APIs in a worker is actually
Speaker 3: something I've tested. It. It works on all these mobile
Speaker 3: devices and desktop browsers, so that.
Speaker 1: I think super interesting. Will you drop we? Okay?
Speaker 3: Agreed?
Speaker 1: Agreed, because the baseline is pretty broad. Baseline typically applies
Speaker 1: to the entire specification, except in the case of past key,
Speaker 1: where it only applies to one item in half of
Speaker 1: the options. You and I have both had fun with
Speaker 1: that one.
Speaker 3: Yes we have.
Speaker 1: Yeah, yeah, so yeah, drop a link to some resource
Speaker 1: for that, please, because just so, what I'll do is
Speaker 1: like comments.
Speaker 3: What I'm going to do is actually drop a link.
Speaker 3: I've referred to this a couple of times, but I'm
Speaker 3: going to drop a link to a library that I
Speaker 3: recently wrote, which tries to abstract client side storage. Gives
Speaker 3: you a key value abstraction across all five of the
Speaker 3: major client storage mechanisms. There's cookies, which people don't often
Speaker 3: think of as client storage, but you can actually read
Speaker 3: and write keyvaals and cookies. There's local storage and session storage.
Speaker 3: There's index dB, and there's OPFs, and that library supports
Speaker 3: both the OPFs in the main thread, but then you know,
Speaker 3: it doesn't support all browsers, or there's also the worker
Speaker 3: version of that which does work in more browsers. You
Speaker 3: just have to be willing to do the you know,
Speaker 3: some of the reasons why people don't like worker based
Speaker 3: logic is because it can it can make more complex
Speaker 3: your security headers, like your CSP policy on a site
Speaker 3: or things like that. You have to be a little
Speaker 3: more careful. But if you're willing to go down that route,
Speaker 3: you can use OPFs in all of the major the
Speaker 3: stable versions of all the major browsers and devices today.
Speaker 3: And so I'll drop a link to the storage library
Speaker 3: that I wrote that tries to just give you a
Speaker 3: very easy, consistent key value abstraction across all of those.
Speaker 3: So my understanding is the way that that works in
Speaker 3: practice is that you create a main thread API that
Speaker 3: resembles closely the worker thread API. It transforms data into
Speaker 3: a buffer and then sends it as a shared buffer
Speaker 3: object across the worker thread, and then the worker thread
Speaker 3: sends it back as a shared buffer object, and then
Speaker 3: it gets re encoded. That is that the basic cycle
Speaker 3: of that. So sharing data between workers is actually a
Speaker 3: bit of a complex thing, and it's unfortunate that it
Speaker 3: is so complex. But sharing data between workers can either
Speaker 3: be serializing to a string and sending that string of
Speaker 3: data across the inner process channel, or this newer standard
Speaker 3: of these transferable objects transferable objects. It's a more complex
Speaker 3: programming paradigm, but it is effectively that you use stuff
Speaker 3: some data in a type deray, and then you tell
Speaker 3: the browser I'm relinquishing control of this type deray to
Speaker 3: a thread and I can no longer read from it
Speaker 3: while that thread has control of the type deray, and
Speaker 3: then the thread now instantly has access with zero copy
Speaker 3: to that same shared memory, can read from that type
Speaker 3: deray the literal binary data from it, can read the
Speaker 3: bits from that, do whatever it wants right back to it,
Speaker 3: and then relinquish control back to the main thread. That's
Speaker 3: what transferable like, being able to transfer things. Most people
Speaker 3: don't go that route unless they have massive amounts of
Speaker 3: data that they're trying to send, and by massive I
Speaker 3: mean like one hundred megabytes for more. Most people, Yeah,
Speaker 3: I think when they're sending data back and forth are
Speaker 3: just serializing to Jason and sending it across.
Speaker 1: I think that PAPA parse was maybe the first widely known,
Speaker 1: popular library that took advantage of these tricks because it
Speaker 1: supposed to be able to handle you know, gigabyte CSV files.
Speaker 3: Mm hm, I don't know.
Speaker 1: Do you know of anything else that's in that vein
Speaker 1: because that that's my experience with worker threads is pretty
Speaker 1: much PAPA parse and a couple of failed experiments.
Speaker 3: I don't know Papa parts. I haven't used that one.
Speaker 3: I don't think I've ever used any worker libraries. I've
Speaker 3: always just used the you know, the direct work or
Speaker 3: interface that we get in the browser. So I don't
Speaker 3: have any specific recommendations to make around there. But like
Speaker 3: this this library that I'm you know, posting this this
Speaker 3: link to, you could look at that code. It's only
Speaker 3: like a couple dozen lines of code. You could look
Speaker 3: at the code of how I'm managing those workers, and
Speaker 3: you could very easily write an adaptation of that that
Speaker 3: instead of sending the data across in Jason did so
Speaker 3: with a more sophisticated, you know, transferable or you know,
Speaker 3: bury it in a binary array and a typed array
Speaker 3: and do a transferred object kind of thing. You could
Speaker 3: do that. It wouldn't be that hard, all.
Speaker 1: Right, Cool, So I forget the track that we were on.
Speaker 1: I actually, since I forgot anyway, I actually want to
Speaker 1: go back a little bit. And we've we've thrown around
Speaker 1: some terms that it seems like recently, I'm I'm. What
Speaker 1: I'm picking up is that people are using these terms
Speaker 1: in different ways, and so that's like huge step back.
Speaker 1: Let's define cloud, because cloud meant I have a VPS
Speaker 1: on Lenode. That's what cloud meant. What does cloud mean now?
Speaker 3: I mean cloud basically means now that you're using a
Speaker 3: managed hosting solution with built in scaleability. So you're using
Speaker 3: something like AWS or Google Cloud Platform or maybe Azure
Speaker 3: for Microsoft, using one of those big cloud providers, and
Speaker 3: you're basically allowing those managed services to do all of
Speaker 3: the provisioning, the spinning up and down of your servers.
Speaker 3: You're not really doing a lot of that manually, although
Speaker 3: you could, you know, you know, AWS as a dashboard,
Speaker 3: you could go in and take down a server or
Speaker 3: put up a new one if you want it. But
Speaker 3: you're basically creating these these policies so that it's managing
Speaker 3: your your scale and your growth for you. I don't
Speaker 3: have any more understanding of cloud than what I just
Speaker 3: said that is the sum total knowledge, because I never
Speaker 3: got into that space. There's probably listeners here who would
Speaker 3: have a very different and much more detailed view of
Speaker 3: the cloud. But what I understand the cloud because I
Speaker 3: have a VM online line ode right, and I don't
Speaker 3: call that the cloud. I'm paying for a virtual machine,
Speaker 3: but I do all of my own management, and there's
Speaker 3: no built in scalability where I get a new VM
Speaker 3: just because I get you know, slash dot it or
Speaker 3: at the homepage of Reddit or something. I have to
Speaker 3: manage all of that stuff. So I don't call that
Speaker 3: the cloud because they're not really doing anything for me.
Speaker 3: I'm just renting a bit of memory and CPU cycles
Speaker 3: from them.
Speaker 1: So low cloud VPS, middle cloud auto scaling. But then
Speaker 1: there's high cloud, which is serveralus functions.
Speaker 3: Sure, yeah, cloud Flare with you know, with their durable objects,
Speaker 3: and we've got you know, functions as the fast functions
Speaker 3: as the service and AWS Lambda and all of that stuff.
Speaker 3: That would be Yeah, I think that's fair to call
Speaker 3: that a higher abstraction of cloud.
Speaker 1: Because right now on Twitter, right now, it seems like
Speaker 1: whenever people are saying cloud in references, particularly to all
Speaker 1: this DHA stuff, they actually specifically mean functions. They don't
Speaker 1: mean the auto scaling, they don't mean like they are
Speaker 1: strictly it seems like they are strictly talking about just functions.
Speaker 1: And that was confusing to me because, like I said,
Speaker 1: I while I've heard the term cloud, it's gone from
Speaker 1: meaning I don't host the server in the closet at
Speaker 1: the office, I co locate it, or I use just
Speaker 1: a portion vert via VM, to now it means like
Speaker 1: it basically, it seems like it means anything that marketers
Speaker 1: wanted to mean at the moment.
Speaker 3: And public I think it's important at each other. I
Speaker 3: think it's important to note there. I think there's a
Speaker 3: very important distinction between a VM that I am responsible
Speaker 3: with the root login to manage and turn take down
Speaker 3: and to reboot and upgrade and all of that stuff,
Speaker 3: versus a fully managed service where I don't even know
Speaker 3: what my VM is. I've just given you like Docker images,
Speaker 3: and I've said, please just go spin up whatever servers
Speaker 3: I need out of that stuff. Those are very different
Speaker 3: system that men thought processes, and they take very different
Speaker 3: skill sets. So I think there's a distinction there to
Speaker 3: be made, and I would call the ladder of those
Speaker 3: cloud versus you use the term co locate. I mean
Speaker 3: I was doing that back in ninety seven in college.
Speaker 3: I was running a server in my apartment in college,
Speaker 3: and then I remember the day that I was like, yeah,
Speaker 3: I can't do this anymore, and I went and bought
Speaker 3: a one U server and stuck my hardware in a
Speaker 3: data center somewhere that certainly was not the cloud, because
Speaker 3: I was still completely responsible for that server. They just
Speaker 3: gave me a power plug and an Ethernet plug, all right.
Speaker 1: So, uh then onto onto the next thing, well, the
Speaker 1: kind of two things maybe. So I want to know
Speaker 1: where I want to know what is the alternative because
Speaker 1: we talked about, okay, people are going to have this
Speaker 1: data locally, and uh, I agree, there's some efficiencies there.
Speaker 1: There's also some inefficiencies, especially on Android devices due to
Speaker 1: the single core uh speed and and Jason parsing from
Speaker 1: local storage or index dB actually becomes significant a lot
Speaker 1: quicker than most people would think.
Speaker 3: Uh.
Speaker 1: But like there's there's a potential, there's certainly bandwidth savings.
Speaker 1: There's definitely potential performance savings, although a lot of the
Speaker 1: critics of that have you know, I believe that a
Speaker 1: lot of their points are valid. But like you were saying,
Speaker 1: it's like, what layer are you viewing at this? If
Speaker 1: it's if it's time to first contentful paint, but the
Speaker 1: person still can't click a button, well, then you're just
Speaker 1: lying to the user. You didn't actually do anything better.
Speaker 1: And then, so what is the alternative to the cloud
Speaker 1: in terms of how the data is going to work?
Speaker 1: It doesn't seem like web RTC is really there yet,
Speaker 1: But what's the alternative? And then what are the places?
Speaker 1: How do we distinguish between the places where local first
Speaker 1: makes sense and local first doesn't make sense because it
Speaker 1: sounds like to me, Amazon or Walmart search would never
Speaker 1: make sense. Bank access and email access seems like that
Speaker 1: would always make sense, and Twitter would be somewhere in between.
Speaker 1: So you give me your take, and that you know,
Speaker 1: given that context, these are.
Speaker 3: Fair questions, and I'll I'll acknowledge that lots of different
Speaker 3: perspectives are going to exist on this, So I'm only
Speaker 3: giving my one little slice of perspective. But I actually
Speaker 3: do think that probably the lion's share of applications should
Speaker 3: move local first. And I personally feel that way because
Speaker 3: not only do we have the description, you know, the
Speaker 3: discussion that we had earlier about the business model and
Speaker 3: whether users can monetize and whether there's like a business
Speaker 3: justification for local first. That's part of the equation. That's
Speaker 3: not what brought me to local first. What brought me
Speaker 3: to local first was actually a personal convection around the
Speaker 3: importance of the autonomy of users owning their own identity,
Speaker 3: taking that with them wherever they go, and owning their data.
Speaker 3: I make the assertion in a couple of different meetups
Speaker 3: and conference talks recently that data that you don't physically
Speaker 3: control is data that you don't own. In other words,
Speaker 3: custody of data is the whole game. If I have
Speaker 3: data that theoretically is mine, but it's actually physically in
Speaker 3: the custody of a cloud server that's behind some business
Speaker 3: model of a company that I don't own and control,
Speaker 3: then that's no longer my day. I'm renting that data back,
Speaker 3: and I believe that's the ransom.
Speaker 1: That's why they give you the first ten years for free.
Speaker 3: Exactly. They get you hooked, just like any good drug
Speaker 3: dealer does. I genuinely believe that most of the Web
Speaker 3: needs to move to a model where users have that
Speaker 3: autonomy over their identity and over their data, and I
Speaker 3: believe that local first is the only compelling model for
Speaker 3: us moving in that direction right now. Are their challenges
Speaker 3: with local first? Of course? Is it so nascent that
Speaker 3: it's unlikely to win? I mean, I think we have
Speaker 3: to concede that most challenges to the status quo of
Speaker 3: billion dollar businesses don't win. I think we have to
Speaker 3: concede that we've had a whole other sphere, which we're
Speaker 3: not even talking about here. We've had this Web three
Speaker 3: crypto movement that for fifteen years has been saying we're
Speaker 3: the answer to that. I actually worked at a Web
Speaker 3: three company for a while, and they've said we're the
Speaker 3: answer to all of that centralization and give everybody their stuff.
Speaker 3: I worked for a Web three company and for that
Speaker 3: six months was like continually confronted by how easy it
Speaker 3: was for people in that space to just grin and
Speaker 3: blink away. The big gap between the way the web
Speaker 3: is currently built and the way users currently experience that
Speaker 3: and what Web three is. And so I left there thinking,
Speaker 3: I don't know if we're ever going to get to
Speaker 3: Web three, but if we're ever going to get anywhere forward,
Speaker 3: we need to evolve the web. And I started calling
Speaker 3: it web two point five, where the web goes to
Speaker 3: more of a users own their data, users own their identity,
Speaker 3: the experiences are more installed rather than accessed on every round,
Speaker 3: Like you know, every time you go to a web page,
Speaker 3: you're effectively reinstalling that web app. And that's bonkers because
Speaker 3: we wouldn't treat native AP apps that way, where every
Speaker 3: single time we opened up or clicked a button in
Speaker 3: an app, we re downloaded the whole app or even
Speaker 3: part of the app.
Speaker 1: But this is this is the allure of React, right,
Speaker 1: this is this is the same problem like the state
Speaker 1: management's hard, the upgrade path is hard, Diffing the data
Speaker 1: is hard. We're just going to redo the whole thing
Speaker 1: from top to bottom.
Speaker 3: I don't so. First of all, I don't think we're
Speaker 3: redoing the whole thing, because if you build local first
Speaker 3: apps with web technology, you can build.
Speaker 1: What I meant re rendering, reloading.
Speaker 3: But oh well, that's that's I We could do multiple
Speaker 3: episodes on whether or not the virtual Dawn was a
Speaker 3: good thing for for us or whether it really took us.
Speaker 3: You know, I think it was very much a let's
Speaker 3: climb a local Maxima hill and we got to the
Speaker 3: very top of that local maximam hill and then we're like, oh,
Speaker 3: this sucks. This isn't the right hill to climb. But
Speaker 3: that's you know, that's my personal take on on the
Speaker 3: virtual dom and dom diffing and all of you know,
Speaker 3: rerender every you know, fifteen MILLI.
Speaker 1: But the basic concept what I'm saying is the basic
Speaker 1: concept is state is hard. Let's not do it. That
Speaker 1: was the allure. State is hard, Let's not do it.
Speaker 1: We're going to render the whole thing so we don't
Speaker 1: have to keep track of individual state. We don't need
Speaker 1: to know.
Speaker 3: There's no app button, there's no app in existence that
Speaker 3: is using react, that is not doing sophisticated state management
Speaker 3: alongside it. So I know, I know that doesn't exist.
Speaker 1: We's pardon your French, Sorry, No, I'm I'm there with you.
Speaker 1: I'm just saying that that's the allure, and there is
Speaker 1: something to that, Like I think I've taken a look
Speaker 1: at swift UI and I think Android jetpack is the
Speaker 1: same and swift U. I when I hear if I
Speaker 1: close my eyes and I listen to the conference talk,
Speaker 1: I hear react react, react, react, But when I open
Speaker 1: my eyes, I see something that it's like this looks
Speaker 1: like this looks like it actually solves the problem, which
Speaker 1: is like really surprising because I was, like, I abhorred
Speaker 1: reacts so much. But swift Ui is something that's really
Speaker 1: intriguing to me. How can these two things be And
Speaker 1: I don't know. There's like there's the promise, there's what's
Speaker 1: on the conference side, and then there's the implementation. And
Speaker 1: I think when you look at something like swift Ui,
Speaker 1: it's the same promise. But I think they might have
Speaker 1: the implementation right. I don't have enough experience with it
Speaker 1: to say, but I think they might.
Speaker 3: The thing I would point out is that the only
Speaker 3: thing that's really significant in the front end development space
Speaker 3: over the last couple of years that is somewhat antithetical
Speaker 3: to the local first movement is the move to server
Speaker 3: side rendering of components and that whole complexity, all the
Speaker 3: other things that and and and, as I argued earlier,
Speaker 3: they only did that because they keep trying to chase
Speaker 3: this ethical zero millisecond reinstall experience that that product managers
Speaker 3: and people have just sold as a reality that isn't.
Speaker 3: They're trying to get closer and closer to pretending as
Speaker 3: if the app can reside in both places at the
Speaker 3: exact same time and there's no cost over the wire.
Speaker 3: If you didn't ever start with that as your goal,
Speaker 3: which I never did, then you wouldn't have ever gone
Speaker 3: down the road of trying to do server side component
Speaker 3: rendering and all of that stuff. That wouldn't have been
Speaker 3: the way you tried to fix it, and local first
Speaker 3: fixes it in different ways that I think are much
Speaker 3: less complex. And so that's really the only thing that's
Speaker 3: happened in the last few years of development that you
Speaker 3: might have to abandon. If you really wanted to embrace
Speaker 3: local first, you would have to kind of get away
Speaker 3: from that server side component way of thinking that people
Speaker 3: are starting to get excited about and enjoy. But all
Speaker 3: of the other things that you could bring. You could
Speaker 3: bring a straight up React fifteen virtual dom application straight
Speaker 3: to local first. You can do what I do, which
Speaker 3: I didn't even use the front end frameworks. I use
Speaker 3: templating and I'm super old school, but I use mustache
Speaker 3: templates and you can do that. You can use reactive
Speaker 3: things like view you know, and their signals in spell.
Speaker 3: You can do any of those things for local first development.
Speaker 3: The only thing you can't do is offload significant amounts
Speaker 3: of your front end logic to a back end, because
Speaker 3: you really need to stick that back end on the
Speaker 3: client to embrace what local first is about.
Speaker 1: Okay, so this here, I just just bounce an idea
Speaker 1: the promise, the promise of graphql but delivered as a
Speaker 1: local API, because the allure of graphql was graphql is
Speaker 1: going to handle the data manipulation for you. Graphql and
Speaker 1: I think that the data, the ETL, the extract, transform load,
Speaker 1: the sinking of day, the transforming logic. I believe that
Speaker 1: that is classically a back end task. We could call
Speaker 1: it the middle end. And I'm one hundred percent on
Speaker 1: board with your classification of the middle end. There's like
Speaker 1: the core API, the JSON where things kiss. That's the
Speaker 1: middle end and that and that's where that's the problem
Speaker 1: the graph Ql was kind of trying to solve. If
Speaker 1: you if you move graph QL's complexity to the middle
Speaker 1: end and you give people that are purely on the
Speaker 1: front end the the autocomplete of graph ql with local storage.
Speaker 1: I think I think maybe it wins.
Speaker 3: Yeah, I'm I think you should go be a marketing
Speaker 3: consultant for a number of the players in the space,
Speaker 3: because that sounds very much like how they're trying to
Speaker 3: sell this. They know that there's a significant pleasurable desired
Speaker 3: DX around those types of models, and they're saying we
Speaker 3: can repurpose those models and back them with much more
Speaker 3: sophisticated things like a CRDT that's syncing out to a
Speaker 3: cloud server or whatever.
Speaker 1: Okay, well, yeah, give me their contact information. I'll see
Speaker 1: what I can do. But yeah, I think graph kel
Speaker 1: was always going to fail because it was solving the
Speaker 1: problem fundamentally in the wrong way. It's saying, we're going
Speaker 1: to reduce your data load by making more round trips
Speaker 1: to the server all the time. If they had inverted that,
Speaker 1: we're going to reduce your data load by doing large
Speaker 1: batch fetches from the server and then updating ad hoc
Speaker 1: when data is stale and giving you the same API
Speaker 1: that graph ql gives you. That I think could have
Speaker 1: been a winning strategy, and that that's really I think
Speaker 1: that's compelling because I look at graph l, I look
Speaker 1: at the promise of it, I look at those autocomplete
Speaker 1: tools and think, man, I love it. I absolutely love it.
Speaker 1: I just yeah, how do we? How do we? Maybe
Speaker 1: maybe that could be the the poisoned apple or you know,
Speaker 1: uh wrong term, but you know that the hook the addicts.
Speaker 3: Thing, right. I think there's a tremendous amount of potential here,
Speaker 3: and I just I want to re emphasize that local
Speaker 3: first software development is, and especially local first web software
Speaker 3: development is really just saying, let's take all the things
Speaker 3: that we currently assume can only happen on a server
Speaker 3: and ask how much of that could actually happen on
Speaker 3: the client device. It's not saying if you like this framework,
Speaker 3: you just have to give up because you've got no place.
Speaker 3: In fact, it's saying the opposite. Bring whatever uh application
Speaker 3: building techniques you have, but but build more of those
Speaker 3: things into the client experience. The thicker client, to borrow
Speaker 3: a term from the nineties, Build thicker clients that have
Speaker 3: more of that stuff built in, and stop assuming that
Speaker 3: the only place for data is up in a cloud server.
Speaker 3: There's lots of other ways. And you asked you asked
Speaker 3: earlier about like how do we you know is webs
Speaker 3: is is web RTC or web sockets or whatever, like
Speaker 3: how are we how are we gonna have apps?
Speaker 1: Yeah?
Speaker 3: How are we gonna have these client apps talking to
Speaker 3: each other? So we do. We do definitely have web ertc.
Speaker 3: The nice thing is that it's been around for a
Speaker 3: long time. There's a lot of abstractions. The bad news
Speaker 3: is that webertc never achieved its goal of zero server signaling.
Speaker 3: It's zero server after the signaling, but it still requires
Speaker 3: servers that can be quite expensive and quite uh single
Speaker 3: point of failure for the signaling aspects because of all
Speaker 3: the complexities of not traversial and stuff like that.
Speaker 1: Just give it to you for free, though, I mean,
Speaker 1: don't you just get to use Google's Chrome Chrome? So
Speaker 1: if you're using Chrome, if it's in Chrome, if you
Speaker 1: get that for free?
Speaker 3: Right? Not really? So there's two without getting too much
Speaker 3: into the rabbit hole, there's two standards. There's stun in turn.
Speaker 3: One is used for the signaling, but one is used
Speaker 3: for media. Really, which is what most people are trying
Speaker 3: to do with ROBERTC is do media relay kind of
Speaker 3: like the call that we're having here. They're trying to
Speaker 3: do media relay, and media relay is absolutely not free
Speaker 3: because it's very expensive to the provider. So the I
Speaker 3: believe it's turn servers or the media relay I might
Speaker 3: have that backwards. It's stun in turn. But whichever one
Speaker 3: of those is the media relay servers, there are not
Speaker 3: free ones. There are companies that you can pay for,
Speaker 3: but it's you know, hundreds of dollars a month to
Speaker 3: pay for a scaled out media relay server. Anyway, So
Speaker 3: weber TC if we thought about it as one standard,
Speaker 3: I think it's actually a really good API. But this
Speaker 3: signaling problem is kind of the fly and the oightment
Speaker 3: or the poisoned apple to borrow the term from you
Speaker 3: from just a minute ago. But there are wrong There
Speaker 3: are options for fixing the signaling issue. One of those
Speaker 3: options is if you move from purely web into hybrid apps,
Speaker 3: if you use those native wrappers with web views, things
Speaker 3: like towry, things like electron, things like socket supply. These
Speaker 3: these hybrid the old days it was like phone gap
Speaker 3: and ionic and stuff. There's there's dozens of them, but
Speaker 3: those native apps have the potential to kind of break
Speaker 3: outside of the current restraints of the web and give
Speaker 3: you true peer to peer communications through networking protocols. And
Speaker 3: so there are multiple options there for a web app
Speaker 3: to be given a slightly extra superpower, which is let
Speaker 3: you communicate. There's also potentially, I really hope this happens,
Speaker 3: there's a there's a working group working on a standard
Speaker 3: for peer to peer local peer to peer communications which
Speaker 3: would be able to tunnel between my two devices using
Speaker 3: things like Bluetooth or local wife, which is a standard
Speaker 3: that Android and iOS put together. So there are web
Speaker 3: standards that maybe hopefully land someday that are going to
Speaker 3: let us let our web apps talk directly peer to peer,
Speaker 3: even without those native wrappers around them. But I do
Speaker 3: think that that will for people that decide to go
Speaker 3: that route. That's not local first, that's kind of beyond
Speaker 3: local first. But when you go beyond local first to
Speaker 3: trying to get closer to a peer to peer architecture
Speaker 3: of an app, that's where you see the true benefit
Speaker 3: of potentially shutting down your cloud server entirely and for
Speaker 3: closing on your entire cloud bill, because most of what
Speaker 3: you need to communicate with can actually tunnel over these
Speaker 3: peer to peer networks, and so I think that's a
Speaker 3: little bit further out from local first, but I think
Speaker 3: it's a step along the way. I think local first,
Speaker 3: and then that will come after that.
Speaker 1: But then, how do you get people if you can't
Speaker 1: ransom the data? How do you get people to pay?
Speaker 1: How do you turn? How do you turn from users
Speaker 1: to customers?
Speaker 3: I'm used about this on my Twitter account a while back,
Speaker 3: like that, are there any business models that are compelling
Speaker 3: that are not based upon we hold you ransom? And
Speaker 3: we brought up thirty seven signals. They are basically saying,
Speaker 3: we're a successful business that is doing exactly that. You
Speaker 3: pay a one time fee you license our software. It's
Speaker 3: all your software, and it's all your data, and you
Speaker 3: don't have to keep paying us a subscribe, a subscription
Speaker 3: ransom fee. You have to be willing to think about
Speaker 3: your business model potentially the way that we used to
Speaker 3: think about business models, which is not how do I
Speaker 3: capture as much possible value from every single user as
Speaker 3: humanly you know you can imagine versus how do I
Speaker 3: capture enough value that my business is viable and growing.
Speaker 3: You have to somewhat restrain the greed when you design
Speaker 3: business models that way.
Speaker 1: I don't know that it's greed as much as it's hype.
Speaker 1: And you need money. You need a lot of money,
Speaker 1: you need a lot of time. So if you want
Speaker 1: to get the money, you got to get the investment.
Speaker 1: If you get the investment, you have to offer almost
Speaker 1: everything for free because you need the drug. And if
Speaker 1: you offer everything almost for free, then you'll never make
Speaker 1: that money back in a one time payment because the
Speaker 1: cost is too high. The investor won't get their return.
Speaker 1: So you have to make it a subscription. I mean,
Speaker 1: even when you look at the companies, the profitable companies Microsoft, Apple,
Speaker 1: they're actually profitable and they're turning into subscription models because
Speaker 1: it's the only way to grow. There's no growth opportunity left.
Speaker 1: Word to capture the planet.
Speaker 3: I don't agree that it's the only way to grow.
Speaker 3: I agree that it is currently the most popular and
Speaker 3: compelling way to grow. So how do you grow?
Speaker 1: I don't captured everyone on the planet.
Speaker 3: What's that?
Speaker 1: How do you grow once you've captured everyone on the planet,
Speaker 1: other than subdividing your services and turn them into subscriptions,
Speaker 1: Because the only way you can't multiply, Like there's ten
Speaker 1: billion people. You've caught all ten billion people, all ten
Speaker 1: billion people have bought your product or use your service.
Speaker 1: That can Facebook, Apple, whatever. How do you convert them?
Speaker 1: It's either ads or it's subscriptions, because subscriptions you can
Speaker 1: give them. Well, you know, we told you this was
Speaker 1: the pro tier, but actually now there's the ultratier. We
Speaker 1: told you was the ultratier, but four K is actually
Speaker 1: moving to the Ultra plus tier.
Speaker 3: Well, you know, I'm not going to answer. I'm not
Speaker 3: going to give a very satisfying answer here, but it's
Speaker 3: the best one I think we can fit into this
Speaker 3: particular podcast episode, which is that's part of why the
Speaker 3: Web three folks are saying, hey, pay attention to us,
Speaker 3: because we have tried to come up with a decentralized
Speaker 3: mechanism for monetization. I'm not here to shill for Web three. Yeah,
Speaker 3: I know there might very well be useful ideas where
Speaker 3: you know, I'm just going to give a crazy little example.
Speaker 3: Let's imagine that I've built a calendar app, kind of
Speaker 3: like what you know, thirty seven signals did they build
Speaker 3: a calendaring app. I build a calendar app, and I
Speaker 3: sell it for ten bucks and I let you run
Speaker 3: all your own data. You can host it wherever you
Speaker 3: want on a three dollars VM or whatever, and I
Speaker 3: don't charge any subscription fee. But then let's imagine that
Speaker 3: I come up with some really compelling cool thing, like
Speaker 3: an AI summary of a calendar or something. I'm just
Speaker 3: making something up. Well, I can deploy services out there
Speaker 3: on the peer to peer web that, say, you can
Speaker 3: choose on a per calendar event basis to opt into this,
Speaker 3: and it's going to cost the equivalent of a dollar
Speaker 3: of cryptocurrency transaction for you to have that data that
Speaker 3: you send from your calendar send into this black box,
Speaker 3: and then this smart contract sends you back your AI
Speaker 3: summarized data or whatever. I'm just like, I'm literally making
Speaker 3: something up on the fly. But I can monetize that way.
Speaker 3: I could create services out there that people can choose
Speaker 3: to use on an OLI cart basis. And if I
Speaker 3: make those services is compelling enough and I make it
Speaker 3: easy enough for people to pay for I think you
Speaker 3: can grow without locking people into subscriptions. But I do
Speaker 3: concede that the vast majority of the world, and basically
Speaker 3: every investor in the world, is only interested right now
Speaker 3: in the subscription based business models.
Speaker 1: Yeah, and I just to touch on the Web three thing.
Speaker 1: I think it's really unfortunate because I do see the
Speaker 1: good ideas. The problem is one they called it Web
Speaker 1: three as a gimmick because it's not the Web. What
Speaker 1: they want is they want an alternate universe in which
Speaker 1: it's kind of like rust right, like Russ. They want
Speaker 1: an alternate universe in which programming is perfect without trade
Speaker 1: offs other than the trade off of learning rust right,
Speaker 1: but it and the Web three people they want this
Speaker 1: perfect universe that literally can't exist because like first principles
Speaker 1: and incompleteness theorem and but and so there. Instead of saying, Okay,
Speaker 1: we're gonna we're gonna evolve the web. We're gonna take
Speaker 1: what we have and we're gonna make it one step
Speaker 1: towards our ideal, they're saying we're starting over from scratch,
Speaker 1: but not just from scratch, like really from scratch, Like
Speaker 1: we would get rid of TCP if we could, but
Speaker 1: somehow we haven't figured out how to do that yet.
Speaker 1: Like if the Web three people had their way, you
Speaker 1: would have to buy a proprietary network card. And by
Speaker 1: proprietary I mean not in accordance with any existing standard
Speaker 1: and not useful to any other standard it would.
Speaker 3: Can I can I briefly offer an alternate view of
Speaker 3: that world, having spent a brief six months there. I'm
Speaker 3: certainly not a spokesman for Web three, and I'm not
Speaker 3: here to shill for some Web three coin or something,
Speaker 3: but the underlying culture that I was exposed to in
Speaker 3: that world when I was trying to learn it and
Speaker 3: trying to figure out they hired me because they wanted
Speaker 3: me to help bridge the gap from Web two to
Speaker 3: Web three, and so I was trying to look at
Speaker 3: it from that perspective, what's missing, what are they assuming
Speaker 3: that's not true? And all of that. And one of
Speaker 3: the things that I got from the culture that the
Speaker 3: cyberpunk genre of writing seems to be an extremely important
Speaker 3: part of the culture in Web three. And if you
Speaker 3: read people like Neil Stevenson or whatever. I'm not a
Speaker 3: big reader, but I did read a couple of his
Speaker 3: books trying to get this mindset a little bit more
Speaker 3: injected into mind. And if you read that, I think
Speaker 3: they're actually saying something a bit opposite of what you're saying.
Speaker 3: I think what they're saying is not we want an idealistic,
Speaker 3: perfect world, but they assume that the world is inevitably
Speaker 3: going to fall in on itself in its current track,
Speaker 3: and the only way to avoid the certain doom. I'm
Speaker 3: using really big words like I was a you know,
Speaker 3: a writer. There's something there, but the only way to
Speaker 3: avoid that is to jump to their view. So from
Speaker 3: where from where we sit in a mostly functioning but
Speaker 3: certainly not zero problem world, we look at them and say, oh, well,
Speaker 3: those folks are just you know, they're pie in the
Speaker 3: sky and they just they want things that are never
Speaker 3: going to happen. It's completely naive and idealistic. But I
Speaker 3: think their perspective is, man, you just don't even realize
Speaker 3: that the track that you're on is already going to fail.
Speaker 3: It's inevitable, and we're just trying to get as many
Speaker 3: people to jump off that track before the train goes
Speaker 3: off the rails.
Speaker 1: That's that's our bridge. We need an off ramp, because
Speaker 1: what they're asking is jump off the train one hundred
Speaker 1: and fifty feet down into the gorge below, rather than
Speaker 1: jump off to the train onto this nice little floating
Speaker 1: ninja turtle blimp we have for you.
Speaker 3: Right, But That's exactly why I left that space and
Speaker 3: why I'm trying to build things that I I think
Speaker 3: will constitute the gap, that will bridge the gap. And
Speaker 3: I call it the web two point five. This idea
Speaker 3: of owning your identity, this idea of promoting local first,
Speaker 3: this idea of those are things that I think need
Speaker 3: to happen if anybody's ever going to plausibly make that job,
Speaker 3: that's my wible.
Speaker 1: Okay, so I think we are we're at time for this.
Speaker 1: I for those listening on, I actually want to continue
Speaker 1: on with another segment, but I think so, I think
Speaker 1: we need to wrap this one up can make so please.
Speaker 3: Please one last plug around this space. So I have
Speaker 3: been building pieces in the local first and the identity space,
Speaker 3: and anybody who's followed me on social media has seen
Speaker 3: me building libraries like, for example, the local vault library.
Speaker 3: I'll I'll provide all of these links, but the local
Speaker 3: vault library to use past keys to own your identity.
Speaker 3: That's one set of effort that I'm trying to do
Speaker 3: to to help create the things that other smarter people
Speaker 3: will actually build real viable solutions around. I'm trying to
Speaker 3: put together those local pieces. So that they can be used.
Speaker 3: The other thing that I wanted to say, which is
Speaker 3: related butt separate, which is a recent initiative that I
Speaker 3: have around what's called what I call bring your Own JavaScript.
Speaker 3: There has been a decidedly like anti framework tone to
Speaker 3: our conversation, and I just want to state clearly for
Speaker 3: the record, I am not anti framework. I am not
Speaker 3: down with React and view sucks. The people who created
Speaker 3: those things are far smarter than I am, and I
Speaker 3: look up to them. I wish I was as good
Speaker 3: an engineer as many of the people that design these systems,
Speaker 3: and I'm glad they exist and they are solving things
Speaker 3: in ways that many of our engineers in the industry
Speaker 3: really appreciate their I am not the great spoke when
Speaker 3: I say, I think there is a tremendous amount of
Speaker 3: value there. But what we have lost is what I lament.
Speaker 3: What we have lost is the appreciation of the importance
Speaker 3: of understanding how the systems work under and how sometimes
Speaker 3: those aren't the right answer. We've lost that appreciation, and
Speaker 3: so BYOJS, bring your Own JavaScript is really designed to
Speaker 3: not say down with frameworks and down with Typescript and
Speaker 3: down with tools, but rather, let's carve out a separate
Speaker 3: space where we can champion those who still believe that
Speaker 3: those skills and techniques are important, and we can mutually
Speaker 3: sit alongside the much bigger behemoth of the framework first
Speaker 3: crowd the stuff. So I just wanted to plug the
Speaker 3: stuff I'm trying to do around local vaults and using
Speaker 3: past keys to create our identities and protect our data locally.
Speaker 3: And then this Bring your Own JavaScript is trying to
Speaker 3: champion JavaScript without the requirement to go very heavy on
Speaker 3: framework and tooling. Those are things that I think will
Speaker 3: be very important keys I hope in the local first movement.
Speaker 3: But I don't own the local first movement in any way, right.
Speaker 3: I'm one guy. I don't have a company in local first.
Speaker 3: There are many many other people out there, so don't
Speaker 3: I hope that people won't take my little slice of
Speaker 3: thinking about local first as gospel. There's a tremendously big
Speaker 3: community couple thousand people in the Discord community for the
Speaker 3: Local First web dev which we'll have a link to.
Speaker 3: I invite anybody that's curious about local first, even if
Speaker 3: you totally disagree with how I've presented it, but you're
Speaker 3: still curious, please come and join that community. Because there
Speaker 3: is a big tent, there's a lot of room for
Speaker 3: a lot of different ways of doing it. I just
Speaker 3: have my own little tiny slice of how I'm trying
Speaker 3: to go about it.
Speaker 1: All right, Well, thank you for that, and again we're
Speaker 1: gonna continue on with another segment. We're gonna wrap this
Speaker 1: one up. Uh So, let's go ahead. We're going to
Speaker 1: do picks. If you it sounds like you're not gonna
Speaker 1: have any problem with that. I'm going to go ahead
Speaker 1: and have Steve go first, because he I want to
Speaker 1: be We've already not been sensitive to your time, so
Speaker 1: I have go ahead and have you go first.
Speaker 2: There, Steve, all right, so the uh my picks are
Speaker 2: the highlight of any Javascriptaber episode, at least the ones
Speaker 2: that I'm on with the dad jokes of the week.
Speaker 2: So let's see this is sort of a visual one,
Speaker 2: but I'll make it a little better. Fun fact, the
Speaker 2: sentence are you as bored as I am? Can be
Speaker 2: said backwards? Right?
Speaker 3: Am?
Speaker 2: I as bored as you are? Backwards?
Speaker 3: Nice?
Speaker 2: Second, I've been a bit bored lately myself, so I
Speaker 2: decided to take up fencing. Man, are my neighbors mad
Speaker 2: at me? And then Finally, this is a brother tasty question.
Speaker 2: Why did the cannibal leave the restaurant? You got cold feet?
Speaker 1: Oh that's so bad. That's so bad.
Speaker 3: At least bring it out warmed up right right? Well,
Speaker 3: you know.
Speaker 2: The the similar question is is why did Jeffrey Dahmer
Speaker 2: keep a blender on his porch? You'd like to greet
Speaker 2: people with a warm handshake.
Speaker 1: Oh that too soon? Too soon?
Speaker 2: Sorry, Kyle, Kyle.
Speaker 1: Oh, I feel icky inside right now.
Speaker 3: Oh that's gross. Please don't do that against Steve.
Speaker 1: All right, great?
Speaker 2: Uh?
Speaker 1: Any was there anything else on that, Steve? Are we
Speaker 1: ready to move on to Kyle?
Speaker 2: Ready to move on?
Speaker 3: All right? Oh?
Speaker 1: Wait, No, we do the We do the guest last.
Speaker 1: That's how we do it. See, it's been so long.
Speaker 1: I'm rusty moving from me. Yeah, I am moving on
Speaker 1: from you. That is that is what I'm doing, all right.
Speaker 1: So the thing that I want to pick is gonna
Speaker 1: be Oh I have to oh oh, Utah JAS conference,
Speaker 1: Utah JAS conference. The videos have dropped. So if you
Speaker 1: want to watch the Utah JS stuff, the videos have dropped.
Speaker 1: And I'm gonna Utah JS COMF twenty twenty four. I
Speaker 1: thought it was a great conference because I think this
Speaker 1: is the second year in a row that I'm seeing
Speaker 1: the glaze coming off of people's eyes or no, that's
Speaker 1: not the right expression. People are starting to.
Speaker 3: See the light.
Speaker 1: Like the scales, the scales, the scales are coming off
Speaker 1: people's eyes and they're starting to see the light. Because
Speaker 1: there were so many great talks that were hey, maybe
Speaker 1: we could do this in a simpler way. One of
Speaker 1: the ones that I absolutely loved was I forget his
Speaker 1: first name is something delaney. I think he gave a
Speaker 1: presentation on the thing that caught my eye about it
Speaker 1: was server side events. And it turns out you can
Speaker 1: implement server side events and literally in a tweet, actual
Speaker 1: functional server side events will fit in a tweet. Well, okay,
Speaker 1: I put it in an image in a tweet, but anyway, Yeah,
Speaker 1: and I'll give that too. And I would look up
Speaker 1: the name, but I don't want to take up too
Speaker 1: much time what what the actual talk was called. But
Speaker 1: let's see sc in a tweet. Where did my tweet go? Oh,
Speaker 1: I don't have it, but there's that. Okay, that's not
Speaker 1: that's oops that that RL went nasty but oops? Okay, anyway,
Speaker 1: so yeah, those those are those are two things that
Speaker 1: I'm going to pick right now, I've got I've got
Speaker 1: a couple other picks. Maybe I'll pick in the next segment.
Speaker 1: But that's utah JAS conference. Go take a look on YouTube.
Speaker 1: I just put the link in here, but if you
Speaker 1: look up utah js on on YouTube. The conference, I
Speaker 1: really really thought there were some great talks. There was
Speaker 1: one that was the one hundred year web app how
Speaker 1: to choose technology that will survive that you know, if
Speaker 1: you if you if somehow it's still hosted in one
Speaker 1: hundred years, it would still work in one hundred years.
Speaker 1: I thought that was talking was actually so many excellent
Speaker 1: talks is here because it was it was getting away
Speaker 1: from I mean, there was still some framework hype there,
Speaker 1: but it was getting away from framework hype and it
Speaker 1: was getting back to not necessarily back to basics, like
Speaker 1: service side events wouldn't necessarily say basics. But it was
Speaker 1: mind blowing to find out how simple they are in
Speaker 1: comparison to web sockets, how performant they are, and see
Speaker 1: that that demo that was done, and there was there
Speaker 1: was three or four talks I went to where I
Speaker 1: was just blown away with I learned stuff and stuff
Speaker 1: that I feel is valuable that I'm going to use,
Speaker 1: and I don't often feel that way about the hype stuff,
Speaker 1: but I mean a lot of that's my attitude. But anyway,
Speaker 1: so I got that, Kyle, what are your picks?
Speaker 3: I'll just do one similar to but not the same.
Speaker 3: And this is not something I created. But the last
Speaker 3: couple of days a new initiative is launched called the
Speaker 3: Pure Web Foundation, and you can get to it at
Speaker 3: pureweb dot dev if you're interested. But the Pure Web
Speaker 3: Foundation's goal is too similar to b yojs, is to
Speaker 3: champion building with the web platform without frameworks and tools
Speaker 3: necessarily layered on top. It's an attempt to kind of
Speaker 3: maybe even rediscover the way the web was built before
Speaker 3: we were taken over by those things. I'm very excited
Speaker 3: about that, and I hope more people will kind of
Speaker 3: give it a look and kick the tires on this.
Speaker 3: They're going, we're a lot of resources that we're going
Speaker 3: to try to create for it. So it's not about
Speaker 3: creating code or libraries, but about creating resources that help
Speaker 3: educate around that.
Speaker 1: So all right, well, thanks for that, and it has
Speaker 1: been a pleasure having you so so far. Thank you
Speaker 1: so much for coming on and talking about this, and
Speaker 1: and uh glad that we get to have some warm disagreements.
Speaker 1: I think that always makes an episode a lot better.
Speaker 1: And I'm glad that you were able to defend your
Speaker 1: position because I'm gonna say something that I don't normally say.
Speaker 1: Sometimes if people don't defend their position, I just don't
Speaker 1: ask the next question. So, Okay, I don't want to
Speaker 1: be abrasive, but like when people defend the position, then
Speaker 1: that gives me the ability to dig deeper. Sure, so
Speaker 1: thank you for that.
Speaker 3: Yeah, I've enjoyed It's been a good, lively debate, so
Speaker 3: thanks for having me, all right, And with.
Speaker 1: That, those of you are online, stay tuned, but for
Speaker 1: this being cut for podcast release. Audios, everybody,