La script née t'a aimé de mettre la développement plateforme native à JavaScript
dans un moyen naturel comme possible.
Elle veut vous permettre de faire des choses plateformes de JavaScript,
choses comme Kotlin, Swift, Objective-C, Java.
Bonjour, bienvenue à la podcast de DevTools FM.
C'est un podcast de développeurs de la production de tools.
Les gens vont faire ça.
Je suis Andrew et je suis ma host, Justin.
Hey, everyone.
We're really excited to have Eduardo Spironi on and Nathan Walker.
And we're going to be talking about a topic that I'm actually really excited about
because I heard this, I heard about this about a decade ago.
And I was like really, really interested in it, like played around a bit in the early days.
So we're going to be talking about native script today.
And it's crazy to me that it's been a decade.
I was like going back and like looking at it is like, yeah.
You know, I think it was like made in 2014, but really publicly announced in 2015.
So I was like, wow, that's crazy.
It's been that long, but I'm super excited to talk about this.
But before we begin, would you each like to give an intro?
Nathan, why don't you start?
Sure. Hey, everybody.
Nathan Walker, I'm co-founder in studio and a member on the working group
or technical steering committee with native script.
And love working around that kind of stuff.
So excited, excited to be here.
I'm Eduardo Spironi.
I'm also on the TSC and I've been working mostly with Valor Software,
but I also like work with Nathan on a few projects.
Awesome.
So let's just dive into it with when you all like to sort of just like describe
what is native script and maybe some of our familiar
our listeners are probably familiar with like react natives.
Maybe we can kind of compare and contrast with that.
Yeah, maybe I'll start on that one.
I mean, native script aims to bring native platform
development to JavaScript in as natural way as it can.
It wants to allow you to do platform things from JavaScript
and therefore it sort of brings platform languages to JavaScript,
things like Kotlin, Swift, Objective-C, Java.
You can do constructs.
You can even use practices and constructs that you would use.
And Objective-C, philosophical structures
and approaches like delegates, for example.
And Objective-C, you can do those in JavaScript with native script
and really aims to bring the entire JS ecosystem to platform land.
That comes with a lot of a lot of things to talk about there.
But I think maybe in a nutshell, that's what it is.
But along with JavaScript comes all the things you would expect
like web approach, CSS, being able to do standard view,
templating and markup, marry that with CSS to develop an app.
So is it like, is it like a react native
where you're composing native stuff to create an app?
Or like, I saw there was CSS in there, or is it like more of a web view
but you can hook into the native stuff and then show stuff in a web view?
React Native and native script have similarities
in what you're working with,
because you're working with the platform view language.
So, you know, a UI view, for example,
and UI kit on iOS is something you'd work with
through a view construct in React Native.
Native script, you'd work with the same thing
and say a grid layout or a stack layout.
There's even talks to maybe bring a singular view
like React Native to native script.
So you're working with the same view level
between React Native and native script.
But that's probably where the similarities end
in terms of the approach,
because native script takes more of an approach
that you are dealing with the platform kind of as is.
You tend to work with the platform language as you would
when you're in Objective-C or Swift.
And so you're not having to necessarily go too much
in and around the platform maybe sometimes.
Yeah, and to just like expand a bit on that,
a native script like the UI layer, you can say,
you know, it's all, or like most of it is done directly in JavaScript.
So you don't need to get, you know,
you don't need to write native code
to build a new UI even from scratch.
I remember when I discovered native script,
around that time, I was still sort of messing around
with like Cordova apps.
I don't really remember what the state of,
I don't think React Native was really much of a thing then,
or I wasn't aware of it at all.
I don't even think it existed then.
But like, I had been doing a lot of Cordova apps
and you get to this point where it's like,
okay, well, now you have to write like native extensions,
like, you know, in the app framework.
So Cordova, for those people haven't heard of it,
is like a way to just make apps with a web view.
That was really kind of all it was,
is like package up a website, add as an app.
And the thing about native script that just seemed magic
is Nathan, like you said earlier,
you kind of generate JavaScript bindings for the entire,
the entirety of the native APIs,
like everything that you can call,
you know, in Objective-C, on iOS,
or in Java, on Android,
you can call with JavaScript.
And that like blew my mind.
It's like, wait, so I can write a JavaScript file
that kind of like hooks on different platforms
and uses the bare platform primitives.
One of my questions that I have,
that I always wondered is like,
is that really slow like doing the native bridging?
You know, this is something that we have a problem with,
with like Wazom these days,
is like the, there is a cost to translating
from one data type to the other,
like one, you know, the bridging cost.
But so what's the story
with like performance and native script?
I'll let Ed touch on that in a minute,
but maybe I'll comment on one thing,
which is that very aspect of it,
which is bringing all platform bindings to JavaScript,
is I think what rightfully so scared people to
in the beginning is a bit,
a bit maybe ahead of its time.
At that time,
in the thought of doing that,
I think rightfully so scared some people,
excited some people.
And so along with that came some controversy.
And you know, there's always controversy
around bringing anything innovative out there.
And so there was a lot of uncharted territory in that.
And so, you know, in the 10 years that has span by,
you know, that approach has been brought to production
and a lot of different aspects.
And so, you know, let's talk about
the performance nature of that.
And maybe Ed, if you want to touch on that.
Yeah, so a native script is like,
does most things like very,
I mean, the most optimal things that we can, right?
So for example, when we generate the app,
like at build time, we actually generate.
So during that build time,
which is not like long, it's just like a short build time,
we actually generate the whole bindings for the platform,
but we mostly generate what we call metadata, right?
So we know how to call,
like which functions to call dynamically at build time.
And then that becomes like a file,
a binary file of like, you know,
three megabytes or something,
you can be smarter, bigger depending on
how you configure it, right?
We generate this small file that is then like
directly injected into the binary of your app.
So when your app opens,
that thing's already loaded into memory, right?
So we don't need to like load anything in,
it's already there, right?
So it makes it much faster, right?
So we try to access things and find things
when we need to.
And of course, we do have essentially like,
we have a couple of overheads, right?
So we have like the overhead on iOS,
which is first, I mean, we're using V8,
we are also expanding on other different engines as well,
but we're using V8 underneath,
and at least like most other engines
are also using some kind of like C++
or right, some kind of thing like that.
And what happens is,
so we, there's like the traditional cost
of like going from V8, like JavaScript to C++,
which is kind of big, but not really, you know,
like if you, so, I mean,
if you can do like three,
I think it was like a three million ops per second,
then like if, I mean,
three million ops per second
in JavaScript pure JavaScript using V8,
then if you like, instead replace that JavaScript operation
with like a native function call
that goes like 2.5, you know, a million per second.
So it's kind of like, it's un nextable thing
for most part.
The heaviest part is usually because,
so you're like you're passing, you know,
like you're passing a number
and then the function might receive like an int
or a, receive a string
and then native script does its best
to do the conversion for you sometimes,
you know, like if you pass a number
and the thing requires a string,
we're just going to like throw an error
because like you're trying to call like a different,
like a function that doesn't exist.
So we'd have to do that.
I think that's a good pause,
a good pause point too,
because, you know, if you're working in Swift
and you try to pass a string to a function argument
that expects a number,
you know, you're going to get a crash,
but more likely your compiler is not going to compile.
Native script brings the types to the platform.
So for most API calls,
you also are going to get a compile time error.
So, you know, the function signature
is actually going to be in typescript
that it actually accepts a,
you know, a string and not a number.
But for any given purpose,
if you were to pass something into a function
that either the types were weak enough
that didn't capture you,
you're going to get a similar throw
that you would get in Swift or Objective-C-Land.
So your experience working with that language
is pretty similar.
Yeah, I mean, like, we are also typescript first, right?
So for as well,
with like generating the metadata,
we generate also the types for the metadata.
So there's no way for you to, you know,
I mean, at least like if you're using typescript,
you're going to like get, you know,
build errors if you try to just use different typies.
But the other overhead that we have
is also like the LibFFI, right?
Essentially, it's on iOS, right?
So LibFFI is what, you know,
node uses underneath and like,
deno is underneath everything everyone uses
to call functions that you essentially,
you know, are not built into, right?
Eventually, when Apple allows us to use JIT
on, you know, on their platform
or like on their app store,
we should be able to improve that even further
by, you know, just pre-compiling
a few hot methods that you're using,
like quite much, right?
But essentially, like it's around that,
we have like a few benchmarks that we've done,
comparing like mostly like native React native
and native script or like the overhead
that we take for like each method, right?
And it's essentially like,
yeah, if your function does like very little
and you're calling it quite a lot,
then you're going to take, you know, a hit
and you're going to fill the hit.
But it has to be like called like quite frequently
for that to happen like thousands of times per second.
Or something, right?
Or like that on Android,
so you have like the other side,
which is Android uses the Java native interface,
so JNI and that's a bit slower, right?
So on Android,
we try to limit a bit more of like what the calls
that you do, right?
To native, but still like,
still like fast enough for, you know,
the most of like use cases
and if you're unhappy with how like that's going,
you can just write your own like, you know,
Java wrapper that does like batches a few operations
if you like really needed,
but I don't think we like ever needed that on a project.
This week, we'd like to thank our sponsor,
but we don't have one.
So if you'd like to sponsor the DevTools FM podcast,
head over to devtoolsfm.com.
slash sponsor to apply.
If you want to find another way to support the podcast,
head over to shop.devtools.fm.
There, you'll be able to find all of our cool merch
and really rep your nerd swag wherever you go.
But if you want a little less public way to support the show,
become a member on one of the various platforms
where we offer it.
There, you'll get ad-free episodes
and you'll get the episodes just a little bit earlier.
With that, let's get back to the episode.
So you mentioned run times a little bit there.
I saw a tweet from Jamie about how like JavaScript core,
you can like call directly to objective C methods.
So like, what are explorations are you doing with new run times?
And like, to me, it seems like it would be very hard
to change that at all.
Well, I should mention JavaScript core,
specifically the NeoScript runtime
was originally written on JavaScript core for iOS.
And it was extremely, you know, mature runtime.
The Taylor again progress, both did a great job with that runtime.
Sometime around 2019, 2020,
it was adapted to V8.
And V8 had a much more easier to use API,
I think in general.
And it was also evolving, you know, in a public way.
And so it around that time, it was shifted to V8
and all the focus was put on to V8 for really two reasons.
I think one was maintenance,
but also number two,
it aligned the engines between iOS and Android.
Because Android had always been on V8
and then iOS was on JavaScript core.
And so there were very subtle differences between those two.
So everyone wanted those two engines to be identical.
So they are identical today.
Other engines is like right now,
navel script runs on Hermes.
There hasn't been a whole lot of information
published about this as of yet,
mainly because there has been a poll request
sort of hanging in flight to bring note API to Hermes.
And, you know, when if that lands,
I just heard an RC was published with it
and others were invited to sort of experiment with it.
We've been working with that for maybe three or four months now.
And we do have some,
some native script examples working like an Expo, for example.
But a public release on that
probably wouldn't come until sometime 2025.
More because number one,
it depends on upstream Hermes changes to support note API,
but also we want to bring the engine to Android
before there's a full public release there.
So, like just to expand a bit,
like we are also planning on like creating
at least improving our runtimes with like a common API
so that like good hook,
you know, they trip into whatever runtime you have.
Right. So right now, like they are very like focused
on like specific tasks,
but ideally we want to like completely
the couple from v8, you know,
our like how,
our whole like object system
and everything,
what to the couple from v8.
And then you can just use that in,
you know, Hermes or Quick or whatever,
like, it doesn't matter.
Yeah, I should mention Quick.js as well.
There's some other contributors around native script.
They got it running under Quick.js,
which is another engine too.
So there's definitely quite a few like adaptations out there,
which brings up a good question,
like what is native script
when you start talking about it
in terms of these different engines?
I think it's one of more interesting
kind of conversations around it
because I think originally when it came to market,
it really was sort of
centralized around a product focus,
you know,
and I'd say ever since it's
been sort of shifted to the OpenJS Foundation,
native script is more an approach
with JavaScript to bring platform development
to JavaScript.
And so it really is intentional today
that native script aims to be as adaptable
to any engine and really any environment
in which you want to use that approach.
And I mean,
once a truly drop in adaptable
engine layer is available,
then I think that will bring true,
I think, to that statement.
This is this is really fascinating to me.
So I mean, going back to sort of
the early conversation about, you know,
there being some maybe contention
around like native scripts approach,
I found like,
I was super excited about it
because building apps that like cross layers
is like, oh,
I want to do all my work in JavaScript,
but I have to, you know,
integrate with the system at some level.
It means that there's like defining
foreign function interfaces or whatever,
like a bridge for your,
you know, app,
your JavaScript world to talk to the like hardware world
is always just such a pain.
And it takes like a specific expertise
across every platform.
And even today,
anytime that I do FFI,
it's like always, it's still a pain.
So it's like, I'm doing some Dino work
and I'm like trying to work
with like native web view APIs.
And it's like, it just, you know,
I mean, Dino is like,
Dino and like the node APIs we have today
are worlds better than it used to be,
but it's always still a pain.
And it's like, this idea, this promise is like,
oh, like it's all just JavaScript
and you can use any of the system native APIs
is magic.
Just because the idea of it's like all generated at build time.
Be careful of saying magic,
people don't like that word.
Well, I mean, it is magic though, right?
Our kind doesn't like that word, right?
Engineers don't like that word.
But yeah, I mean, that is the feeling
you get certainly, you know, when you use it.
It never wears off like that.
That feeling of magic is with you every day
when you're working with it.
So it's true.
I shouldn't mention, you mentioned Dino.
We have native script working on Dino as well.
And actually, there may be something out on that
in the next couple of weeks for the desktop.
But the, I think the general thinking,
like there's sort of this mentality,
I think in development,
if you've ever worked day in, day out
on somebody who's over your shoulder wanting to say,
go this way, go that way, go this way, go that way.
And it's always reaching and reaching
and reaching and reaching.
You know, you always, I think it's always
a difficult position to be in as a developer
to be able to say, no, we can't do that
because our stack.
And therefore, the question comes up,
what will do we need to change our stack to do this?
You know, and that's always a difficult decision
for any team.
And if you've ever been part of a team
that's had to migrate from one tech stack to another,
it's usually a pretty large undertaking.
It can be very painful.
I think the general idea with native script
is that it leaves nothing off the table.
You know, the very essence and spirit of it
is that you can do as much SwiftUI
with native script as you want.
You can do as much Jetpack compose
with native script as you want.
You can do as much Flutter with native script as you want.
And you can even move in between those paradigms
as much as you want per case.
And that is kind of the essence and point of it.
We use React Native plugins in native script today,
you know, through a community effort called OpenNative.
And that's a really brilliant effort led by Amar Ahmed,
who's from the React Native community,
and Jamie Burch as well.
And it's sort of, that at least shows
what native script brings to the table,
I think, in general.
One thing I also, like I always like to mention is,
like if you can do something native,
you can do it inside native script
because actually, native script is just
posing native to you, right?
So if you can run React Native in native,
you can run React Native in native script.
So you can run if React Native is able to call functions,
like native functions that receive a JSON sometimes,
you can just call them from native script as well.
So that's like the basis behind OpenNative itself,
which is just like a layer
that does this translation for you.
Do you have to define that layer?
Or is it all code gen?
Like how much work actually goes into defining
all of those APIs?
None, it's all code gen.
No, the OpenNative layer is kind of neat
because it does handle sort of the graderal
and objective C layer,
you know, when you bring a React Native plugin in.
I should say that right now,
it's pretty much focused on SDK layer plugins,
things like React Native's CommunityNetInfo,
for example, or React Native Auth0.
We've used that in native script apps before.
Those are more SDK level, they're not so view focused.
But Ammar has allowed OpenNative
to be working with React Native WebView,
which is actually view layer.
So the view manager does work on OpenNative in native script.
Generally, for some pretty complex view,
React Native plugins,
those typically you would probably want to adapt,
you know, to some degree.
I mean, and yes, it does mean
you could use a React Native plugin in view,
you know, you could use a React Native plugin in Angular,
you can do that with OpenNative.
As I'm thinking about this,
is like when I discovered native script originally,
the point was, or the point that I interpreted at the time
was like making building apps simpler,
just using the languages you know,
just using JavaScript.
And there were some incredibly strong benefits for it.
So one is that you don't have to recompile
after every change that you do,
even if you're accessing native things.
That the improvement of iteration speed is huge.
And y'all even today have this preview feature
that is absolutely crazy.
I mean, I think that other parts in the ecosystem
like Expo is really good and like providing previews too.
So the whole sort of ecosystem is like really leveled up,
but I still think like native scripts preview
is pretty wild because you're really touching on
like native APIs and stuff, and that's impressive.
I think the native script community
would love to work with Expo.
I mean, you know, more in bringing that stuff to Expo.
I think it's important to delineate the line,
which is what native script enables
is not something that is barred or lined from
Racknative, you know,
I think maybe traditionally in the past
that was thought to be the case,
but it's really not true.
You know, native script and what you can do in preview
can also be done in Expo
through what we already have working.
And of course, when it's,
when Node API is enabled in Hermes upstream,
you can probably get that right away,
certainly for iOS.
And it sort of bears the question, you know,
what are the use cases and what you would use that?
I mean, you know, it's hard to say
right now in terms of different projects
and challenges that are happening,
but you can maybe use it as a quick
sort of enabler just to try something out.
And then maybe you do want to then write that
in a Swift layer and objective C layer,
but it's sort of a quick enable access.
You can maybe try something out,
see if that direction is going to work.
And if it does,
that's sort of the thing I think we like
working with it with professional developments
is that we can tool it when we need to.
So if there's a case where we want to drop down a layer,
we can, you know,
and we're not, it's not a big deal to do so.
You know, if for any reason we were building out
some view that we decided we wanted to optimize
in some particular way
and we want to decide to cut this portion out,
maybe do that down in an objective C layer,
maybe want to drop that in a Swift or even Kotlin,
we could do that.
And it could still plug into the whole system.
We don't have to shift our whole stack to do that.
We have, there is an app that I think Ed
is even using for his lighting today
that is a native script app
where we did a lot of this
and we can maybe talk about it
a little bit more in direct relation
because I think sometimes these concepts
are hard to talk about on the surface
unless you're really talking about it
in like real world terms.
So we can shift into that in a minute,
but I don't want to get too direct in there just yet.
So you guys have talked about plugins,
but what is it exactly plugging into?
Like is it adding like specific,
like platform specific files and like bindings
or is it plugging into like the bundler?
So yeah.
Great question, I'll comment on this too,
but what I'd say about plugins is,
plugins are just conveniences,
you know, more than anything,
I think it also like consistent APIs, you know?
I think those are the two forms
of which you approach plugins.
Number one, can I get this thing working faster?
Number two, can I get this working
in a consistent way between iOS and Android
because oftentimes that's the point all along, right?
You usually choose some type of hybrid tech
because you want to do multiple platforms from one.
So those are the most common questions
that are easily answered with plugins.
The fact is that you can do the plugins,
of course, internally to projects
and we've done that a lot over the years
where, you know, if a plugin doesn't exist,
because of what Navelscript enables,
you can write a plugin easily inside on the project
and create your own consistent API if you want.
You know, that only makes sense in certain cases.
I mean, there are a lot of plugins out there
for some pretty concrete cases that you would need,
but, you know, I think community size
and, you know, when you compare it
to the plugin ecosystem around Racknative,
it's definitely, you know, I think it's hard to compare
because that ecosystem is very large.
Oh, like what NeatScript enables, right?
It's like core API access, right?
So like native.
But when you're like choosing the technology
you want to develop your app,
if you're just writing essentially like objective scene,
JavaScript and Java and JavaScript,
why are you just like not developing Java
and you're object to see it?
So the reason that plugins mostly exist
is that more often than not,
you probably just want to install a plugin
and just use like a common API, right?
So plugins are usually that.
So if you look at like the plugin code specifically,
I mean, some of them actually do add some Java code
or objective code or whatever,
but mostly you see like, you know,
it's like an app radio with no specific dependency
that gets pulled in, then we pull in when you install that.
And then it's just like, you know,
a file for Android, a file for iOS
and like a common API that just interrupts
with whatever APIs that you have.
So it's more like a very like convenience, I think.
Yeah, I think to answer that maybe concretely
is what is a plugin is often a pod file, maybe on iOS.
A plugin may bring in a pod file for you.
That brings in like, if we talk about Firebase SDK,
there's a iOS SDK.
So the Firebase plugin for NeatScript
would bring in that pod for you
and attach it into your project.
The include gradle that would come along with that
would also attach the Android SDK for Firebase.
And that's often what plugins are doing.
They're bringing those platform dependencies in
and then they're providing basically a surface
of a common API usually.
And that's usually all they are.
Nice. I'd like to talk a little bit about framework integration.
So NeatScript has a lot of examples and tutorials
on using a web framework that you might be familiar with.
So like View or React or Svelte or Angular.
And we've already kind of talked about
like the model is more conceptually similar
to React Native than it is to Cordova.
It's like, this isn't a web view, it's a native view
that you're rendering these UIs to.
So how do you bridge the gap
between we have this web framework
and we want it to render in these native views?
Like, what does that translation look like?
Do you have to write sort of custom code
to hook into each framework?
I know React has its own reconciler,
so it's kind of easy to plug in,
but I'm not sure how the other framework
is working that regard.
This is an interesting conversation.
Ed, I'm going to let you get into the renderer part.
It's an interesting conversation
more because of this historical nature
around NeatScript Core.
NeatScript Core really is sort of like a condensed layer
and API that basically uses everything
the runtimes provide to create some sort of consistent API,
which is what the web is, right?
And so that's where often a lot of confusion comes up.
If the web has already got this consolidated API,
what is this thing NeatScript Core?
Let's talk about that in a minute, Ed.
Yeah, I mean, Core is kind of like,
the way that I usually like to think about this
is imagine like your developing app
where you're not allowed to use div or anything like that.
What you're allowed to use is web components.
So there's a web component
that has a specific layout,
a web component that's got a web view or a button.
So that's how essentially NeatScript kind of works.
So every component that we provide in NeatScript Core
actually is just kind of like a web component
that you're using.
And then what we have is
we usually have to write our own renderer, right?
Or extend the existing renderer.
So for example, I usually maintain
the Angular integration or the Angular renderer.
And Angular is pretty easy to extend.
There's just a class that you just implement.
And then you just, essentially,
we add everything through JavaScript.
So when you add a child,
I just call it an NeatScript API
that adds a child to a component.
And then depending on what's the name of the component,
I put some kind of,
I know if you ask for a button,
I know that I have to get an NeatScript button to put here.
And that's how pretty much all our other frameworks are done.
And some people think, well,
but why not kind of just emulate the DOM?
You'd think it would be easier to do that.
But the problem is, and I think that's a pretty big problem
that I see is that people don't realize
that when you're dealing with a native app,
so when you're dealing with a web app,
you have your browser,
and then you're writing your code inside the tab that you're working in.
And then the user opens another tab,
and it's another instance.
When you develop a native app, you're developing the browser.
So if the user wants to create,
if you want to open a model,
or if you, depending on applications,
are now able to also be multi-window,
all this has to be like,
you have to handle all of this.
And it's not like, just make a DOM.
How do you represent two detached DOM trees
when you say document.add something or create something,
how do I know which DOM tree you're adding?
So it's kind of like,
especially like model navigation,
where you open a model,
and inside this model, you have your own navigation,
and once that model goes away,
you want to go back to the previous navigation that you had in.
And this is done on iOS,
with view controllers and everything.
And that's something that DOM just cannot represent.
DOM is something that you can open a model
and then you can replace the contents of a model
that seems like a navigation,
but it's not really a proper native navigation.
And if you want native behavior,
you're going to have to express things
in ways that the DOM was never thought to be possible to do.
So it's a tricky thing,
it's always a tricky situation.
And then sometimes you also have virtualized lists,
which is also a pretty big deal,
especially mobile,
when you have an app with a virtualized list,
that's always a performance nightmare
on whatever framework that you're working on.
And you have to express that.
And if you express that in a DOM way,
it's bound to be probably inefficient
and not exactly what you're looking for.
So it makes more sense
to have you create your own...
I mean, you create your own head renderer,
and then you use this kind of web component
in a way to get the result that you want.
So that conversation,
I think, also has to be discussed
in a way that you talk about divs and A tags
in the markup itself.
Like, I think a common confusion and frustration
is, well, why can't I just use a div
or an A tag here?
The reality is, you really could,
there's a register element API,
and you can actually register the div in the A
and just have that match,
and we could even do that for people through core.
So why wouldn't we do that?
You know, I think in general,
to fit all of the web cases
that are out there,
if you think about taking your website
that you have today
and using Natascript to run that on iOS and Android,
but run it natively.
So now you're rendering it natively.
But you're taking your markup that you've already written
and run it exactly as is.
What exactly is your expectation there?
We could render it pretty close,
but there are cases like float left,
float right on some of those divs,
some of the resetting that you may get
on their flow layout
that we can make a general assumption
about how that should render
in native landing could probably get pretty close.
Jamie has some examples out there
where he did exactly that
of using Natascript to render.
I think it was Reddit feed,
and he rendered the exact on markup,
actually using Natascript,
and it actually is pretty close.
Could you, yeah, you could do that.
And we could probably release something
that would just allow you to do that.
But then does it bring up this whole complaint
of, well, you know,
that's not exactly what my,
you know, web market was doing,
and now we have this whole other conversation to have.
Could it get you most of the way there?
Probably.
It could definitely be a quick like POC way
where you could take some website you've written
and just run it natively
and then start sort of tooling it from there
and make decisions on what you want to do there.
So, it's a conversation that's been evolving,
I think, around Natascript since the beginning.
It's probably closer to being some dumb layer
out there that you could use in lieu of...
Another conversation we'll talk about here,
which is Natascript Foundation,
which is sort of a new modern evolution, of course, itself.
But we'll touch on that in just a minute.
There'd probably also be like perf concerns with that, right?
Because we were talking with like the Tom Agoui creator,
et il a l'air de la façon dont il a essayé de faire un plus de performance
comme de combiner des éléments,
pour que ça rend le vu plus rapide.
Oui, je pense que vous devez être l'envers des marques
de l'ingénieur de la web,
et de mettre votre marquette à l'envers de la supertoulle.
Mais nous savons qu'il y a beaucoup de divs de nestage
sur la web, et si l'une de ces divs
s'adresse à un kit de UIVU,
par exemple, sur IOS,
c'est beaucoup d'incessaires.
Vous pouvez acheter le même layout avec Warn,
en native land.
Et donc, vous pouvez se faire de plus en plus
dans la plateforme de tournage,
juste par la nature de ce qu'il y a.
Un autre point intéressant que nous avons
dans la conversation avec le Tom Agoui,
c'est que, React Native,
c'est une building, comme Eduardo a dit,
d'un browser, et avec ça,
il y a beaucoup de choses.
Vous vous soutenez de la CSS,
et je suis sûr que ce n'est pas la vraie CSS,
c'est un CSS translaté.
Donc, je suis là-bas,
et est-ce que vous avez des choses
que vous avez portées
sur la plateforme web
pour la native script,
pour que vous soyez plus dans un browser?
Ma question est,
qu'est-ce que c'est vrai?
En fin de compte,
qu'est-ce que c'est vrai?
Vous savez, la CSS,
et même la discussion de cours,
en 2014,
la native script a été élevée,
en mars 2014,
et c'est vrai,
il y a eu beaucoup de temps.
Le corps a originalement
été créé dans la native land,
et puis, il a été adapté
à la JavaScript,
car les rondeaux
ont donné l'obligation
de faire ça.
Et ça a aussi ouvert la
door pour que la CORE
soit plus facile à contribuer,
car la plupart des gens
peuvent contribuer à la JavaScript
plus facile que la JavaScript
pour l'objectif de la CET,
ou la JavaScript.
Et aujourd'hui,
on parle d'avoir peut-être
pris des aspects de ça
en bas,
en bas,
en bas.
Le raison pour cela
est que la CORE,
en parlant de la
procédure,
vous pouvez travailler
avec quelque chose comme la CSS,
dans les aspects de la web
que vous voulez.
Vous voulez que ça soit
asoptimisé possible.
Donc, votre code de code
de la CORE
peut se faire un peu
bien et bien,
et c'est bien.
Mais vous voulez vraiment
construire sur le top
la plus tige,
la plus tige,
possible.
Parce que c'est ce que la
plateforme de web
donne,
css est un des topics
qui est
très optimisé.
CORE est
une lait optimisée,
pour sûr.
Ce n'est pas
très bas,
mais quand on parle
d'optimisation,
on parle
de très détaillant
de la minutie.
Donc, je pense que c'est
important de prendre
que,
souvent,
quand on parle d'optimisation,
on ne parle pas
d'optimisation
par la nécessité,
on parle d'optimisation
parce que nous
pouvons devenir
fricces sur la performance.
Et tout ça peut être.
Et donc,
c'est
souvent ce que nous parlons
de css.
Css est un des
des...
c'est certainement
d'implémenter
un core en JavaScript.
Donc,
la core de la naix
est la possibilité
de construire css
en naix.
Cette
implementation
pourrait être
par la lait

