Has Javascript Fatigue went away?

[GarryOne (Igor Mardari)]

Ca si continuare a discutiei de aici, as propune spre discutie intrebarea din titlu.

Personal, mi se pe ca in cea mai mare parte, da, a plecat.

Fatigue-ul, cred eu ca, venea din cauza ca aveam foarte multe libarii si aproape nici un framework. Evident, in conditiile astea pot exista o mie de combinatii dintre acele librarii, care mai de care mai complicate sau deochiate.

Un alt factor important al fatigue-ul credca era Babel & Co, care nu mi se pare normal ca developer-ul sa configureze genul asta de detalii. Partea asta de complexitate, ar fi normal sa fie abstractizata, fie de limbaj (ceea ce nu e posibil, in cazul JS), fie de framework-uri, ceea ce a urmat mai tarziu, fie de alte package-uri (precum parcel.js )

Au murit o gramada de inovatii dubioase precum MeteorJS si altele, ceea ce ne lasa mai putine optiuni de ales. Un lucru bun.

Iar, dupa cum spuneam, aparitia, perpetuarea si maturizarea unor framework-uri (cateva), cred ca a fost cel mai important factor al incheierii aceste ere, a Javascript Fatigue-ului.

Daca vorbim strict de partea de Client, aici vad 3 framework-uri mari si late.
Next.js framework on top of React library
Nuxt.js framework on top of Vue library
Angular framework

Personal, folosesc Next.js

Daca vorbim de partea de server-side, adica de Node, vad 1-2 framework-uri mari si late
Nest.js framework on top of Express library
Adonis.js framework, nu stiu daca foloseste altceva la baza.

Personal folosesec Nest.js

Acestea fiind spuse, sunt curios sa aud si parerea voastra vizavi de acest subiect.

[iamntz (Ionuț Staicu)]

Nu cred că a plecat nicăieri, poate doar ne-am… călit noi.

Nu știu dacă prin JS fatigue te referi la multitudinea de opțiuni sau la complexitatea ecosistemului în general. Pentru mine este reprezentată de a doua variantă.

Hai să luăm ca exemplu Vue, care mi se pare că are mult potențial dar mi se mai pare și mega frustrant la început: Installation | Vue.js aici nu scrie nicăieri ce să faci după ce ai instalat vue prin npm. Ori folosești cli-ul pentru a instala o aplicație de bază pe care o modifici ori trebuie să știi (de unde?) că ai de făcut treaba asta:

import { createApp } from "vue";

const app = createApp({
  // root instance definition
});

app.mount("#app");

Iar porcăria asta se întâmplă pentru toate plugin-urile mai mari Vue: Vuex, router, i18n etc.

Cumva, ca prin magie, trebuie să știi toate lucrurile astea…

[rolisz (Roland)]

Eu am luat-o pe calea backend development/data pipelines/machine learning prin 2014, asa ca skillurile mele sunt ramase in epoca aia. In facultate parca la ceva materie am lucrat cu AngularJS, dar ce stiu e jQuery.

Anul acesta, fie am avut nevoie sa ma ating de unele chestii de frontend (ca sa repar buguri in proiecte open source pe care le foloseam), fie a trebuit eu sa fac niste UI-uri simple. Concluzia: vai de mine. De ce trebuie atatea nivele de abstractie? De ce atatea complicari? Back in my day, asa “simplu” era cu jQuery.

Ceva ce mi se pare ca lipseste e ceva cum erau aplicatiile Windows Forms/QT builder, unde iti faceai un UI cu un drag and drop builder, dadeai dublu click pe element si scriai event handlerul pentru button click/input validation/whatever. Mai ales ca eu scriu backenduri in Python, e super frustrant sa scriu API-ul in Python, sa scriu clientul in JS, si cand updatez ceva, sa schimb in doua locuri.

Anyway, trebuie sa invat si eu unul din frameworkurile majore de JS mai serios, probabil React.

[alessioalex (Alexandru Vladutu)]

