1
00:00:02,240 --> 00:00:04,370
When React was first released, its

2
00:00:04,370 --> 00:00:06,660
performance was striking and helped set it

3
00:00:06,660 --> 00:00:09,860
apart from the competition. The React team

4
00:00:09,860 --> 00:00:12,160
recognized that JavaScript is fast, but

5
00:00:12,160 --> 00:00:15,020
it's the DOM that makes it feel slow. They

6
00:00:15,020 --> 00:00:16,530
realized that updating the DOM is

7
00:00:16,530 --> 00:00:19,080
expensive, so they found that updating the

8
00:00:19,080 --> 00:00:21,320
DOM in the most efficient way would help

9
00:00:21,320 --> 00:00:24,025
enhance performance. So behind the scenes,

10
00:00:24,025 --> 00:00:26,230
when you change data, React intelligently

11
00:00:26,230 --> 00:00:27,980
figures out the most efficient way to

12
00:00:27,980 --> 00:00:31,020
update the DOM. When React was created,

13
00:00:31,020 --> 00:00:33,410
years ago, this was a novel design that

14
00:00:33,410 --> 00:00:35,680
gave React a notable performance advantage

15
00:00:35,680 --> 00:00:40,200
in many cases. See, before React, most

16
00:00:40,200 --> 00:00:42,500
libraries would unintelligently update the

17
00:00:42,500 --> 00:00:44,970
DOM to reflect the new state. This often

18
00:00:44,970 --> 00:00:46,950
lead to redrawing a significant portion of

19
00:00:46,950 --> 00:00:49,540
the page, even when only a minor change

20
00:00:49,540 --> 00:00:52,880
had occurred. In contrast, React monitors

21
00:00:52,880 --> 00:00:55,350
the values of each component state. When a

22
00:00:55,350 --> 00:00:57,610
component state changes, React compares

23
00:00:57,610 --> 00:01:00,060
the existing DOM state to what the new DOM

24
00:01:00,060 --> 00:01:02,390
should look like. It then determines the

25
00:01:02,390 --> 00:01:05,010
least expensive way to update the DOM.

26
00:01:05,010 --> 00:01:06,880
This sounds complicated, but it's all

27
00:01:06,880 --> 00:01:09,470
handled automatically behind the scenes.

28
00:01:09,470 --> 00:01:11,750
And there are multiple benefits to this

29
00:01:11,750 --> 00:01:14,940
approach. It helps avoid layout thrashing,

30
00:01:14,940 --> 00:01:17,170
which is when a browser has to recalculate

31
00:01:17,170 --> 00:01:19,480
the position of everything when a DOM

32
00:01:19,480 --> 00:01:22,460
element changes. And being efficient is

33
00:01:22,460 --> 00:01:24,470
increasingly important in a world where

34
00:01:24,470 --> 00:01:27,100
many people are using mobile devices.

35
00:01:27,100 --> 00:01:29,240
Mobile devices vary widely in their CPU

36
00:01:29,240 --> 00:01:31,800
power, and conserving battery life is a

37
00:01:31,800 --> 00:01:35,040
concern as well. This also enables React

38
00:01:35,040 --> 00:01:37,290
simple programming model. When data

39
00:01:37,290 --> 00:01:40,220
changes, React efficiently updates the DOM

40
00:01:40,220 --> 00:01:43,070
automatically, and there's nothing extra

41
00:01:43,070 --> 00:01:44,480
that you have to do to enjoy this

42
00:01:44,480 --> 00:01:46,630
performance benefit. When you update the

43
00:01:46,630 --> 00:01:48,190
state of a component, it happens

44
00:01:48,190 --> 00:01:50,610
automatically. The comparison happens in

45
00:01:50,610 --> 00:01:54,380
memory, so it's typically very fast.

46
00:01:54,380 --> 00:01:56,440
Today, a variety of other libraries use a

47
00:01:56,440 --> 00:01:58,640
similar approach, but Reacts performance

48
00:01:58,640 --> 00:02:01,610
remains quite competitive. React offers

49
00:02:01,610 --> 00:02:03,850
various performance optimizations, but in

50
00:02:03,850 --> 00:02:06,570
my experience, they're rarely necessary.

51
00:02:06,570 --> 00:02:08,800
React is fast enough by default that many

52
00:02:08,800 --> 00:02:12,410
apps run great on the first try. Of

53
00:02:12,410 --> 00:02:14,280
course, the library size also has an

54
00:02:14,280 --> 00:02:16,870
impact on performance, too. React with

55
00:02:16,870 --> 00:02:19,890
React DOM weighs only 35k when G‑zipped

56
00:02:19,890 --> 00:02:22,390
and minified, so React lends itself well

57
00:02:22,390 --> 00:02:25,010
to bandwidth constraint use cases like

58
00:02:25,010 --> 00:02:27,570
mobile. It's significantly smaller than

59
00:02:27,570 --> 00:02:29,990
many of its competitors, but if you need

60
00:02:29,990 --> 00:02:32,340
the smallest library size possible, there

61
00:02:32,340 --> 00:02:34,530
are alternative React‑like libraries that

62
00:02:34,530 --> 00:02:37,940
you can consider using as well. Inferno is

63
00:02:37,940 --> 00:02:39,880
a lightweight React alternative that only

64
00:02:39,880 --> 00:02:43,920
weighs 9k, but has a very similar API to

65
00:02:43,920 --> 00:02:47,330
React. And Preact is even smaller,

66
00:02:47,330 --> 00:02:50,550
weighing in at only 3k. Both Preact and

67
00:02:50,550 --> 00:02:52,800
Inferno are extremely similar to React and

68
00:02:52,800 --> 00:02:55,570
utilize the same API. They just omit a few

69
00:02:55,570 --> 00:02:58,610
features to help keep the size down. So

70
00:02:58,610 --> 00:03:00,850
these are great options if the bundle size

71
00:03:00,850 --> 00:03:07,000
is a high priority for you. And it's easy to switch to these later, if desired.

