We've now seen a lot of different options for transpiring and bundling, and these options include either
setting up that remote API or just doing everything locally inside the browser.
So I put together a little list here of kind of pros and cons of each approach.
So if we go with this kind of remote approach of sending out setting up some outside public API, the
upsides there are that we can very easily download NPM modules and cache them on that API server.
And that means that in theory we could bundle code for all of our different users much more quickly.
The other big benefit to this is that because our server is responsible for transport and bundling,
any user who is on a slow device or has a limited Internet connection, we'll be able to run our application
much more quickly whenever you download dependencies.
That's a lot of bandwidth being used.
So if we can make sure that our users don't have to download a ton of source code in order to do this
bundling or transpiring, well, it would definitely be a net benefit for them, even though they do
have to make an extra request to this API.
Now, on the local aspect, if we implement the trans in the bundler inside the reactor application,
there's some definite upsides there as well.
So if we got the local approach, we're definitely going to possibly have faster execution of code because
we no longer have to rely upon making a request to our API server, just getting our code over to that
API server could take some number of milliseconds.
That's just additional time.
We have to wait.
The other benefit is that in this style, we don't have to create this outside observer at all.
We don't have to make this outside bundler or worry about deploying it or maintaining it or anything
like that.
That is a huge benefit, especially considering that this book application that we are putting together
is really not a commercial app or say we're not really selling this for money or anything like that.
This is really just a tool for any arbitrary developer to make use of this.
It's kind of like, hey, if you want to use this tool, great, but you're going to have to maintain
some this infrastructure or essentially run this infrastructure yourself in the form of really just
running the react application.
And then finally, in theory, there's also going to be less complexity here because, well, we don't
have an API server.
We don't have to develop that entire thing or worry about implementing that bundler or worry about moving
code back and forth between the React app and that API.
So in total, between these two approaches, I think that we're going to go honestly with the local
approach, the reason for this just you know, I have implemented both styles in developing this course.
The local approach ends up being significantly faster.
There's actually some other really interesting challenges that we're going to run into if we take this
local approach.
And that's really kind of what this course is all about.
It's all about showing you some interesting problems and challenges that come up.
So I'd rather go to a slightly more challenging possibly solution where we might have to run into a
couple of problems and have to solve them.
So that means that we need to go build up our reactor application and somehow implement Watpac inside
of it with this custom plug in, we also need to make sure that inside of a reactor application, we
have some kind of in Browsr transpire, something to take all that jazz, all that kind of stuff and
convert it into plain JavaScript code.
This is quite the undertaking we need to maybe wire up something like Babille or Watpac inside of a
reactor at.
Now, having said that, there's one little problem that we're going to run into very quickly with this
local approach and this problem is very easily summarized.
Here's a small problem.
Turns out Watpac does not work correctly in the browser.
You could probably bang your head against the wall quite a bit and you're not really going to get Watpac
working correctly inside of a react application.
So this kind of throws a really big wrench in our plans.
We can't use Watpac at all.
So how are we going to do this bundling process?
Well, let's not give up hope just yet.
Turns out that there's actually going to be a rather elegant solution here, some other library we can
use.
That's really going to be the absolute pinnacle or the linchpin, I should say, of our entire app.
Let's take a look at how are we going to solve this problem in just a moment.