Bonsai od Jane Street podbiło Hacker News, ale jego prawdziwym rywalem jest model komponentów Reacta

Bonsai od Jane Street trafiło w sierpniu na stronę główną Hacker News, zdobywając setki głosów i wywołując głębszą dyskusję o tym, jak złożone interfejsy powinny zarządzać zmianami. Ta biblioteka OCaml o otwartym kodzie źródłowym nie oferuje jedynie kolejnego sposobu renderowania przycisków i formularzy. Kwestionuje model komponentów, który ukształtował główny nurt rozwoju frontendowego.

Dyskusja jest istotna, ponieważ Bonsai pochodzi z wyjątkowo wymagającego środowiska produkcyjnego. Jane Street twierdzi, że używa biblioteki w niemal każdej wewnętrznej aplikacji webowej. Aplikacje te obejmują zarówno firmowy katalog, jak i narzędzia monitorujące systemy transakcyjne oraz umożliwiające interakcję z nimi.

Głównym przeciwnikiem Bonsai nie jest zatem jedna konkurencyjna biblioteka. Jest nim założenie, utrwalone przez Reacta i jego następców, że stan, renderowanie i aktualizacje inkrementalne należą do hierarchii komponentów UI. Jane Street rozdziela te kwestie i stosuje obliczenia inkrementalne poza widoczną stroną.

Taki projekt przyciągnął zainteresowanie programistów ceniących typowane programowanie funkcyjne i przewidywalne automaty stanów. Ujawnia jednak również trudny problem adopcji. Framework oparty na OCaml, Js_of_ocaml i wewnętrznych potrzebach Jane Street trafia na znacznie węższy rynek talentów i pakietów niż JavaScript czy TypeScript.

Uwaga Hacker News uwidoczniła ten kompromis. Bonsai oferuje wyjątkowo spójną odpowiedź na potrzeby dużych aplikacji aktualizowanych na żywo, ale spójność w obrębie jednej firmy nie gwarantuje przenośności w szerszym ekosystemie webowym.

Co faktycznie zmieniła uwaga Hacker News

Wiadomością nie jest to, że Bonsai nagle zadebiutowało, lecz że dojrzały wewnętrzny framework wyszedł poza swoją zwykłą społeczność OCaml.

Jane Street rozpoczęło prace nad Bonsai pod koniec marca 2019 roku. Dokument opisujący historię projektu wskazuje, że powstał on po tym, jak programiści obserwowali studentów zmagających się z Incr_dom, wcześniejszym frameworkiem Jane Street. Wraz z rozrostem aplikacji coraz trudniej było je komponować, natomiast łączenie mniejszych komponentów tworzyło kolejne źródło błędów.

Bonsai istnieje więc od lat. Sierpniowy wątek na Hacker News zmienił jego widoczność, a nie fundament techniczny. Do 31 sierpnia strona dyskusji pokazywała 390 punktów i 154 komentarze — znacznie więcej niż 82 punkty i 24 komentarze odnotowane, gdy historia została po raz pierwszy zarejestrowana.

Ten wzrost ma znaczenie, ponieważ komentarze nie skupiały się wyłącznie na składni OCaml. Programiści dyskutowali o obliczeniach inkrementalnych, współdzielonych typach frontendu i backendu, interoperacyjności z JavaScriptem, WebAssembly, testowaniu oraz koszcie opuszczenia dominującego ekosystemu.

Repozytorium Bonsai również przedstawia więcej dowodów na ciągły rozwój niż typowy eksperymentalny framework. Pod koniec sierpnia GitHub wyświetlał około 1400 gwiazdek, 57 forków, 148 commitów, siedem otwartych zgłoszeń i dwa otwarte pull requesty.

Liczby te nie dowodzą szerokiego wdrożenia produkcyjnego. Gwiazdki mierzą uwagę, a niewielka liczba zgłoszeń może odzwierciedlać zarówno stabilność, jak i stosunkowo małą społeczność zewnętrzną. Bardziej użytecznym sygnałem jest opis Bonsai przez Jane Street jako standardowej wewnętrznej infrastruktury.

