Czemu minifikacja jest potrzebna?

Webpack minifikuje pliki .js / .css / inne? w szczególności ucina białe znaki i zmienia nazwy zmiennych na jednoznakowe. Ich dokumentacja zaleca włączenie tej opcji w kilku miejscach, np. tu.

Ma to swoje znaczenie do obfuskacji kodu, ale o ile rozumiem głównym założeniem jest optymalizacja czasu ładowania strony.

Nie do końca rozumiem, czemu to jest istotne pod względem czasu ładowania strony?

Serwery, jeśli się nie mylę, wysyłają zazwyczaj przeglądarkom kod strony skompresowany za pomocą gz. Kompresja bez problemu radzi sobie z często powtarzającymi się, choć długimi napisami. Dlatego też nie ma większego znaczenia, że po minifikacji będą pozostawać takie napisy, jak class czy createElement:

class a extends o.Component{render(){return o.createElement("p",null,"Hello"," ",this.props.toWhat)}}

Czemu ma znaczenie, że jest class a zamiast class Hello oraz extends o.Component zamiast extends React.component?

Czy dobrze rozumiem, że założenie jest takie, że biblioteczne nazwy (Component, props, createElement, etc) mają szansę się często powtarzać, wobec czego kompresja gz poradzi sobie z tym, podczas gdy moje identyfikatory (class Hello, import React from react`) mają szansę niezbyt często się powtarzać, albo wręcz być tylko jednorazowe, w związku z czym muszą być zastąpione pojedynczymi literkami?

Po prostu wychodzi mniejszy plik, zero filozofii.
Możesz sobie porównać - spakuj swoje js choćby zipem, a potem usuń białe znaki i znowu spakuj. Nieduża różnica ale po co przepłacać.

Kiedyś walczono o każdy przesyłany kilobajt bo to była nawet sekunda ładowania dłużej. Teraz hello world zajmuje 3MB więc ludzie zaczynają pytać po co usuwać białe znaki, a niedługo będzie po co używamy jpg

Tutaj masz artykuł na ten temat

Minifikacja pomaga usunąć dodatkowe kilka kb, z którymi gzip sobie nie poradził

Kompresja jest bezstratna serwer nie jest na tyle "mądry" aby wiedzieć, że w przypadku js można usunąć białe znaki więc zysk jest.

no dobrze, ale w takim razie dlaczego zostawiło o.Component zamiast zrobić z tego, nie wiem, o.x albo o.h? Minimizer ma dostęp do kodu źródłowego reacta więc powinien móc to zrobić?

mało tego, dlaczego zostawil class i extends? No jasne: to są słowa kluczowe języka, nie można ich tak po prostu opuścić. Ale przy takim parciu na każdy kilobajt to imaginowałbym sobie, że przeglądarki powinny zaimplementować jakiś miniJS, miniHTM oraz miniCSS, tym sie różniące, że w miniJS nie ma while tylko jest w, w miniHTML nie ma span tylko t, zaś w miniCSS nie ma min-content tylko v? + kompilator normalnego JS, HTML + CSS do miniJS, miniHTML, miniCSS

nie dałoby się w tym programować bez transpilera, aż takiego parcia nie ma. minimizery to 3rd party toole które po prostu wykorzystują różne techniki i robią co mogą żeby sprytnie wyciągnąć max z tego co się da bez współpracy z twórcami przeglądarek i standardów
react został "zminimalizowany" osobno, takie rzeczy jak Component są zaznaczone jako publiczne exportowane api i minimizer ich nie rusza żeby były dostępne z zewnątrz dla developerów pod ludzką nazwą - nikt nie zmusza do używania minimizera, kod zminifikowany można używać z zewnątrz w ten sam sposób co zwykły. Możesz zapewne włączyć react do projektu zamiast używać go jako zależności, wtedy czas pakowania się trochę wydłuży ale powinno zostać zrobione to o czym piszesz, tylko że to już popadanie w paranoje

YetAnohterone napisał(a):

no dobrze, ale w takim razie dlaczego zostawiło o.Component zamiast zrobić z tego, nie wiem, o.x albo o.h?

Skrypt do minifikacji nie może w takich wypadkach zmieniać nazw rzeczy (klas, metod, funkcji itd), które są eksportowane na zewnątrz. Zwłaszcza, gdy nie ma jednego ustalonego standardu i jeden algorytm zmieni to na o.h, a drugi przykładowo na x.D.

Powodowałoby to ogromne problemy. Wyobraź sobie sytuację, że wrzucasz sobie kod reacta na stronę i zamiast używać React.Component tak jak masz w dokumentacji to musisz używać jakiegoś o.h, bo tak ustawił skrypt do minifikacji.

Xarviel napisał(a):

Powodowałoby to ogromne problemy. Wyobraź sobie sytuację, że wrzucasz sobie kod reacta na stronę i zamiast używać React.Component tak jak masz w dokumentacji to musisz używać jakiegoś o.h, bo tak ustawił skrypt do minifikacji.

Jasne, gdyby minifikator miał dostęp tylko do kodu reacta. Ale on ma dostęp zarówno do kodu reacta jak i mojego. Więc ja powinienem pisać React.Component, a przeglądarka otrzymywać o.h?

YetAnohterone napisał(a):

Jasne, gdyby minifikator miał dostęp tylko do kodu reacta. Ale on ma dostęp zarówno do kodu reacta jak i mojego. Więc ja powinienem pisać React.Component, a przeglądarka otrzymywać o.h?

A co w przypadku jakby część kodu byłaby generowana przez minifikator, a część pochodziła z jakiegoś innego źródła typu <script src="https://example.com/assets/js/widget.js"></script> do której nie masz dostępu i jest pomijana przez Twój proces minifikacji? Wtedy przy korzystaniu z tej samej biblioteki byłyby błędy.