Minifikacja JS

Question

Odnośnie projektu który teraz robię (https://github.com/kornellapacz/minlib.js). Chcę żeby to była jak najlżejsza biblioteka. I teraz pytanie: jak daleko można zajść z minifikacją kodu. Wiadomo skracanie nazw zmiennych, usuwanie białych znaków. Ale czy np można zaryzykować pousuwanie ";" ? (wiadomy parę bitów do przodu  a JS i tak podobno wstawia je automatycznie). I czy znacie jeszcze jakieś sposoby ? (oprócz kompresji np : gzip)  

Comments

Pokrętna logika

"Drobna warstwa abstrakcji" – czyli zaczynasz walczyć z samym językiem tylko po to, żeby nie stawiać średników ;)

Wyciągasz moje słowa z kontekstu. "Drobna warstwa abstrakcji" jest potrzebna po to, aby uznać średniki za zbędny dodatek, a nie po to, żeby była formą walki z językiem. Swoją drogą z nikim nie walczę - bo to po prostu działa.

A prawda jest taka, że na średnikach i tak nic nie zyskujesz – minifikator zrobi optymalizacje, o których Ty nawet nie pomyślisz przy pisaniu kodu.

A kompilator zrobi optymalizacje, o której minifikator nawet nie pomyśli... i co z tego? Podle sugerujesz jakobym uważał, że niewstawianie średników uczyni mój kod bardziej wydajnym. Nic z tych rzeczy. Tu nie chodzi o wydajność, tylko o mój czas. Piszę setki linijek kodu miesięcznie - już samo rozpraszanie przez krzyczący o średnikach linter jest irytujące.

Poza tym: to nie jest "zbędne dekorowanie kodu". Samo istnienie ASI wskazuje na to, że średniki są niezbędne do "kompilacji" JS-a.

Właśnie dlatego, że istnieje ASI - średniki to zbędne dekorowanie kodu

---

A wiesz dlaczego istnieje ASI? Już tłumaczę: bo pierwsi programiści JS nie byli programistami a klepaczami kodu, zaś sam JS służył do tworzenia padającego śnieżku. Dlatego też ktoś wpadł na genialny pomysł, że nie pójdzie w stronę drakońskiej obsługi błędów XML, a w stronę wybaczającego głupoty HTML-a. Tym sposobem powstał mechanizm, który wstawia średniki zamiast programisty i tworzy iluzję, że nie są potrzebne. Tymczasem są i ich brak powoduje błąd składni. Nikt tego nie doświadczył, bo ASI z quirka engine'a stało się standaryzowaną częścią JS-a, która istnieje WYŁĄCZNIE dla zachowania wstecznej kompatybilności z kodem z lat 90' ubiegłego wieku. Z tego też powodu ten bzdurny mechanizm nie może zostać usunięty z przeglądarek – a szkoda, bo… jest bzdurny.

Tu nie chodzi o wydajność, tylko o mój czas. Piszę setki linijek kodu miesięcznie - już samo rozpraszanie przez krzyczący o średnikach linter jest irytujące.

A ja rzeknę tak: dobre narzędzia same naprawiają takie problemy w kodzie. Jak zapomnisz średnika, to ESLint czy Prettier może to poprawić, a Ty nawet nie musisz kiwnąć palcem. Więc argument średnio trafiony.

"Drobna warstwa abstrakcji" jest potrzebna po to, aby uznać średniki za zbędny dodatek, a nie po to, żeby była formą walki z językiem. 

Ale jak wstawiasz średniki, to tej warstwy nie ma. Żeby nie wstawiać średników należało wprowadzić do stylu kodowania reguły całkowicie od czapy – i to jest IMO walka z językiem w czystej postaci: udowodnić za wszelką cenę, że się da.

Inna rzecz: czemu nikt się nie rzuca o obowiązek wstawiania średników chociażby w PHP? Odpowiedź jest prosta: nie ma tam bzdurnego mechanizmu, który pozwala pisać niepoprawny składniowo kod i modlić się, żeby parser to zrozumiał. Błąd składniowy to błąd składniowy – amen.

---

A wiesz dlaczego istnieje ASI? Już tłumaczę: bo pierwsi programiści JS nie byli programistami a klepaczami kodu, zaś sam JS służył do tworzenia padającego śnieżku. Dlatego też ktoś wpadł na genialny pomysł, że nie pójdzie w stronę drakońskiej obsługi błędów XML, a w stronę wybaczającego głupoty HTML-a. Tym sposobem powstał mechanizm, który wstawia średniki zamiast programisty i tworzy iluzję, że nie są potrzebne

Na pierwszym miejscu postawiłbym argument: ASI istnieje, ponieważ ludzie są leniwi.

standaryzowaną częścią JS-a, która istnieje WYŁĄCZNIE dla zachowania wstecznej kompatybilności z kodem z lat 90' ubiegłego wieku. Z tego też powodu ten bzdurny mechanizm nie może zostać usunięty z przeglądarek

A co z nodem?