Nu a plecat nicaieri fatigue-ul. Lucrurile sunt la fel de complexe.

Pe partea de JS frameworks eu zic ca Angular e kind of dead, iar SvelteJS e preferatul meu. Solid.js e si el trending. React si Vue raman liderii.

Pe partea de Node, recomand Fastify.js. E facuta de baietii de la Nearform, care sunt si core contributori la Node. Fastify e facut cu gandul la performanta in primul rand. Decat sa folosesti ceva in genul Nest.js mai bine folosesti Rails.

[Cosmin_Popescu (cosmos)]

https://htmx.org/

Pare de luat in seama pentru interfete simple.

[GarryOne (Igor Mardari)]

@iamntz

Nu știu dacă prin JS fatigue te referi la multitudinea de opțiuni sau la complexitatea ecosistemului în general. Pentru mine este reprezentată de a doua variantă.

@alessioalex

Nu a plecat nicaieri fatigue-ul. Lucrurile sunt la fel de complexe.

Eu am gasit urmatoarea definitie:

JavaScript fatigue refers to the inability to keep up with the latest tools, the fear of becoming obsolete, the constant change of the ecosystem, and the overwhelming choice

---

@iamntz

Hai să luăm ca exemplu Vue, care mi se pare că are mult potențial dar mi se mai pare și mega frustrant la început: Installation | Vue.js aici nu scrie nicăieri ce să faci după ce ai instalat vue prin npm. Ori folosești cli-ul pentru a instala o aplicație de bază pe care o modifici ori trebuie să știi (de unde?) că ai de făcut treaba asta:

Ai dreptate, sunt asa cazuri, dar asta cred ca poti gasi in orice alt limbaj, pana la urma, nu doar in Javascript.

Pe de alta parte, la documentia Next.js si Nest.js nu am intalnit probleme, in principiu.
A fost o placere sa le urmaresc documentatia.

@Cosmin_Popescu,
Asta-i exact genul de chestie, de - asa nu!. Genul de chestie care contribuie la JS Fatigue si care nu neaparat ajuta la evolutia limbajului, ecosistemului. E doar un alt mod mai diferit si nestandardizat de a face o chestie, existenta deja. Un fel de CoffeScript.
Sa fim seriosi, in ce conditii ar putea ajunge conectarea la WebSockets prin atribute de HTML, un standard? Ori noi asta ne dorim. Din cauza asta ne plangem. Ca nu avem standarde, directii clare.

@alessioalex

Decat sa folosesti ceva in genul Nest.js mai bine folosesti Rails.

Poti sa argumentezi, te rog?

@rolisz

fie a trebuit eu sa fac niste UI-uri simple. Concluzia: vai de mine. De ce trebuie atatea nivele de abstractie? De ce atatea complicari?

De acord, fapt pentru care nu agreez Styled Components. Adica CSS in JS. CSS/SCSS e suficient, isi face treaba foarte simplu si eficient.

---

@rolisz

Back in my day, asa “simplu” era cu jQuery.

Da, era simplu cu jQuery dar si UI-urile pe vremea lui aratau si functionau, ca atare. Adica mult sub ce avem astazi.

---

@rolisz

Mai ales ca eu scriu backenduri in Python, e super frustrant sa scriu API-ul in Python, sa scriu clientul in JS, si cand updatez ceva, sa schimb in doua locuri.

Da, astea e partea incomoda la a decupla backend-ul de frontend, dar problema asta ai o ai tot timpul, cand decuplezi si micro-serviciile intre ele. Pierzi pe o parte, castigi pe alta.

[isti37 (István F.)]

Nici vorbă să fi dispărut, e exact la fel.

React s-a maturizat cu NextJS, cu hook-urile, dar e tot enervant în unele locuri cu TypeScript și librării.

Mai nou se fac șmecherii foarte complexe cu edge server side rendering și rețele distribuite, crypto (ethereum, polkadot)…

Dacă vreți să vedeți WTF citiți despre server side components.