Firma twierdzi, że niemal wszystkie jej aplikacje webowe korzystają z Bonsai. To stawia bibliotekę w innej kategorii niż weekendowy framework czy projekt demonstracyjny. Jane Street opiera na niej interfejsy o bardzo różnych zakresach odpowiedzialności i poziomach ryzyka.

Repozytorium opisuje aplikacje monitorujące systemy transakcyjne i umożliwiające interakcję z nimi. Takie interfejsy przetwarzają zmieniające się dane, koordynują działania użytkowników i prezentują stan, którego poprawność ma znaczenie. Przypominają rozbudowane oprogramowanie operacyjne spotykane w finansach, logistyce, infrastrukturze i administracji przedsiębiorstw.

Ten kontekst wyjaśnia reakcję Hacker News. Bonsai daje wgląd w to, jak firma handlowa silnie nastawiona na inżynierię traktuje architekturę frontendu, gdy zwykłe renderowanie strony jest tylko częścią problemu.

Wątek ujawnił też ważne nieporozumienie. Kilku komentujących początkowo traktowało Bonsai jako alternatywę dla Reacta w OCaml. Inni uczestnicy wskazali, że podstawowa abstrakcja jest bardziej ogólna: inkrementalny, komponowalny automat stanów, który może tworzyć interfejs webowy, terminalowy lub inny rezultat.

To rozróżnienie tworzy centralne napięcie artykułu. React zaczyna od komponentów jako jednostki organizującej interfejs użytkownika. Bonsai zaczyna od obliczeń i automatów stanów, a następnie pozwala rendererowi przeglądarkowemu wykorzystywać ich wyniki.

Różnica brzmi teoretycznie, dopóki aplikacja nie zawiera danych rynkowych na żywo, filtrowanych tabel, uprawnień, żądań asynchronicznych i obliczeń pochodnych. Wtedy kontrola nad tym, co jest przeliczane, może być równie ważna jak kontrola nad tym, co jest renderowane ponownie.

Post na Hacker News nie uczynił z Bonsai frameworka głównego nurtu. Dał szerszej grupie programistów konkretny przykład alternatywnego wyboru architektonicznego, który już sprawdził się w wymagającej organizacji.

Dlaczego biblioteka UI Jane Street wywiera presję na model komponentów

Bonsai wywiera presję na frameworki skupione na komponentach, traktując pracę inkrementalną jako właściwość całej aplikacji, a nie optymalizację renderowania.

Większość współczesnych programistów frontendowych myśli w kategoriach komponentów. Komponent posiada lub otrzymuje stan, oblicza widok i uczestniczy w drzewie. Frameworki unikają następnie niepotrzebnej pracy dzięki memoizacji, reaktywności o drobnej granularności, porównaniom wirtualnego DOM, kompilatorom lub harmonogramowaniu.

Bonsai rozdziela ten pakiet. Jego prymitywy stanu i obliczeń inkrementalnych można komponować niezależnie od renderowanego widoku. Ten sam system, który zapobiega odświeżaniu nieistotnych elementów interfejsu, może także uniknąć ponownego wykonywania kosztownego obliczenia biznesowego.

Obliczenia inkrementalne oznaczają aktualizowanie wyniku poprzez ponowne przeliczenie wyłącznie tych części, na które wpłynęły zmienione dane wejściowe. Jane Street opracowało osobną bibliotekę Incremental do tworzenia obliczeń, których zależności można śledzić automatycznie.

Bonsai stosuje tę ideę w całym grafie aplikacji. Wartości pozostają nieaktywne, dopóki nie zmienią się ich zależności, nawet gdy wartości te nie reprezentują bezpośrednio HTML. Renderowanie staje się jednym z odbiorców szerszego modelu obliczeniowego.

React znacznie wykroczył poza swoją pierwotną rolę biblioteki widoków, ale jego centrum pojęciowe nadal stanowi drzewo komponentów. Stan umieszczony blisko komponentów oferuje przystępny sposób budowania aplikacji. Zmusza jednak również programistów do rozumowania o tożsamości, cyklu życia, tablicach zależności, domknięciach i przepływie danych przez tę hierarchię.