A ja rzeknę tak: dobre narzędzia same naprawiają takie problemy w kodzie. Jak zapomnisz średnika, to ESLint czy Prettier może to poprawić, a Ty nawet nie musisz kiwnąć palcem. Więc argument średnio trafiony.

Co za różnica, czy zrobi to ASI, bundler, czy Prettier? I tak polegasz na maszynie która nie rozumie kodu.

Ale jak wstawiasz średniki, to tej warstwy nie ma.

Nawet jak wstawiasz średniki, to: "Drobna warstwa abstrakcji jest potrzebna po to, aby uznać średniki za zbędny dodatek"

 Żeby nie wstawiać średników należało wprowadzić do stylu kodowania reguły całkowicie od czapy – i to jest IMO walka z językiem w czystej postaci: udowodnić za wszelką cenę, że się da.

Imo wyolbrzymiasz 

reguły regułę
udowodnić za wszelką cenę wszelką cenę? jaka tu jest cena? wstawienie NIEZBĘDNEGO średnika raz na 20k linii?

Inna rzecz: czemu nikt się nie rzuca o obowiązek wstawiania średników chociażby w PHP? Odpowiedź jest prosta: nie ma tam bzdurnego mechanizmu, który pozwala pisać niepoprawny składniowo kod i modlić się, żeby parser to zrozumiał. Błąd składniowy to błąd składniowy – amen.

Jeśli dany kod wykonuje się prawidłowo w każdym środowisku, czy jest możliwe, aby miał niepoprawny syntax?

---

Na pierwszym miejscu postawiłbym argument: ASI istnieje, ponieważ ludzie są leniwi.

Więc są od tego narzędzia :P Jakoś w innych językach nikt nie jest na tyle leniwy, żeby nie postawić średnika czy wcięcia.

A co z nodem?

Node ma silnik przeglądarki, więc interpretuje kod tak samo jak Chrome. Dowód? Spróbuj wpleść komentarze HTML do kodu ;)

 

Co za różnica, czy zrobi to ASI, bundler, czy Prettier? I tak polegasz na maszynie która nie rozumie kodu.

Ale ma inne reguły niż parser z ASI? I tym samym wstawi średniki zgodnie z logiką, która Ci odpowiada (np. na końcu każdej linijki bez oglądania się na nawiasy w kolejnych liniach).

Nawet jak wstawiasz średniki, to: "Drobna warstwa abstrakcji jest potrzebna po to, aby uznać średniki za zbędny dodatek"

 Ale ta "warstwa abstrakcji" to uznanie, że jest zbędny, bo istnieje w każdym parserze JS mechanizm poprawiający błędy składniowe.

Imo wyolbrzymiasz 

reguły regułę 
udowodnić za wszelką cenę wszelką cenę? jaka tu jest cena? wstawienie NIEZBĘDNEGO średnika raz na 20k linii?

REGUŁY. I właśnie dlatego Standard.js zrobił niedźwiedzią przysługę community, bo uszczuplił zasady ASI i tym samym programiści zaczęli się rzucać, że kod nie działa – mimo że działał dokładnie tak, jak jest napisane w specyfikacji.

Jeśli dany kod wykonuje się prawidłowo w każdym środowisku, czy jest możliwe, aby miał niepoprawny syntax?

Tak, patrz: XML-owe zamykanie tagów w HTML 4. Błąd, który był tak częsty, że w ramach HTML5 go ustandaryzowano. Brzmi jak ASI, prawda?

Zresztą zobaczmy do specyfikacji: 

Most ECMAScript statements and declarations must be terminated with a semicolon.

Owszem, później pojawia się stwierdzenie, które rani moje serce:

For convenience, however, such semicolons may be omitted from the source text in certain situations. 

Niemniej pytanie brzmi: czy na pewno chcesz pamiętać wszystkie reguły ASI – żeby się przypadkiem nie ośmieszyć? Jeśli używasz wyłącznie reguł, które radośnie zaaplikował Standard.js, to jest ku temu szansa. Jak chce się omijać średniki, to cały ten rozdział specyfikacji trzeba de facto wykuć na pamięć.

Podsumowując: tak, kod JS bez średników jest niepoprawny składniowo i omijanie średników to po prostu pozwalanie parserowi na poprawienie błędów składniowych wg reguł opisanych dokładnie w specyfikacji.

---

Masz rację. Dzięki Comandeer za tę dyskusję, sporo mnie ona nauczyła.

Answer 1

 I teraz pytanie: jak daleko można zajść z minifikacją kodu

Do 245B

Comments

https://github.com/kornellapacz/minlib.js/pull/1

Answer 2

Ale czy np można zaryzykować pousuwanie ";"  - nie można. Znajdź jakieś narzędzie do minifikacji JS i go zastosuj, przy tak małym projekcie, nie ma też sensu walka o każdy bajt.

Comments

 przy tak małym projekcie, nie ma też sensu walka o każdy bajt

Moim zdaniem własnie na tym cała zabawa polega ; )

---

Moim też