Le bleu était whisky et frustration,
surtout frustration,
presque des pierres,
en prenant sur cette idée
qu'on pourrait faire le Webkit que nous voulions.
La même chose qui s'est annulée avec le Web.
Flutter a commencé à ne pas faire Flutter.
Nous ne voulions pas construire un tool de multipli.
Ce que nous essayons de faire
est de construire une mode rapide pour le Web.
Hello, welcome to DevTools FM.
This is a podcast about developer tools.
And the people will make them.
I'm Andrew and this is my co-host Justin.
Hey everyone, good to see you again.
It's been a little bit since our last episode.
We're excited to have Eric Seidel on with us.
So Eric, you are the brain
or one of the brains behind Flutter,
which is such a cool project.
And you also worked on Dart,
which I have so many questions about.
So I am incredibly excited to chat with you today.
Before we dive in and talk about what you've been doing.
And like these recent days,
would you like to tell our audience a little bit more about you
and like what you've done in the past
and how you got to where you're at?
Sure thing.
So yeah, I'm a midwestern boy
who ended up out in California 20 years ago to work for Apple.
And ended up at Apple, then ended up on Safari,
did web browsers for a very long time,
ended up YC back in 06, long, long time ago,
had a failed fashion social network
that I built with a friend.
And then went to Google, did Chrome,
did WebKit there, started the Blink project there,
then started Flutter, led the Flutter team and later Dart.
And then I left there about three years ago
to start my current company, Shorbert,
where we're trying to take Flutter further than I could at Google.
And we build a CodePush product,
let you update your Flutter app without waiting for the stores.
Yeah, quite the long resume there.
Lots of foundational technologies
that have defined like the past 20 years or so.
Can we start at the beginning
and what got you into browsers at first
and what were like some of your major accomplishments
that you added to WebKit early on?
And are they still there today?
Yeah, surprising number of them are.
Apple takes a...
Apple's very good at simplicity, which is great.
And so, yeah, some of the things that I made are still there.
So, how did I get into browsers?
I got into browsers very unexpectedly, unintentionally.
I was not trying to get into browsers.
I was a UI engineer at Apple working on Sync Services.
Sync Services, this is back, predates the iPhone, right?
So you would hook up your PalmPilot to your Mac
and it would sync your contacts
and tell you that you have two copies of your own Linda
and one of them has the wrong middle name
and then my UI would show up and let you pick and all that stuff.
Obviously, all that tech has long since removed,
but I was working on that team
and this was the end of Leopard, Snow Leopard, Panther,
something like that.
And Apple gave us a month off,
where we were still working,
but we could work on things that we thought were interesting,
thought were important.
We sat right next to the AppKit team,
so we went to lunch with them
and they had all these cool demos
about how you could build a text editor in five minutes
or whatever, and I wanted to build an illustrator,
kind of like a simple sketch app in five minutes.
But in order to do that, I needed a drawing framework.
In order to do that, I needed a file format.
And so that introduced me to SVG.
I found SVG and then I started writing a SVG framework for Mac.
I wrote, I think it was SVG Kid or SVG Core or whatever
in this one compressed month.
I wrote it all in Objective-C.
I got a couple of weeks in, SVG is stupidly complicated.
It's a little better these days,
but back then they were working on SVG 1.2
or something, you freaking had a networking stack
inside your graphics rendering a socket API.
It was crazy.
Anyways, so I had started implementing just a basic SVG.
It was too complicated.
I went looking for an existing implementation.
I found KSVG from the KDE project.
I ported that to Mac.
Rebuilt my system on top of that.
And then I demoed this to our VP at the time.
This was at the end of this one month thing.
It got forced all.
And he was like, this is great and all,
but we shouldn't ship this as a framework.
You should go work on Safari.
And suddenly I was on the Safari team
and was then asked to own XML.
Cause this was like, we were like, I don't know,
what, 10 people, 15 people or something like that.
It was very early.
And I was asked to own XML.
I did work on XMLHCP request and XSLT processor.
And then I did performance related work
and did a bunch of bot and testing stuff for them.
I helped start the windows webkit project.
I like literally created the visual studio code project
or the visual studio was visual studio code
didn't exist at the time project.
Yeah, it was, it was a, you know,
young ambitious 20-something
who was just floundering their way around Apple at the time.
And I got dumped into the web and I really enjoyed it.
And then I left Apple.
Again, being a young ambitious 20-something
and thought I should start a company
I ended up in Y Combinator
cause of the startup school stuff,
the Paul Graham coming, giving talks at Stanford,
which is just down the street from Apple
or just 10 miles away or something from Apple.
And went to that talk, met my future co-founder,
got sucked into YC, left Apple.
That was a very interesting learning experience
of 15 months of not having any idea what you're doing,
banging your head.
Back then Y Combinator,
they gave you a whopping $18,000.
Wow, that is so little.
That's crazy.
And these days they give you a half a million
or something like that.
But, you know, it was like 7% of your company
for $18,000, which was up from 12,000,
which was the previous batch.
And, you know, we lived off of my Apple savings
and tried to build a,
we first built a fashion search engine.
We connected to, I don't know, Banana Republic
and I think nascent Amazon kind of stuff
and built like a something that Google did better
with like Google shopping many, many, many years later.
So we built that and that didn't go anywhere.
And so then we built a fashion shelter network.
I have no idea why we're doing fashion
cause I am not a fashion forward guy to guy.
And we actually had some customers,
not paying customers, but people using us.
Etsy was really new at the time
and Etsy people needed a way to show off
what they were selling.
And Etsy has much more sophisticated tools
for that these days,
but they would use our like closet
and they would use our collage tool to do that.
But we never talked to our users
and the big user from all, big,
big thing I learned from all that,
which I would say to your dev tools,
listeners has talked to your users.
We never talked to our users
and so we never built something people wanted.
And that flamed out after 15 months.
And then I got recruited into Google.
I thought I was gonna go back to Apple.
I was not probably literally living
in my parents' basement,
but pretty close at the time
after my YC, I went and hiked the Appalachian Trail
on a whim, was out there for three and a half months,
recentering and the wilderness.
But then I came back to my parents' house
and thought I was gonna go back to Apple
and ended up getting recruited into Google instead,
kind of on a last minute.
The VP in charge at the time, Linus Upson,
took me and sat me down and said,
I can't tell you what you're gonna work on,
but if you don't like it,
I will help you find a job that you do like inside Google.
And I was willing to take that bet.
Then it turns out he was building Chrome.
He and Sundar were building Chrome.
It was awesome.
I came with all this WebKit experience.
I was a senior reviewer in WebKit.
You know your startup's going wrong
when you start doing your old job.
And when the startup was going wrong,
I started working on WebKit for fun.
And so, then I got to do it for full time at Google
in the early days of Chrome.
And yeah, that was just a blast.
It was another learning experience as a developer.
I came in, I was pretty senior,
senior in my mind, I guess.
I was asked to update their WebKit fork,
which was like two years old at that point,
to being closer to Tipper Tree.
And I did, but I took the long way,
the correct way, and I took their patches
and I upstreamed them,
because I could do that as a reviewer.
But I just, I got in over my head.
I bit off more than I could chew
and another senior engineer had to come rescue me.
But yeah, no, it was a whole experience.
And then that led into many years
of working on making Chrome viable on mobile.
One of the things that eventually pushed towards Flutter
was that we, a whole bunch of us inside Chrome,
just really believed that all these app experiences
that we had on the most important device, right?
So this is like early 2010s, right?
The most important devices,
these iPhones and Andriids in our hand.
And they were all writing in these terrible old Java,
terrible old Objective-C stacks.
And we just believed it should be the web.
But then we tried, we put our money where our mouth was
and we tried and you just couldn't do it.
This is actually pretty close to when Flutter was started.
So several years down the line from this,
but we tried to build the Android calculator
in web technology and you just couldn't do it.
You couldn't get the shadows perfect.
You couldn't get the ink splashes perfect.
You couldn't get the drawer perfect.
We tried to build the calendar.
You couldn't get the parallax perfect.
You couldn't not have jank in the scroll.
And maybe that's all been fixed 10 years later.
But that is why we ended up going down the Flutter route,
which we can get into,
is that you just couldn't make the web good enough.
You couldn't build good enough apps with the web.
And we believed that was the right way to write
was with these portable technology stacks.
Yeah, so at that time where you like,
so iOS definitely was like lockdown is to this day,
I guess, to like web cat safari.
So you had like limited control over like
what you could do with an iPhone
and we all like using what tools were you using at the time
to try to build apps pre Flutter.
Was this like,
was this around the like phone gap Cordova days
where y'all doing something just special internal like what?
I just remember that us on the Chrome team,
you know, so I don't know how much of this ended up,
but there were lots of experiments to build a like a web first phone,
not just at Google,
but I'm sure lots of other people were obviously Microsoft did this,
right, and Google had some dabblings in that space too.
But even if you build web first,
even if you build the Chrome OS equivalent on the phone,
you just, you couldn't like,
we spent so much time during this era,
and again, this is over a decade ago now,
just getting JavaScript off the main thread, right?
Or just getting, sorry,
sorry, getting everything else off the main thread
so that JavaScript thread could be your thread.
Cause it used to be back in the time that like the Chrome networking stack
or the Chrome font parsing stack
or whatever would just wake up in the middle of your animation
and he would just drop frames.
And your only other option was to use CSS animations.
And CSS animations,
once you start them, you're done,
like you can't interact with them,
there's no catching that drawer,
there's no like grabbing it and scrubbing it.
And so those were your two options,
jank and JS,
or have no control in CSS.
And we just believe there was a better way.
And so we tried lots of things,
like before we got to the Flutter stuff,
which we took a more radical departure,
but we tried what if you just took JS
and you gave it some GL bindings
and drove everything that way.
But unless you like rip out the rest of Chrome,
you still have the like,
oh, well the font parsing stack woke up in the middle
and caused me to jank.
Like I remember working a lot with the inbox team,
inbox, if you, it was a,
this is many years ago,
it was an early attempt at like a revolution on Gmail.
I remember working with the inbox team
and they just had the most basic problems.
They were not their fault.
They were just like,
my thing janks in the middle of this animation, why?
And it's like, well, you're using an inline script tag.
And so we're parsing the script as you go,
as opposed to like deferring that part.
Hey, like,
this is why we rewrote the HTML5 parser.
I mean, we wrote the HTML5 parser,
it was one of the things that I did
while I was working on Chrome
because you couldn't understand the existing parser.
So you couldn't know if it was correct or what it was doing.
And so thankfully,
Ian Hickson and HTML5 and the WGW tried to write a spec.
This is how we, the HTML should parse.
And then when we implement that,
once we did it,
then we could change the parser.
We could fix those bugs.
And so that was a lot of the journey.
I think we skipped some steps here,
but this was a lot of the journey after Blink.
So when I was at Chrome,
one of the things that we started in part
so that we could fix these mobile bugs,
but a lot of it was just actually process.
What had happened is that when we had worked with Apple,
when we had collaborated with Apple over WebKit,
Chrome got so large.
Chrome got, I think at its peak,
the whole Chrome organization was close to 1,000 people.
And not all of those were working on the core web browser,
but still, there were probably 30, 40, 50 people
who wanted to send patches up to WebKit.
And that's larger than the entire Safari team,
at least it was at the time.
And so we just had this funny setup
where Apple was in charge.
They ran WebKit understandably,
by fiat or whatever, they were in charge.
Had to go through their approval.
There was a reviewer system and all,
but certainly for big controversial things
that needed the Apple stamp of approval.
And again, it makes total sense.
I would probably run the project the same way,
but that was a point of large friction
for something as large as Chrome,
where it's like we got 40 people trying to write patches
and they're all having to squeeze
to this tiny, does the Apple team
want to review it constraint.
And so that was part of what drove us to fork WebKit.
This is another one of the things
that I did while I was at Google,
was myself and some others,
we forked WebKit to make the Blink project,
which is Google's own fork of WebKit,
which has now been integrated more properly into Chrome,
and it allowed Google to take Chrome and move it faster.
That's a, you've been on such a part
of like this incredible, incredible history
of not only the web, but of this era in Silicon Valley,
which I feel like was very special.
So what was your sort of transition from,
I'm sure this whole time you were stewing on,
man, I really wish we could have made the web work on a phone.
Or it's like, when you're in that world,
you just like, or sort of like web maxing,
you just like really want it to apply it everywhere.
So what sort of process led you from
really thinking about that,
I was like, all right,
we need to do something radically different.
Like we need something like what becomes Flutter.
Yeah, I tell you man, it's a process.
Like the, when we did Blink,
you know, Blink was whiskey and frustration,
mostly frustration, almost tears, right?
And that like giving up on this idea
that we could actually make WebKit do what we wanted.
And the same thing happened with the web.
So the web was maybe a little more gradual.
Flutter started not to do Flutter.
We were not trying to build a multi-platform toolkit.
What we were trying to do
is build a fast mode for the web.
So Flutter started the project,
the code name at the time was called Razor.
And we were literally taking a Razor to Chrome.
We were just cutting away all the slow bits
cause we had worked on this thing for a decade at that point.
And we realized that so much of the web
is death by a thousand cuts.
When I left the web,
and this is probably still true today,
there is like a single if statement
in the deepest hottest part of text rendering
that all exists because there's five websites on the internet
that at least used to, maybe still do,
lie about their RTL-ness, right?
So they actually give you LTR,
it left to right text,
but in a right to left context.
And like, there has to be a way to like override that.
And like it got hacked in at some point,
who knows, whatever.
But it like slows down every page's text rendering by 1%.
You know, last time I measured,
and again, that's a long time ago, the last measure.
That's not the only one,
there's a thousand of these things.
And so Razor was a,
well, what if we just cut out all the stuff?
Is there like a golden nugget in the center of this thing?
And so we did that
and we just started cutting away and cutting away.
And after two weeks of cutting away,
we had made some of the benchmarks for Chrome 20 times faster.
Not 20%, but 20 times.
And so that was enough to get the attention of the then CEO
and the next gen slush funds sort of stuff.
And we got some funding through that.
And six of us left the Chrome team to continue to explore,
could we just have a duck type fast, you know,
or some way to just like cut out all the junk
and use a rendering engine that's much simpler.
And so we cut and we cut.
And this is where the break happened,
was that eventually we realized we'd cut so much
that we had to add something back.
I think the thing that meant a trigger to it was that we'd cut away
all of the exec command stuff.
If any of you ever worked on the deep bowels
of text editing on the web,
it's all this like weird API
that Microsoft came up with in 90s called exec command.
It would cut away all of that.
But then we still need to be like type characters
into a text field,
as you have to add something back.
And so we imagined some stuff,
but then what we had imagined
was at least three years away from being the web.
Right, cause even if we had done a perfect job,
it still was going to go through standards,
committee approval process and all that stuff.
And get to can I use being green and all that.
But we just realized,
and this fractured the team and was another like tears
and I don't know how much whiskey was involved.
Certainly tears moment of,
okay, we're not building the web anymore.
We're not working on the web.
And half the team left.
You know, of those six,
three of them went back to the Chrome team.
And maybe two of them went back to the Chrome team.
And then a couple of us, more of us continued on
until we hit another blocker
where we realized that we couldn't even.
So again, this was fast mode.
So the early days,
we moved from the razor experiment
to a thing that we called Sky.
We named it Sky cause,
I don't know,
it was a name we knew we could never keep
cause there was Sky TV in the UK.
But we named it Sky.
And we wrote three versions
at least of the framework in JavaScript.
It was still served over HTTPS.
It was run locally.
It was Android only at the time.
I mean, there's demos of me
showing this online on YouTube
of this like HTTP based,
or this remote loading based framework.
But eventually we,
eventually gave up on JavaScript.
Not because JavaScript is not awesome.
I've worked on JavaScript VMs before.
You know, JavaScript is a great language.
But just like your last guest was trying to solve,
JavaScript doesn't AOT.
And we,
we hit this point where we had started to work on iOS as well.
And we took our thing and we would run it on iOS
and it would take 12 seconds to boot
because we'd written so much JavaScript.
And JavaScript,
so what AOT is is ahead of time compilation, right?
And so the way that your stuff on your mobile phone works
is that when you click on the icon,
it just loads up where the code starts
and just starts executing on the CPU,
which is different from how JavaScript works.
JavaScript and all these interpreted
or just in time compiled languages,
they have to first parse it all.
They have to compile it all
or maybe they have to interpret it all.
And there's ways to make it, you know, fast ish,
but it's still not as fast as just,
I'm going to just start it offset zero and go.
And so we needed a language that could AOT.
And so we eventually left JavaScript
and we rewrote in Dart.
And Dart at the time was super close to JavaScript
because Dart had been written by the same team as wrote V8.
And the same team would wrote in hotspot for Java before then.
And so when we transitioned to Dart, it was funny.
It was months later that we realized
that we hadn't even updated all of our unit tests
to be Dart syntax.
They were still just JavaScript syntax
that was parsing fine in Dart.
And Dart and JavaScript have evolved
since that point in time,
but back in 2014 or 2015,
they were very similar languages
or more similar than they are today.
Et donc, on a réussi à transition
à un langage qui avait
une compétition juste en temps pour une expérience
très belle de développeur,
et une compétition très bien de développement.
C'est intéressant de voir comment le field
a été élevé de manière similaire,
comme en parallèles.
Je n'ai pas fait de la flotte,
mais beaucoup de choses que vous avez dit
me rendent un réact natif.
Ils ont fait un nombre incroyable de travail
pour faire des choses,
et de se sentir comme AOT
avec le Hormes Engine et tout ça.
Donc, ça semble qu'on se sent
tous les mêmes problèmes sur et sur.
Oh, totalement.
Oui, j'ai beaucoup de respect
pour le team de réact natif.
On a été avec eux en un basis régulier.
La différence fondamentale là
est que le réact
est en train d'une approche que les browsers ont utilisé.
Donc, en fait, en fin de jour,
les browsers ont utilisé les contrôles natifs.
Je ne sais pas comment,
c'est trop ouf pour l'audience,
mais comme en fin de jour,
les browsers ont utilisé les contrôles natifs.
Donc, quand vous avez cliqué sur cette clé,
c'était un bot d'aqua.
Et quand Safari était en train de se faire,
c'était un...
ou bien, un bot de 32 ans.
Et les browsers ont vu
aucun end de problèmes
en résultat.
Parce que vous allez au site
et il y aura 1000 clés sur ça.
Et ça se crasse.
Ou vous allez au site
et il espère que le CSS
devrait s'inspirer dans le bouton.
Et ça ne se fait pas.
Et ça a été une chose
que nous avons passée
dans les hautes avant,
comme en se défendant.
Et peut-être que nous devons avoir
des contrôles de CSS
et des contrôles de formes
qui devraient être lesquels l'autor
et lesquels l'autor
veut.
Et ça a même
causé des problèmes de sécurité
pour les browsers.
Parce que quand vous vous déplaîtez
quelque chose qui est fait par AppKit,
ce qui est une frameworks de Macs,
pas par Safari,
vous pouvez causer
AppKit pour se couper
dans des états de faute
sous les couvres.
Et donc les browsers ont traduit
d'une façon de l'élection
de leur stack.
Le Firefox était un pioneer
de tout ce qui a ensuite
été suivi.
C'est un point où Chrome
n'utilise pas...
Ou peut-être qu'il y a des jours
mais je ne pense pas
qu'il utilise des graphiques corgérées
sur iOS.
Il y a juste un ski
avec ça
et il parle de la GPU.
Et donc la différence,
la différence principale
entre React,
Native et Flutter
est que React Native
est, d'accord,
en appui de la façon de
dire,
nous allons utiliser les graphiques corgérées.
Nous allons utiliser
le bouton qui est déjà ici.
Assuming qu'on a un bouton,
nous allons utiliser ce bouton.
Alors que Flutter va être...
Non, non, nous allons
mettre tous nos propres boutons.
Nous allons fonctionner
plus loin d'un jeu.
Et c'est...
6 et 7.
Il y a des traductions pour les deux.
Ça semble
que la construction de la whole
graphique pour
la framework UI
serait un challenge.
Peut-être que l'on est
en train de comprendre
ce que...
Et, vous savez,
surtout quand vous parlez
aux gens sur le web,
sur...
Je pense que un commun
product surface
que les gens vont travailler
sur est comme un canvas.
Et vous pouvez
littéralement prendre
le canvas HTML
comme fonctionnement
pour l'envers.
Donc si vous faites
un canvas infinitaire,
vous pouvez utiliser
ce fonctionnement.
Vous pouvez
construire
ou émuler
juste en utilisant le canvas HTML.
Et il y a certainement
des approches de la bothne.
Et l'une des les plus
les plus grandes
choses qui sortent
dans ces conversations
est l'accessibilité
dans ces surfaces
ou en essayant de
mettre des features
qui sont...
Vous pouvez juste
relier sur le web
qui a été
construit
toutes ces années,
toutes ces extra-capabilités.