Bonsai zarządza natomiast stanem poza jawną hierarchią komponentów. Jego dokumentacja prosi użytkowników Reacta, by wyobrazili sobie aplikację, w której niemal wszystko przypomina hooki, podczas gdy stan znajduje się poza drzewem komponentów.

Podejście to zmienia sposób, w jaki programiści obsługują zestaw stanowych widżetów wewnątrz innego widżetu. Prostym przykładem jest interfejs kart. Każda karta może zawierać własne kontrolki, lokalne wybory i aktywność asynchroniczną.

W systemie skupionym na komponentach programiści często zachowują stan, utrzymując komponenty zamontowane, wynosząc stan wyżej, przypisując stabilne klucze lub dodając osobny magazyn stanu. Każdy wybór zmienia zachowanie cyklu życia i może prowadzić do przypadkowych resetów lub nieaktualnych wartości.

Jane Street twierdzi, że Bonsai zapewnia API do zarządzania cyklem życia i zakresem stanu bez konieczności ręcznego wynoszenia stanu każdego zagnieżdżonego komponentu do modelu najwyższego poziomu. Nie oznacza to wyeliminowania złożoności. Przenosi ją do frameworka o bardziej jawnej semantyce.

Projekt jest szczególnie istotny dla oprogramowania operacyjnego. Panel transakcyjny może wyświetlać wybrane konto, kilka strumieni danych na żywo, obliczoną ekspozycję, oczekujące działania i filtrowane historie. Jedna wartość wejściowa może wpływać na wiele części tego systemu, nie należąc w naturalny sposób do pojedynczego komponentu wizualnego.

Bonsai modeluje te relacje jako graf zależności. Graf określa, które obliczenia potrzebują nowych wartości po zmianie danych wejściowych. Widoczna strona pozostaje ważna, ale przestaje definiować architekturę.

Model ten obsługuje również cele inne niż przeglądarka. Podstawowa biblioteka Bonsai tworzy inkrementalne, komponowalne automaty stanów. Bonsai_web specjalizuje te prymitywy dla interfejsów przeglądarkowych, a Bonsai_term stosuje je do interaktywnych aplikacji terminalowych.

Ten podział wzmacnia argument Jane Street. Jeśli ten sam model stanu i obliczeń może napędzać zarówno interfejsy webowe, jak i terminalowe, komponent wizualny nie może być najbardziej fundamentalną abstrakcją.

React nie stoi w miejscu, a jego ekosystem obejmuje automaty stanów, sygnały, cache zapytań, obserwowalne magazyny stanu i reaktywne biblioteki o drobnej granularności. Programiści mogą złożyć podobne zachowanie z kilku narzędzi.

Wyzwanie Bonsai dotyczy integracji. Jane Street oferuje jeden typowany model dla stanu, zależności, efektów, renderowania i testowania. Zespoły pracujące w głównym nurcie JavaScriptu często łączą biblioteki o różnych założeniach i zasadach cyklu życia.

Presja ma charakter koncepcyjny, a nie komercyjny. React prawdopodobnie nie straci znaczącego udziału w rynku z powodu jednej biblioteki OCaml. Bonsai pokazuje jednak, że hierarchia komponentów jest wyborem projektowym, a nie nieuniknioną właściwością interaktywnego oprogramowania.

Prawdziwym mechanizmem są obliczenia inkrementalne wszędzie

Mechanizmem definiującym Bonsai jest zdolność śledzenia zmian zarówno w kodzie interfejsu, jak i w logice biznesowej.

Podstawowy komponent Bonsai jest implementowany jako czysto funkcyjny automat stanów. Automat stanów opisuje, jak akcja przekształca bieżący stan w następny bez mutowania ukrytych wartości. Taka struktura ułatwia analizę i testowanie zachowania.

Biblioteka następnie inkrementalnie ocenia obliczenia zbudowane wokół tych maszyn. Jeśli zmieni się jedna wartość, Bonsai aktualizuje tylko tę dalszą pracę, która od niej zależy. Niepowiązane obliczenia zachowują dotychczasowe wyniki.

Frameworki frontendowe zwykle oferują węższą wersję takiego zachowania. React może pomijać część renderowań dzięki memoizacji, podczas gdy inne frameworki śledzą zależności na poziomie sygnału lub właściwości. Bonsai twierdzi, że inkrementalizacja dotyczy każdej wartości w jego grafie obliczeń.

