Zmęczenie Javascript

Kilka dni temu spotkałem się z przyjacielem i zajrzałem przy kawie.

Saul: „Jak leci?”
Ja: „Zmęczona”.
Saul: „Rodzina?”
Ja: „Nie, JavaScript”.

Mówiąc dokładniej, miałem na myśli React i towarzyszący mu ekosystem Javascript.

Na początek rozważ to

zapytany, dlaczego React jest przytłaczający dla początkujących:

Jeśli korzystasz z Reacta, prawdopodobnie masz te same doświadczenia z

:

W społeczności Reacta istnieje poważny problem, który paraliżuje początkujących i przeszkadza zarówno ekspertom, jak i ekspertom.

Za dużo narzędzi.

W pracy w minionym kwartale mozolnie rozpoczęliśmy trzy nowe projekty. Mówię „z wyczuciem”, ponieważ każdy projekt wymagał podejmowania decyzji dotyczących narzędzi w zależności od zakresu i potrzeb.

Ostatecznie problem polega na tym, że wybierając React (i nieodłącznie JSX), nieświadomie wybrałeś mylące gniazdo narzędzi do budowania, szablonów, lintersów i pochłaniaczy czasu, z którymi musisz sobie poradzić, zanim zaczniesz cokolwiek tworzyć .

Kotły i generatory nie są odpowiedzią.

Yeoman & Plop może zmniejszyć ilość kopiowania i wklejania, które wykonujesz między projektami.

Jednak generowany nigdy nie jest meczem jeden do jednego i nie może nim być.

Na dużą skalę przy wystarczającej liczbie projektów niezwykle trudno jest przenieść funkcje i ulepszenia z jednej aplikacji do pozostałych, ponieważ wspólny kod nie jest wyabstrahowany do niezależnie aktualizowalnej zależności.

Kiedy generator jest dobrym rozwiązaniem dla powtarzającego się kodu, lepszym rozwiązaniem jest przekształcenie go w prostsze API.

W przeciwnym razie generator sam w sobie staje się mylącą, pomieszaną logiką aplikacją ze względu na permutacje możliwych przypadków użycia, na zawsze w wyścigu o zachowanie zgodności z aplikacjami, które stworzył.

Doświadczyłem tego z pierwszej ręki z kilkoma generatorami, w tym z moją własną ewolucją/wordpressem .

Zbyt wiele interfejsów API. Za dużo konfiguracji.

Przykład tego można zobaczyć w

, biblioteki takie jak Redux , React Router , Webpack i ekosystem React w dużej mierze zdecydowały się na dyskretną modularyzację kosztem lapidarnych interfejsów API, przerzucając ich podstawy architektoniczne na użytkownika, co w rezultacie pogarszało doświadczenie programisty łącznie.

Same interfejsy API są małe, ale nawet mniej niż garstka powoduje prawie niezrozumiały bałagan kodu dla każdej nowej pary oczu.

Nawet jeśli jest zawarty w projekcie „boilerplate”, rusztowaniu przez generator lub schowanym w pliku finalCreateStorev3SeriousThisTime.js , stworzyliśmy szczurze gniazdo okablowania, które sprawiłoby, że wtyczki WordPressa rumienią się.

Więcej abstrakcji. Mniej kodu.

Oczywiście te interfejsy API są wymagane do posiadania mniejszych, oddzielonych, testowalnych, a zatem wysokiej jakości bibliotek.

Potrzebujemy jednak abstrakcyjnego środka między zależnościami okablowania a generowaniem boilerplate’ów .

Abstrakcje są niezbędne, aby zmniejszyć obciążenie poznawcze tego, jak działają rzeczy, abyś mógł skupić się na tworzeniu.

Walcz z liniami kodu.

Każdy projekt o znacznym zakresie będzie już miał za sobą znaczną ilość kodu.

Twórcy aplikacji nie powinni być ekspertami w zakresie podstaw biblioteki tylko po to, aby z niej korzystać.

Dlatego oprzyrządowanie powinno być jak najmniejsze .

Rozważ tę pospiesznie skompilowaną listę alternatyw :

• Zapewnij opiniowany, zatwierdzony przez autora interfejs API lub bibliotekę dla teoretycznych 90% przypadków użycia.
  (Sam wycięcie schematu dla React + Router + Redux byłoby dla wielu ogromną poprawą.)
• Publikuj predefiniowane przypadki użycia podobne do predefiniowanych Babel (np . es2015 , React , itp.).
• Wykorzystaj konwencje nazewnictwa folderów i plików, aby automatycznie wykrywać trasy, akcje, testy i nie tylko specyficzne dla aplikacji.
  (Jest to już powszechne w przypadku testowania (np . Mocha ) i obsługi zasobów publicznych, ale w jakiś sposób każdy projekt wymaga magicznej konfiguracji jednorożca.)
• Oparte na społeczności narzędzia do szybkiego tworzenia aplikacji (RAD) znacznie opóźniają potrzebę jawnej konfiguracji do czasu utrwalenia zakresu.

Narzędzia RAD

Podążając za powyższymi wątkami na Twitterze, wielu słusznie przyznaje, że nie ma jednego uniwersalnego rozwiązania.

Jeśli jednak zaczniemy z zamiarem zbudowania prototypu, podstawowe abstrakcje nie mają znaczenia.

Związane z,

rzucił wyzwanie społeczności do opracowania narzędzi do szybkiego prototypowania , nawet kosztem dostosowania.

W międzyczasie znam kilka opcji, których możesz użyć dzisiaj , aby szybko rozpocząć swój następny projekt:

• budo
• nwb
• prot
• rackt-cli
• rwb

Jestem przekonany, że już wkrótce znajdzie się on pomiędzy szybkim rozwojem a dostosowywaniem.

W rzeczywistości mój przyjaciel wyczuwa ten sam wzorzec:

Rok 2016 prawdopodobnie będzie obejmował poważne, ukierunkowane łączenie projektów, narzędzi i funkcji językowych, aby połączyć najlepsze i najjaśniejsze pakiety/narzędzia/boilerplates w bardziej sformalizowane projekty. —

w State of the Union.js

Oto ekscytujący rok 2016! :)