Acum vine puternic Rust în ecosistemul de JS, total alt limbaj cu total alte pattern-uri, chiar hardcore.

Rome, SWC, aplicații cu WASM.

Tailwind e fain dar greu la început și Tailwind nu e singura soluție ciudată.

[Moon]

@alessioalex

Nu a plecat nicaieri fatigue-ul. Lucrurile sunt la fel de complexe.

Pe partea de JS frameworks eu zic ca Angular e kind of dead, iar SvelteJS e preferatul meu. Solid.js e si el trending. React si Vue raman liderii.

Pe partea de Node, recomand Fastify.js. E facuta de baietii de la Nearform, care sunt si core contributori la Node. Fastify e facut cu gandul la performanta in primul rand. Decat sa folosesti ceva in genul Nest.js mai bine folosesti Rails.

Nici nu am auzit de Fastify.js, Solid.js, Nest.js, fatigue a ramas, asa era inainte, foloseai ceva si apoi veneau cineva si zicea, ha, nimeni nu mai foloseste x, y is all the rage, peste 3 luni y is obsolete boomer, toata lumea foloseste z, is so cool, facut de cutare.

[alessioalex (Alexandru Vladutu)]

@GarryOne

@alessioalex

Decat sa folosesti ceva in genul Nest.js mai bine folosesti Rails.

Poti sa argumentezi, te rog?

Din mai multe motive, cel mai important find ca este un mamut de framework pentru aplicatii tip CRUD.

Mai degraba as folosi Rails sau Laravel decat un echivalent al lor in Node, pentru ca in Node e mult mai usor sa “shoot yourself in the foot”. Daca faci ceva gresit si blocheaza eventloop-ul, blocheaza toti userii de pe acel proces Node. De asta prefer mai degraba framework-urile mici si specializate, ale caror cod sursa il pot citi cu usurinta.

Un alt motiv pentru care imi displace Nest il reprezinta chestiile non-standard, ca si decoratorii:

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})

Nu in ultimul rand, e foarte ‘ceremonios’ ca si Angular.js. Prefer lucrurile simple de folosit.

[alessioalex (Alexandru Vladutu)]

@Moon

@alessioalex

Nu a plecat nicaieri fatigue-ul. Lucrurile sunt la fel de complexe.

Pe partea de JS frameworks eu zic ca Angular e kind of dead, iar SvelteJS e preferatul meu. Solid.js e si el trending. React si Vue raman liderii.

Pe partea de Node, recomand Fastify.js. E facuta de baietii de la Nearform, care sunt si core contributori la Node. Fastify e facut cu gandul la performanta in primul rand. Decat sa folosesti ceva in genul Nest.js mai bine folosesti Rails.

Nici nu am auzit de Fastify.js, Solid.js, Nest.js, fatigue a ramas, asa era inainte, foloseai ceva si apoi veneau cineva si zicea, ha, nimeni nu mai foloseste x, y is all the rage, peste 3 luni y is obsolete boomer, toata lumea foloseste z, is so cool, facut de cutare.

Nu spune nimeni sa folosesti ce-i mai nou. Pana la urma folosesti ceea ce stii in primul rand. Eu am folosit de exemplu Alpine.js la un site la care se preta lucrul asta (nu existau alti frontend devs in afara de mine, nu era un SPA).

Ceea ca ma loveste totusi la acest fatigue e ca acum toti publica module ESM, care sunt practic nefolosibile cu cele CommonJS. Ma refer la asta: ES modules are terrible | Hacker News

[isti37 (István F.)]

E fain dacă te folosești de ESM, nu mai trebuie făcut build.

Doar că nu vor fi multe proiecte fără build-uri.

[sebi]

Nici nu am auzit de Fastify.js, Solid.js, Nest.js, fatigue a ramas, asa era inainte, foloseai ceva si apoi venea cineva si zicea, ha, nimeni nu mai foloseste x, y is all the rage, peste 3 luni y is obsolete boomer, toata lumea foloseste z, is so cool, facut de cutare.