Rozważmy tabelę aktualizowaną na żywo, zawierającą pozycje z kilku systemów transakcyjnych. Użytkownik może zmienić jeden filtr, zaktualizować wybrane konto lub otrzymać nową wartość z serwera. Te dane wejściowe wpływają na różne podzbiory wierszy, sum, kontrolek i ostrzeżeń.

Aplikacja zorientowana na komponenty może obsłużyć takie obciążenie. Programiści mogą używać selektorów, obliczeń memoizowanych, znormalizowanych magazynów stanu, wirtualizacji i cache zapytań. Trudność polega na utrzymywaniu połączeń w miarę rozwoju aplikacji.

Bonsai czyni graf zależności centralną abstrakcją frameworka. Obliczenia są komponowane z wartości, których relacje są znane silnikowi inkrementalnemu. System może więc zdecydować, które węzły wymagają ponownej ewaluacji.

Mechanizm ten odzwierciedla historię Jane Street z Incr_dom. Według historii projektu wcześniejszy framework potrafił izolować komponenty, lecz miał trudności z ich automatycznym komponowaniem.

Jeden problem dotyczył łączenia widoków z niezależnych komponentów. Inny dotyczył wywołań zwrotnych widoczności, które mogły aktualizować współdzielony model. Incr_dom przekazywał odpowiedzialność za koordynowanie tych aktualizacji programistom aplikacji.

Projektanci Bonsai zareagowali, usuwając założenia, które uniemożliwiały kompozycję. Kluczowy rezultat stał się ogólny, zamiast być ograniczony do węzła wirtualnego DOM-u. Akcje i modele z czasem stały się szczegółami implementacyjnymi, a nie publicznymi parametrami typów współdzielonymi między komponentami.

Zmiany te nie były jedynie kosmetycznym porządkowaniem API. Ograniczyły sposoby, w jakie sąsiednie komponenty mogły ingerować w swój wewnętrzny stan. Komponenty mogły komunikować się za pośrednictwem danych wejściowych i wyników, zamiast przekraczać granice w celu manipulowania modelem innego komponentu.

Projekt korzysta również z systemu typów OCaml. Jane Street może używać tego samego języka i wielu tych samych typów na serwerach i w przeglądarkach, ponieważ Js_of_ocaml kompiluje OCaml do JavaScript.

Współdzielone typy ograniczają potrzebę translacji między warstwami. Aplikacja może spójnie reprezentować dane biznesowe, zamiast definiować jeden model dla przetwarzania backendowego, a drugi dla klientów TypeScript.

Korzyść ta rośnie, gdy firma kontroluje oba końce stosu technologicznego. Jane Street kontroluje swoje usługi backendowe, wewnętrzne interfejsy użytkownika, biblioteki i środowisko wdrożeniowe. Może standaryzować OCaml na całej ścieżce.

Kompromis staje się widoczny, gdy aplikacja Bonsai wchodzi w szerszy ekosystem webowy. API przeglądarek i pakiety JavaScript innych firm nadal wymagają zgodnych powiązań. Popularna biblioteka JavaScript często oferuje deklaracje TypeScript, przykłady i przewodniki integracyjne, z których zespół OCaml nie może korzystać bezpośrednio.

Dyskusja na Hacker News wielokrotnie wracała do tego problemu. Komentujący wskazywali na Fable, ClojureScript, Scala.js, Kotlin/JS, Google Web Toolkit i inne próby wprowadzenia języków innych niż JavaScript do przeglądarek.

Projekty te pokazują, że rozwój w jednym współdzielonym języku nie jest nowym celem. Pokazują też, dlaczego spójność techniczna rzadko przesądza o adopcji. Interoperacyjność, rekrutacja, dokumentacja, narzędzia do debugowania i pokrycie bibliotekami często decydują o tym, czy język przetrwa poza własną społecznością.

Mechanizm Bonsai pozostaje godny uwagi, ponieważ nie został zaprojektowany wyłącznie po to, by unikać JavaScript. Jane Street stworzyło go, aby rozwiązać problemy kompozycji i aktualizacji przyrostowych, które już występowały w rozbudowanym środowisku aplikacji OCaml.