quand vous êtes
en train de
vraiment faire
ce que vous pensez
que Flutter
sera dans ces dernières jours
et en pensant
sur les capacités,
où sont les choses
que vous vous dites
OK, nous devons absolument
faire ça
parce que le web nous a dit
que c'est invalué
vers ce que
on ne peut pas faire
et c'est OK.
Vous devez faire
ces traitements.
Qu'est-ce que
votre direction
de guide?
Donc Flutter
était tout à l'heure
sur la ceilée.
Flutter était tout à l'heure
pour faire
tout ce que votre design
voulait faire.
Nous étions en train de
construire une plateforme
de qualité de la qualité
de la plateforme
qui était bonne
pour Google.
Donc Google
avait un whole bunch
de bonnes
ways de partager
entre
des surfaces
différentes
mais ce n'était pas
comme
nous devons utiliser
tout ça.
Il y avait des équipes
qui voulaient utiliser le web
mais ils en ont terminé
avec un résultat pauvre.
Nous voulions
un truc qui pourrait
produire
des résultats
qui avaient
une excellente accessibilité,
une excellente graphique,
une excellente animation.
Les appels de qualité Google
et aussi des portables.
Et donc ce que Flutter
avait designé.
Donc la réponse
qu'on a fait
avec l'accessibilité
et tout ça
et ce qui nous a
confié
que ce soit possible
était les browsers.
Donc nous avons
travaillé sur les browsers
pour toujours.
Nous avons fait
les nut et les bolts
des browsers.
Et les browsers
ont besoin
d'avoir une excellente accessibilité.
On peut en argumenter
qu'ils ont besoin
d'avoir une excellente graphique
et une excellente performance.
Et bien,
notre expérience
n'a pas été
que l'accessibilité
et l'accessibilité
de l'ancient
et les 30 ans de croissance.
C'était ce que nous avons fait.
Mais on a pu que ce soit possible.
Je vais dire avec un caveat
qui est iOS.
Donc iOS,
parce qu'ils n'ont pas
un deuxième browser,
ils n'ont jamais
exposé ces API.
Donc si vous allez
à GitHub,
si vous allez à WebKit,
il y a
une whole fold
de choses qu'ils n'ont pas
appelées APIs,
des interfaces de système privé.
Il y avait un filet
que j'ai travaillé sur.
Et on a eu le temps
à la valeur de faire
ce filet le plus petit possible.
Parce qu'ils étaient clairement
des holes en MacOS
que nous devons exposer
pour toutes les autres apps
qu'on peut utiliser.
Si Safari a besoin de
ces autres apps,
non.
Ces jours, c'est juste
des folders
et des pages et des pages
de tout ce qui est
les APIs privées
que ça fait
de faire ce que le Safari peut
que vous,
un développeur commun,
ne pouvez pas accéder.
Et donc
Flutter a eu
ce challenge sur iOS
de que
jusqu'à l'Ouest gouvernement
ou quelqu'un d'autre
s'est passé par là,
vous ne pouvez pas accéder
à ces choses
que l'Apple peut.
Et donc
on doit le faire.
En tant qu'Android,
parce qu'il y a des
3rd party browsers,
ils ont généralement
exposé toutes les choses
que vous avez besoin de
pour avoir la meilleure accessibilité.
Donc,
construire une plateforme cross,
comme,
on a laissé le web
et laissé ses défis
pour, je dirais,
probablement un host
de nouvelles défis.
En fait,
nous pouvons construire
toutes les plateformes
que nous avons besoin.
Ils offert différentes expériences.
L'apple iOS
se sent beaucoup différent
que l'apple Android.
Et ils se sentent
beaucoup plus différents
que l'applet de la web.
Donc,
comment peut Flutter
se faire avec ça?
Comme,
j'ai un sheet de drawer
sur une app mobile.
Comment ça se translera
dans l'applet de la
web ou des web à la base?
Oui.
Donc,
je pense que vous êtes right.
Et Flutter a toujours
refusé sur le ceil,
en faisant tout possible,
pas nécessairement le flore,
ce qui fait
que c'est un peu triviel.
Et je pense
qu'il y a beaucoup plus de travail
que nous pouvons faire
dans le monde Flutter
sur le flore
en termes de
de la plateformes multiplatées
adaptées à l'expérience.
Nous fichons beaucoup
sur le ceil,
que si vous allez
au desktop,
vous devriez avoir
une expérience de parfait desktop.
Si vous allez au Android,
vous devriez avoir
une expérience de parfait Android.
Mais ça peut require
beaucoup de travail.
Et je pense que ça
vient de la culture Google.
C'est que Google
est juste
brummageant
avec des ingénieurs.
Et donc,
pour que vous donnes
un outil
qui peut les faire
où ils vont,
ils vont y arriver.
Mais oui,
c'est un challenge.
Et Flutter
vous donne
beaucoup de pièces
pas toujours
toutes les deux
étangées.
Comme c'est
le Cupertino.
Vous savez, nous vous donnons
une expérience
vraiment facile
de faire une réplique
d'un micro-s
de contrôle de Switch.
Et amusant,
quand nous
nous avons commencé
le projet
et nous étions
parfaitement
matchés au switch,
nous avons trouvé des bugs
dans le micro-s de contrôle de Switch.
Vous savez,
je ne sais pas
si ils ont fixé
ceci.
Mais ces parts
sont plus simples.
Ce qui est difficile
est que
ce qui est difficile
est de faire
facile pour les développeurs
pour mettre le switch de contrôle
au right place
et utiliser la navigation
au right place.
Et Flutter
a des affordances
pour ça.
Des contrôles adaptées.
Mais je pense qu'il y a beaucoup plus
qu'on pourrait faire
ou beaucoup plus
que la communauté.
Et c'est une des choses
que j'ai excité
avec mon current
avantage
avec Shorebird
c'est que
les incentives
pour le team Flutter
Flutter
est wonderful,
full de
tous les grands gens
et Google
a été un grand tour
de ce produit.
Mais
les incentives
sont tous
en train de