qui est faite
et c++
de la même manière.
Et c'est probable
que ça va
arriver dans le futur.
Oui,
additionnel pour ça,
c'est de

ce programme ici.





Et
baille,
Css
c Will
C'est juste que c'est un subset de CSS, ce n'est pas un full CSS, mais c'est bien enough
que ça vous permet de faire le style que vous avez sur le web, pour le plus grand.
Et oui, c'est juste...
C'est pas un vrai, mais c'est aussi comme...
En fin de compte, le browser fait la même chose.
C'est comme si vous passiez par un CSS et vous allez le faire et vous utilisez de façon
qu'il peut comprendre.
Le autre chose qui est intéressant de faire css en core c'est que c'est assez approchable.
Si vous voulez un petit peu de nouveau property en core et que css soit adaptable,
c'est plutôt...
On pourrait le faire dans 5 minutes sur ce call.
C'est très approchable.
Il y a un style property class, et vous pouvez faire tout ce que vous voulez,
css styleable.
Et ça devient partie de l'oncle style.
Vous vous donnez le même nom que vous voulez dans css.
C'est assez imparable et fun de la façon.
Euh...
Mais namé, ceci c'est aussi Judaism qui formalise css en candle
outro quiritt à la mer d'un hôtel Anne qui studio,
uneóleTS solution pine Sun.
Ouvrir le même networking et s'혀gi en learner dos de l' strengthené
ho gl capacit és et sa bibliothиссie Lancel walker g
en train de sé Connecté le laundryyt
pour essayer de créer une base commune
que les innovateurs sur le point de vue de JavaScript
peuvent coller sur les deux,
au moins pour les environnements non-broussés,
qui certainement sont en JavaScript.
Et nous sommes maintenant en train de
impliquer leur full spec de WinnerCG.
Et ça juste bringe des préoccupations communes,
je pense, de l'ingéniement à l'ingénie.
Je me suis juste inquiétant si j'avais des opinions sur les styles.
Si WinnerCG avait une opinion sur les styles de CSS
ou les ingéniements.
Je n'ai pas vu ça.
Je n'ai pas pensé que c'était juste
juste des runtimes de JavaScript.
Mais idéalement, on veut créer
une base commune
dans le trip.
Et ça va être essentiellement dans le futur.
On veut créer un API qui est
comme un API d'un peu plus d'un plus d'un API
que nous voulons.
Et c'est plus comme...
On va toujours pouvoir
utiliser nos vies et créer nos vies en JavaScript.
Mais c'est plus comme...
pour ne pas être expunissé
par un sublok optimal
avec vos layouts.
Parce que beaucoup de fois,
si vous avez juste de margements et de paddings,
la plupart des fois, vous ne avez pas besoin d'un UI.
Vous avez juste besoin d'un
rendu,
ou d'un layout calculation.
On pourrait créer des vies.
Nous avons un projet
d'utiliser un plugin
qui est utilisé en Tafi,
par exemple,
pour ça.
Et nous essayons de
expenser ça.
Et puis,
avec ça,
et
en approchant
notre
ingénie CSS
sous la hood,
ça vous ennemi.
C'est juste un grand vent
pour en approcher vos performances.
Oui, je pense qu'il y a
une chose intéressante
qui est danser sur cette conversation.
C'est que
toutes les extractions sont lesquelles.
Et il y a des choses que vous pouvez faire
pour que l'environnement
se fasse plus familier.
C'est comme, oh, vous avez fait des webstuffes.
Ici, vous pouvez faire des
webstuffes que vous avez faites avant,
mais comme, targetées en native.
Mais il y a toujours cette question
de la balance de ce que vous faites.
Parce que, à l'endemain de la journée,
c'est transmis à quelque chose de différent.
Et le plus ignorant que vous êtes,
le plus difficile c'est pour vous
de construire une app
de performance.
Et le plus
que vous, les maintaineurs,
avez à faire,
c'est de construire
ces abstractions
et de penser
sur ce que vous avez à faire
et ce que vous n'avez pas à faire
et comment vous documenter
les cas de courant
et tout ce que vous faites.
Donc, c'est une tension intéressante.
Je l'ai vu ici
plusieurs ans ago
en utilisant le React Native
et en essayant de mettre
les components React Native
ou, comme,
à travers le système native
et le web design
comme le Guy Tamagui
qui parle de ça.
Mais c'est comme,
le Web React Native
était la recommandation.
C'est comme,
non, on ne va pas faire
le Web React Native
on va en fait faire le Web
plus comme le React Native.
Et c'est comme,
il y a tous ces implications
et dans ma
expérience
dans la compagnie
que j'ai travaillée.
On a fini par
complètement divorcer.
C'est comme,
vous savez,
on ne va pas les partager
on va juste
partager les designs
et on va avoir
différents systèmes.
Donc,
c'est intéressant
et un peu difficile.
La description
a un même approche
comme si vous allez faire le Web
avec la description
qui est une des questions
les plus commones
vous savez,
on a un Web app
ici
on veut vous
vous en mettre
iOS et Android
sur la table.
La recommandation
aujourd'hui
et c'est comme,
nous le faisons
c'est comme,
nous le mettons dans le laboratoire
et puis nous la shareons
tous les bindings
et dans la logique
vous pouvez partager
la date de component.
Donc,
ce que vous avez à l'enquête
au bout de l'endemain
c'est vraiment
juste une décoration
pour
qui vous êtes.
Donc,
ultimement,
vous avez
un dom,
un markup
pour votre Web.
Nous personnelly
préfère ça
parce que
vous pouvez optimiser
pour chaque casque
et vous n'êtes pas
sorti de