To produkcyjne pochodzenie nadaje architekturze wiarygodność. Nie dowodzi jednak, że inne organizacje mierzą się z tymi samymi ograniczeniami ani że powinny akceptować te same koszty ekosystemowe.

Testowanie jest najsilniejszym praktycznym argumentem Bonsai

Bonsai jest najbardziej przekonujące wtedy, gdy jego projekt oparty na maszynach stanów zamienia złożone zachowanie interfejsu w deterministyczne testy.

Jane Street przedstawia zautomatyzowane testowanie jako centralną funkcję, a nie zewnętrzny dodatek. Deweloperzy mogą utworzyć komponent, sprawdzić jego wirtualny DOM, zasymulować akcję i porównać wynikową zmianę z oczekiwanym rezultatem.

Test expect przechowuje przewidywany wynik obok kodu testowego. Gdy zachowanie się zmienia, program uruchamiający testy wyświetla precyzyjną różnicę między poprzednim a bieżącym wynikiem.

W przypadku pola tekstowego test może najpierw zapisać puste powitanie. Następnie może zasymulować wpisanie imienia i pokazać w wirtualnym DOM-ie wyłącznie zmieniony tekst. Deweloper nie musi uruchamiać przeglądarki ani ręcznie przeklikiwać interfejsu.

Testy Bonsai mogą również symulować wywołania serwera i sprawdzać zmiany stanu stojącego za widokiem. Jest to istotne, ponieważ wiele awarii interfejsu nie ma charakteru wyłącznie wizualnego. Obejmują nieprawidłowe przejście stanu, nieaktualne dane pochodne lub odpowiedź zastosowaną do niewłaściwego stanu.

Deterministyczna maszyna stanów ułatwia odtworzenie takich ścieżek. Testy mogą w każdym uruchomieniu zapewniać ten sam model początkowy, sekwencję akcji i zamockowane odpowiedzi zewnętrzne.

Podejście to pasuje do kultury inżynieryjnej Jane Street. Narzędzia finansowe wymagają zachowania, które można poddać przeglądowi, zwłaszcza gdy kontrolka wizualna może wywołać działanie operacyjne. Zrzut ekranu może ujawnić zmiany układu, ale nie może w pełni wyjaśnić, dlaczego zmienił się stan bazowy.

Testy end-to-end oparte na przeglądarce nadal mają swoją rolę. Wykrywają błędy CSS, fokusu, dostępności, zgodności przeglądarek i integracji, których testy wirtualnego DOM-u nie mogą zagwarantować. Jane Street nie dowodzi, że testy Bonsai eliminują tę potrzebę.

Zaletą jest większa warstwa możliwa do testowania poniżej przeglądarki. Deweloperzy mogą weryfikować zachowanie komponentów, przejścia stanów i generowane znaczniki bez ponoszenia kosztów konfiguracji i działania pełnej sesji przeglądarkowej dla każdego przypadku.

Zespoły React mogą budować podobne procesy testowe. React Testing Library promuje testy oparte na zachowaniu widocznym dla użytkownika, a Playwright i Cypress obsługują automatyzację przeglądarki. Biblioteki maszyn stanów mogą jasno określać przejścia.

Różnica w Bonsai polega na tym, że testowalność wynika z architektury. Czyste maszyny stanów i wartości przyrostowe już ujawniają dane wejściowe i wyjściowe potrzebne testowi. System testowy nie musi odtwarzać kolejności na podstawie rozproszonych hooków i mutowalnych usług.

Ta integracja może ograniczać niejednoznaczność podczas przeglądu kodu. Różnica w bloku expect pokazuje, jak akcja zmieniła wygenerowany DOM. Recenzenci mogą sprawdzić tę zmianę obok kodu, który ją wywołał.

Nadal występuje koszt utrzymania. Duże tekstowe snapshoty mogą stać się hałaśliwe, a deweloperzy czasami zatwierdzają zmiany, nie rozumiejąc ich. Testy skupiające się na niestabilnych szczegółach implementacji mogą również generować pracę bez wykrywania istotnych regresji.