une équipe Google
qui est successeuse
avec elle
et
ne pas
pas en prenant
des toes d'Android
et des choses
qui
poursuivent
de Google.
Et plus
sur
comment je fais
que
vous
un développeur
successeuse
pour vos besoins
parce que
vos besoins
ne me permettent pas
de faire
sur la team Flutter
ou sur Google.
C'est
une des choses
que j'ai excité
avec mon current avantage
c'est
comment je
aligne
ces incentives
pour que
quand vous êtes
successeuse
à Andrew
ou quand vous
êtes successeuse
à Toyota
Toyota
pour exemple
je crois que
ce modèle
est
en train de

sur les véhicules
tous les véhicules
donc
dans
un
monde
le monde
devrait être
extrêmement
trés
parce que
le monde
fait
de l'argent
mais
dans le monde
est-il
quelqu'un
qui est
promos
dans la team
quand ça
s'occupe?
Je ne sais pas
ce n'est pas
pas bon ou mal
c'est
une démonstration
de l'incentif
que je vais essayer de
faire
oui
ça semble être
une propre
de
des projets Google
donc
pour exemple
je suis sur
une équipe de plate-formes
et
Basel
est un
chose
que nous
interrompons
beaucoup
et c'est comme
c'est presque
dans le même monde
de
comme
c'est été
mis
mais
il y a un
lot de
choses
dans Google
qui
fait
un très
productive
tool
qu'il n'y a pas
d'insentif
pour
quelqu'un
pour
s'y partager
d'un

