@spam_only: dwie kupiłem za 35zł uszkodzone żeby mieć obudowy ich. ;d

@Aleks: 6, jedną dokupiłem po tym zdjęciu

x

ps ale to jest wolne, płaku płaku

jak się kochają to chuj z nimi

@sens:
Haha, rozumiem ten emocjonalny rollercoaster bardzo dobrze 😄
Tree-sitter ma dokładnie tę aurę „o, to wygląda prosto… a jednak jest pół fabryki pod spodem”.

To co opisujesz, to w sumie dość typowe:

• Małe, kompaktowe generatory → zazwyczaj fajne na prototyp, ale później wychodzi, że brakuje ci drobiazgów, np. sensownego error recovery albo wsparcia dla komentarzy.
• „Tylko JS” → no i wtedy jesteś w klatce ekosystemu, nawet jak twój projekt w ogóle z JS nie korzysta.
• Tree-sitter → niby C core, szybki, cross-language bindingi, ale... cała definicja w JS + cała ta magia „generowania” wymaga Node’a.

Paradoksalnie to, że gramatyka jest w JS, ma sens techniczny — dzięki temu można robić programistyczne konstrukcje w definicji (makra, reużywalne reguły itp.) i to się kompiluje do czystej struktury C, ale z punktu widzenia purysty „chcę jeden plik .grammar” to jest trochę „meh”.

Co do highlightingu w Lispu — to jest Tree-sitter queries, czyli ich mini-dialekt S-expressions. Też się z tym pierwszy raz obijałem w Neovimie i miałem wrażenie, że ktoś mnie teleportował do Emacsa, ale to jest w sumie całkiem potężne (i trochę lepiej się debuguje niż klasyczne regexowe highlighty).

No i tak, domyślna definicja parsera jako cały projekt to w sumie cena za to, że potem dostajesz:

• AST w czasie rzeczywistym
• error recovery
• możliwość modyfikowania highlightu i foldingów bez rekompilacji parsera
• od razu wsparcie w kilkunastu edytorach

Jak na ironię — dla kogoś, kto chce tylko „mały parser” to jest kobyła, ale jeśli chcesz coś długofalowo rozwijać, to trudno znaleźć lepsze narzędzie.

Jeśli chcesz, mogę ci pokazać jak spłaszczyć definicję Tree-sittera do jednego katalogu z minimalnym Node-overheadem, tak żeby nie wyglądało to jak rozdmuchany projekt. To dość mocno redukuje „niesmak”.

Chcesz, żebym to od razu rozpisał?

@sens:
No np. teraz react się od ponad roku pierdoli z tym kompilerem. Ja nie mam problemu z useMemo i useCallback, ale ludzie nie ogarniają i się mutują rzeczy niepotrzebnie w chuj - w svelte kompiler już jest od dawna pisząc x = $derived(, nie musisz mu dawać tablicy zależności, bo kompiler jest od tego.

W reakcie masz nie mutować stanu więc moja cała reactowa głowa w svetle myśli jak nie mutować stanu, a on w sumie chce, żeby stan mutować i element można usunąć items.splice(index, 1);.

W rekacie chciej input kontrolować:

const [value, setValue] = useState('')
<input value={value} onChange={(e) => setValue(e.target.value)} />

W svelte jak się napisze <input bind:value /> to nie trzeba statów pchać i bonus, że można <input type="number" bind:value={person.age}> i to zmodyfikuje propsa age, na person.

Nie trzeba dawać key.

Małe proste bzdury ale przyjemne. Na tym etapie co się wgryzłem to mi się podoba, dotykałem przed nim angulara to pierdolę go serdecznie, zwykle jak o angularze mówiłem to nie moje klocki, ale przynajmniej wiadomo co jest w środku, freamwork podejmuje więksoszość decyzji, a w Reakcie masz 5 kostek i losuje libki do routingu, fetchowania, stora i każdej decyzji i nigdy nie wiadomo co wylosuje. Ale jak chwile popracowałem to w angularze większość decyzji robi jakiś korpośmieć wyrwany z 2018 roku.

Jezu jeszcze jakaś spierdolina w angularze stwierdziła, że język do templatownia może mieć gołe @for:
<ul>
@for (product of products(); track product.id) {
<li>
<app-product-card [product]="product" />
</li>
}
</ul>

@for w środku htmla bez żadnych klamr. W Svelte lepiej, ale lubię JSX - jedna z lepszych rzeczy w reactie.

Właśnie dawno pięknej funcji nie sprawdzałem, a zaraz co miesięczny updejt

Lumie w sumie zdechły przez to żeby były takie dziwaczne, mama miała jak chciała żebym jej coś wyklikał to musiałem sobie wypierdolić mózg na drugą stronę, bo te kafle były tak intuicyjne jak kafle w Windows 8.

@sens: ja wolę 3330/10.

2x

@sens:
W ogóle śmieszne, bo jak robiłem te mapkę herbami i mi zaczęło jebać przeglądarkę przy 2k nodów w HTMLu to doszedłem, że jednak trzeba je wrzucić na canvas z 0FPS. I potem poszedłem na rozmowę do firmy od diagramów to jest dokładnie problem z diagramami więc błysnąłem, że sam miałem ten problem i tak go rozwiązałem. I jak są przeskurwysyńskie diagramy to ją stawiają na płatnej libce na canvasie https://gojs.net/latest/ i ta libka rysująca wszystko sama bez htmla (więc button musi mieć onMouseOvery w canvasie setowane i cuda żeby był hover) jest rozwijana w js od 1998 roku czuć w niej czasami, te decyzje programistyczne z 2006 roku.

Dużo bindownania po this, funkcje które nie mają obiektu że robisz setPosition({ y }) tylko musisz dać setPosition(undefinded, y) bo funkcja powstała jak jeszcze nie było dekonstrukcji w obiektach. ;d

W sumie jak na to co robi tak całkiem ułożona, ale inny i zbudowany osobno świat JSa, a jeszcze żaden darmowy MIT projekt jej nie zeżarł, bo jednak 25 lat developmentu daje jakąś przewagę. xD

@sens:
Z gotowych apek to reactflow jest spoko libką, a do layoutów skomplikowanych (pewnie Ciebie nie dotknie) typu jak rozstawić 100 nodów i poprowadzić edge jest elkjs.

The Eclipse Layout Kernel (or ELK) - libka do layoutów od Eclipsa.

@sens: w obecnej pracę pracuję dużo z diagramami i trzeba strzałki z jednego prostokąta do drugiego robić i właśnie SVG, w ogóle ciekawy temat jak rozkładać nody na diagramie żeby nie wyglądał jak gówno i są layouty, że masz połączenie między nodami i ono ma 10 punktów i rysuje się SVG który się w nich łamie żeby omijać pozostałe

@Aleks:
Btw ja w tej starej mam jakieś wżarcia w stali nierdzewnej i lekko pogięta jest jak ją przyjebałem kilka razy (też przez W xD), chcę żeby to dobrze wyglądało.

@Aleks: przynajmniej W będzie działać, btw może wymienie więcej key capsów, jak w ogóle mi się uda to wymienić, bo jestem głupi xd