Bonsai ogranicza część tego ryzyka dzięki ukierunkowanym różnicom, ale nie może wyeliminować złego projektowania testów. Zespoły nadal muszą wybierać zachowania, które mają znaczenie, i unikać traktowania każdej zmiany znaczników jako błędu.

Dokumentacja stanowi kolejny problem. Jeden z komentujących na Hacker News opisał publiczną dokumentację jako skąpą i stwierdził, że kod źródłowy ujawnił więcej na temat projektu frameworka. To subiektywna obserwacja, ale wskazuje praktyczną barierę adopcji.

Jane Street udostępnia szybki start, przewodniki koncepcyjne, przykłady, materiały API, notatki historyczne oraz dyskusję o frameworku w podcaście Signals and Threads. Zewnętrznym zespołom nadal brakuje głębi wiedzy instytucjonalnej dostępnej wewnątrz firmy.

Niszowy framework potrzebuje wyjątkowo dobrej publicznej dokumentacji, ponieważ użytkownicy nie mogą polegać na szeroko dostępnych poradnikach ani współpracownikach z wcześniejszym doświadczeniem. Zespoły oceniające Bonsai potrzebowałyby przeszukiwalnego zapisu decyzji architektonicznych, przykładów i lokalnych konwencji.

Ta potrzeba wykracza poza Bonsai. Inżynieryjna baza wiedzy może pomóc zespołom połączyć dokumentację frameworka z wewnętrznymi decyzjami i działającymi przykładami. Nie może zastąpić zdrowej społeczności zewnętrznej.

Testowanie może zatem być najbardziej przenośną lekcją Bonsai. Nawet zespoły, które nigdy nie wdrożą OCaml, mogą przeanalizować, jak jawne maszyny stanów i zależności przyrostowe ułatwiają weryfikację złożonego zachowania interfejsu.

Czego debata na Hacker News nie dowodzi

Zainteresowanie na Hacker News potwierdza, że architektura jest tematem do dyskusji, a nie że Bonsai jest domyślnym wyborem dla zespołów zewnętrznych.

Najmocniejsze dowody na rzecz Bonsai pochodzą od samego Jane Street. Firma twierdzi, że używa frameworka w niemal wszystkich swoich wewnętrznych aplikacjach webowych, w tym w oprogramowaniu powiązanym z operacjami handlowymi.

To znaczące doświadczenie produkcyjne. Jest to również studium przypadku jednej organizacji, ukształtowane przez nietypowe warunki. Jane Street zatrudnia wielu deweloperów OCaml, utrzymuje ważne biblioteki, kontroluje swój stos backendowy i może przez długi czas finansować wewnętrzne narzędzia.

Większość firm zaczyna z przeciwnej pozycji. Ich frontendowcy znają JavaScript lub TypeScript. Ich systemy projektowe są ukierunkowane na React, Vue, Angular lub komponenty webowe. Ich praktyki monitorowania, dostępności, testowania i rekrutacji zakładają te ekosystemy.

Wdrożenie Bonsai wymagałoby czegoś więcej niż nauki nowego API. Zespół potrzebowałby wiedzy o OCaml, potoku budowania Js_of_ocaml, powiązań dla niezbędnych bibliotek przeglądarkowych oraz operacyjnej pewności w mniejszym publicznym ekosystemie.

1,400 gwiazdek repozytorium świadczy o ciekawości, ale liczba ta pozostaje niewielka w porównaniu z głównymi społecznościami frontendowymi. 57 forków wskazuje na pewne zewnętrzne eksperymenty, jednak publiczna aktywność repozytorium nie ujawnia, ile organizacji prowadzi produkcyjne aplikacje Bonsai.

Jane Street nie publikuje listy klientów, ponieważ Bonsai nie jest pozycjonowane jako platforma komercyjna. Zewnętrzna adopcja jest więc trudna do zmierzenia. Pobrane pakiety, niezależne studia przypadków, wystąpienia konferencyjne i długotrwałe projekty firm trzecich byłyby silniejszymi dowodami.