100%
oui
je
je n'ai pas
rien
de
les choses
pour
moi
Top
Go
inappropriate
significantly
pas
그러니까 en tant qu'interface de Hong Kong en prie à l' 진행 style,
on complicated structure et à tômes jusqu'à ce n'est manifestrementisel.
D'olesome, et en tant qu'interface on s'est fait cet propre recruité
car la France n' brightenigerait pas tout cet ordre.
Ça crée un temps.
Systematisé, on peut bounce et on co-z Nous tous, nous roulons de Gibson,
lambda micron Area Jun Make On est l'un des côtéließants du Wakame.
Oui.
Donc, la première chose que nous essayons de résoudre, c'est que nous essayons de remplir les pièces.
Donc, une des choses que nous étions en train de faire, que nous étions en train de faire,
comme le leadership de la équipe de Flutter, c'est de construire une pièce qui fit dans Google.
On n'a pas étendu trop de pièces ou causé des conflits pour beaucoup de pièces,
et on a travaillé avec Google Technologies.
Et c'est bien, mais je pense que vous avez une autre pièce,
vous, Justin, avez une autre pièce, que un ingénieur Google random.
Et donc, la première chose que nous essayons de faire, c'est de faire surement
que le set de choses que vous avez besoin d'être réussie,
comme vous, Justin, avec Flutter, est là.
Et le premier point que nous avons essayé de remplir,
c'était le numéro un des plus élevés d'issues de tout le temps,
à l'heure de Flutter, et un des plus élevés d'élevés à l'heure de Github,
qui était la première de la pression de code pour Flutter.
Donc, la pression de code est l'idée de pouvoir évoluer votre code
instantanément à travers tous vos utilisateurs.
C'est comme si vous vous mettez sur le web,
comme si vous vous mettez sur le server,
comme si vous faisiez avec, honnêtement,
une environnement normale, c'est de la mienne,
et de la mienne, et de l'idée de ce type de mobile,
que tous nos équipes vont être comme NASA,
où on va faire de la preuve pour plusieurs mois,
et puis on va le battre et le vendre à Mars,
et on espère que, quand ça arrive en trois mois,
ça va travailler parfaitement, et la réalité est que le monde ne fonctionne de cette façon.
Et donc, Code Push est le moyen de toutes les appes de fonction.
Si vous regardez tous les appels de votre téléphone,
les TikToks, les Facebooks, les YouTube, et tout,
ils automatiquement s'éteignent en différentes manières,
ils ont tous construit leurs propres solutions pour cela.
Et c'est juste nécessaire, parce que, à l'heure de maintenant,
on est enregistrés, c'est une semaine de Thanksgiving
dans les États-Unis, on va avoir Black Friday,
où tous les stores font leur monnaie.
Vous pouvez imaginer, comme un commerce,
si vous êtes une app Flutter qui est un commerce base,
et que vous êtes en train d'avoir une heure sur Black Friday,
c'est juste inacceptable.
Et donc, c'est pourquoi quelque chose comme Code Push
doit exister.
Nous étions en train de parler d'un très grand customer,
et ils nous ont dit la semaine dernière
qu'une des choses cool qu'ils ont déclaré,
c'est que, quand ils ont un bug en production,
peut-être pas un bug, mais un bug,
ils pensent qu'ils peuvent juste mettre des loges,
et aller à la nuit,
c'est comme un normal chose qu'ils ont fait en tant qu'un web-developer.
Pouchez des loges, allez à la nuit, et venez à l'hôpital.
Mais maintenant, ils peuvent faire ça sur mobile,
qu'ils n'ont jamais réalisé que possible.
Et alors, ils viennent de la nuit,
et ils ont des loges dans le sens
qu'il y a un bug sur leur app.
C'est comme ça qu'on a prévenu, et ils ne le fixent pas.
Une autre pousse après la nuit.
Et c'est comme ça que la développement doit aller.
Vous avez demandé, que se passe-t-il ?
Nous étions en train de remplir les pièces.
C'est un peu plus difficile que je pensais que c'était possible,
qu'on peut parler de ça,
mais on avait à construire un tout bon et un peu d'endroit.
On a fait des choses pour faire ça.
On a filmé ce code Pouchez, et on a construit un producte CI,
parce qu'on a besoin de le faire pour notre propre.
On a un peu d'art,
on a écrit nos services,
on a écrit la ligne de commande,
on a écrit un peu d'endroit.
On a besoin d'un système CI,
donc on a construit un pour nous.
On a fait ça pour d'autres,
et on a vu des projets de plus en plus.
On a fait les pièces.
Et puis, le long terme,
c'est que la fin de la course
doit être des déploies de l'unité,
ou d'un business qui va à Red Hat,
ou d'autres.
Tu te sens comme,
« Oh, ils ont toutes les choses que j'ai besoin. »
Ils me le font.
Je pense que React Native a des choses
qui sont de l'expo.
Ils me le font.
Ils me comprendent.
Ils ont toutes les choses que j'ai besoin.
Ils ont une carte de crédit.
Je peux payer les choses que j'ai besoin
et pas payer les choses que je ne veux pas.
C'est comme ça.
Parce qu'il y a des millions de développeurs de Flutter.
Il y a un stat que Google a publié
l'année dernière
que une troisième de toutes les app
qui ont été subies dans l'année précédente
ont été Flutter apps.
La survey Stack Overflow
a montré que le dart est un peu plus grand
que Swift.
C'est une commune très grande.
Et où est
la company Flutter ?
Où est la company que je peux venir ?
Et ils me donnent ce grand hug.
Vous allez être successeux avec Flutter.
On va faire sure que vous êtes successeux
avec Flutter.
Et c'est ce que nous avons fait.
Le code push stuff a probablement
éloqué beaucoup pour les développeurs de Flutter.
Vous avez juste mentionné le projet Toyota.
Je suis sûr qu'ils ne pouvaient pas
s'assurer que les appareils ne sont pas sur le terrain
pour fixer leurs carres.
Comment vous appareillez un car ?
Donc, on va faire un code push stuff.
Vous avez dit que c'était plus difficile
que ce que vous pensiez.
Comment vous avez travaillé ?
Comment vous pensez que c'était en bas ?
Comment vous avez fait ?
Et quelles sont les décisions que vous avez fait ?
C'était un autre détail dans le business.
Je pense que c'était un mois
pour avoir une version Android
et peut-être deux ou trois pour avoir
la version iOS.
Je pense que nous pouvons avoir
plus agressifement arrêté
et tenté de vendre.
Mais le ingénieur et moi
voulaient faire ça très bien.
Nous avons donc pris un autre 2 ans
ou un an et demi
pour faire la partie iOS
particulièrement.
iOS a plus de restrictions
que Android fait en faisant ça très bien.
Et la partie qui fait ça très bien
est que nous avons dû
apprendre le système Dart.
Dart a déjà eu un interpreter
et vous avez besoin d'un interpreter
pour compliquer avec les guidelines app store.
Donc, le app store dit
que vous pouvez rééterne votre app
autant que vous voulez.
Vous avez deux choses.
L'une est que vous avez besoin d'un interpreter
si vous voulez l'éterner.
Et vous ne pouvez pas changer
la cause de votre app.
Ils ne veulent pas que vous
vendez un jeu
et que vous vouliez faire un app
pour certains régions.
C'est un exemple historique.
Ils ne veulent pas que vous faites ça.
Et c'est bien.
Parce que, encore une fois,
tous les appes les plus grandes
travaillent de cette façon.
Toutes.
Mais c'était très difficile
d'en prendre un interpreter
qui était très lent
parce que les interpreters sont très lent
et de faire travailler très bien
dans la production.
Parce que notre initial demo
pour iOS,
quand vous patchiez l'app,
quand vous le tournez,
tout de suite votre app
serait très lent.
Parce que c'était interpréter tout.
Et donc, la vraie chose
qu'on a faite,
c'était qu'on a appris
comment,
sans vous recommencer
dans votre code d'art,
quelles parts
vous interpréterez vers pas.
Pour nous,
dynamiquement,
sans vous faire quelque chose,
on va magically se faire
faire, ok, on va faire
cette partie de votre app
dans l'interprète
et cette partie pas.
Et je peux aller
dans plus de détails,
comme vous l'avez fait.
C'est un podcast de DevTools.
Mais ça a été un problème très dur.
Oui.
Est-ce que
les iOS limitent
les optimisations?
Est-ce que
ils ne sont pas allowed
de jeter?
Ils ne sont pas allowed de jeter.
Donc, la restriction technique
sur les iOS est
que vous ne pouvez pas
avoir une page de membre.
La page est juste
comme une unité de membre.
Mais vous ne pouvez pas avoir
une page de membre
qui a été
élevé
pour être élevé
ou de toute autre façon.
Je pense que
peut-être que vous pouvez
avoir une chose qui est élevé,
mais elle perd une élevé
si vous voulez.
Et
il y a des...
Vous pouvez avoir la permission
de jeter
pendant la période de développement.
Vous pouvez avoir la permission de jeter
quand la code X est connectée.
Mais en général,
vous ne pouvez pas
avoir
une membre
qui peut être élevé,
ce qui est ce que vous avez besoin
pour jeter.
Et donc, vous êtes
en train de
interpréter.
C'est bien.
C'est ce que leurs guidelines
disent, et nous sommes
heureux de les suivre.
Mais vous devez
utiliser un interpréter.
Et les interpréters sont
très sains.
Hermes, ce que vous avez mentionné
avant,
a des capacités
d'interpréter.
Et les choses qu'ils font
sont qu'ils ont un interpréter
très haut.
Donc,
ici ici,
avec
où vous avez terminé de votre vie en plus.
Je veux connecter vos deux start-ups.
Donc, la première, vous savez, vous êtes jeune, vous êtes encore en train de apprendre,
vous vous entendez et vous ne parlez pas aux customers,
et vous travaillez sur un domaine qui ne peut pas être votre passion actuelle,
mais vous pensez qu'il y a quelque chose là-bas,
jusqu'à vous, vous savez, vous commencez à travailler sur votre projet d'offre d'employeur.
C'est un projet d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'offre d'
D'pson ruling mon
Comment tu penses de la modernisation des choses? Comment tu as vécu ces idées?
Je veux juste vous distiller des learnings et de ce que c'est de l'être en fond.
Oui, des choses, des choses que je peux dire.
Dis-tu à vos clients.
Pourquoi un accommodateur, je dirais 90% de leurs conseils,
peut-être 99% de leurs conseils,
fait quelque chose que les gens veulent,
fait quelque chose que vous voulez,
ce sont toutes les bonnes choses.
Je pense que c'est très similaire à la première fois.
C'est un schlap, c'est juste beaucoup.
Je suis un company compliquant,
qui me choque à quel point c'est compliqué,
d'un point de vue de la direction de l'examen.
Mais je pense que ça vient de parler à vos clients,
de faire quelque chose que les gens veulent.
L'attention du jour 1, si vous êtes dans le space B2B,
on le fait et je suis vraiment content que nous l'avons fait.
Ce n'est pas même pas le mien.
C'est le mien dans le sens de,
quand les gens ont pu tirer leur carte de crédit,
c'est une autre chose que si ils se laissent.
Il y a un niveau différent de l'intent.
Mais plus importantement,
comme développeur,
comme développeur en écoutant,
c'est pour compléter le loo.
Le dernier 5% est 90% du travail,
ou quelque chose de la même manière.
Quand vous vous forcez à vous faire
tout le monde compliquer le loo,
et faire la integration de l'attention,
et prendre des paies,
ça fait que c'est plus vrai.
Je suis content que nous l'avons fait.
Je serais content de le marcher plus tard.
Je pense que j'aurais lu ce que les founders second,
les founders troisième,
dans tous les credibilityurs que j'avonds,
boats,



