Now, why do we need Frontend UI Frameworks?
I answered it in the last lecture already,
I just wanna summarize it here.
Building complex frontend interfaces,
which are powered by a browser side to JavaScript code,
since it's stat code that allows us to change
and manipulate the DOM,
can become very difficult error-prone and cumbersome
as your interface becomes more complex.
Now, the reasons for that in the end are
that you have to select and store all the DOM elements
with which you want to interact, like for example here
in the example from the last course section
where I need to get access to my forum and the to-do list,
and then in various functions,
I also have to get access to other elements,
like for example here in deleteTodo
where I get access to the button that was clicked
so that I can then get access to the list item
that contains the button.
This is all very cumbersome,
and we always have to look at the HTML code to find out
that if we want to get hold of a certain element,
which ID it has and so on.
So that is all pretty annoying.
And it's not even all because as soon as we got hold of
certain elements and we fixed this problem,
we now often want to add event listeners,
or we want to store some data,
which we need in different parts
of our front end user interface.
For example, in this code,
of course we add event listeners here at the bottom
or one event listener to be precise,
but I also then add event listeners to the buttons of a new
list item element, as I create those buttons.
And I do need to manage data,
which is needed in different parts of this interface.
I store my edited to do element as soon as we start editing.
So as soon as we clicked the edit button,
because I need this edited to do element in different other
functions, because it's this edited to do element,
which has to do ID stored with such a data dash attribute.
And whilst we can use these data dash attributes,
we again have to remember that we add them
to the elements in the first place.
We have to remember their names and we have to manage them
in different parts of our code.
And this can also become annoying.
And then last, but definitely not least.
We of course also have to update the DOM.
When things change. When we add a new to-do, for example,
we have to insert this new to-do item,
DOM element into our DOM, into this list of elements.
And as you can see in this code,
I showed you in the last section,
it can be a lot of code to add a simple,
to do element with two buttons into the DOM.
And again, here, it's a lot of code.
You have to write a lot of code, you have to maintain,
and a lot of possibilities to mess something up.
Because the more code you have to write
and the more nitty-gritty details you have to take care of,
the easier it is to introduce an error.
So working with JavaScript code
in this case on the frontend,
as shown to you, can be very annoying.
And we can sum up this overall problem,
which we're facing here.
We are writing this browser side JavaScript code for
interacting with our interface in an imperative way.
Now, what does this mean?
Imperative simply means that in the end we write
step by step instructions.
We first write the code to select an element.
Then we write the code to add an event listener.
Then we add all those functions. And in those functions,
we also have step-by-step instructions.
We first create the list item element.
Then we set the, to do ID on it,
on this data dash attribute.
Then we add a paragraph.
Then we set the text of this paragraph and so on.
And of course programming is about executing code
step-by-step after each other.
But if we are talking about the user interface,
it can be very annoying and cumbersome and error prone
if we have to describe the interface and the changes that
should be performed on that interface
in such a step-by-step manner,
because it's easy to forget a step or to mix up steps.
And just to bring this back to memory and be clear here,
this is not how we normally write our interface code.
Normally we write HTML code because there
we don't have step-by-step instructions. Instead,
we describe how our final interface should look like.
We clearly say that we want to have two sections where in
the first section, we want to have a forum.
And in the second section and unordered list.
With HTML code, we've got this easy to read markup code
where the relations between different elements
are easy to see.
We are not saying,
please create a section, now add a forum, now add a label.
Instead, we just write the overall markup
where we can see that a forum has a label and the input.
And that's the key difference, with HTML code,
we can see the final result here, the final structure of our
document. With JavaScript code, we just have
line after line,
and it's not really easy to see how these elements will be
related. We have to read all the code to understand it.
And as mentioned, it's easy to mess something up there.
So writing such a user interface related code in an
imperative way is annoying and error prone.
And that's where these front-end JavaScript UI frameworks
help us because they solve this problem by giving us a
declarative approach of defining our interface and the
different states we want to have in that interface.
And when these states should change and switch,
and this sounds totally abstract right now,
I'm fully aware of that,
but that's exactly what we're going to learn in this course
section.
We're going to learn how we can use one of these frameworks
to write our JavaScript code, our browser site
JavaScript code in such a declarative approach to build a
complex user interface in a way easier way.
Because we will be able to just describe our desired
end results and states.
And it will then be up to the framework which we're using to
figure out that the nitty-gritty details and take care about
them behind the scenes.
Just as we're using express on the backend so that we don't
have to focus on the nitty-gritty details of finding out
which path a request used or which method a request used
there.