dans une ou l'autre.
Donc,
vous pouvez utiliser
comme
le meilleur optimal
le meilleur de la manière
que vous voulez
sur un particular
un.
Et en instant
de serre
dans ce genre de
généralisation
où
vous savez,
ça devrait généralement
travailler là
et ça devrait généralement
travailler là.
Je voulais travailler
précisément
vous savez,
comme le Web
est tendu ici
et je voulais
travailler précisément
comme ce qui est tendu
sur iOS et Android.
Et je pense que
ça aussi
vous m'aimiez de l'hôpital
que j'ai entendu beaucoup
de confusion
qui est
la temps de tour
et
comment ça fonctionne
et
comment ça compare
la transpiration.
Parce que je pense que
la termine
transpiration
est souvent
quand vous parlez de
ces technologies
et c'est un concept très différent
et ce que vous endz
avec à l'end de l'heure
et les constraintes
sont très différentes.
La transpiration
est vraiment
le fait
d'en prendre
une forme
en fachéonite
et de transpirer
dans un autre.
Donc,
il sort de
transformer
dans un autre.
Ce n'est pas
tout
ce que la JavaScript
fait.
La JavaScript ne transpire
rien.
Elle en fait
directement
comme c'est.
Et c'est un point

très important
parce que
c'est vraiment
tentant de vous donner
comment vous allez
travailler avec la plate-forme
si vous le faites
en Swift.
Vous le faites
en typescript
et ça
fonctionne
dans le même
manière.
Ce sont les calls
qui sont
en train de
faire la même
compréhension.
Ils sont en train de
faire la même
compréhension.
Et vous êtes
en train de
faire exactement ce que vous

