Now that is the front- end code.
And again, we'll see it in action
in a couple of minutes, no worries.
I wanted to explain it in great detail though
so that we're all on the same page,
and you have a chance of understanding it
once you see the action soon.
But now one big question might come up:
Why are we doing that?
Why are we not just adding a regular view to the backend
and we rendered this dynamic data on the backend
as we did it before in the course.
So why might we wanna have such a decoupled fronted
which runs on a different server,
which uses these Ajax requests to talk to a backend?
The answer is we could absolutely add views to the backend,
but maybe we built an API;
we decided to go for an API instead of a classic website
because we wanna have our clients as well.
Maybe we also are building a mobile app that should talk to
this API.
And therefore we went for an API instead of a classic
website.
This could be one reason for having such a decoupled
front-end. Another reason could be that such a decoupled
front-end,
which is served by a different server and where JavaScript,
browser side JavaScript, is responsible for updating the
user interface could provide a better user experience,
not necessarily in all cases,
but it could provide a better experience because since we
use browser side JavaScript code,
we never have to wait for a response from the server.
I mean, we technically do, but for the user,
when the user clicks a button,
it's not the case that he or she sees the page refreshing,
or has to wait for a response where the user might see an
empty page whilst we're waiting. But instead,
the user just sees a user interface and the page on which
the user is never reloads the visitor off this page,
never loads a different page because we have only one HTML
file.
And then it's the JavaScript code,
which updates this existing page.
But therefore,
since all this updating happens behind the scenes,
we could provide a better user experience because to the
user, to the visitor,
it's almost this mobile app like experience, where you are
on a user interface and you never have a flashing white
screen whilst a new page loads,
but instead parts of that user interface update,
as you interact with it, for example,
here only the unordered list will update the rest of the
pages static and will never change.
And this could be a better user experience,
not necessarily always, but it could be.
So these are reasons why we might go for such a decoupled
front-end and nowadays in modern web development,
it's pretty normal to have decoupled
front-ends, just as it is also still normal to build classic
websites as you learned it throughout this course.
And as you learned, you
can also easily transition from classic websites to APIs.
That's hopefully one of the main takeaways in this section
anyways, but with that,
this is why we might want to have such a decoupled front-end
and this is how the code generally works there.
But now that was a lot of talking.
Let's finally see how it works.
And there we'll see that we run into an error.