Pai inclusiv in topicul asta sunt exemple de asa ceva.

[sebi]

Pe partea de JS frameworks eu zic ca Angular e kind of dead, iar SvelteJS e preferatul meu. Solid.js e si el trending. React si Vue raman liderii.

Nu e dead chiar deloc, if anything, as zice ca mai degraba Svelte sau Solid sunt aproape unheard of.

[isti37 (István F.)]

Vă dau exemplu cu ce îmi omor neuronii acum:

React Query

Cu https://react-table.tanstack.com

Totul frumos, dar doar până când îmi dau seama că nu merge cum mi-am imaginat, coloanele, datele și opțiunile la tabel trebuie memoizate, dar nu oricum, fiecare individual.

E ușor de zis, mult mai greu de făcut să meargă în practică dacă ai ceva logică.

[AlleXyS (Alexandru Tudor)]

nu stiu de ce vi se pare unora ca Angular e mort sau spre moarte deoarece nu e primul framework js folosit. Ce stiu sigur e ca eu nu m-as fi apucat vreodata de frontend daca nu exista Angular/Typescript Ca acum sunt mai multe librarii care au adoptat ts, inseamna doar ca angular a facut o miscare corecta (rescrierea lui angularjs pe ts), cu mult inaintea altora De ce as vrea sa ma intorc in trecut si sa am intr-un singur fisier cod javascript, css si html, in loc sa le separ frumos pe tipuri?

mai mult, pentru cei care fac full stack, angular e mult mai usor de folosit/invatat, fiind aproape o copie a backendului, cum zicea si rolisz, in mare parte fiind nevoie de duplicare cod.

are bubele sale, probabil ca orice limbaj/framework/librarie, eu unul n-am reusit sa fac upgrade unui proiect la versiuni curente, fara sute de erori care au rezolvare mai usoara crearea unui nou proiect si importarea pachetului cu totul :))

[sebi]

Pai probabil fiindca daca constant incerci ultimul framework din seria “ce e hot in ultimele 6 luni”, Angular nu a mai aparut de ceva vreme pe acolo, si unii trag concluzia ca e dead.

Poate aia sunt aceeasi care trag concluzia si ca Node.js e dead, fiindca acum Deno e mai hot, si tot asa.

Asa te trezesti pe proiecte pe care s-a pus acum 7 ani o librarie sau un framework, fiindca parea cel mai hot pe vremea aia (desi aparuse de abia un an), si nu a mai fost mentinut de 6 ani - I’m looking at you, Reflux.js -. Apoi e un pain sa-l scoti din proiect si te gandesti oare cui i-a venit ideea de a-l baga, dar persoana respectiva e long gone.

Probabil a fost si platit mai bine, fiindca la vremea aia a introdus “un tool nou si inovator” - bonus points ca parea si mai skilled in fata managementului, fiindca e “up to speed cu ultimele trenduri”

[crystal (Adrian)]

La mine la firma mult timp a fost o politica gen sa scri cod in ce vrei tu, asa ca avem in codul de java cod scala si kotilin. Nu mult, dar suficient sa puna probleme pt ca persoanele care au facut asta nu mai sunt in firma de mult :)))

[viczam (Victor)]

De acord. Si era de asteptat sa se ajunga aici, era normal ca unele frameworkuri sa ajunga sa castige “intrecerea”.

Si eu folosesc aceleasi framework-uri si librarii (Nest.js, Next.js) cu GraphQL pe partea de comunicare client - server (cu Apollo).
Am urmarit ecosistemul destul de atent, chiar m-am uitat si in ograda Rails si Laravel si sunt convins ca asta e combo-ul cel mai bun (cel putin pentru perioada curenta).

In rest, tine de conventii personale:

• module reutilizabile de nest.js, pe langa cele populare
• un ORM / ODM bun
• un UI library bun (pentru mine mui si chakra-ui sunt cele mai bune)
• o serie de UI libraries pentru taskuri comune: forms library, file uploading, sorting etc. (ai de unde alege ).