Ce n'est pas transformé
dans un autre.
Donc,
vous avez mentionné
que ce serait
intéressant de
faire ça
dans un exemple
réel
et le exemple de l'électro-

pouvez-vous
faire ça
et peut-être
des outils
et des outils
dans l'écosystème
que vous
avez vraiment
utilisé ?
Oui,
où devons-nous
commencer?
Peut-être
oui,
peut-être
on va juste
commencer
avec l'écosystème
je pense en général.
Je pense que
les
renders de la

sont
tous contribués
par la communauté.
Je pense que Ed
m'a mentionné
l'interprète
qui est
vraiment excellent
aujourd'hui.
Le v-render est fait
par Igor Rangelovic
qui est
le groupe de travail
aussi.
Le réacte
de la flavor
est fait par Jamie Birch.
Le
sphète
de la flavor
est fait par
Hanson
ou Happy Nelson.
Je pense que
comme nous
connaissons
et aussi
le
lait
est fait par
Dominative
qui est
oh,
oh,
Ed
me rappelait
que mon cerveau est en blanc.
Pas une chanson classique.
Je veux lui appeler
son nom.
Vous pouvez pas
faire cette chanson
que vous pensez,
non?
Eukino Song,
merci.
Je veux dire
qu'elle est une belle
personne.
Elle a aussi
créé
cette
chanson
qui s'appelle Dominative.
Dominative
a un bon
rêve
pour en faire
un dom.
Nous parlons
de dom
et de l'immolation.
C'est vraiment
un
approach
avec
la scripte
qui peut
enlever
les flavors
plus facilement.
Je suis juste
comme ça
sans leur
propre
rèndre.
Donc
il y a
des discussions
autour de ça.
Vous savez,
souvent
la
des plugins
de la scripte
nous utilisons
beaucoup de
ces
dans
nos
projets.
Certainement
Martin
Guyon
si je le prononce.
Martin Guyon
est le
qui
souvent
offre
beaucoup de
ces plugins.
Il a un bon travail
là-bas.
OC Fortune
aussi
fait un bon travail
dans la communauté
avec
des choses comme
Canvas.
Nous avons utilisé
le
plugin
de Canvas
qui a créé
des
3D
animatifs
et
des
works
audiovisuels
juste l'année dernière.
Et
ceux qui
ont probablement
arrêté
à moins pour moi
et je ne sais pas
si vous avez
des callouts