Niska liczba otwartych zgłoszeń w bibliotece również jest niejednoznaczna. Siedem otwartych zgłoszeń może wskazywać na staranne utrzymanie. Może też oznaczać, że wiele wewnętrznych problemów jest zgłaszanych i rozwiązywanych za pośrednictwem systemów, których opinia publiczna nie widzi.

Publiczny współtwórca napotyka kolejną asymetrię. Inżynierowie Jane Street mogą rozumieć framework dzięki wewnętrznym aplikacjom, współpracownikom i historii projektu. Deweloper z zewnątrz musi wywnioskować więcej z publicznej dokumentacji i kodu źródłowego.

Interoperacyjność jest największą niewiadomą techniczną. Bonsai tworzy interfejsy przeglądarkowe przez JavaScript, lecz otaczający ekosystem przeglądarki nadal mówi przede wszystkim językiem JavaScript. Każda nieobsługiwana zależność wymaga decyzji: napisać powiązanie, zastąpić pakiet lub zbudować funkcjonalność wewnętrznie.

Jane Street może zaakceptować ten koszt, ponieważ już intensywnie inwestuje w stos skoncentrowany na OCaml. Mniejsza firma mogłaby poświęcić więcej czasu inżynieryjnego na integrację, niż zaoszczędziłaby dzięki lepszej semantyce przyrostowej.

Porównanie z React również wymaga powściągliwości. Model komponentów React ma dobrze znane komplikacje, ale jego ekosystem zapewnia rozbudowane biblioteki, systemy projektowe, materiały edukacyjne, narzędzia do debugowania i doświadczonych deweloperów.

Bonsai nie musi pokonać React, aby być użyteczne. Może dobrze służyć Jane Street, pozostając jednocześnie wyspecjalizowaną opcją gdzie indziej. Argument architektoniczny i argument dotyczący adopcji należy oceniać osobno.

Sierpniowy wątek zawierał również entuzjazm napędzany frustracją związaną z JavaScript. Niektórzy komentujący żartowali, że nauczą się OCaml, aby uniknąć pisania JavaScript. Ten sentyment może motywować do eksperymentów, ale niechęć do jednego języka nie potwierdza produkcyjnego dopasowania innego frameworka.

Inni komentujący wymieniali ClojureScript, Scala.js, Fable, Kotlin/JS, Phoenix LiveView oraz starsze systemy, takie jak Google Web Toolkit. Ich przykłady osłabiają wszelkie twierdzenie, że współdzielone typy frontendu i backendu są czymś unikalnym dla Bonsai.

Wzmacniają inne wnioski. Wiele ekosystemów dążyło do typowanego, nieopartego na JavaScript rozwoju w przeglądarce, jednak JavaScript i TypeScript nadal dominują. Powracającą barierą było pełne środowisko programistyczne, a nie sama możliwość kompilowania kodu dla przeglądarki.

Publiczne dowody dotyczące Bonsai wspierają ostrożne twierdzenie: Jane Street zbudowało spójny framework wokół rzeczywistych wewnętrznych wymagań. Nie dowodzą one niższych kosztów, lepszej wydajności ani większej niezawodności dla typowej organizacji zewnętrznej.

Trzy sygnały, które zdefiniują kolejny rozdział Bonsai

Szersze znaczenie Bonsai zależy teraz od niezależnej adopcji, głębi publicznego ekosystemu oraz dowodów, że jego model przyrostowy zapewnia mierzalne korzyści operacyjne.

Pierwszym sygnałem jest znaczące studium przypadku wdrożenia produkcyjnego poza Jane Street. Wiarygodny przykład powinien opisywać skalę aplikacji, przepływ danych, skład zespołu, wymagania integracyjne i doświadczenia z utrzymaniem.

Jedno niezależne wdrożenie nie potwierdziłoby szerokiej przydatności. Nadal sprawdziłoby jednak, czy zalety Bonsai utrzymują się bez kultury OCaml Jane Street i jej wewnętrznej sieci wsparcia.

Studium przypadku pokazujące, że niewielki zespół opanował framework, zintegrował wymagane biblioteki przeglądarkowe i utrzymał złożoną aplikację, wzmocniłoby argument o jego przenośności. Doniesienia o długotrwałych pracach nad wiązaniami lub trudnościach rekrutacyjnych osłabiłyby go.