Pe server side mai trebuie clarificata partea de comunicare cu o baza de date. Acolo Prisma pare sa devina dominant, dar pentru mine e doar un typed knex care stie mai multe despre structura bazei de date, asa ca am preferat sa imi fac un mongo data mapper similar cu TypeORM (si zic eu ceva mai bun ), usor de extins prin mixins.

[alessioalex (Alexandru Vladutu)]

@AlleXyS

nu stiu de ce vi se pare unora ca Angular e mort sau spre moarte deoarece nu e primul framework js folosit. Ce stiu sigur e ca eu nu m-as fi apucat vreodata de frontend daca nu exista Angular/Typescript Ca acum sunt mai multe librarii care au adoptat ts, inseamna doar ca angular a facut o miscare corecta (rescrierea lui angularjs pe ts), cu mult inaintea altora De ce as vrea sa ma intorc in trecut si sa am intr-un singur fisier cod javascript, css si html, in loc sa le separ frumos pe tipuri?

mai mult, pentru cei care fac full stack, angular e mult mai usor de folosit/invatat, fiind aproape o copie a backendului, cum zicea si rolisz, in mare parte fiind nevoie de duplicare cod.

are bubele sale, probabil ca orice limbaj/framework/librarie, eu unul n-am reusit sa fac upgrade unui proiect la versiuni curente, fara sute de erori care au rezolvare mai usoara crearea unui nou proiect si importarea pachetului cu totul :))

Cred ca la mine e exact opusul, daca ma apucam cu Angular si TypeScript ramaneam pe backend. Si spun asta lucrand cu Angular de multi ani de zile. Mi se pare bloated, si m-am saturat de conceptele unice ale framework-urilor din ziua de azi. Nu vreau sa ma gandesc la dependency injection, servicii, inject si injectable sau la hooks si memoization.

Cum bine a spus cineva pe un thread de HN:

“This is my first look at Svelte. It looks amazing. I hope for the day when front-end development is more language primitives and fewer frameworks–what with their ‘useEffectOf’ and @Component’s of the world.”

Si acel thread find ca Vercel (baietii care au facut Next.js) il angajeaza full time pe creatorul Svelte.js ca sa lucreze pe banii companiei la frameworkul sau: Rich Harris joins Vercel to work on Svelte full time | Hacker News

@sebi The Most Loved Web Framework for Developers in 2021 Is Svelte: Report | ITPro Today: IT News, How-Tos, Trends, Case Studies, Career Tips, More

[alessioalex (Alexandru Vladutu)]

@isti37

Vă dau exemplu cu ce îmi omor neuronii acum:

https://react-query.tanstack.com/
Cu https://react-table.tanstack.com

Totul frumos, dar doar până când îmi dau seama că nu merge cum mi-am imaginat, coloanele, datele și opțiunile la tabel trebuie memoizate, dar nu oricum, fiecare individual.

E ușor de zis, mult mai greu de făcut să meargă în practică dacă ai ceva logică.

De cand cu Coronavirus si work from home, am urmat si eu zeci de ore de tutoriale de React ca nah, e la moda si am zis sa nu raman in urma. Toti spun ca nu are rost sa folosesti redux, ca poti folosi Context API si alte minunatii.

In practica din ce am vazut cu React trebuie sa fii foarte atent si sa “memorezi” totul altfel se tot re-renderizeaza. Ideea din spatele React cu acel tree de componente care se re-renderizeaza la schimbari mi se pare interesanta, insa ceea ce face Svelte prin compiler-ul sau mi se pare superior (cu mult).

O ultima remarca: folositi in continuare ceea ce doriti, ceea ce va place si ceea ce stiti. Pana la urma conteaza mai mult produsul si mai putin limbajul / frameworkul folosit. booking.com e facut in Perl de exemplu si nu are teste unitare, ci doar functionale.