on dirait que le point Eat hashtens


ES,
on ne parle pas de ça.
On vend à, je ne sais pas, 50 plus de pays.
C'est juste qu'on est tout sur le monde, c'est un très global product.
Donc, les choses se sont développées très bien.
On s'est acheté un peu maintenant.
Donc, les choses sont belles.
Il y a beaucoup de problèmes de difficulté qui sont à la fin de la solution.
Et ça me fait toujours plaisir.
C'est un bon conseil.
Je suis toujours un grand fan de dogfooding.
Et si vous pouvez vous faire le custom,
vous êtes déçus de vous-même et vous avez un bon product en fin.
Avant de regarder le futur et de vous rappeler,
nous vivons dans un temps de change pour les programmers.
Je dirais que dans ma career de 10 ans,
je n'ai pas eu peur de l'environnement comme je suis maintenant.
La code de vibes est ici.
C'est changé de la façon dont beaucoup de gens pensent sur la programmation.
Peut-être pas les programmers.
Mais je veux avoir votre take sur ça.
Qu'est-ce que vous pensez de la code de vibes
comme une personne qui a été dans l'industrie
pour tout à l'heure,
qui a travaillé sur des technologies fondamentales.
C'est probablement un code de vibes.
Comment vous viewz la code de vibes
dans les tools AI que nous avons aujourd'hui?
Je suis vraiment heureux de avoir des nouvelles tools.
Je pense que les nouvelles tools sont bien.
C'est particulièrement le meilleur que j'ai eu.
C'est le cursor et la multiline auto-complete.
Je pense que je veux prendre toutes les autres auto-completes.
Je ne veux pas.
Je veux juste une auto-complete LLM.
C'est bien.
Je suis intrigue par la gravité.
Je n'ai pas de quota pour utiliser ça pour plus de 5 minutes.
Je n'ai pas de quota pour utiliser ça.
Je ne veux pas vraiment avoir des stuffes de vibes.
Je ne sais pas ce que c'est,
mais les v0s de l'EU,
je vois l'attraction.
C'est vraiment utile.
Nous avons recently appris un personne de marketing
et une des choses qu'ils ont appris à notre récemment,
c'était que nous pouvions regarder X
ou y.
Qu'est-ce que nous serions plus...
C'était super utile.
Devoir un shot de vibes,
une image de stéphane,
un site de web, etc.
J'ai dit que je voulais faire un interview,
mais ils ont appris une version de vibes
de la façon dont ils pensaient que notre site
serait notre compte.
C'est super utile.
Mais en en train d'en faire,
je peux changer de production,
ce n'est pas une étude que je suis
personnellement accueillie.
Je pense que je suis
positive sur les outils.
Il y a beaucoup de la
faute de la production,
mais je pense que je suis




