WEBVTT
00:00:00.100 --> 00:00:04.679
We all know that at the end of the day, their webpages that are like, that's all the customer cares about.
00:00:04.681 --> 00:00:06.759
They get their HML, their CSS and their JavaScript.
00:00:06.790 --> 00:00:08.880
However, it gets there doesn't matter.
00:00:09.019 --> 00:00:12.240
So the more we can make that easier for people to do better, it is.
00:00:13.539 --> 00:00:14.240
Hi everyone.
00:00:14.419 --> 00:00:18.879
And welcome to developer experience a podcast by Algolia.
00:00:19.059 --> 00:00:26.429
We chat with guests who built products for developers about their developer experience, strategy, what it means for them, why it's important.
00:00:26.809 --> 00:00:38.829
And so on, on today's episode, we are going to talk about the challenges of providing amazing developer experience for a wide variety of technical stacks.
00:00:39.250 --> 00:00:42.939
How do you consistently provide incredible DX to everyone?
00:00:43.450 --> 00:00:53.340
When what you're building is not specific to a single platform, how do you properly think of such systems to answer those questions today?
00:00:53.979 --> 00:00:55.579
I have Ben Hong with me.
00:00:56.119 --> 00:01:05.409
Ben is a staff developer experience engineer at Netlify one of the most popular serverless platforms to build and deploy web apps.
00:01:05.840 --> 00:01:13.409
He's also very present in the UJS community as a member of the core team and as a view mastery instructor.
00:01:14.019 --> 00:01:14.569
Hello, Ben.
00:01:15.060 --> 00:01:15.409
Hello.
00:01:16.209 --> 00:01:16.370
All right.
00:01:16.510 --> 00:01:17.730
So let's dive in.
00:01:17.829 --> 00:01:19.609
I'm a big fan of Netlify.
00:01:19.730 --> 00:01:20.810
I really use it a lot.
00:01:20.989 --> 00:01:29.719
And as a frontend engineer myself, when I hear Netlify to me, it's like, Nety JAMstack same thing goes hand in hand.
00:01:29.870 --> 00:01:42.319
When you look at the gems stack ecosystem in and of itself, it's already pretty wide, you know, you have many different libraries like JavaScript, but not only Hugo and Jackal, many different languages.
00:01:42.930 --> 00:01:48.430
And then on top of that, you have the frameworks Gadsby next, et cetera.
00:01:48.650 --> 00:01:58.629
But even then when I go on the Netlify website, I see that you support solutions like DRAL or WordPress, which traditionally are dynamically rendered.
00:01:58.631 --> 00:02:00.629
Like you give a JAMstack spin to that.
00:02:00.689 --> 00:02:01.709
So I'm interested.
00:02:02.170 --> 00:02:08.259
How do you decide what to support and how do you make sure that you can actually sustain it?
00:02:08.719 --> 00:02:17.620
So, as you mentioned at LFI, one of our goals is really to make it as easy as possible for developers to build and ship modern web applications as possible.
00:02:18.199 --> 00:02:23.500
And I think one of the things about like the origin of jam SAK is that cuz it was originally defined as like JavaScript, right.
00:02:23.810 --> 00:02:24.930
An API and markup.
00:02:25.349 --> 00:02:28.210
And so it was like, well, if there's no JavaScript, it can be jams stack.
00:02:28.211 --> 00:02:34.849
And really, if we think about it, like the reason jams tech even came up was because we had this whole era of single page applications, right.
00:02:35.110 --> 00:02:40.490
We were deploying these like, um, you know, single index that HTML, we were using JavaScript to rendering everything.
00:02:40.870 --> 00:02:47.919
And so in really, if we think about a lot of technological concept, this is, was kind of a throwback to the way things kind of were originally done.
00:02:48.090 --> 00:02:48.439
Right?
00:02:48.439 --> 00:02:53.000
You ship as little HTML are like just enough for the client to, to get started.
00:02:53.780 --> 00:02:59.520
And so when it came to like support, really it's about figuring out how to generate the most impact.
00:02:59.569 --> 00:02:59.919
Right?
00:03:00.030 --> 00:03:10.360
Certainly popularity is a consideration when a lot of people use it because if you know that, for example, like WordPress powers, a large percentage of sites on the web, then certainly we wanna make sure that we have support for it.
00:03:10.360 --> 00:03:21.110
Even though WordPress is traditionally more PHP and there's really not as much JavaScript on it, we still wanna make it as easy as possible for you to ship, call it a headless WordPress cm mess with the things that you might wanna build otherwise.
00:03:21.409 --> 00:03:28.550
And so, yeah, I mean, that's kind of like what goes into it as far as support since like, to your point, it is tricky when you have so many different libraries.
00:03:28.569 --> 00:03:36.349
And so I think the team is constantly looking at how can we make sure that we help improve the web and get developers to ship quicker with their solutions?
00:03:37.180 --> 00:03:38.669
Yeah, that makes a lot of sense.
00:03:38.870 --> 00:03:50.379
Uh, I love what you said about, uh, like it's, it doesn't have to be specifically JavaScript and that's like when it comes to gems stack, while I believe if you take a step back, it's not about JavaScript.
00:03:50.381 --> 00:03:55.979
It's really more about building and using tools and using specific technologies where they're good at.
00:03:56.039 --> 00:04:01.969
And what I love is that when you think of gems stack, for example, it's not that you have to ditch WordPress.
00:04:01.971 --> 00:04:03.169
Like you can still use it.
00:04:03.170 --> 00:04:05.889
It's a pretty darn good piece of software for editing.
00:04:06.150 --> 00:04:07.210
It makes a lot of sense.
00:04:07.289 --> 00:04:14.930
A lot of people are already trained on it, but should it be the part that renders your UI that renders your website?
00:04:15.180 --> 00:04:15.849
Maybe not.
00:04:16.310 --> 00:04:29.879
Do you need to have your own server that you build like that run and you keep an eye on it, et cetera, maybe not because what you have may not be as dynamic as you think, or maybe only have a few parts that are dynamic.
00:04:30.149 --> 00:04:35.560
It's kind of the same idea that you have with Algolia should you own your own search engine?
00:04:35.740 --> 00:04:37.879
Should it be hosted on your own server?
00:04:38.139 --> 00:04:40.120
Do you need it to be done on the backend?
00:04:40.120 --> 00:04:54.949
Like you really need it when you realize what every piece of the pipe, whether it's the server, the client like that, this and that language, you realize that all have really interesting strength and weaknesses.
00:04:55.170 --> 00:05:00.509
And to me, that's really this idea of building SaaS products like that and build building those kinds of platforms.
00:05:00.511 --> 00:05:07.019
Is that really focusing on where you can bring the most value and piecing that together.
00:05:07.279 --> 00:05:11.540
To me, that really goes back to the initial concept of developer experience.
00:05:11.629 --> 00:05:24.009
Maybe some people like it, but when you are a frontend engineer, you're especially in many companies, when you're a frontend engineer, you're probably going to be the one who's responsible of the website.
00:05:24.011 --> 00:05:25.449
Like the entire website.
00:05:25.509 --> 00:05:34.730
You may not have a team, a fully dedicated team of people working on the website, but are you comfortable operating a server?
00:05:35.029 --> 00:05:42.560
Are you comfortable making sure that this build step happens in the right way or that you use the right CI or whatever may not.
00:05:42.660 --> 00:05:52.800
And so that's what I find really interesting about services like Netlify is that it really integrates with what you have, but it takes away the common parts that you don't want to care about.
00:05:53.029 --> 00:05:53.319
Yeah.
00:05:53.339 --> 00:06:10.519
And I think to your point again, JAMstack evolved out of its time as far as like its timing of the ecosystem with a single page applications, but it really is like a architectural concept regarding trying to simplify this idea that when you're deploying things that you keep them in an anatomic way, that you abstract the way these problems that we all had to deal with.
00:06:10.521 --> 00:06:16.240
Right of us who used to actually directly F TPR files onto the server, dealing with cashing and all that stuff.
00:06:16.240 --> 00:06:21.029
You were wanna focus on solving your problems, not these common problems that everyone keeps solving over and over again.
00:06:21.050 --> 00:06:26.310
So to your point like services like neti and Algolia like helping you to abstract those problems away.
00:06:26.310 --> 00:06:31.589
So you can focus on, you know, solving your customer needs rather than these solutions that, you know, Algolia has done a wonderful job.
00:06:31.591 --> 00:06:40.699
Like we have such a great time using it on the view doc side, just to know that, like we don't have to come up with our own our solution for all our docs and we can focus on writing great docs.
00:06:41.120 --> 00:06:43.300
So we're really grateful to tools like Algolia.
00:06:43.560 --> 00:06:46.779
So how do you actually decide what to support?
00:06:46.781 --> 00:06:49.220
Because Netlify is a universal platform.
00:06:49.410 --> 00:06:51.259
It's not tied to specific technology.
00:06:51.600 --> 00:06:55.100
How do you keep an eye on what's going on in the JAMstack ecosystem?
00:06:55.579 --> 00:07:01.009
More like I would even say like in the realm of website making, how do you keep an eye on that?
00:07:01.011 --> 00:07:05.769
What's your strategy around deciding, oh, that's actually interesting.
00:07:06.370 --> 00:07:06.930
It's getting traction.
00:07:07.399 --> 00:07:10.209
This may be not so much like what's the strategy around that.
00:07:10.670 --> 00:07:12.689
So I think it's you bring up an excellent point, right?
00:07:12.690 --> 00:07:19.560
Think a running theme we'll see in this episode is that it's not about whether it's a jam stack, a specific technology, but it's a at how does it impact the web, right?
00:07:19.759 --> 00:07:21.199
Cause we're about shipping web applications.
00:07:21.300 --> 00:07:27.439
And so when it comes to deciding these technologies, so the NFI, we have an entire team devoted to developer experience.
00:07:27.819 --> 00:07:30.600
And so each of us does cover like specific areas.
00:07:30.600 --> 00:07:37.639
So we have Jason who came from like the Gasby community Cassidy who focuses on like the, sort of the reaction generic overall I cover view.
00:07:37.699 --> 00:07:43.310
And we have to, who does angular fill sort of more generic like JavaScript frameworks, like 11.
00:07:43.769 --> 00:07:47.870
And we have Kenny here also providing support because everyone's tapped into different ecosystems.
00:07:48.050 --> 00:07:52.069
We have the ability to kind of listen with our ear to the ground as far as what's going on.
00:07:52.089 --> 00:07:54.910
And like what kind of conversations are happening around the web?
00:07:54.911 --> 00:07:55.910
Because we were talking about it.
00:07:55.911 --> 00:07:56.949
Doesn't have to be JavaScript.
00:07:57.040 --> 00:08:01.899
Let's rust is making quite a bit noise right within the community as far as potential improvements.
00:08:02.279 --> 00:08:08.060
And so should one day there's like a really major rust framework that really helps to let people ship things faster.
00:08:08.399 --> 00:08:12.660
That's something we want to invest in because again, our goal is to get people to ship faster, right?
00:08:12.759 --> 00:08:20.089
As we know in software development, the more you can iterate on something at a, at an inexpensive way, the faster we are to make changes in improve to it.
00:08:20.120 --> 00:08:29.410
It's when you have the really long build times the TES that take 20 hours to run, those are the times where like people start being afraid to make change because the feedback loop is so long.
00:08:29.550 --> 00:08:37.610
And so I think these are some of the things we constantly look at, because again, if we're about shipping and iterating faster, then we gotta figure out, make sure we keep our ears to the ground.
00:08:37.610 --> 00:08:39.210
As far as those tools to invest in,
00:08:40.889 --> 00:08:48.110
You actually brought up a really interesting point is that you have a developer experience team, like a fully dedicated to developer experience.
00:08:48.129 --> 00:08:49.070
And within that team.
00:08:49.071 --> 00:08:52.389
And I remember reading what your former VP, Sarah ner wrote.
00:08:52.390 --> 00:09:05.080
She wrote an interesting article on that, on the amplify blog, how this team is composed and you have within that, you have even people focused like you are on DX specifically in community aspects.
00:09:05.220 --> 00:09:10.440
And it looks like you have specialists on many facets, uh, of the JAMstack.
00:09:10.539 --> 00:09:12.080
And that to me is really fascinating.
00:09:12.259 --> 00:09:15.029
I'm wondering like, is this by design?
00:09:15.049 --> 00:09:15.870
Is this on purpose?
00:09:15.970 --> 00:09:19.190
Is this like part of a strategy or did it really just happen?
00:09:19.220 --> 00:09:35.500
Like it happened to that Nety had someone interested in react, had someone interested in view, had someone interested in angular, is it something like you make sure to keep to preserve so that you can have an ear and a, like a voice in every community on top of that?
00:09:35.500 --> 00:09:41.500
Like how does that help keeping the bar high across the board with everything you build at Alii?
00:09:42.659 --> 00:09:45.580
I can't speak for, you know, Sarah's hiring practices at the time.
00:09:45.600 --> 00:09:52.700
But to me though, as far as like my impressions, it does seem keeping specialists in the different communities is something that was entirely intentional.
00:09:52.701 --> 00:10:03.169
Because if we think about it, like one of the things that's trickiest about think development is that when we get kind of used to a stack that we're comfortable working in that sometimes we forget to look outside the box and what other people are doing.
00:10:03.171 --> 00:10:03.409
Right.
00:10:03.410 --> 00:10:08.610
Because, you know, we talked about react, angular and view, for example, but felt obviously is making a lot of noise.
00:10:08.610 --> 00:10:11.169
And there's a lot of people who really love things about felt.
00:10:11.171 --> 00:10:19.679
And I think it would be a travesty for teams ignore that these up and coming frameworks because when people create new solutions, there obviously is a problem missing there, right.
00:10:19.681 --> 00:10:23.799
Or new ideas to play with recently, like ES build is starting to really become a thing, right.
00:10:23.799 --> 00:10:25.720
With tools like vs snow pack.
00:10:25.980 --> 00:10:29.559
If we were to just say that, oh, it's not that popular yet, but we ignore it.
00:10:29.561 --> 00:10:37.990
Like this is how I think companies or teams would miss the opportunity to like really innovate on their technology from that regard, I'd say it is good to have that to of diversity of opinions.
00:10:37.990 --> 00:10:41.190
So you can have people's perspectives to reflect on things.
00:10:41.191 --> 00:10:55.830
When you go like this is the perfect solution and that I've seen, but it's oftentimes they're catered to a certain customer with a certain kind of tech stack because a lot of us we talked about, right, we're just talking about JavaScript framework, but what about people in the WordPress ecosystem and other headless CMSs databases?
00:10:55.831 --> 00:10:58.139
And that's why part, part of our job too.
00:10:58.340 --> 00:11:03.779
It's also diversified the things that we learn about so that we can keep a broad perspective on tolling in the community.
00:11:04.240 --> 00:11:14.220
That's actually, uh, an interesting point because you have a lot of people in your team who are really knowledgeable about the JavaScript ecosystem, like your part of the view core team.
00:11:14.240 --> 00:11:21.169
So obviously your team can rely on you on any thing, new or upcoming in view that should not be missed.
00:11:21.600 --> 00:11:26.649
Same for the Rya Gadsby, uh, next like Cassidy and Jason will be on top of that.
00:11:27.230 --> 00:11:32.289
Now, WordPress, like whatever anybody said, WordPress is still extremely present.
00:11:32.629 --> 00:11:35.889
Not only extremely present, powering a huge chunk of the web.
00:11:36.490 --> 00:11:39.360
They're really cool, interesting features that come out.
00:11:39.360 --> 00:11:50.600
Like it has a rest API for a while, but like the Gutenberg API keeps on improving et cetera, but you don't necessarily have someone who's a specialist on WordPress on the team.
00:11:51.100 --> 00:12:03.480
And so how do you manage to preserve great developer experience on stocks that you are not familiar with, that you don't have anybody who's specialized on that and who will have a natural appeal at keeping up with that community?
00:12:04.460 --> 00:12:10.320
One of the things I really love about my team is that everyone here has a, a real appetite for learning and trying new things.
00:12:10.700 --> 00:12:20.190
And so while we've all become special list in our respective domains, for example, Jason has his learn with Jason show where he brings on new guests every week to talk about new tooling and that kind of thing.
00:12:20.870 --> 00:12:24.110
Um, we are encouraged by net LFI to go out and explore those things.
00:12:24.610 --> 00:12:33.779
And so, for example, whether it's working with the Shopify CMS and building things with new tools, a lot of us on the team use what we have as a base to then go out and just keep expand, ending on that knowledge.
00:12:33.780 --> 00:12:37.179
Because once again, I find that innovation often comes from the most unexpected places.
00:12:37.759 --> 00:12:40.940
And so I'm always eager to just see how are other people doing it, right?
00:12:40.960 --> 00:12:42.659
How are they thinking of these problems?
00:12:42.799 --> 00:12:59.250
And so whether it's building demos using, for example, like view with the headless WordPress, those are the kind of things we're given the freedom to explore because our team is trusted to figure out like what we think might be the most impactful within our given communities, as well as how it might also add up to on a larger scale as far as like impact for the web as a whole.
00:12:59.649 --> 00:13:06.409
I can definitely recognize that at Algolia it's been definitely quite challenging, especially because we have many integrations.
00:13:06.480 --> 00:13:10.929
Like we have integrations with many different languages, frameworks, et cetera.
00:13:11.149 --> 00:13:15.440
And the more I think about it, the more I'm like DX should a shared responsibility.
00:13:15.509 --> 00:13:18.519
It's not like everything will be on the integration.
00:13:18.520 --> 00:13:19.840
Like there's common stuff.
00:13:20.230 --> 00:13:28.000
There's common logic, there's com common aspect that probably always need to be handled at a lower level.
00:13:28.419 --> 00:13:33.240
The more things you can shove into the part that you, anybody and everybody can share the better.
00:13:33.269 --> 00:13:36.750
Because when you think of about, let's say, okay, let's take gets beef.
00:13:36.769 --> 00:13:47.870
For example, what's important when you think about gets beef in the context of a service net, like Algolia Nety is that it should be the most Gadsby ask experience.
00:13:48.289 --> 00:13:58.580
That's the role of this aspect, like gets be this strategy, this part of the product, it should be about being the, the more, or gets BX experience for the person that's using it.
00:13:59.379 --> 00:14:01.700
Anything else should probably be at lower level.
00:14:01.759 --> 00:14:14.059
And so that, you know, that layering aspect to me is really core to the problem thinking in layers and making sure that every part is really responsible for what it is strong about, what matters about it.
00:14:14.159 --> 00:14:17.090
And that's not really just an engineering issue.
00:14:17.320 --> 00:14:19.450
It's really a, a product problem.
00:14:19.600 --> 00:14:21.250
It's how you design things.
00:14:21.830 --> 00:14:27.809
So every part solves the exact problem that it is going to be good
00:14:27.909 --> 00:14:28.129
At.
00:14:28.570 --> 00:14:36.559
I think that's really important to highlight here is the DX team at LFI in particular is just one aspect of how we manage DX across the entire right.
00:14:36.580 --> 00:14:44.840
So my team specifically with Jason Casy, Tara, Phil, and Kenny, we represent a very specific team within Netlife I, as far as like community outreach.
00:14:45.059 --> 00:14:54.679
So, you know, obviously coming on and being able to talk with you, writing blog posts, creating content, as well as exploring and interacting with the communities, but we're not also solely responsible for DX across the company.
00:14:54.899 --> 00:15:04.200
We have integration teams who are responsible for like the engineering aspect of taking what the things we've learned about and bringing it back into the core product and figuring out how they can improve that.
00:15:04.759 --> 00:15:10.200
It's really important to highlight that there's a lot of teamwork going on and a lot of different teams involve in making net what it is
00:15:10.730 --> 00:15:12.149
As a view Corps member.
00:15:12.330 --> 00:15:22.629
How have you witnessed that being a part of this community as whole so helped inject better DX at Nety and maybe vice versa.
00:15:22.970 --> 00:15:27.990
How maybe did you witness that your involvement at Netlify and being in that space?
00:15:27.990 --> 00:15:38.899
Like it's probably the most popular platform did help or did you witness it help when it comes to how you think of new features on view, on view, press on V press
00:15:39.990 --> 00:15:42.730
My involvement with the view community, I think has been a mutually beneficial one.
00:15:43.070 --> 00:15:47.529
One of the things I really love about the view community is that it's always willing to learn from others, right?
00:15:47.590 --> 00:15:49.090
It doesn't try to reinvent the wheel.
00:15:49.091 --> 00:15:54.360
And it says when the framework does something, well, it tries to explore with that concept and figure out it does this solve the problem.
00:15:54.509 --> 00:15:59.799
Well, and so, for example, Evan's been playing lately with like a sugar ref, um, RFC right.
00:15:59.801 --> 00:16:05.759
Request for change, where it actually kind of mimics the felt syntax, which a lot of people find really weird, right?
00:16:05.919 --> 00:16:07.039
Cuz it's not traditional JavaScript.
00:16:07.041 --> 00:16:22.909
These are the kind of things that are great to think about because for technology to move forward, we have to be willing to try new things that might feel foreign because I think a lot of people, especially in tech now forget that like a lot of things you're familiar with with vanilla JavaScript, you know, quote unquote is actually things that came from the jQuery days.
00:16:22.909 --> 00:16:26.110
Like it was an external library that like they did such a good job with it.
00:16:26.110 --> 00:16:27.149
They made it part of the core.
00:16:27.250 --> 00:16:33.779
And so when libraries are trying new things, I think we have an inherent like, oh no, that's not the view way or the react way.
00:16:33.780 --> 00:16:41.820
Like to me, it's like if it solves a problem that helps to move the web forward, that is the more important thing rather than sort of being comfortable with like the one way of doing things.
00:16:42.360 --> 00:16:56.330
And so similarly, you know, in the Netlife I ecosystem, I, I am always really happy to learn how other people are doing things because one of the challenges that we have with deployment of websites is what happens when you are, when you wanna have long build times, how do we solve that problem?
00:16:57.070 --> 00:17:09.009
And so, you know, learning from the different architectures and thinking about how we can make a solution that works well across the web was one of those things where yeah, it's super exciting to see all the different solutions and try to piece together.
00:17:09.009 --> 00:17:09.930
What makes the most sense?
00:17:10.130 --> 00:17:15.200
I think that's what view I think I learned a lot from view it's like at extract away certain things, right?
00:17:15.201 --> 00:17:21.839
So example we have the template block, which is basically HTML, but there are a lot of people that are like, oh, well sometimes I really need programmatic HTML.
00:17:21.960 --> 00:17:23.160
I need, JSX great.
00:17:23.500 --> 00:17:24.960
We have a render function for you.
00:17:24.961 --> 00:17:33.839
But like in the 90% of use cases where you don't need a render function, just use HTML that I know that guy's a lot of the ethos, as far as my creation of tooling and solutions,
00:17:34.730 --> 00:17:38.269
That's actually a really good segue to, to something that I wanted to ask you.
00:17:38.299 --> 00:17:50.559
Like, you briefly mentioned the way you build, you know, when you think about static side generation, especially when that's something that you are really familiar with, it may look like, oh, it's a solve problem, you know?
00:17:50.589 --> 00:17:50.880
Yeah.
00:17:50.881 --> 00:17:51.160
Okay.
00:17:51.161 --> 00:17:57.759
You're going to compile a website you're going push to get, and then you're going to specify what your bill command is.
00:17:57.900 --> 00:18:01.640
And then the directory in which the files are gonna be, and then that's it.
00:18:01.660 --> 00:18:06.000
But what I find really interesting is that it also means new problems.
00:18:06.019 --> 00:18:08.440
You know, like new patterns are starting to emerge.
00:18:08.900 --> 00:18:15.269
When you think of next JS, for example, they created what they call incremental static regeneration ISR.
00:18:15.970 --> 00:18:20.029
And the goal is to basically avoid long builds when you have large websites.
00:18:20.030 --> 00:18:25.509
So instead of recompiling everything, you are going to compile on demand, but such a feature.
00:18:26.390 --> 00:18:27.750
It is not just one new thing.
00:18:27.859 --> 00:18:29.940
It's also, it has implication.
00:18:30.119 --> 00:18:33.140
It has consequences on the infrastructure.
00:18:33.880 --> 00:18:40.779
And so I'm wondering because that might be an easy problem when all you focus on is next, it like it has its challenges.
00:18:40.780 --> 00:18:55.730
But on top of that, when you are Nefi, you are a universal platform, you need to cater to everybody including next JS, but not only when you have so a responsibility of catering to many communities, but you need to stay abstract enough.
00:18:56.150 --> 00:19:03.170
How do you keep up with those kinds of problems that need probably more tech than you initially intended for that problem?
00:19:04.039 --> 00:19:05.980
You know, we're talking about long tail bills, right?
00:19:06.000 --> 00:19:10.809
So, you know, for the audience who might be new to this problem, imagine you have an e-commerce site, right?
00:19:11.130 --> 00:19:17.970
Like I say, it has thousands of items, but the truth is, is that maybe only like a hundred of your items are the ones that are kind of most frequently visited.
00:19:18.589 --> 00:19:26.890
And so with the traditional static site generation model, every time you build the site, you need to generate all thousand pages along with anything else that results.
00:19:27.190 --> 00:19:31.440
But at the same time, part of you probably also wonders, like, is that really necessary, right?
00:19:31.599 --> 00:19:46.279
Cause that result in long build times, which then as we talked about earlier, like that increased the amount of time it takes to get feedback, the concept being talked about here, um, which we're sort of terming like distributed persistent rendering is this idea that what if you could only build the files that you needed up front.
00:19:46.279 --> 00:19:50.359
So you, you marked these specific pages as like, these are the main ones that need to go immediately.
00:19:50.740 --> 00:20:01.069
And the, then in the future, if anyone requests anything that's like outside of that realm and we have the data for it, we will then generate those pages for you dynamically and then cash them according to that build.
00:20:01.289 --> 00:20:05.430
And so this is sort of another solution, like we're turning it on demand builders and net Lai.
00:20:05.890 --> 00:20:08.230
And so this is part of the challenge part, right?
00:20:08.420 --> 00:20:15.980
When we create solutions, we want them to be in a way that like solves everyone's problems, it's sort of a generic solution that applies to your framework regardless.
00:20:16.680 --> 00:20:30.180
And the reason that's important is because as we know, frameworks do come and go, we happen to be in kind of like a nice period where frameworks seem to be stabilizing, but we know that it doesn't take much in technology to have all of that disrupted and have the kind of the ecosystem switch.
00:20:30.400 --> 00:20:59.839
And so similarly to how we try to auto make deployment in a way that's like not specific to a specific framework, we wanna make sure that similarly, when you're trying to create these sort of architectural patterns that allow you to define core pages and then the ones that will be returned later, we wanted to think, how can we make it easier for framework authors and whatever framework come up in the future to also leverage these architectural models so that they can then take advantage of it without feeling like, oh, well this is the view way of rendering things versus like the react way of rendering things, right?
00:21:00.099 --> 00:21:04.640
We all know that at the end of the day, their webpages that are like, that's all the customer cares about.
00:21:04.641 --> 00:21:06.829
They get their HTML, their CSS and their Java as script.
00:21:06.830 --> 00:21:08.910
However, it gets there doesn't matter.
00:21:09.049 --> 00:21:11.950
So the more we can make that easier for people to do better.
00:21:11.951 --> 00:21:12.269
It is
00:21:13.380 --> 00:21:22.920
You mentioned it, we're probably in a sweet spot right now because there, a lot of things are stable and there's more and more qualified people working on it.
00:21:23.099 --> 00:21:35.829
The experimentation is usually a bit more fruitful than it was back in the days where we're transitioning between the old way of doing, uh, making website or building JavaScript or anything in relationship to, to what we have today.
00:21:36.289 --> 00:21:43.990
Now, one thing to, to stress is that it is okay to take the time, to really find the right angle.
00:21:44.099 --> 00:22:01.539
Because when you think about ISR or DPR, like it's not just a new hot feature, it's one solution to a symptom of a bigger topic in gems stack four, for that matter, that's okay to take the time to really think about it from a higher level.
00:22:01.920 --> 00:22:03.500
We see it in Angolia every day.
00:22:03.500 --> 00:22:21.650
Like we have customers who are very specific requests and that's actually awesome, you know, because it gives us concrete application examples, but it doesn't mean that we have to jump on it and make it, or as is we can take the time, you know, to reflect and, you know, take a step back and think about it more holistically.
00:22:22.069 --> 00:22:23.130
And to me that makes sense.
00:22:23.131 --> 00:22:30.920
Like, that's really the role that you have when you built such platforms in a way like that was the initial idea, always network based APIs, right?
00:22:31.180 --> 00:22:33.039
We need access to a functionality.
00:22:33.259 --> 00:22:41.440
And regardless of what it is, in what language it's written, we just want to have access to that thing in a way that works for everything.
00:22:41.460 --> 00:22:45.799
And so then this abstraction came in and it powers a huge part of the web.
00:22:45.800 --> 00:22:48.799
Like you have web hooks, et cetera, all built on top of that.
00:22:48.900 --> 00:22:56.789
And that also what Algolia evolved to, uh, I don't know if you know the story, but we used to be a mobile, offline search engine.
00:22:57.019 --> 00:23:02.750
That was Algolia at the very beginning, it was running on your phone and now we are a rest API base.
00:23:02.809 --> 00:23:19.140
So we are able to actually power any kind of stack, anything that runs in a client can power Algolia I think when good takeaways that those problems that you see and those patterns, it can feel like, oh, that's the new thing I need to hop.
00:23:19.210 --> 00:23:20.579
Like, jump on that horse.
00:23:21.329 --> 00:23:28.460
It's actually really much more interesting to take a step back and to think broader, what is the actual problem?
00:23:28.769 --> 00:23:30.019
What are we trying to solve?
00:23:30.690 --> 00:23:33.490
And how can we build something that's sustainable?
00:23:33.549 --> 00:23:39.130
And that's probably, even if we don't know the future, that's probably going to span some future cases.
00:23:39.640 --> 00:23:39.930
Yeah.
00:23:40.089 --> 00:23:43.450
I really love that this focus on the problem you're solving is something.
00:23:43.451 --> 00:23:46.039
I think that a lot of engineers often forget, right?
00:23:46.069 --> 00:23:49.319
When you have the latest hottest trend, why are you implementing this?
00:23:49.320 --> 00:23:49.519
Right?
00:23:49.660 --> 00:23:51.319
Why are you using static site generation?
00:23:51.320 --> 00:23:51.440
Right.
00:23:51.720 --> 00:23:56.640
Everyone says to do it, but like maybe it makes more sense for yours to be like just a single single page application.
00:23:56.641 --> 00:23:56.880
Right.
00:23:57.240 --> 00:23:58.200
I think people forget, right?
00:23:58.201 --> 00:24:00.559
Every engineering decision you make comes with trade offs.
00:24:00.560 --> 00:24:02.200
There's no perfect solution.
00:24:02.450 --> 00:24:08.390
Maybe it solves a problem in a perfect way, but it won't solve the same, like another problem in the same way.
00:24:08.650 --> 00:24:24.829
The other thing I think that's worth mentioning is you mentioned like, as these concepts come up, right, like we were talking about like DPR ISR, this stuff, it's kind of interesting because I think for engineers who have been in the space for a while, it feels like a lot of the stuff coming back is the way that it was used to be done, which is kind of interesting.
00:24:25.289 --> 00:24:28.579
Like a lot of front end theories are originating in backend.
00:24:28.769 --> 00:24:30.859
Like they're like, oh, backend did this years ago.
00:24:31.160 --> 00:24:37.299
And I think it's funny in the development culture of this need to like assign, oh, well this came from this, this came from this.
00:24:37.319 --> 00:24:40.859
But really if you ask me at the end of the day, are we solving problems?
00:24:40.861 --> 00:24:41.700
Are we moving forward?
00:24:42.420 --> 00:24:49.930
I think it's, that's much a much more fruitful discussion over of the whole like, well, the, you know, that this is actually just basically server side rendering.
00:24:49.931 --> 00:24:51.650
We've been doing this for 30 years.
00:24:52.130 --> 00:24:55.410
I prefer not to get into those sort of arguments with, with this kind of stuff.
00:24:55.950 --> 00:25:02.809
That's a very human thing, you know, to try and draw connections between things that you think are the same, like, oh, there's the new thing.
00:25:03.069 --> 00:25:05.170
How does it relate to something that I already know?
00:25:05.369 --> 00:25:18.960
Like that's kind of re reassuring for you to be able to put it in the same box because that, that means that you probably don't have to learn it, but at the same time, what can be, as you said, more fruitful in the conversation is what kind of new problems are we solving?
00:25:19.279 --> 00:25:39.750
I say that it's, it's pretty, you reassuring that we are reusing work that has been developed a while ago would be probably sad to see that we are throwing everything and that all that work, that, all that research or that all that knowledge, all that technology is really gone.
00:25:39.779 --> 00:25:41.150
Like there is nothing left from it.
00:25:41.299 --> 00:25:45.710
There's a lot to learn from how things used to be done.
00:25:45.980 --> 00:25:56.859
Even before static side generation was a hot word, like before the Jack days, basically people used to statically generate some of their sites for security reasons.
00:25:57.319 --> 00:26:03.140
And back then, like most people thought they were crazy to do that because it was like, yeah, your website is not dynamic.
00:26:03.410 --> 00:26:08.049
Like, you know, to me, that's quite reassuring to go back to developers experience.
00:26:08.050 --> 00:26:23.690
That's the point of the, the conversation today is that you part of, to me, of the developer experience and having a good developer experience is to be able to reuse things that you already know is to be able to leverage the knowledge that you have.
00:26:23.829 --> 00:26:26.609
Not everybody comes in that space with the same baggage.
00:26:26.720 --> 00:26:28.920
Some people started react, developers.
00:26:28.921 --> 00:26:32.920
Some people started as WordPress developers, whatever, even not even developers.
00:26:32.980 --> 00:26:38.880
But what's interesting is that we can reuse prior arts to solve new problems.
00:26:39.009 --> 00:26:52.960
There are things that exist today that were not even a conversation back in the days, things like, and now of course like this is not a new problem, but when you think of stuff like responsive design, like I clearly remember that shift.
00:26:53.559 --> 00:26:57.440
There was a time where we didn't care at all about responsive web design.
00:26:57.539 --> 00:27:02.869
Nobody cared about it because nobody had a smartphone to where they wanted to look at a site.
00:27:03.009 --> 00:27:05.589
But today that's something like that's important.
00:27:05.720 --> 00:27:06.910
There are ways to think about that.
00:27:06.930 --> 00:27:14.470
But then the, I would say the more, the faster your computer is, you're probably less and less tolerant to performance lags.
00:27:14.471 --> 00:27:19.230
You know, you don't want anything to be slow when everything on your machine is, is really fast.
00:27:19.490 --> 00:27:29.380
And at the same time, you have people who can ha now I access the internet who couldn't before, but they're not doing it on the same devices that you and I are using.
00:27:29.640 --> 00:27:30.940
So those are new problems.
00:27:31.180 --> 00:27:33.859
Those, and they are not technical problems.
00:27:34.059 --> 00:27:34.900
They are human problems.
00:27:34.901 --> 00:27:39.740
Then they are around individuals, around people, existing information.
00:27:39.740 --> 00:27:41.380
That's what technology is here to bridge.
00:27:41.740 --> 00:27:46.170
A lot of actually I think DX as well, all is about that incremental improvement.
00:27:46.171 --> 00:27:46.369
Right?
00:27:46.450 --> 00:27:51.970
I think we oftentimes forget that technology, when we evolve, we took older concepts, right?
00:27:51.971 --> 00:27:57.809
Like you said, static site, for those who like built, who used to ship via FDP, that was technically all static, right.
00:27:57.810 --> 00:28:04.640
If we were using the, the hot term, but really what we've done is like over time, we made it easier to do things that would've he to do.
00:28:04.641 --> 00:28:04.839
Right.
00:28:04.840 --> 00:28:11.400
Because those of us know that like when you deploy the same style that CSS filed multiple times, you have a weird caching thing, right?
00:28:11.401 --> 00:28:12.599
People don't get the same one.
00:28:12.900 --> 00:28:13.599
So what do we do?
00:28:13.601 --> 00:28:15.759
We started appending custom hashes to it.
00:28:15.980 --> 00:28:23.440
And so then this is why the build process started getting appended because we wanted it to make sure that we were deploying unique assets, that people could actually get the newest thing faster.
00:28:24.359 --> 00:28:36.390
Uh, and so a lot of times like your, I think to your point, Sarah, like when we take ideas that have existed and we can increment them by just like, you know, 1%, but we consistently make that 1% increase.
00:28:36.509 --> 00:28:39.029
I think we forget that that has a compounding effect over time.
00:28:39.410 --> 00:28:43.670
And that's one of the reasons why we are in a little bit of a stickier situation now with like build tools and stuff.
00:28:43.671 --> 00:28:43.829
Right.
00:28:44.029 --> 00:28:44.950
Cause people are like that.
00:28:45.160 --> 00:28:54.380
So complicated from where the way it used to be, but there are reasons why we needed this because the problems have advanced and they've gotten more trickier as we deal with your point new devices and all these things.
00:28:54.490 --> 00:28:55.700
It's a fun space to be in.
00:28:56.390 --> 00:28:57.059
Definitely.
00:28:57.160 --> 00:28:57.380
Yes.
00:28:57.640 --> 00:29:05.420
On the last episode, uh, we had Adam more than with us from tailwind and I really liked the way that he summarized the X E.
00:29:05.890 --> 00:29:10.690
He said, basically that it is providing superpowers without getting in the way.
00:29:11.009 --> 00:29:12.450
I really love this definition.
00:29:12.589 --> 00:29:20.690
And again, when you are a generic service, like you, you amplify your Algolia, you care about many people, not a specific usage.
00:29:21.269 --> 00:29:23.089
You're not tied to specific technology.
00:29:23.710 --> 00:29:24.769
How do you achieve that?
00:29:24.869 --> 00:29:28.799
How do you provide superpowers without getting in the way?
00:29:28.800 --> 00:29:36.440
And especially it's easy, you know, to care about the hot things and to have some that are left behind.
00:29:36.500 --> 00:29:47.480
So how do you, for example, ensure that N users feel as catered for as Gadsby users and similarly that JCO users don't feel left behind
00:29:48.019 --> 00:29:51.160
One of the nice things I think about, even though you're managing different frameworks, right?
00:29:51.161 --> 00:29:59.000
If you're running a tool that has like you're servicing different customers, is that typically the users aren't necessarily like they're not using Gatsby and nuts at the same time in those cases.
00:29:59.000 --> 00:29:59.319
Right.
00:29:59.619 --> 00:30:07.109
But at the same time, I think when people feel like you've created a good developer experience for them, it's about kind of like to Adam's point, right?
00:30:07.490 --> 00:30:16.750
You are giving them you're supercharging their past so that you can let them do something and then let them do it in a way that's not like as few configurations as possible.
00:30:16.910 --> 00:30:20.670
I think that's one of the key things to a lot of good developer experience for getting started.
00:30:20.671 --> 00:30:20.910
Right.
00:30:21.089 --> 00:30:27.059
Because if you knew that, like when you started the card, you had to like, press all these buttons before putting in your key and then turning it on, right?
00:30:27.059 --> 00:30:28.339
Like that's a lot of work.
00:30:28.640 --> 00:30:34.779
And so the more we can reduce the barrier of entry into tooling and then allow to incrementally grow on it.
00:30:34.780 --> 00:30:34.980
Right.
00:30:34.980 --> 00:30:41.460
This is one of the reason why, for example, the view community also starts you with templates because we wanna leverage what you already know with HTML.
00:30:41.910 --> 00:30:46.690
And then certainly when you have additional problems you wanna solve, then we can then give you the render functions.
00:30:46.691 --> 00:30:48.450
We can give you other things to make it better.
00:30:48.869 --> 00:30:55.210
And so with Netlify as well, like a lot of people, I think with their entry point, when Nety is like deploying their sites, right.
00:30:55.269 --> 00:31:03.440
Making it easy so that each and every time you push a commit or you add a new branch that it creates those deploy previews for you and makes it so easy to integrate.
00:31:03.441 --> 00:31:08.400
Like, all you do is hook up your GitHub, repo, like you said, to like define the customizations.
00:31:08.900 --> 00:31:11.880
And so, for example, like you were talking about framework experience, right?
00:31:12.059 --> 00:31:17.680
And so this is why when you hook up a repo with Alii, we try to detect in advance, which framework you're using.
00:31:17.940 --> 00:31:19.400
So we can automatically populate.
00:31:19.401 --> 00:31:19.680
Right?
00:31:19.750 --> 00:31:24.430
It's one less thing that you have to go into your package, that out JSON to figure out what's your build command.
00:31:24.431 --> 00:31:28.829
And then like, we automatically populate for that for you, so that you can then ship it and then see how that goes.
00:31:29.130 --> 00:31:44.500
And then once you're there, then you can start being like, okay, now that everything's deploying really smoothly, I can start thinking about things like, how do I want my red RXs to be, or maybe we start integrating serverless functions into our application to make things easier and like on unlock a whole world of possibilities.
00:31:44.559 --> 00:31:52.059
That's really, the key is making people feel comfortable in the space that you're in so that they can then feel basically confident enough to then take that next step.
00:31:53.119 --> 00:31:53.279
All right.
00:31:53.420 --> 00:31:56.279
And so for our question would be, how does that scale?
00:31:56.660 --> 00:32:04.589
So many different platforms, so many different solutions, you can create a JAMstack website with different languages, different frameworks.
00:32:04.769 --> 00:32:11.230
How does that scale, how do you make sure that you can keep up with a wide variety, uh, of
00:32:11.230 --> 00:32:11.509
Tools?
00:32:11.700 --> 00:32:20.349
Nice thing about, especially the way that nullify has architected, it is that, you know, with technology, it becomes, luckily our build tools, aren't changing that quickly, that we need things to be every day.
00:32:20.769 --> 00:32:27.140
And so, as a result, we basically have a manifest and we figure out what the highest impact is as far as the sites that we see people trying to deploy with.
00:32:27.200 --> 00:32:29.700
And this is also why it's really important to be in touch with their community, right?
00:32:29.701 --> 00:32:37.740
Because you might have a lens as far as like your analytics and your metrics, but if you're actually listening to what the community is talking about, a lot of times, that'll let you get ahead of things.
00:32:37.759 --> 00:32:41.079
As far as like, this is a new framework that's coming up, that people are trying out.
00:32:41.099 --> 00:32:48.440
And so that might be a job, for example, my team, to go and build some test deployments and figure out how do those demos work in relation to our current workflow.
00:32:48.441 --> 00:32:51.079
And are there things we can learn and improve as far as that goes?
00:32:51.670 --> 00:32:53.200
Yeah, that that's really interesting.
00:32:53.440 --> 00:33:02.069
And I think it's also, it's, uh, highlights kind of a hybrid role that is starting to grow and we call it developer advocate.
00:33:02.250 --> 00:33:04.069
But that term is really loaded.
00:33:04.309 --> 00:33:07.190
And in the mind of, of different people, it means different things.
00:33:07.250 --> 00:33:22.700
But I think there's something really interesting in having actual ICS, like people really building the tooling, building the production software, also being in the community and being involved and being around people and discussing with people.
00:33:22.880 --> 00:33:31.420
To me, the, the developer advocacy realm is really much bigger than what we have in mind for, for, from maybe five years ago.
00:33:31.839 --> 00:33:44.329
But that really outlines the necessity for engineers to be much more product oriented, which is actually really exciting, especially when you're building for developers, which is what we both do.
00:33:44.460 --> 00:33:46.569
We're building tooling for other developers.
00:33:47.109 --> 00:33:48.690
You are kind of your own customer.
00:33:48.799 --> 00:33:54.170
Like you're supposed to be interested in those problems because they are the problems that you want to solve for yourself.
00:33:54.670 --> 00:34:07.160
And it is much more interesting to be in touch with the community in touch with the actual concerns that that people have, because it's going to make you a better developer.
00:34:07.579 --> 00:34:22.150
You have, it's so much more interesting that when you can have an impact on the roadmap, when you are able to say, Hey, you know, that thing is really what we should be looking at right now, because when you are on the field, that's something you can see, people are into that.
00:34:22.210 --> 00:34:24.269
And if we don't do that, we're gonna use the train
00:34:24.489 --> 00:34:25.630
To build on what you were saying.
00:34:25.750 --> 00:34:47.980
I think this is what I think is what I really love about what Sarah did with the team and what I'd love to see more companies do is like with developer experience to allow them the opportunity to be basically hybrid engineers, as well as advocates, cuz I know that's so I think that's a lot of the topic of discussion around this right now is that to your point, if you're not helping to build the product that you're helping to advocate for, it's kind of a weird separation, right?
00:34:48.219 --> 00:34:53.739
It, it actually synergizes really well when your advocates are also involved in product discussions.
00:34:54.039 --> 00:35:02.090
And Sarah did a really great job as far as helping to ensure that the net DX team has that like has a voice in the engineering department as well as is in product.
00:35:02.269 --> 00:35:03.769
And just sort of having that all around.
00:35:04.489 --> 00:35:09.489
I can confirm even from the outside that Netflix, I is really the, probably the model for that.
00:35:09.490 --> 00:35:15.889
Like there is such a really great grasp at community in this company and we can see it from the outside.
00:35:15.949 --> 00:35:16.769
That's really amazing.
00:35:16.800 --> 00:35:19.610
Like the, the work you've done with the, the DX team is really incredible.
00:35:20.050 --> 00:35:25.280
I have one question for you, specif is I'm going to put you on the spot with that.
00:35:25.460 --> 00:35:30.039
How do you specifically as a person, how do you define great DX?
00:35:30.349 --> 00:35:33.280
What is your level of expectation?
00:35:33.599 --> 00:35:33.719
All right.
00:35:33.739 --> 00:35:51.079
So to me, great developer experience is striking that balance between abstracting away a problem that people have consistently while leveraging models that they already have up to a point where it's the Preto principle of where for 20% of effort you get 80% of impact, right?
00:35:51.440 --> 00:35:55.599
I think this is where people feel really excited to keep continuing with a tool.
00:35:56.219 --> 00:36:09.510
How ever, I think there comes a point where it becomes overly opinionated and when people need to break out of it, if you've locked themselves in too much, then this is where I think people do have the bad experience of like, you know, it was great at first.
00:36:09.769 --> 00:36:15.710
And then by the time I got in, and then I had a problem that I needed to customize, it was like a nightmare to get out of it.
00:36:16.010 --> 00:36:17.300
To me, that's not good to DX.
00:36:17.300 --> 00:36:19.460
It just means that you've solved one particular path.
00:36:19.960 --> 00:36:21.900
And then you are like, good luck after that.
00:36:21.900 --> 00:36:22.179
Right?
00:36:22.420 --> 00:36:26.179
Like, you know, if you did it my way, then you're great, but the moment you wanna do it a different way.
00:36:26.250 --> 00:36:27.900
Like to me, that's not necessarily good DX.
00:36:28.139 --> 00:36:29.019
That's, that's a really strong opinion.
00:36:29.280 --> 00:36:36.139
And then, so this is why I think the other half of DX comes with the allowing people a way to then customize how they do things from there.
00:36:36.141 --> 00:36:37.969
So I, I like to call'em escape hatches.
00:36:38.269 --> 00:36:46.849
The more you can allow people to do that, I think the, the better you get to a point where you really do allow people to kind of customize the solution to really their own.
00:36:47.110 --> 00:36:50.969
For example, most of us don't wanna be solving cashing problems, right?
00:36:50.971 --> 00:36:51.530
Like that's a problem.
00:36:51.769 --> 00:36:53.250
Most we just wanna build, develop.
00:36:53.250 --> 00:36:56.610
And we, as long as the customer gets what we like the latest and greatest, we are happy.
00:36:56.630 --> 00:37:02.440
We don't need to know, you know, which caching methodology is being used, like security protocols.
00:37:02.440 --> 00:37:06.760
How many of us wanna be dealing with authentication managing those are things you do kind of wanna abstract away.
00:37:06.820 --> 00:37:14.239
And those, I would say are great examples of where it might not necessarily make sense for you to allow someone to customize security credentials, because that has a big foot gun.
00:37:14.240 --> 00:37:14.440
Right?
00:37:14.460 --> 00:37:19.949
And so for those who are, aren't familiar with the term, just like ways for people, for developers to make MIS stakes, that they can't come back from.
00:37:20.289 --> 00:37:28.309
So it really is a delicate balance of like providing enough opinion so that they feel empower to get started escape hatchers to customize it.
00:37:28.570 --> 00:37:41.059
But then also like considering the foot guns of where, well, if we give developers this much power to customize, they might end up breaking things or they might end up like doing things that harm their customers, leaking sensitive data, that kind of stuff in that case, let's shield them.
00:37:41.061 --> 00:37:41.219
Right.
00:37:41.221 --> 00:37:45.539
And so, and as we mentioned before, earlier in this show, there are always trade offs, right?
00:37:45.610 --> 00:37:48.739
Like to some extent you can always abstract things.
00:37:48.760 --> 00:37:57.980
To some extent you can allow customization, but Maning those trade offs for your customers and listening to your community, I think will be the key in striking that solid DX for your audience.
00:37:58.900 --> 00:38:08.369
The, I, I really, you love with everything that you just said, and I think that's, uh, that's really a perfect point, uh, to wrap onto Ben, where can people go to find you online?
00:38:08.400 --> 00:38:08.690
Yeah.
00:38:08.690 --> 00:38:11.650
You can find me under the moniker, Ben code Zen.
00:38:12.150 --> 00:38:18.289
And so whether it's Twitter, YouTube, Twitch, I think I've got a handle on, I think I've got most of the platforms luckily.
00:38:18.630 --> 00:38:25.039
And so if you're looking for me on whatever reply from them on you just find me at www dot Ben code, zen.io, and you'll find all my stuff there.
00:38:26.469 --> 00:38:26.590
All right.
00:38:26.829 --> 00:38:30.630
And so you can find me at front stuff underscore IO on Twitter.
00:38:31.090 --> 00:38:38.719
If you're looking for Algolia stuff, it would be on@algoaontwitterandyoucanfindusonalgolia.com.
00:38:39.619 --> 00:38:41.760
Ben, thank you so much for coming.
00:38:41.760 --> 00:38:42.360
Thanks so much.
00:38:42.360 --> 00:38:42.920
It's been great.
00:38:43.389 --> 00:38:47.639
This was developer experience, a podcast brought to you by Algolia.
00:38:48.219 --> 00:38:51.000
You can find this podcast on your favorite podcast platform.
00:38:51.940 --> 00:38:59.190
If you want to know more about Algolia check out@agoya.com and we are at Algolia on Twitter.
00:00:00.100 --> 00:00:04.679
We all know that at the end of the day, their webpages that are like, that's all the customer cares about.
00:00:04.681 --> 00:00:06.759
They get their HML, their CSS and their JavaScript.
00:00:06.790 --> 00:00:08.880
However, it gets there doesn't matter.
00:00:09.019 --> 00:00:12.240
So the more we can make that easier for people to do better, it is.
00:00:13.539 --> 00:00:14.240
Hi everyone.
00:00:14.419 --> 00:00:18.879
And welcome to developer experience a podcast by Algolia.
00:00:19.059 --> 00:00:26.429
We chat with guests who built products for developers about their developer experience, strategy, what it means for them, why it's important.
00:00:26.809 --> 00:00:38.829
And so on, on today's episode, we are going to talk about the challenges of providing amazing developer experience for a wide variety of technical stacks.
00:00:39.250 --> 00:00:42.939
How do you consistently provide incredible DX to everyone?
00:00:43.450 --> 00:00:53.340
When what you're building is not specific to a single platform, how do you properly think of such systems to answer those questions today?
00:00:53.979 --> 00:00:55.579
I have Ben Hong with me.
00:00:56.119 --> 00:01:05.409
Ben is a staff developer experience engineer at Netlify one of the most popular serverless platforms to build and deploy web apps.
00:01:05.840 --> 00:01:13.409
He's also very present in the UJS community as a member of the core team and as a view mastery instructor.
00:01:14.019 --> 00:01:14.569
Hello, Ben.
00:01:15.060 --> 00:01:15.409
Hello.
00:01:16.209 --> 00:01:16.370
All right.
00:01:16.510 --> 00:01:17.730
So let's dive in.
00:01:17.829 --> 00:01:19.609
I'm a big fan of Netlify.
00:01:19.730 --> 00:01:20.810
I really use it a lot.
00:01:20.989 --> 00:01:29.719
And as a frontend engineer myself, when I hear Netlify to me, it's like, Nety JAMstack same thing goes hand in hand.
00:01:29.870 --> 00:01:42.319
When you look at the gems stack ecosystem in and of itself, it's already pretty wide, you know, you have many different libraries like JavaScript, but not only Hugo and Jackal, many different languages.
00:01:42.930 --> 00:01:48.430
And then on top of that, you have the frameworks Gadsby next, et cetera.
00:01:48.650 --> 00:01:58.629
But even then when I go on the Netlify website, I see that you support solutions like DRAL or WordPress, which traditionally are dynamically rendered.
00:01:58.631 --> 00:02:00.629
Like you give a JAMstack spin to that.
00:02:00.689 --> 00:02:01.709
So I'm interested.
00:02:02.170 --> 00:02:08.259
How do you decide what to support and how do you make sure that you can actually sustain it?
00:02:08.719 --> 00:02:17.620
So, as you mentioned at LFI, one of our goals is really to make it as easy as possible for developers to build and ship modern web applications as possible.
00:02:18.199 --> 00:02:23.500
And I think one of the things about like the origin of jam SAK is that cuz it was originally defined as like JavaScript, right.
00:02:23.810 --> 00:02:24.930
An API and markup.
00:02:25.349 --> 00:02:28.210
And so it was like, well, if there's no JavaScript, it can be jams stack.
00:02:28.211 --> 00:02:34.849
And really, if we think about it, like the reason jams tech even came up was because we had this whole era of single page applications, right.
00:02:35.110 --> 00:02:40.490
We were deploying these like, um, you know, single index that HTML, we were using JavaScript to rendering everything.
00:02:40.870 --> 00:02:47.919
And so in really, if we think about a lot of technological concept, this is, was kind of a throwback to the way things kind of were originally done.
00:02:48.090 --> 00:02:48.439
Right?
00:02:48.439 --> 00:02:53.000
You ship as little HTML are like just enough for the client to, to get started.
00:02:53.780 --> 00:02:59.520
And so when it came to like support, really it's about figuring out how to generate the most impact.
00:02:59.569 --> 00:02:59.919
Right?
00:03:00.030 --> 00:03:10.360
Certainly popularity is a consideration when a lot of people use it because if you know that, for example, like WordPress powers, a large percentage of sites on the web, then certainly we wanna make sure that we have support for it.
00:03:10.360 --> 00:03:21.110
Even though WordPress is traditionally more PHP and there's really not as much JavaScript on it, we still wanna make it as easy as possible for you to ship, call it a headless WordPress cm mess with the things that you might wanna build otherwise.
00:03:21.409 --> 00:03:28.550
And so, yeah, I mean, that's kind of like what goes into it as far as support since like, to your point, it is tricky when you have so many different libraries.
00:03:28.569 --> 00:03:36.349
And so I think the team is constantly looking at how can we make sure that we help improve the web and get developers to ship quicker with their solutions?
00:03:37.180 --> 00:03:38.669
Yeah, that makes a lot of sense.
00:03:38.870 --> 00:03:50.379
Uh, I love what you said about, uh, like it's, it doesn't have to be specifically JavaScript and that's like when it comes to gems stack, while I believe if you take a step back, it's not about JavaScript.
00:03:50.381 --> 00:03:55.979
It's really more about building and using tools and using specific technologies where they're good at.
00:03:56.039 --> 00:04:01.969
And what I love is that when you think of gems stack, for example, it's not that you have to ditch WordPress.
00:04:01.971 --> 00:04:03.169
Like you can still use it.
00:04:03.170 --> 00:04:05.889
It's a pretty darn good piece of software for editing.
00:04:06.150 --> 00:04:07.210
It makes a lot of sense.
00:04:07.289 --> 00:04:14.930
A lot of people are already trained on it, but should it be the part that renders your UI that renders your website?
00:04:15.180 --> 00:04:15.849
Maybe not.
00:04:16.310 --> 00:04:29.879
Do you need to have your own server that you build like that run and you keep an eye on it, et cetera, maybe not because what you have may not be as dynamic as you think, or maybe only have a few parts that are dynamic.
00:04:30.149 --> 00:04:35.560
It's kind of the same idea that you have with Algolia should you own your own search engine?
00:04:35.740 --> 00:04:37.879
Should it be hosted on your own server?
00:04:38.139 --> 00:04:40.120
Do you need it to be done on the backend?
00:04:40.120 --> 00:04:54.949
Like you really need it when you realize what every piece of the pipe, whether it's the server, the client like that, this and that language, you realize that all have really interesting strength and weaknesses.
00:04:55.170 --> 00:05:00.509
And to me, that's really this idea of building SaaS products like that and build building those kinds of platforms.
00:05:00.511 --> 00:05:07.019
Is that really focusing on where you can bring the most value and piecing that together.
00:05:07.279 --> 00:05:11.540
To me, that really goes back to the initial concept of developer experience.
00:05:11.629 --> 00:05:24.009
Maybe some people like it, but when you are a frontend engineer, you're especially in many companies, when you're a frontend engineer, you're probably going to be the one who's responsible of the website.
00:05:24.011 --> 00:05:25.449
Like the entire website.
00:05:25.509 --> 00:05:34.730
You may not have a team, a fully dedicated team of people working on the website, but are you comfortable operating a server?
00:05:35.029 --> 00:05:42.560
Are you comfortable making sure that this build step happens in the right way or that you use the right CI or whatever may not.
00:05:42.660 --> 00:05:52.800
And so that's what I find really interesting about services like Netlify is that it really integrates with what you have, but it takes away the common parts that you don't want to care about.
00:05:53.029 --> 00:05:53.319
Yeah.
00:05:53.339 --> 00:06:10.519
And I think to your point again, JAMstack evolved out of its time as far as like its timing of the ecosystem with a single page applications, but it really is like a architectural concept regarding trying to simplify this idea that when you're deploying things that you keep them in an anatomic way, that you abstract the way these problems that we all had to deal with.
00:06:10.521 --> 00:06:16.240
Right of us who used to actually directly F TPR files onto the server, dealing with cashing and all that stuff.
00:06:16.240 --> 00:06:21.029
You were wanna focus on solving your problems, not these common problems that everyone keeps solving over and over again.
00:06:21.050 --> 00:06:26.310
So to your point like services like neti and Algolia like helping you to abstract those problems away.
00:06:26.310 --> 00:06:31.589
So you can focus on, you know, solving your customer needs rather than these solutions that, you know, Algolia has done a wonderful job.
00:06:31.591 --> 00:06:40.699
Like we have such a great time using it on the view doc side, just to know that, like we don't have to come up with our own our solution for all our docs and we can focus on writing great docs.
00:06:41.120 --> 00:06:43.300
So we're really grateful to tools like Algolia.
00:06:43.560 --> 00:06:46.779
So how do you actually decide what to support?
00:06:46.781 --> 00:06:49.220
Because Netlify is a universal platform.
00:06:49.410 --> 00:06:51.259
It's not tied to specific technology.
00:06:51.600 --> 00:06:55.100
How do you keep an eye on what's going on in the JAMstack ecosystem?
00:06:55.579 --> 00:07:01.009
More like I would even say like in the realm of website making, how do you keep an eye on that?
00:07:01.011 --> 00:07:05.769
What's your strategy around deciding, oh, that's actually interesting.
00:07:06.370 --> 00:07:06.930
It's getting traction.
00:07:07.399 --> 00:07:10.209
This may be not so much like what's the strategy around that.
00:07:10.670 --> 00:07:12.689
So I think it's you bring up an excellent point, right?
00:07:12.690 --> 00:07:19.560
Think a running theme we'll see in this episode is that it's not about whether it's a jam stack, a specific technology, but it's a at how does it impact the web, right?
00:07:19.759 --> 00:07:21.199
Cause we're about shipping web applications.
00:07:21.300 --> 00:07:27.439
And so when it comes to deciding these technologies, so the NFI, we have an entire team devoted to developer experience.
00:07:27.819 --> 00:07:30.600
And so each of us does cover like specific areas.
00:07:30.600 --> 00:07:37.639
So we have Jason who came from like the Gasby community Cassidy who focuses on like the, sort of the reaction generic overall I cover view.
00:07:37.699 --> 00:07:43.310
And we have to, who does angular fill sort of more generic like JavaScript frameworks, like 11.
00:07:43.769 --> 00:07:47.870
And we have Kenny here also providing support because everyone's tapped into different ecosystems.
00:07:48.050 --> 00:07:52.069
We have the ability to kind of listen with our ear to the ground as far as what's going on.
00:07:52.089 --> 00:07:54.910
And like what kind of conversations are happening around the web?
00:07:54.911 --> 00:07:55.910
Because we were talking about it.
00:07:55.911 --> 00:07:56.949
Doesn't have to be JavaScript.
00:07:57.040 --> 00:08:01.899
Let's rust is making quite a bit noise right within the community as far as potential improvements.
00:08:02.279 --> 00:08:08.060
And so should one day there's like a really major rust framework that really helps to let people ship things faster.
00:08:08.399 --> 00:08:12.660
That's something we want to invest in because again, our goal is to get people to ship faster, right?
00:08:12.759 --> 00:08:20.089
As we know in software development, the more you can iterate on something at a, at an inexpensive way, the faster we are to make changes in improve to it.
00:08:20.120 --> 00:08:29.410
It's when you have the really long build times the TES that take 20 hours to run, those are the times where like people start being afraid to make change because the feedback loop is so long.
00:08:29.550 --> 00:08:37.610
And so I think these are some of the things we constantly look at, because again, if we're about shipping and iterating faster, then we gotta figure out, make sure we keep our ears to the ground.
00:08:37.610 --> 00:08:39.210
As far as those tools to invest in,
00:08:40.889 --> 00:08:48.110
You actually brought up a really interesting point is that you have a developer experience team, like a fully dedicated to developer experience.
00:08:48.129 --> 00:08:49.070
And within that team.
00:08:49.071 --> 00:08:52.389
And I remember reading what your former VP, Sarah ner wrote.
00:08:52.390 --> 00:09:05.080
She wrote an interesting article on that, on the amplify blog, how this team is composed and you have within that, you have even people focused like you are on DX specifically in community aspects.
00:09:05.220 --> 00:09:10.440
And it looks like you have specialists on many facets, uh, of the JAMstack.
00:09:10.539 --> 00:09:12.080
And that to me is really fascinating.
00:09:12.259 --> 00:09:15.029
I'm wondering like, is this by design?
00:09:15.049 --> 00:09:15.870
Is this on purpose?
00:09:15.970 --> 00:09:19.190
Is this like part of a strategy or did it really just happen?
00:09:19.220 --> 00:09:35.500
Like it happened to that Nety had someone interested in react, had someone interested in view, had someone interested in angular, is it something like you make sure to keep to preserve so that you can have an ear and a, like a voice in every community on top of that?
00:09:35.500 --> 00:09:41.500
Like how does that help keeping the bar high across the board with everything you build at Alii?
00:09:42.659 --> 00:09:45.580
I can't speak for, you know, Sarah's hiring practices at the time.
00:09:45.600 --> 00:09:52.700
But to me though, as far as like my impressions, it does seem keeping specialists in the different communities is something that was entirely intentional.
00:09:52.701 --> 00:10:03.169
Because if we think about it, like one of the things that's trickiest about think development is that when we get kind of used to a stack that we're comfortable working in that sometimes we forget to look outside the box and what other people are doing.
00:10:03.171 --> 00:10:03.409
Right.
00:10:03.410 --> 00:10:08.610
Because, you know, we talked about react, angular and view, for example, but felt obviously is making a lot of noise.
00:10:08.610 --> 00:10:11.169
And there's a lot of people who really love things about felt.
00:10:11.171 --> 00:10:19.679
And I think it would be a travesty for teams ignore that these up and coming frameworks because when people create new solutions, there obviously is a problem missing there, right.
00:10:19.681 --> 00:10:23.799
Or new ideas to play with recently, like ES build is starting to really become a thing, right.
00:10:23.799 --> 00:10:25.720
With tools like vs snow pack.
00:10:25.980 --> 00:10:29.559
If we were to just say that, oh, it's not that popular yet, but we ignore it.
00:10:29.561 --> 00:10:37.990
Like this is how I think companies or teams would miss the opportunity to like really innovate on their technology from that regard, I'd say it is good to have that to of diversity of opinions.
00:10:37.990 --> 00:10:41.190
So you can have people's perspectives to reflect on things.
00:10:41.191 --> 00:10:55.830
When you go like this is the perfect solution and that I've seen, but it's oftentimes they're catered to a certain customer with a certain kind of tech stack because a lot of us we talked about, right, we're just talking about JavaScript framework, but what about people in the WordPress ecosystem and other headless CMSs databases?
00:10:55.831 --> 00:10:58.139
And that's why part, part of our job too.
00:10:58.340 --> 00:11:03.779
It's also diversified the things that we learn about so that we can keep a broad perspective on tolling in the community.
00:11:04.240 --> 00:11:14.220
That's actually, uh, an interesting point because you have a lot of people in your team who are really knowledgeable about the JavaScript ecosystem, like your part of the view core team.
00:11:14.240 --> 00:11:21.169
So obviously your team can rely on you on any thing, new or upcoming in view that should not be missed.
00:11:21.600 --> 00:11:26.649
Same for the Rya Gadsby, uh, next like Cassidy and Jason will be on top of that.
00:11:27.230 --> 00:11:32.289
Now, WordPress, like whatever anybody said, WordPress is still extremely present.
00:11:32.629 --> 00:11:35.889
Not only extremely present, powering a huge chunk of the web.
00:11:36.490 --> 00:11:39.360
They're really cool, interesting features that come out.
00:11:39.360 --> 00:11:50.600
Like it has a rest API for a while, but like the Gutenberg API keeps on improving et cetera, but you don't necessarily have someone who's a specialist on WordPress on the team.
00:11:51.100 --> 00:12:03.480
And so how do you manage to preserve great developer experience on stocks that you are not familiar with, that you don't have anybody who's specialized on that and who will have a natural appeal at keeping up with that community?
00:12:04.460 --> 00:12:10.320
One of the things I really love about my team is that everyone here has a, a real appetite for learning and trying new things.
00:12:10.700 --> 00:12:20.190
And so while we've all become special list in our respective domains, for example, Jason has his learn with Jason show where he brings on new guests every week to talk about new tooling and that kind of thing.
00:12:20.870 --> 00:12:24.110
Um, we are encouraged by net LFI to go out and explore those things.
00:12:24.610 --> 00:12:33.779
And so, for example, whether it's working with the Shopify CMS and building things with new tools, a lot of us on the team use what we have as a base to then go out and just keep expand, ending on that knowledge.
00:12:33.780 --> 00:12:37.179
Because once again, I find that innovation often comes from the most unexpected places.
00:12:37.759 --> 00:12:40.940
And so I'm always eager to just see how are other people doing it, right?
00:12:40.960 --> 00:12:42.659
How are they thinking of these problems?
00:12:42.799 --> 00:12:59.250
And so whether it's building demos using, for example, like view with the headless WordPress, those are the kind of things we're given the freedom to explore because our team is trusted to figure out like what we think might be the most impactful within our given communities, as well as how it might also add up to on a larger scale as far as like impact for the web as a whole.
00:12:59.649 --> 00:13:06.409
I can definitely recognize that at Algolia it's been definitely quite challenging, especially because we have many integrations.
00:13:06.480 --> 00:13:10.929
Like we have integrations with many different languages, frameworks, et cetera.
00:13:11.149 --> 00:13:15.440
And the more I think about it, the more I'm like DX should a shared responsibility.
00:13:15.509 --> 00:13:18.519
It's not like everything will be on the integration.
00:13:18.520 --> 00:13:19.840
Like there's common stuff.
00:13:20.230 --> 00:13:28.000
There's common logic, there's com common aspect that probably always need to be handled at a lower level.
00:13:28.419 --> 00:13:33.240
The more things you can shove into the part that you, anybody and everybody can share the better.
00:13:33.269 --> 00:13:36.750
Because when you think of about, let's say, okay, let's take gets beef.
00:13:36.769 --> 00:13:47.870
For example, what's important when you think about gets beef in the context of a service net, like Algolia Nety is that it should be the most Gadsby ask experience.
00:13:48.289 --> 00:13:58.580
That's the role of this aspect, like gets be this strategy, this part of the product, it should be about being the, the more, or gets BX experience for the person that's using it.
00:13:59.379 --> 00:14:01.700
Anything else should probably be at lower level.
00:14:01.759 --> 00:14:14.059
And so that, you know, that layering aspect to me is really core to the problem thinking in layers and making sure that every part is really responsible for what it is strong about, what matters about it.
00:14:14.159 --> 00:14:17.090
And that's not really just an engineering issue.
00:14:17.320 --> 00:14:19.450
It's really a, a product problem.
00:14:19.600 --> 00:14:21.250
It's how you design things.
00:14:21.830 --> 00:14:27.809
So every part solves the exact problem that it is going to be good
00:14:27.909 --> 00:14:28.129
At.
00:14:28.570 --> 00:14:36.559
I think that's really important to highlight here is the DX team at LFI in particular is just one aspect of how we manage DX across the entire right.
00:14:36.580 --> 00:14:44.840
So my team specifically with Jason Casy, Tara, Phil, and Kenny, we represent a very specific team within Netlife I, as far as like community outreach.
00:14:45.059 --> 00:14:54.679
So, you know, obviously coming on and being able to talk with you, writing blog posts, creating content, as well as exploring and interacting with the communities, but we're not also solely responsible for DX across the company.
00:14:54.899 --> 00:15:04.200
We have integration teams who are responsible for like the engineering aspect of taking what the things we've learned about and bringing it back into the core product and figuring out how they can improve that.
00:15:04.759 --> 00:15:10.200
It's really important to highlight that there's a lot of teamwork going on and a lot of different teams involve in making net what it is
00:15:10.730 --> 00:15:12.149
As a view Corps member.
00:15:12.330 --> 00:15:22.629
How have you witnessed that being a part of this community as whole so helped inject better DX at Nety and maybe vice versa.
00:15:22.970 --> 00:15:27.990
How maybe did you witness that your involvement at Netlify and being in that space?
00:15:27.990 --> 00:15:38.899
Like it's probably the most popular platform did help or did you witness it help when it comes to how you think of new features on view, on view, press on V press
00:15:39.990 --> 00:15:42.730
My involvement with the view community, I think has been a mutually beneficial one.
00:15:43.070 --> 00:15:47.529
One of the things I really love about the view community is that it's always willing to learn from others, right?
00:15:47.590 --> 00:15:49.090
It doesn't try to reinvent the wheel.
00:15:49.091 --> 00:15:54.360
And it says when the framework does something, well, it tries to explore with that concept and figure out it does this solve the problem.
00:15:54.509 --> 00:15:59.799
Well, and so, for example, Evan's been playing lately with like a sugar ref, um, RFC right.
00:15:59.801 --> 00:16:05.759
Request for change, where it actually kind of mimics the felt syntax, which a lot of people find really weird, right?
00:16:05.919 --> 00:16:07.039
Cuz it's not traditional JavaScript.
00:16:07.041 --> 00:16:22.909
These are the kind of things that are great to think about because for technology to move forward, we have to be willing to try new things that might feel foreign because I think a lot of people, especially in tech now forget that like a lot of things you're familiar with with vanilla JavaScript, you know, quote unquote is actually things that came from the jQuery days.
00:16:22.909 --> 00:16:26.110
Like it was an external library that like they did such a good job with it.
00:16:26.110 --> 00:16:27.149
They made it part of the core.
00:16:27.250 --> 00:16:33.779
And so when libraries are trying new things, I think we have an inherent like, oh no, that's not the view way or the react way.
00:16:33.780 --> 00:16:41.820
Like to me, it's like if it solves a problem that helps to move the web forward, that is the more important thing rather than sort of being comfortable with like the one way of doing things.
00:16:42.360 --> 00:16:56.330
And so similarly, you know, in the Netlife I ecosystem, I, I am always really happy to learn how other people are doing things because one of the challenges that we have with deployment of websites is what happens when you are, when you wanna have long build times, how do we solve that problem?
00:16:57.070 --> 00:17:09.009
And so, you know, learning from the different architectures and thinking about how we can make a solution that works well across the web was one of those things where yeah, it's super exciting to see all the different solutions and try to piece together.
00:17:09.009 --> 00:17:09.930
What makes the most sense?
00:17:10.130 --> 00:17:15.200
I think that's what view I think I learned a lot from view it's like at extract away certain things, right?
00:17:15.201 --> 00:17:21.839
So example we have the template block, which is basically HTML, but there are a lot of people that are like, oh, well sometimes I really need programmatic HTML.
00:17:21.960 --> 00:17:23.160
I need, JSX great.
00:17:23.500 --> 00:17:24.960
We have a render function for you.
00:17:24.961 --> 00:17:33.839
But like in the 90% of use cases where you don't need a render function, just use HTML that I know that guy's a lot of the ethos, as far as my creation of tooling and solutions,
00:17:34.730 --> 00:17:38.269
That's actually a really good segue to, to something that I wanted to ask you.
00:17:38.299 --> 00:17:50.559
Like, you briefly mentioned the way you build, you know, when you think about static side generation, especially when that's something that you are really familiar with, it may look like, oh, it's a solve problem, you know?
00:17:50.589 --> 00:17:50.880
Yeah.
00:17:50.881 --> 00:17:51.160
Okay.
00:17:51.161 --> 00:17:57.759
You're going to compile a website you're going push to get, and then you're going to specify what your bill command is.
00:17:57.900 --> 00:18:01.640
And then the directory in which the files are gonna be, and then that's it.
00:18:01.660 --> 00:18:06.000
But what I find really interesting is that it also means new problems.
00:18:06.019 --> 00:18:08.440
You know, like new patterns are starting to emerge.
00:18:08.900 --> 00:18:15.269
When you think of next JS, for example, they created what they call incremental static regeneration ISR.
00:18:15.970 --> 00:18:20.029
And the goal is to basically avoid long builds when you have large websites.
00:18:20.030 --> 00:18:25.509
So instead of recompiling everything, you are going to compile on demand, but such a feature.
00:18:26.390 --> 00:18:27.750
It is not just one new thing.
00:18:27.859 --> 00:18:29.940
It's also, it has implication.
00:18:30.119 --> 00:18:33.140
It has consequences on the infrastructure.
00:18:33.880 --> 00:18:40.779
And so I'm wondering because that might be an easy problem when all you focus on is next, it like it has its challenges.
00:18:40.780 --> 00:18:55.730
But on top of that, when you are Nefi, you are a universal platform, you need to cater to everybody including next JS, but not only when you have so a responsibility of catering to many communities, but you need to stay abstract enough.
00:18:56.150 --> 00:19:03.170
How do you keep up with those kinds of problems that need probably more tech than you initially intended for that problem?
00:19:04.039 --> 00:19:05.980
You know, we're talking about long tail bills, right?
00:19:06.000 --> 00:19:10.809
So, you know, for the audience who might be new to this problem, imagine you have an e-commerce site, right?
00:19:11.130 --> 00:19:17.970
Like I say, it has thousands of items, but the truth is, is that maybe only like a hundred of your items are the ones that are kind of most frequently visited.
00:19:18.589 --> 00:19:26.890
And so with the traditional static site generation model, every time you build the site, you need to generate all thousand pages along with anything else that results.
00:19:27.190 --> 00:19:31.440
But at the same time, part of you probably also wonders, like, is that really necessary, right?
00:19:31.599 --> 00:19:46.279
Cause that result in long build times, which then as we talked about earlier, like that increased the amount of time it takes to get feedback, the concept being talked about here, um, which we're sort of terming like distributed persistent rendering is this idea that what if you could only build the files that you needed up front.
00:19:46.279 --> 00:19:50.359
So you, you marked these specific pages as like, these are the main ones that need to go immediately.
00:19:50.740 --> 00:20:01.069
And the, then in the future, if anyone requests anything that's like outside of that realm and we have the data for it, we will then generate those pages for you dynamically and then cash them according to that build.
00:20:01.289 --> 00:20:05.430
And so this is sort of another solution, like we're turning it on demand builders and net Lai.
00:20:05.890 --> 00:20:08.230
And so this is part of the challenge part, right?
00:20:08.420 --> 00:20:15.980
When we create solutions, we want them to be in a way that like solves everyone's problems, it's sort of a generic solution that applies to your framework regardless.
00:20:16.680 --> 00:20:30.180
And the reason that's important is because as we know, frameworks do come and go, we happen to be in kind of like a nice period where frameworks seem to be stabilizing, but we know that it doesn't take much in technology to have all of that disrupted and have the kind of the ecosystem switch.
00:20:30.400 --> 00:20:59.839
And so similarly to how we try to auto make deployment in a way that's like not specific to a specific framework, we wanna make sure that similarly, when you're trying to create these sort of architectural patterns that allow you to define core pages and then the ones that will be returned later, we wanted to think, how can we make it easier for framework authors and whatever framework come up in the future to also leverage these architectural models so that they can then take advantage of it without feeling like, oh, well this is the view way of rendering things versus like the react way of rendering things, right?
00:21:00.099 --> 00:21:04.640
We all know that at the end of the day, their webpages that are like, that's all the customer cares about.
00:21:04.641 --> 00:21:06.829
They get their HTML, their CSS and their Java as script.
00:21:06.830 --> 00:21:08.910
However, it gets there doesn't matter.
00:21:09.049 --> 00:21:11.950
So the more we can make that easier for people to do better.
00:21:11.951 --> 00:21:12.269
It is
00:21:13.380 --> 00:21:22.920
You mentioned it, we're probably in a sweet spot right now because there, a lot of things are stable and there's more and more qualified people working on it.
00:21:23.099 --> 00:21:35.829
The experimentation is usually a bit more fruitful than it was back in the days where we're transitioning between the old way of doing, uh, making website or building JavaScript or anything in relationship to, to what we have today.
00:21:36.289 --> 00:21:43.990
Now, one thing to, to stress is that it is okay to take the time, to really find the right angle.
00:21:44.099 --> 00:22:01.539
Because when you think about ISR or DPR, like it's not just a new hot feature, it's one solution to a symptom of a bigger topic in gems stack four, for that matter, that's okay to take the time to really think about it from a higher level.
00:22:01.920 --> 00:22:03.500
We see it in Angolia every day.
00:22:03.500 --> 00:22:21.650
Like we have customers who are very specific requests and that's actually awesome, you know, because it gives us concrete application examples, but it doesn't mean that we have to jump on it and make it, or as is we can take the time, you know, to reflect and, you know, take a step back and think about it more holistically.
00:22:22.069 --> 00:22:23.130
And to me that makes sense.
00:22:23.131 --> 00:22:30.920
Like, that's really the role that you have when you built such platforms in a way like that was the initial idea, always network based APIs, right?
00:22:31.180 --> 00:22:33.039
We need access to a functionality.
00:22:33.259 --> 00:22:41.440
And regardless of what it is, in what language it's written, we just want to have access to that thing in a way that works for everything.
00:22:41.460 --> 00:22:45.799
And so then this abstraction came in and it powers a huge part of the web.
00:22:45.800 --> 00:22:48.799
Like you have web hooks, et cetera, all built on top of that.
00:22:48.900 --> 00:22:56.789
And that also what Algolia evolved to, uh, I don't know if you know the story, but we used to be a mobile, offline search engine.
00:22:57.019 --> 00:23:02.750
That was Algolia at the very beginning, it was running on your phone and now we are a rest API base.
00:23:02.809 --> 00:23:19.140
So we are able to actually power any kind of stack, anything that runs in a client can power Algolia I think when good takeaways that those problems that you see and those patterns, it can feel like, oh, that's the new thing I need to hop.
00:23:19.210 --> 00:23:20.579
Like, jump on that horse.
00:23:21.329 --> 00:23:28.460
It's actually really much more interesting to take a step back and to think broader, what is the actual problem?
00:23:28.769 --> 00:23:30.019
What are we trying to solve?
00:23:30.690 --> 00:23:33.490
And how can we build something that's sustainable?
00:23:33.549 --> 00:23:39.130
And that's probably, even if we don't know the future, that's probably going to span some future cases.
00:23:39.640 --> 00:23:39.930
Yeah.
00:23:40.089 --> 00:23:43.450
I really love that this focus on the problem you're solving is something.
00:23:43.451 --> 00:23:46.039
I think that a lot of engineers often forget, right?
00:23:46.069 --> 00:23:49.319
When you have the latest hottest trend, why are you implementing this?
00:23:49.320 --> 00:23:49.519
Right?
00:23:49.660 --> 00:23:51.319
Why are you using static site generation?
00:23:51.320 --> 00:23:51.440
Right.
00:23:51.720 --> 00:23:56.640
Everyone says to do it, but like maybe it makes more sense for yours to be like just a single single page application.
00:23:56.641 --> 00:23:56.880
Right.
00:23:57.240 --> 00:23:58.200
I think people forget, right?
00:23:58.201 --> 00:24:00.559
Every engineering decision you make comes with trade offs.
00:24:00.560 --> 00:24:02.200
There's no perfect solution.
00:24:02.450 --> 00:24:08.390
Maybe it solves a problem in a perfect way, but it won't solve the same, like another problem in the same way.
00:24:08.650 --> 00:24:24.829
The other thing I think that's worth mentioning is you mentioned like, as these concepts come up, right, like we were talking about like DPR ISR, this stuff, it's kind of interesting because I think for engineers who have been in the space for a while, it feels like a lot of the stuff coming back is the way that it was used to be done, which is kind of interesting.
00:24:25.289 --> 00:24:28.579
Like a lot of front end theories are originating in backend.
00:24:28.769 --> 00:24:30.859
Like they're like, oh, backend did this years ago.
00:24:31.160 --> 00:24:37.299
And I think it's funny in the development culture of this need to like assign, oh, well this came from this, this came from this.
00:24:37.319 --> 00:24:40.859
But really if you ask me at the end of the day, are we solving problems?
00:24:40.861 --> 00:24:41.700
Are we moving forward?
00:24:42.420 --> 00:24:49.930
I think it's, that's much a much more fruitful discussion over of the whole like, well, the, you know, that this is actually just basically server side rendering.
00:24:49.931 --> 00:24:51.650
We've been doing this for 30 years.
00:24:52.130 --> 00:24:55.410
I prefer not to get into those sort of arguments with, with this kind of stuff.
00:24:55.950 --> 00:25:02.809
That's a very human thing, you know, to try and draw connections between things that you think are the same, like, oh, there's the new thing.
00:25:03.069 --> 00:25:05.170
How does it relate to something that I already know?
00:25:05.369 --> 00:25:18.960
Like that's kind of re reassuring for you to be able to put it in the same box because that, that means that you probably don't have to learn it, but at the same time, what can be, as you said, more fruitful in the conversation is what kind of new problems are we solving?
00:25:19.279 --> 00:25:39.750
I say that it's, it's pretty, you reassuring that we are reusing work that has been developed a while ago would be probably sad to see that we are throwing everything and that all that work, that, all that research or that all that knowledge, all that technology is really gone.
00:25:39.779 --> 00:25:41.150
Like there is nothing left from it.
00:25:41.299 --> 00:25:45.710
There's a lot to learn from how things used to be done.
00:25:45.980 --> 00:25:56.859
Even before static side generation was a hot word, like before the Jack days, basically people used to statically generate some of their sites for security reasons.
00:25:57.319 --> 00:26:03.140
And back then, like most people thought they were crazy to do that because it was like, yeah, your website is not dynamic.
00:26:03.410 --> 00:26:08.049
Like, you know, to me, that's quite reassuring to go back to developers experience.
00:26:08.050 --> 00:26:23.690
That's the point of the, the conversation today is that you part of, to me, of the developer experience and having a good developer experience is to be able to reuse things that you already know is to be able to leverage the knowledge that you have.
00:26:23.829 --> 00:26:26.609
Not everybody comes in that space with the same baggage.
00:26:26.720 --> 00:26:28.920
Some people started react, developers.
00:26:28.921 --> 00:26:32.920
Some people started as WordPress developers, whatever, even not even developers.
00:26:32.980 --> 00:26:38.880
But what's interesting is that we can reuse prior arts to solve new problems.
00:26:39.009 --> 00:26:52.960
There are things that exist today that were not even a conversation back in the days, things like, and now of course like this is not a new problem, but when you think of stuff like responsive design, like I clearly remember that shift.
00:26:53.559 --> 00:26:57.440
There was a time where we didn't care at all about responsive web design.
00:26:57.539 --> 00:27:02.869
Nobody cared about it because nobody had a smartphone to where they wanted to look at a site.
00:27:03.009 --> 00:27:05.589
But today that's something like that's important.
00:27:05.720 --> 00:27:06.910
There are ways to think about that.
00:27:06.930 --> 00:27:14.470
But then the, I would say the more, the faster your computer is, you're probably less and less tolerant to performance lags.
00:27:14.471 --> 00:27:19.230
You know, you don't want anything to be slow when everything on your machine is, is really fast.
00:27:19.490 --> 00:27:29.380
And at the same time, you have people who can ha now I access the internet who couldn't before, but they're not doing it on the same devices that you and I are using.
00:27:29.640 --> 00:27:30.940
So those are new problems.
00:27:31.180 --> 00:27:33.859
Those, and they are not technical problems.
00:27:34.059 --> 00:27:34.900
They are human problems.
00:27:34.901 --> 00:27:39.740
Then they are around individuals, around people, existing information.
00:27:39.740 --> 00:27:41.380
That's what technology is here to bridge.
00:27:41.740 --> 00:27:46.170
A lot of actually I think DX as well, all is about that incremental improvement.
00:27:46.171 --> 00:27:46.369
Right?
00:27:46.450 --> 00:27:51.970
I think we oftentimes forget that technology, when we evolve, we took older concepts, right?
00:27:51.971 --> 00:27:57.809
Like you said, static site, for those who like built, who used to ship via FDP, that was technically all static, right.
00:27:57.810 --> 00:28:04.640
If we were using the, the hot term, but really what we've done is like over time, we made it easier to do things that would've he to do.
00:28:04.641 --> 00:28:04.839
Right.
00:28:04.840 --> 00:28:11.400
Because those of us know that like when you deploy the same style that CSS filed multiple times, you have a weird caching thing, right?
00:28:11.401 --> 00:28:12.599
People don't get the same one.
00:28:12.900 --> 00:28:13.599
So what do we do?
00:28:13.601 --> 00:28:15.759
We started appending custom hashes to it.
00:28:15.980 --> 00:28:23.440
And so then this is why the build process started getting appended because we wanted it to make sure that we were deploying unique assets, that people could actually get the newest thing faster.
00:28:24.359 --> 00:28:36.390
Uh, and so a lot of times like your, I think to your point, Sarah, like when we take ideas that have existed and we can increment them by just like, you know, 1%, but we consistently make that 1% increase.
00:28:36.509 --> 00:28:39.029
I think we forget that that has a compounding effect over time.
00:28:39.410 --> 00:28:43.670
And that's one of the reasons why we are in a little bit of a stickier situation now with like build tools and stuff.
00:28:43.671 --> 00:28:43.829
Right.
00:28:44.029 --> 00:28:44.950
Cause people are like that.
00:28:45.160 --> 00:28:54.380
So complicated from where the way it used to be, but there are reasons why we needed this because the problems have advanced and they've gotten more trickier as we deal with your point new devices and all these things.
00:28:54.490 --> 00:28:55.700
It's a fun space to be in.
00:28:56.390 --> 00:28:57.059
Definitely.
00:28:57.160 --> 00:28:57.380
Yes.
00:28:57.640 --> 00:29:05.420
On the last episode, uh, we had Adam more than with us from tailwind and I really liked the way that he summarized the X E.
00:29:05.890 --> 00:29:10.690
He said, basically that it is providing superpowers without getting in the way.
00:29:11.009 --> 00:29:12.450
I really love this definition.
00:29:12.589 --> 00:29:20.690
And again, when you are a generic service, like you, you amplify your Algolia, you care about many people, not a specific usage.
00:29:21.269 --> 00:29:23.089
You're not tied to specific technology.
00:29:23.710 --> 00:29:24.769
How do you achieve that?
00:29:24.869 --> 00:29:28.799
How do you provide superpowers without getting in the way?
00:29:28.800 --> 00:29:36.440
And especially it's easy, you know, to care about the hot things and to have some that are left behind.
00:29:36.500 --> 00:29:47.480
So how do you, for example, ensure that N users feel as catered for as Gadsby users and similarly that JCO users don't feel left behind
00:29:48.019 --> 00:29:51.160
One of the nice things I think about, even though you're managing different frameworks, right?
00:29:51.161 --> 00:29:59.000
If you're running a tool that has like you're servicing different customers, is that typically the users aren't necessarily like they're not using Gatsby and nuts at the same time in those cases.
00:29:59.000 --> 00:29:59.319
Right.
00:29:59.619 --> 00:30:07.109
But at the same time, I think when people feel like you've created a good developer experience for them, it's about kind of like to Adam's point, right?
00:30:07.490 --> 00:30:16.750
You are giving them you're supercharging their past so that you can let them do something and then let them do it in a way that's not like as few configurations as possible.
00:30:16.910 --> 00:30:20.670
I think that's one of the key things to a lot of good developer experience for getting started.
00:30:20.671 --> 00:30:20.910
Right.
00:30:21.089 --> 00:30:27.059
Because if you knew that, like when you started the card, you had to like, press all these buttons before putting in your key and then turning it on, right?
00:30:27.059 --> 00:30:28.339
Like that's a lot of work.
00:30:28.640 --> 00:30:34.779
And so the more we can reduce the barrier of entry into tooling and then allow to incrementally grow on it.
00:30:34.780 --> 00:30:34.980
Right.
00:30:34.980 --> 00:30:41.460
This is one of the reason why, for example, the view community also starts you with templates because we wanna leverage what you already know with HTML.
00:30:41.910 --> 00:30:46.690
And then certainly when you have additional problems you wanna solve, then we can then give you the render functions.
00:30:46.691 --> 00:30:48.450
We can give you other things to make it better.
00:30:48.869 --> 00:30:55.210
And so with Netlify as well, like a lot of people, I think with their entry point, when Nety is like deploying their sites, right.
00:30:55.269 --> 00:31:03.440
Making it easy so that each and every time you push a commit or you add a new branch that it creates those deploy previews for you and makes it so easy to integrate.
00:31:03.441 --> 00:31:08.400
Like, all you do is hook up your GitHub, repo, like you said, to like define the customizations.
00:31:08.900 --> 00:31:11.880
And so, for example, like you were talking about framework experience, right?
00:31:12.059 --> 00:31:17.680
And so this is why when you hook up a repo with Alii, we try to detect in advance, which framework you're using.
00:31:17.940 --> 00:31:19.400
So we can automatically populate.
00:31:19.401 --> 00:31:19.680
Right?
00:31:19.750 --> 00:31:24.430
It's one less thing that you have to go into your package, that out JSON to figure out what's your build command.
00:31:24.431 --> 00:31:28.829
And then like, we automatically populate for that for you, so that you can then ship it and then see how that goes.
00:31:29.130 --> 00:31:44.500
And then once you're there, then you can start being like, okay, now that everything's deploying really smoothly, I can start thinking about things like, how do I want my red RXs to be, or maybe we start integrating serverless functions into our application to make things easier and like on unlock a whole world of possibilities.
00:31:44.559 --> 00:31:52.059
That's really, the key is making people feel comfortable in the space that you're in so that they can then feel basically confident enough to then take that next step.
00:31:53.119 --> 00:31:53.279
All right.
00:31:53.420 --> 00:31:56.279
And so for our question would be, how does that scale?
00:31:56.660 --> 00:32:04.589
So many different platforms, so many different solutions, you can create a JAMstack website with different languages, different frameworks.
00:32:04.769 --> 00:32:11.230
How does that scale, how do you make sure that you can keep up with a wide variety, uh, of
00:32:11.230 --> 00:32:11.509
Tools?
00:32:11.700 --> 00:32:20.349
Nice thing about, especially the way that nullify has architected, it is that, you know, with technology, it becomes, luckily our build tools, aren't changing that quickly, that we need things to be every day.
00:32:20.769 --> 00:32:27.140
And so, as a result, we basically have a manifest and we figure out what the highest impact is as far as the sites that we see people trying to deploy with.
00:32:27.200 --> 00:32:29.700
And this is also why it's really important to be in touch with their community, right?
00:32:29.701 --> 00:32:37.740
Because you might have a lens as far as like your analytics and your metrics, but if you're actually listening to what the community is talking about, a lot of times, that'll let you get ahead of things.
00:32:37.759 --> 00:32:41.079
As far as like, this is a new framework that's coming up, that people are trying out.
00:32:41.099 --> 00:32:48.440
And so that might be a job, for example, my team, to go and build some test deployments and figure out how do those demos work in relation to our current workflow.
00:32:48.441 --> 00:32:51.079
And are there things we can learn and improve as far as that goes?
00:32:51.670 --> 00:32:53.200
Yeah, that that's really interesting.
00:32:53.440 --> 00:33:02.069
And I think it's also, it's, uh, highlights kind of a hybrid role that is starting to grow and we call it developer advocate.
00:33:02.250 --> 00:33:04.069
But that term is really loaded.
00:33:04.309 --> 00:33:07.190
And in the mind of, of different people, it means different things.
00:33:07.250 --> 00:33:22.700
But I think there's something really interesting in having actual ICS, like people really building the tooling, building the production software, also being in the community and being involved and being around people and discussing with people.
00:33:22.880 --> 00:33:31.420
To me, the, the developer advocacy realm is really much bigger than what we have in mind for, for, from maybe five years ago.
00:33:31.839 --> 00:33:44.329
But that really outlines the necessity for engineers to be much more product oriented, which is actually really exciting, especially when you're building for developers, which is what we both do.
00:33:44.460 --> 00:33:46.569
We're building tooling for other developers.
00:33:47.109 --> 00:33:48.690
You are kind of your own customer.
00:33:48.799 --> 00:33:54.170
Like you're supposed to be interested in those problems because they are the problems that you want to solve for yourself.
00:33:54.670 --> 00:34:07.160
And it is much more interesting to be in touch with the community in touch with the actual concerns that that people have, because it's going to make you a better developer.
00:34:07.579 --> 00:34:22.150
You have, it's so much more interesting that when you can have an impact on the roadmap, when you are able to say, Hey, you know, that thing is really what we should be looking at right now, because when you are on the field, that's something you can see, people are into that.
00:34:22.210 --> 00:34:24.269
And if we don't do that, we're gonna use the train
00:34:24.489 --> 00:34:25.630
To build on what you were saying.
00:34:25.750 --> 00:34:47.980
I think this is what I think is what I really love about what Sarah did with the team and what I'd love to see more companies do is like with developer experience to allow them the opportunity to be basically hybrid engineers, as well as advocates, cuz I know that's so I think that's a lot of the topic of discussion around this right now is that to your point, if you're not helping to build the product that you're helping to advocate for, it's kind of a weird separation, right?
00:34:48.219 --> 00:34:53.739
It, it actually synergizes really well when your advocates are also involved in product discussions.
00:34:54.039 --> 00:35:02.090
And Sarah did a really great job as far as helping to ensure that the net DX team has that like has a voice in the engineering department as well as is in product.
00:35:02.269 --> 00:35:03.769
And just sort of having that all around.
00:35:04.489 --> 00:35:09.489
I can confirm even from the outside that Netflix, I is really the, probably the model for that.
00:35:09.490 --> 00:35:15.889
Like there is such a really great grasp at community in this company and we can see it from the outside.
00:35:15.949 --> 00:35:16.769
That's really amazing.
00:35:16.800 --> 00:35:19.610
Like the, the work you've done with the, the DX team is really incredible.
00:35:20.050 --> 00:35:25.280
I have one question for you, specif is I'm going to put you on the spot with that.
00:35:25.460 --> 00:35:30.039
How do you specifically as a person, how do you define great DX?
00:35:30.349 --> 00:35:33.280
What is your level of expectation?
00:35:33.599 --> 00:35:33.719
All right.
00:35:33.739 --> 00:35:51.079
So to me, great developer experience is striking that balance between abstracting away a problem that people have consistently while leveraging models that they already have up to a point where it's the Preto principle of where for 20% of effort you get 80% of impact, right?
00:35:51.440 --> 00:35:55.599
I think this is where people feel really excited to keep continuing with a tool.
00:35:56.219 --> 00:36:09.510
How ever, I think there comes a point where it becomes overly opinionated and when people need to break out of it, if you've locked themselves in too much, then this is where I think people do have the bad experience of like, you know, it was great at first.
00:36:09.769 --> 00:36:15.710
And then by the time I got in, and then I had a problem that I needed to customize, it was like a nightmare to get out of it.
00:36:16.010 --> 00:36:17.300
To me, that's not good to DX.
00:36:17.300 --> 00:36:19.460
It just means that you've solved one particular path.
00:36:19.960 --> 00:36:21.900
And then you are like, good luck after that.
00:36:21.900 --> 00:36:22.179
Right?
00:36:22.420 --> 00:36:26.179
Like, you know, if you did it my way, then you're great, but the moment you wanna do it a different way.
00:36:26.250 --> 00:36:27.900
Like to me, that's not necessarily good DX.
00:36:28.139 --> 00:36:29.019
That's, that's a really strong opinion.
00:36:29.280 --> 00:36:36.139
And then, so this is why I think the other half of DX comes with the allowing people a way to then customize how they do things from there.
00:36:36.141 --> 00:36:37.969
So I, I like to call'em escape hatches.
00:36:38.269 --> 00:36:46.849
The more you can allow people to do that, I think the, the better you get to a point where you really do allow people to kind of customize the solution to really their own.
00:36:47.110 --> 00:36:50.969
For example, most of us don't wanna be solving cashing problems, right?
00:36:50.971 --> 00:36:51.530
Like that's a problem.
00:36:51.769 --> 00:36:53.250
Most we just wanna build, develop.
00:36:53.250 --> 00:36:56.610
And we, as long as the customer gets what we like the latest and greatest, we are happy.
00:36:56.630 --> 00:37:02.440
We don't need to know, you know, which caching methodology is being used, like security protocols.
00:37:02.440 --> 00:37:06.760
How many of us wanna be dealing with authentication managing those are things you do kind of wanna abstract away.
00:37:06.820 --> 00:37:14.239
And those, I would say are great examples of where it might not necessarily make sense for you to allow someone to customize security credentials, because that has a big foot gun.
00:37:14.240 --> 00:37:14.440
Right?
00:37:14.460 --> 00:37:19.949
And so for those who are, aren't familiar with the term, just like ways for people, for developers to make MIS stakes, that they can't come back from.
00:37:20.289 --> 00:37:28.309
So it really is a delicate balance of like providing enough opinion so that they feel empower to get started escape hatchers to customize it.
00:37:28.570 --> 00:37:41.059
But then also like considering the foot guns of where, well, if we give developers this much power to customize, they might end up breaking things or they might end up like doing things that harm their customers, leaking sensitive data, that kind of stuff in that case, let's shield them.
00:37:41.061 --> 00:37:41.219
Right.
00:37:41.221 --> 00:37:45.539
And so, and as we mentioned before, earlier in this show, there are always trade offs, right?
00:37:45.610 --> 00:37:48.739
Like to some extent you can always abstract things.
00:37:48.760 --> 00:37:57.980
To some extent you can allow customization, but Maning those trade offs for your customers and listening to your community, I think will be the key in striking that solid DX for your audience.
00:37:58.900 --> 00:38:08.369
The, I, I really, you love with everything that you just said, and I think that's, uh, that's really a perfect point, uh, to wrap onto Ben, where can people go to find you online?
00:38:08.400 --> 00:38:08.690
Yeah.
00:38:08.690 --> 00:38:11.650
You can find me under the moniker, Ben code Zen.
00:38:12.150 --> 00:38:18.289
And so whether it's Twitter, YouTube, Twitch, I think I've got a handle on, I think I've got most of the platforms luckily.
00:38:18.630 --> 00:38:25.039
And so if you're looking for me on whatever reply from them on you just find me at www dot Ben code, zen.io, and you'll find all my stuff there.
00:38:26.469 --> 00:38:26.590
All right.
00:38:26.829 --> 00:38:30.630
And so you can find me at front stuff underscore IO on Twitter.
00:38:31.090 --> 00:38:38.719
If you're looking for Algolia stuff, it would be on@algoaontwitterandyoucanfindusonalgolia.com.
00:38:39.619 --> 00:38:41.760
Ben, thank you so much for coming.
00:38:41.760 --> 00:38:42.360
Thanks so much.
00:38:42.360 --> 00:38:42.920
It's been great.
00:38:43.389 --> 00:38:47.639
This was developer experience, a podcast brought to you by Algolia.
00:38:48.219 --> 00:38:51.000
You can find this podcast on your favorite podcast platform.
00:38:51.940 --> 00:38:59.190
If you want to know more about Algolia check out@agoya.com and we are at Algolia on Twitter.