Je pense que vous
vous avez
fait beaucoup d'eux.
Je veux dire
Valor
a quelques 2
il y a un Websocket
qui
si vous avez besoin
c'est
Valor Websocket
le plugin
est
incroyable.
Nous
avons adapté
ce Pro
aussi.
Il y a un Pro
qui est
aussi
là-bas.
Donc
quelque chose
je suis
curieux
de
l'es
on a parlé
d'une
l'es
d'Android
Android
et
et
vous savez
même
le Pro
de

et
de
l'es
d'une
l'es

l'es

l'es
d'un

d'un
l'es
d'une
l'es
d'une
l'es
d'une
l'es
d'une
l'es
d'une
l'es
d'une
l'es

l'es
d'une
l'es
Juste
M

Nd
Il n




On
films


on











opte et c'est fait. Ce n'est pas un problème de peut-être être fait.
C'est bien sûr que ça peut être fait. C'est juste un problème de prioritisation.
Les windows ont été faits en neuf script en 2018, c'est la première fois que les windows ont été faits
avec neuf script. Il y a un POC, je pense, BunDio, qui a été dans les
corps de la pandémie, a fait une iteration sur ça. C4tion a aussi fait une iteration avec neuf script.
MacOS et Catalyst ont été élevés. Vous pouvez faire un peu de ça aujourd'hui.
Le Dino, en rafleant sur le desktop, comme je l'ai mentionné, j'espère que dans les next couple
de semaines, il y aura un exemple où les gens peuvent explorer là-bas.
Parce qu'il y a eu un travail en ce moment. Le support desktop,
en tant que de l'entraînement et de la formation, comme comme ça, est complètement
en 1er classe, comme l'IOS et l'Android, probablement vient de
avoir ce besoin professionnel pour le faire. Je pense que c'est ce qui fait que
tout le monde en neuf script. Vision Pro a été fait parce qu'il y a un client qui a
travaillé par ça et ça a été disponible par ça. Et donc, pour quelqu'un qui
veut le support de la plateforme, c'est normal que ça se passe. Le desktop,
comme ça, c'est comme de le faire en plein. Si nous étions en train de le faire comme l'approche de Core
et d'adapter tout de Core à desktop, maintenant Core est expliqué dans les files
d'IOS et d'Android. Les autres ont été indiqués par les implementations de ceux en native script.
Le même chose serait un cas pour Mac. Vous pouvez faire beaucoup de choses catalystes,
comme ça, sans beaucoup de différence. Probablement plus que ça serait dans le processus de boot-up
et des conditions initiales de la application initialement, mais beaucoup de les APIs
pour naviguer. Les catalysts pourraient probablement travailler comme ça.
TvOS est plus probable que la prochaine que nous ferions pour le fold. On a une adaptation de
TvOS sur l'IOS runtime maintenant, qui est probablement plus pour un 9.0
ou un grand élevé. Je ne sais pas si ça serait cette année, mais probablement la prochaine année.
Une chose à considérer est la plupart des choses que vous allez utiliser et être comme.
Par exemple, si vous utilisez QT, A ou autre, vous avez des APIs.
En tant que l'IOS runtime, nous avons tous les infrastructures pour appeler les APIs que vous voulez.
La réalité est que vous pouvez faire des windows avec native script,
comme on le dit aujourd'hui, mais personne ne veut vraiment faire ça pour un app.
Nous voulons donc faire un core, mais nous n'avons pas envie de le réélever
et de dire, nous voulons utiliser ça pour un développement professionnel. Nous voulons
faire un core, probablement, pour que vous puissiez utiliser tout ce qui est documenté
dans le native script docs pour faire ça.
Donc, spécifiquement, ce n'est pas la bindage générée. C'est un problème très tractable,
mais c'est les abstractures qui existent sur le top de ça, en en savoir comment faire
ça et un moyen de soutenir une plateforme cross-platforme qui est plus le plus long
de l'effort que vous avez besoin d'être soutenir pour vraiment vous donner de l'air.
Et ça sort de l'une des questions originales,
qui sont, si je pouvais juste utiliser diff et a tags, et là est mon markup,
juste faire ça, across all platforms. Et la réponse est, oui, on pourrait faire ça.
Je pense que ça serait documenté dans les cas de la base, sur le nesting et
des choses comme ça. Je pense que le plus dom, l'API a été élevé dans le core,
ce qui est un peu de la discussion que nous sommes sortis de la hint,
qui est qu'il y a un core naïve-script et puis il y a une discussion de la foundation naïve-script,
qui est une nouvelle package que le groupe de travail est en train de mettre ensemble
pour boire les choses, surtout la CSS et C++, des aspects de core,
qui sont en train de créer un core sous-current qui va évoluer des choses comme ça,
potentiellement plus directement et plus facile.
Qu'est-ce que vous avez plané pour le prochain ? Est-ce que la foundation est la main-focus
ou sont-ils des autres initiatives de plus ? La foundation est
vraiment où beaucoup de discussions sont en train de prendre place. Je pense que l'extérieur
de la soutien de la plateforme, comme si la TvOS est en train de faire 9.0,
je pense qu'il y aura des efforts là-bas, mais la foundation va probablement
prendre la plupart de la fausse, prédominantly, je pense. Je dois mentionner la soutien de la bundlée.
Il y a eu des questions sur VIT, le web pack est utilisé prédominantly. VIT est possible,
je parle avec Igor sur le groupe de travail, on peut faire quelque chose autour de VIT pour VITConf en
octobre. La main avec VIT est autour de HMR, je pense que l'import maps sont
en train de faire des stuff de HMR et import maps, je ne pense pas que vous êtes
currently supportés sur les runtimes, si nous voulons faire l'import, on pourrait probablement
faire des adaptations dans le runtime, mais d'autres que ça, la bundlée ne pourrait juste travailler,
on ne voit pas de problème. Nous voulons aussi approcher des quelques choses dans les
runtimes qui sont assez intéressantes. Maintenant, à moins que sur les runtimes iOS,
nous voulons encore mettre quelques choses au bout du temps, nous avons, pour exemple,
shared array buffers, donc vous pouvez partager des blocs de memoria entre votre JavaScript et
un travailleur que vous créez, c'est un autre thread. C'est déjà utilisé dans un app que nous
avons développé, le type que je utilise maintenant pour les contrôler mes lignes,
parce que quand vous êtes en train de le faire, cette app utilise l'app
C++ API qui est une voie star, donc un bloc de memoria, et vous pouvez dire
la length, et ensuite transmettre à la nettoire. Ce que la JavaScript fait, et c'est
une partie de la beauté de ça, c'est que si ça se voit comme, bien, ça recrute un point,
et vous êtes passés dans un array buffer, on ne copie rien, on le grabera complètement
et ensuite on le envoie. Si vous voulez le copier, vous avez les APIs que vous pouvez
appuyer, mais idéalement, on le met en tout bloc. Donc, il y a un point de
l'application, de ne pas faire de l'opération du type qui ne vous attend pas de
arriver. Donc, ça, pour Android, ça aussi s'occupe.
Ed, vraiment, devrait faire une poste sur cette
question. Je veux dire, les array buffers et la discussion autour de ça, et aussi
parler de la memoria shared, qui, je pense, a été, à un moment,
un commun, un complément ou un marque, qui est utilisé souvent contre la JavaScript,
parce que l'assumption est que tout est peut-être copié dans les rappeurs, mais la réalité
est que vous n'avez pas besoin. Donc, les array buffers shared sont un
moyen d'évoquer ça, et Ed, vous devez faire quelque chose sur ça.
La JavaScript, c'est aussi une single thread,
c'est comme si tout le monde connaissait ça, mais la chose à considérer, c'est que
vous pouvez seulement avoir un accesse de thread en JavaScript à un moment,
mais pas le même thread. Vous pouvez avoir d'autres threads qui
interviennent dans votre plan de JavaScript pour faire des choses, et ensuite,
exécuter. Ça va bloquer la main thread, si la main thread
doit travailler. Mais vous pouvez utiliser ça pour des petites choses,
que vous n'allez pas appeler comme une fonction, et ça va retourner
dans un autre thread, vous pouvez le faire.
Ou vous pouvez utiliser des travailleurs, et les travailleurs
que la chose peut faire.
Ce qui me passe, a une bonne興iabilité ici,
et que toutes les choses sont en sécurité parkok.
Donc, vous devez avoir un réseau de th Workshop,
et que lesक, les t 해� pelo l l v s n,
ce n est pasuce.
Il faut avoir un אחד positif, et que ce soit valorisé d'une
et on peut juste interrompre, comme si c'était une fois, avec les frères ou tout ça.
On regarde cette app que vous parlez de, qui fait ça.
Je ne sais pas si vous pouvez montrer ça ou ce qui vous a apporté.
C'est une app que Ed et moi ont travaillé ensemble.
C'est un app qui a beaucoup d'analogues, c'est juste pour le iPad.
Il fait déjà un tour sur Android et Vision Pro aujourd'hui.
Ceux de réelité sont probablement plus tard dans le siècle.
Ed, je ne sais pas si vous pouvez montrer quelque chose ou s'appliquer sur des effets.
Oui, pas sûr.
C'est juste comme une app iPad.
C'est au moins comme un iPad.
On travaille sur les versions Android et Vision Pro.
C'est comme une app Angular, mais elle utilise des scripts.
Elle a beaucoup d'informations.
Il y a un projet très simple, qui a l'air de 1.
On a ici les fixations que j'ai, qui sont juste 1.
1 est déjà 20 pixels.
C'est assez léger, mais ici je peux changer l'intense de la lumière.
Mais je peux aussi changer la tintesse.
Je peux aussi changer la couleur si j'ai besoin.
Oh oui, il y a ça.
Ce sont des effets de temps en temps réel,
les iPads à DMX qui contrôlent les lignes.
C'est un des effets de temps réel.
C'est un des effets de temps réel.

C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.






C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.


C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.






C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.







C'est un des effets de temps réel.
C'est un des effets de temps réel.

C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.



C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.








C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.



C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.

C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.

C'est un des effets de temps réel.

C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.
C'est un des effets de temps réel.




C'est un des effets de temps réel.
C'est un des effets de temps réel.