Drugim sygnałem jest rozwój publicznie dostępnych narzędzi i dokumentacji. Kluczowymi wskaźnikami nie są wyłącznie gwiazdki na GitHubie. Deweloperzy powinni obserwować pojawianie się większej liczby utrzymywanych przykładów, komponentów wielokrotnego użytku, wsparcia edytorów, przewodników integracyjnych, niezależnych tutoriali i zewnętrznych współtwórców.

Dokumentacja musi również wyjaśniać tryby awarii. Zespoły potrzebują wskazówek dotyczących profilowania grafów przyrostowych, śledzenia cyklu życia stanu, diagnozowania nieoczekiwanych ponownych obliczeń, obsługi efektów asynchronicznych oraz integracji pakietów JavaScript.

Bogatszy publiczny ekosystem zmniejszyłby lukę wiedzy między pracownikami Jane Street a użytkownikami zewnętrznymi. Jeśli większość odpowiedzi nadal będzie wymagała czytania wnętrza frameworka, Bonsai pozostanie trudny do oceny w warunkach typowych terminów projektowych.

Trzecim sygnałem są porównawcze dowody techniczne. Jane Street wyjaśnia, dlaczego obliczenia przyrostowe pasują do jej aplikacji, lecz publiczne benchmarki i szczegółowe raporty inżynieryjne ułatwiłyby ocenę kompromisów.

Przydatne dowody mierzyłyby opóźnienie aktualizacji, powtarzające się obliczenia, zużycie pamięci, rozmiar bundla, wykonywanie testów i złożoność kodu w realistycznych aplikacjach. Niewielka demonstracja kontrprzykładu lub syntetyczny benchmark ujawniłyby niewiele.

Najcenniejsze porównanie analizowałoby gęstą aplikację aktualizowaną na żywo, zaimplementowaną w Bonsai oraz w dobrze zaprojektowanym popularnym stosie technologicznym. Powinno ono ujawniać, gdzie każda wersja wykorzystuje memoizację, buforowanie, wirtualizację lub zewnętrzne zarządzanie stanem.

Jeśli Bonsai wymaga mniej ręcznie utrzymywanych granic optymalizacji, zachowując przewidywalne opóźnienia, jego argument architektoniczny staje się silniejszy. Jeśli współczesny stos TypeScript osiąga podobne rezultaty przy łatwiejszej rekrutacji i integracji, atrakcyjność Bonsai pozostaje wyspecjalizowana.

Deweloperzy nie powinni czekać na zwycięzcę, zanim wyciągną wnioski. Bonsai już pokazuje, że stan, przyrostowość i renderowanie nie muszą dzielić jednej abstrakcji.

Pokazuje również, jak firma może przekształcić spójność językową w całej domenie w przewagę frontendową. Te same typy i logika biznesowa mogą przechodzić między serwerem a przeglądarką, gdy organizacja kontroluje oba środowiska.

Ostatnia lekcja z Hacker News dotyczy mniej wyboru frameworka, a bardziej zadawania lepszych pytań architektonicznych. Czy drzewo komponentów opisuje rzeczywiste zależności aplikacji, czy tylko jej układ wizualny? Które obliczenia powtarzają się po każdej zmianie stanu? Czy testy mogą odtwarzać istotne zachowanie bez przeglądarki?

Zespoły pracujące nad zwykłymi witrynami z treścią mogą niewiele zyskać na modelu Bonsai. Zespoły budujące interfejsy operacyjne działające na żywo, analityczne środowiska pracy lub narzędzia o głębokim stanie mają więcej powodów, by go studiować.

Według firmy Bonsai pomyślnie przeszedł już test wewnętrznej produkcji w Jane Street. Jego kolejnym testem jest to, czy zewnętrzni deweloperzy mogą uzyskać tę samą przejrzystość bez ponoszenia nieproporcjonalnych kosztów ekosystemowych.

Śledź repozytorium, niezależne projekty i przyszłe dyskusje na Hacker News, mając na uwadze to rozróżnienie. Ważne pytanie nie brzmi, czy Bonsai zastąpi React. Chodzi o to, czy jego przyrostowy model maszyny stanów może wyjść poza organizację, która go zaprojektowała.