parce que je ne veux pas
faire un file de clade.md.
Je suis désolé.
Il y a eu un fail de UX
si je suis en train de faire un file de clade.
Mais je pense que je suis
très barré sur le bubble.
C'est juste que
les révenus ne font pas
le sens.
Il y a
quelque chose
qui se passe là-bas.
Mais je pense que
quand la douce s'attende,
la code n'est pas
la même chose.
Mais je voudrais qu'il y aille
de la même chose.
Je pense que c'est
un peu plus important

















un peu plus important que je





un peu plus important que je

Mais je pense que c'est
un plot
un point à reflection

hava
audit
de l'expérience de la gamme de la façon dont les gens pensent à construire des appels.
Vous êtes construit en compagnie pour évoluer les gens à construire des appels de flottage
et une solution plus scalable, leur donner tous les outils que l'écosystème ne peut pas faire.
Et si vous pensez à la prochaine étape, le futur,
d'être un peu de flottage, spécifiquement, de la nouvelle capacité
que vous pensez qu'on va arriver à l'écosystème de la façon dont les gens construisent les appels,
ou juste, peut-être plus broadly, dans l'industrie, comment nous pensons
à comment vous pensez que les appels de la construction ne peuvent changer.
Je suis curieux, comme, pour avoir votre perspective de la prochaine étape,
est-ce que les choses sur le horizon que vous êtes excité à ne pas?
Est-ce que vous pensez qu'il y aura des chiffres de la série et de la façon dont nous approchons de mettre ensemble les UX?
Est-ce quelles sont les nouvelles capacités?
Et, encore une fois, vous pouvez le faire en bas sur le flottage
ou le faire en plus profondement dans l'industrie,
ce qui est plutôt intéressant pour vous.
Oui, je pense que l'industrie est en train de se poser des questions sur l'aie,
je suis excité de voir Google annoncer la génération de la génération dynamique
qui a été puissante pendant la semaine dernière.
Ils avaient eu une ligne à leur dernière I.O.
qui était comme, la vibe de la première fois à l'extérieur.
Je pense que le besoin pour la plateforme multiplaise ne va pas.
Je pense qu'il y a un grand changement qui va arriver,
et je ne sais pas comment ça va arriver.
Je dirais que c'est le micro-phone,
qui, si vous avez assez d'air,
il y avait un micro-phone et ça a fallu,
grâce à des faibles, des écosystèmes.
C'était formatif pour Flutter et la raison pour laquelle nous existons,
c'est qu'on ne veut pas ça arriver.
Nous avons un petit duopoli entre iOS et Android.
On peut voir ça avec Huawei,
on a un téléphone et peut-être il y aura plus.
Mais je pense qu'il y aura plus de devices.
Je ne sais pas si c'est AR ou VR,
je ne sais pas si c'est des petits pins,
mais il y aura un autre paradigm de devices.
Il va arriver et je pense que c'est un plus de plateforme multiplaise,
pas moins.
Il y a aussi des paradigmes de devices que nous avons oubliés,
comme desktop.
Comment est-il dans le monde que Electron est le meilleur moyen
d'avoir une application de desktop ?
Je suis certain que c'est une révolution
d'avoir une application de desktop et de séparer
les 11e des frameworks qui sont au bout de l'année dernière.
Je ne sais pas.
C'est plus meilleur que ça, mais on ne peut pas faire mieux.
Je pense que si nous nous en avons plus,
nous devons établir des softwares portables,
pour que ce soit pas de Apple,
pas de Google,
qu'ils ont des conflits d'intérêt.
Comment nous avons un vrai wac à la software portable ?
Et puis, quand nous avons ça,
qu'est-ce que ça veut dire pour des différents devices ?
Qu'est-ce que ça veut dire pour le prochain de Microsoft ?
Qu'est-ce que ça veut dire pour l'improver
l'expérience et l'expérience de l'existe des devices ?
Je suis content d'y voir.
Je pense que c'est très important pour moi,
j'en veux pas pour les enquêtes,
mais je suis très occupé d'incendir ces problèmes de pensées
pour ziemaller ces critères de fonction serait bien funnel
qe ce quiлавait Ce Fujian
Muchas thin****n
Merci d' caller Eric, c'ij亲s
on a un 2 moisohl
J'ai l'ap philosophie bien commun àング
beaucoup de plus n***itals editing
Merci d'avoir regardé
Merci Eric,
et juste merci pour tout votre travail dans l'industrie.
Beaucoup d'entre nous avons construit nos careers sur le web
et c'est comme les gens comme vous qui l'ont évoqué
et juste comme que vous êtes heureux pour tout cet travail
et vraiment excité de voir où vous avez pris les cours.
Merci.