Ha Javascript frontendet kell fejlesztenem, akkor...

Hardver

Angular
9% (27 szavazat)
React
8% (25 szavazat)
Hatarozottan se nem Angular se nem React
20% (62 szavazat)
Nem ertek a webhez/Javascripthez
63% (190 szavazat)
Összes szavazat: 304

( mgabor v | 2017. 07. 06., cs – 20:14 )

biztos az a baj, hogy amatőrök készítették, de egy csomó oldalba belefutottam már ahol angulart használnak és annyira "unreszponzív", hogy szegény böngésző örül ha életben marad. rühellem az ilyen oldalakat.

Probalj egyszer egy "alkalmazast" irni, es rogton elkezded dijazni ezeket a frameworkoket.

Csinalj egy tablazatkezelot pl. Es maris helyerekerul itt minden.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A lentebb emlitett react native-ot pl ertem miert jo.

De nekem akkor is meredek a reactban, hogy kell hozza a babeljs, meg csomo minden mas. Mar a build scriptek kizenetetol es mukodesetol ossze szoktam hanyni magam. A kedvencem az volt, amikor csak egy specifikus IDE pluginjakent mukodott a build (minify, apro htmlekbol egy nagy array, mindez commitolva csomo conflict vagy gitignore edit surun, es akkor meg nem kerult szoba, hogy JS-ben opcionalis a pontosvesszo, ami sok file minify-janal kulon visszaut)

Butabb (villamgyors) tablazatkezelot irtam mar sima JS-ben fel nap alatt. Meg jquery se kellett hozza, de modern bongeszo igen ;) Az teny, hogy Androidban gyorsabb lett volna Java Objectekkel, azt meg nem generalta le maganak :P

Szerintem amit itt korulirsz az a dedup lesz:)

Azaz vegigmegy a fuggosegeken, es kiszanalja azt belole, amit sose hivsz meg:
https://github.com/webpack/docs/wiki/optimization

Az teny es valo, hogy egy mostani javascript projektet mar komolyan "buildelni" kell,
egy webpack-ba belerazodni, ugy hogy fejleszteskor is kenyelmes legyen
(valtozaskor buildeljen, es ujrainditsa a szerveroldalt is:) az tobb napba tellik.

Ha egy tablazatkezelot ugy osszehoztal,
hogy ket (vagy tobb) ember tudja szimultan szerkeszteni (+autosave),
es ehhez nem kellett neked framework,
akkor menthetetlen vagy: te mar nem vilagosodsz meg.

Egy csomo vallalati alkalmazast en szerintem 2017ben webre kell irni
(megha belso halon hasznaljak is),
es a nativ alkalmazashoz legyen a legkozelebb a mukodese.
Ehhez egy javascript framework tokeletes.

Mobilnal nalam a React native azert kerult elo, mert pont ott elojon,
hogy nincs mindig internet (vagy terero), viszont hasznalni jo lenne a cuccost.

Amugymeg erre megy a vilag. Vagy beallsz a sorba, vagy elmegy melletted. :-\

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Menthetetlen"
"Nem vilagosodsz meg"

LOL

"Ket vagy tobb ember tudja szerkeszteni"

Ilyen nem volt, egy ember tudta az enyemet. "Van meg remeny", ha valaki megker, hogy talaljam fel ujra a Google Sheetset? :DDD

"Az teny es valo, hogy egy mostani javascript projektet mar komolyan "buildelni" kell,
egy webpack-ba belerazodni, ugy hogy fejleszteskor is kenyelmes legyen
(valtozaskor buildeljen, es ujrainditsa a szerveroldalt is:) az tobb napba tellik."

Emiatt nekem kapasbol "tul magic" az egesz. Es tul sok programozot lattam ennel a resznel (vagy ezek githez kapcsolasanal) hatalmasakat hibazni.

Raadasul meg nagy is az arcuk, miutan egy feleslegesen bonyolult karbantarthatatlan akarmit osszehanytak, hogy "dehat a frontend ma mar bonyolult, tobbet er". Ja, tok egeszseges, hogy 5 honapig implementalsz 8 menupontot es utana mas hozza se tud nyulni mert csak a te IDE-den megy a build gomb.

Eszem agaban nincs meggyozni teged. En a pont leszarom allasponton vagyok, hogy ki mit hasznal.

Mindosszesen olyan usecase-t probaltam neked eloadni, ahol (ugyan nem nelkulozhetetlen) de
nagyon jol jon es nagyon sokat segit egy ilyen framework.

Akinek fule van hallja meg.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"De nekem akkor is meredek a reactban, hogy kell hozza a babeljs, meg csomo minden mas"

Nem kell hozzá babeljs. Érdemes használni, hogy használhasd a jsx szintaxist. De react kódot írhatsz anélkül is. A csomó minden más részre konkrétumok híján nem tudok mit mondani, de ha a build rendszerre gondolsz, az is az előnyödet szolgáltja, főleg nagy projektnél.

Kifejtenéd bővebben, hogy miért tekinted feleslegesen komplexnek a Vue-t? Pont fordítva látom. Amikor még "csak" jQuery volt és kézzel kellett vele turkálni a DOM-ban, azt éreztem feleslegesen komplexnek. Vue-val (meg akármelyik modern keretrendszerrel) ez automatikus. Ha pl. egy tömbből kell egy HTML listát feltölteni, akkor csak definiálni kell a tömböt és egy sablonban megmondani, hogyan renderelje azt le. Ezután, ha bármi módosítja a tömb elemeit, azt észleli a Vue és frissíti a DOM-ot. Szerintem ez kifejezetten kényelmes.

Abban egyetértünk, hogy a build/transpiler/bundle eszközök komplexek lehetnek, szerencsére vannak meta-toolok, amik generálnak egy kezdő webpack konfigot, így nem kell azt se 0-ról írni. Sőt, ha nem kell a régi böngészőket is támogatni, akkor pl. a Vue-hoz nincs szükség semmi extrára, működik egyből egy modern böngészővel.

+1 Vue.

Mindent tud, és a vue-cli eszközzel olyan hatékony scaffoldingot és fejlesztői környezetet (ES6, hot reload stb.) lehet gyártani, ami nálam nagyon bevált.

Egy kicsit furcsa volt az elején a szigorú linter, de most már undorodom, ha máshol pontosvesszőt kellene raknom a sorok végére. Gondolom, ettől Crockford feje elkezdene vörösödni, de úgy látszik, ha a linter jól ismeri a pontosvessző elhagyására vonatkozó szabályokat, akkor abból nem lesz semmi baj.

Korábban próbáltam Backbone-t, Knockoutot, Embert, Reactet, Angulart, meg a fene se emlékszik mi egyebet, de a Vue közelébe egyik se ért.

Én nem tudtam megszeretni a jsx-t, illetve még nem sikerült olyan React kódot írnom, amire jó volt ránézni.

Ezzel szemben Vue komponenseket kifejezetten kellemes volt írni és később is teljesen átláthatónak éreztem. Tehát nekem főleg esztétikai okokból jön be jobban Vue.

Belelapoztam a Vue leírásába. Tényleg gyorsan tanulhatónak jön le. Úgyhogy most elolvasom az interneten található összes "Why we chose Vue.js over React" című cikket :)

Mondjuk hogy felületes React ismereteim vannak, inkább csak kísérleti szinten van tapasztalatom. Ezek alapján nem tartom nehéznek megtanulni alapjában véve, de a csomó cucc, ami vele jár egy komplexebb webalkalmazás készítésénél (Redux, redux függőségek tömege, szerveroldali renderelés, stb) az már bonyolítja.

Szeretnék meggyőzve lenni, hogy jobb választás a Vue, mert az alapján amit olvasok úgy tűnik, hogy könnyebb dolgozni benne. Cserébe React univerzálisabb olyan értelemben, hogy több helyen használják (munkakeresés szemponjából pl érdekes lehet) illetve van react-native, és jó nagy közösség körülötte.

> szerveroldali renderelés

Innen indultunk, nem? Aztan valami okos kitalalta, hogy toljunk mindent a kliensre mer JS meg minden, amit mar akkor latott az ertelmesebbje, hogy abnormalis, szoval most akkor visszamozdulunk a szerveroldali generalashoz? Jo ez a JS kozosseg, folyamatosan talalja fel a melegvizet :)

Ez hogy jön a React vs Vue témakörhöz? :)

Egyébként nem, nem innen indultunk. Ahonnan indultunk, az weblapok, azaz közel statikus dokumentumok megjelenítése a böngészőben. Itt viszont webalkalmazások rendereléséről van szó, amik nem megjelennek, hanem futnak a böngészőben. Amik inkább szoftverek, mint dokumentumok.

Nyilván hülyeség egy wikipedia oldalt kliens oldalon renderelni. De legalább olyan hülyeség elítélni azt, aki egy honfoglalót, vagy egy chat alkalmazást kliensoldali eszközökkel készítene el.

> Ahonnan indultunk, az weblapok, azaz közel statikus dokumentumok megjelenítése a böngészőben

Ott is kellett volna megmaradni.

> Amik inkább szoftverek, mint dokumentumok.

Szoftverre nativ (vagy arra fordulo) alkalmazas valo. Sajnos a webfejlesztok betortek mostmar a desktop piacra is, aztan kapunk olyan szornyszulotteket Atommal, mint a Slack, ami ugyan rendelkezik deskop klienssel, de annak meg szar. A web nem arra lett kitalalva, hogy alkalmazasokat fejlesszenek benne, ehhez a webalkalmazas-fejlesztok teljes mertekben hozza is szoktak, szoval eszukbe se jut peldaul jobbklikkes kontext menut tenni a desktop programba. Nesze neked UX design, meg "a web a jovo". Ja, korlatozottan hasznalhato jovo, hurra.

"Szoftverre nativ (vagy arra fordulo) alkalmazas valo"

És mennyire natív egy python alkalmazás? Vagy egy Java VM-ben futó alkalmazás? Mennyivel jobb egy olyan szoftvert futtatni, ami qml-t használ, mint egy olyat, ami html-t? Miért másabb futtatókörnyezet a böngésző, mint akármi más?

És mennyivel jobb egy natív alkalmazás? Mennyivel jobb, amikor a pécé verzió egy windows-os appot takar, a linux userek pedig kapják be? Mennyivel megbízhatóbb egy random facebook.exe, ami azt csinál a gépeden, amit nem sajnál, mint egy sandboxolt környezetben futtatott webalkalmazás?

Nem vitatom a natív előnyeit, de vedd észre, hogy a web alkalmazásoknak is van rengeteg, többek közt az, hogy elhoznak egy csomó alkalmazást minden platformra, sandboxoltan, telepítgetés nélkül.

Nem arra lett kitalálva. Igaz. Csak azóta fordult egyet a világ, és változott a platform, fejlődött rengeteget, úgyhogy már bőven alkalmas rá. Tessék észrevenni a változást.

A jobbklikkes felvetésed pedig a fejlesztő hibája, nem a platformé.

Gyakran használtnak gyakran használt, de tökéletesnek szerintem messze nem az. PC-n gyakorlatilag "ingyen" van a jobbklikk, míg touchscreen interface-n kb 1-1,5 sec késleltetés, tehát gyakori dolgokat nem célszerű rá tenni, illetve nem annyira intuitív a használata.

Hát, amíg nem lesznek olyan kijelzők, amik felismerik melyik ujjaddal nyomtál oda, vagy nem lesz valami kézenfekvő megoldás az érintőképernyőn két érintés megkülönböztetésére, addig ez a legjobb megoldás. És ha egy kicsit várakozni is kell, tökéletlen megoldásnak nem nevezném. A semminél pedig határozottan jobb.

Egyrészről a JS libeknél (framework-öknél) érdekes az, hogy ugyanazzal a JS kóddal kliens oldalon is le tudod renderelni az oldalt és szerver oldalon is, egyszer kell csak megírni és mind a kettő helyzetben tudod használni.

Másrészről az értelmesebbje tudja, hogy a kliens oldali renderelés és a szerver oldali renderelés is egy eszköz, sem az egyik, sem a másik nem jobb, mind a kettőnek megvannak az előnyei, hátrányai és ezeket az eszközöket az adott feladatnak, követelményeknek megfelelő mennyiségben használja.

Igen, ez elony. En csak nem ertek egyet azzal, hogy a bongeszot alkalmazasplatformnak leptessuk elo, mert igy az eredeti es az uj celjat se tudja megfeleloen teljesiteni.

Mar az is egy elbaltazott dolog, hogy kulonbozo alkalmazasokat "tabokba" rendezzuk, ahelyett, hogy rabiznank az operacios rendszerre az ablakok kezeleset. Ha meg kiszeded oket kulon bongeszo ablakokba, akkor mikor bezarod, majd ujra elinditod a bongeszot, akkor vagy megkergul, vagy visszakapod az eddig megnyitott dolgokat. Egyaltalan, miert akarnam megnyitni az osszes futo "alkalmazast" az elozo sessionbol? A bongeszo "ablakkezelese" ugy altalaban ugy el van baszva*, ahogy csak lehet. Nem csoda, nem erre talaltak ki.

En ertem, hogy a cegeknek, hobbistaknak tok egyszeru nekiallni heggeszteni valamit HTML+CSS+JS-ben, hogy aztan azt a szomszed Pistike is tudja hasznalni, es lehet a szomszed Pistike meg orul is neki, de en nem. Sajnalatos modon a web"alkalmazasok" ternyeresevel a deskop appok supportja elegge lemaradt, mindenki a webre koncentral, ahol a felhasznaloi elmeny, mondjuk ki: szar.

Nekem csak ez a gondom ezzel az egesz "hol rendereljunk" temakorrel. Weboldal? Rendereld szerveroldalon. Alkalmazas? Irj hozza "nativ" klienst.

Szerencsere mar jopar ceg rajott arra, hogy csak a webre tamaszkodni nagyon hulye otlet, szoval elkezdtek kiadogatni a deskop appokat is (valtozo minosegben), de sajnos nem mindenkinek esett le meg a tantusz.

*: szerk: inkabb kicsereltem az "elbaltazottat", nem akartam szoismetlest

szerk2: egyaltalan, milyen dolog mar az, hogy az amugy alapvetoen popup megnyilo ablakot valami atmeretezhetetlen, athelyezhetetlen overlay-jel helyettesitjuk? Tudom, tudom a tortenelmi okait a popup blokkolasnak, de azert ne mondd mar azt, hogy egy alkalmazas eseten blokkolni kellene a teljes UI-t addig, amig azt az egy rohadt felugro "ablakot" el nem tuntetted onnan. Nem is ertem, ezeknek a termekeknek a fejlesztoi nem hasznalnak normalis szoftvereket, es ennyire elszoktak a jo megoldasoktol, vagy csak igenytelenek, es nem erdekli oket, hogy szar, mer' "jovanazugy"?

En csak nem ertek egyet azzal, hogy a bongeszot alkalmazasplatformnak leptessuk elo

Hát erről nagyon lekéstél, több, mint másfél évtizede már előlépett alkalmazásplatformnak, én már 2002 óta szinte kizárólag csak vékony klienses (böngészős) alkalmazásokat fejlesztek. Elhiheted, hogy van rá igény bőven az ügyfelek részéről.

Nem a cégek úri hóbortja, hogy böngészős alkalmazásokat készítsenek, hanem ez az ügyfelek igénye. Szeretik, ha az alkalmazás könnyen telepíthető, karbantartható, frissíthető, biztonságos, skálázható, platform független, ...

Ertem en, es tudom, ott voltam, akkor kezdtem a szakmat, lattam az egeszet, es mar akkor is szurnyulkodtem azon, hogy normalis platformokhoz kepest mennyi szivassal jar a "webalkalmazas". Orommel tudatom, hogy ez azota se valtozott, meg mindig szopas, de mostmar legalabb mashogy.

Viszont felre ne erts, kell webes frontend is. Csak nem annak kellene lennie a fo csapasiranynak. Fallbacknek tokeletes lenne, de elsodleges platformnak en nem eroltetnem. Persze a penz az nagy ur, az igenyesseg csak utanna jon, szoval addigis marad a szenvedes es a szitkozodas csendben, vagy kevesbe csendben a gep elott.

Szerk: amugy 4-5 eve megmondtam, hogy a cegek le fognak jonni errol a "webet mindenhova" baromsagrol, es ki fognak adni nativ klienseket is, mert egyszeruen szornyu a webes UX, es lam, igazam lett. Ahogy egyre egyszerubb lesz nativ alkalmazast fejleszteni, ugy fognak a cegek visszaallni a normalitas utjara, es kezdenek el vegre hasznalhato termekeket gyartani.

Mintha lenne benned egy kis ellenszenv a webes technológiák irányába. :D

A JS szerver oldali renderelésében az volt az újdonság, hogy a JS-en felnövő generációnak nem kellett PHP-Pistikékké is válni, ha akartak backendet készíteni. Ugyanazt a technológiát tudták így használni frontenden és backenden. Mi fáj neked ebben? Én meg használnék frontenden natívan Pythont, csak sajna egyik böngésző se támogatja.

Ha ilyenre van szükség, ott hamar el fognak bonyolódni a dolgok, alapból érdemes egy céleszközt használni rá (pl. Redis). Hogy mi köze ennek a skálázódáshoz, azt nem tudom, de nem is értek NodeJS-hez.

Azonban kívánságod máris meghallgatott, most jött ki az ES8 propóza, benne az áhított új ficsőr: Shared Array Buffers.

Hmm?

https://nodejs.org/docs/latest/api/cluster.html

Egyebkent a skalazodast rengeteg felekeppen el lehet kepzelni:
pl.: nginx + nodejs szerverek. Mondjuk mindegyik egy kis virtualis gep. (ez az egesz egy gepen belul). Ez az alapkiepites:)

Amit te szeretnel hogy valtozokat osszunk meg a processzek kozott annal jobb megoldas,
hogyha a kozos valtozokat kiteszed egy adatbazisba (memcached, redis, stb).
A te megoldasoddal az a baj, hogy mit csinalsz akkor, hogyha kinotted azt a fizikai gepet?
Hogyan szervezed a programodat tobb gepre?
(akkor hogyan fognak kozos valtozoval kommunikalni?)

Nekem jobban tetszik a kis epitokockas elgondolas. Ez a microservice, vagy mi a szosz.
Sokkal konnyebb tenylegesen skalazni (tobb gepre szetosztani).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"
Amit te szeretnel hogy valtozokat osszunk meg a processzek kozott annal jobb megoldas,
hogyha a kozos valtozokat kiteszed egy adatbazisba (memcached, redis, stb).
A te megoldasoddal az a baj, hogy mit csinalsz akkor, hogyha kinotted azt a fizikai gepet?
Hogyan szervezed a programodat tobb gepre?
(akkor hogyan fognak kozos valtozoval kommunikalni?)
"

Szoval azt akarod mondani hogy

Int thread A -> tcp -> redis/memcached -> tcp -> thread B interpretalt nem eppen optimalis listenerje -> Int thread B

sokkal skalazhatobb es megbizhatobb es "enyemmel ellentetben nem problemasabb" megoldas, mint:

Voltile int x;
majd g++-szal optimalis multithread (lock/unlock OS szinten kitesztelt C lib hivasokkal) ASM-et kalkulalni.

(Arrol nem is beszelve, hogy nincs az a JS async kod, aminel ne lehetne sokkal olvashatobb std::thread alapu C++ kodot irni ;) )

(Oke, a C++ tulzas, de nem veletlen kezd elterjedni a Go http szerveroldalon)

Long story short: a node-nak el fog jonni a vege. A PHP elore megirt halala is a rossz thread kezeles egyelore, de ott tobb az esely, hogy eszhez ternek.

"thread B interpretalt nem eppen optimalis listenerje"

A node.js mögött lévő V8 motor compile-olja a JS kódot gépi kódra, és úgy futtatja.

"Szoval azt akarod mondani hogy [tcp, redis, memcached, js] sokkal skalazhatobb es megbizhatobb es "enyemmel ellentetben nem problemasabb" megoldas, mint: Voltile int x; [...]"

Skálázhatóbb? Természetesen. A te változód threadek közt van megosztva egy gépen belül, a memcached pedig akár több gép közt is.

Tény, hogy a te megoldásod gyorsabb, egész addig, amíg a kódnak elég egy gép teljesítménye. Amint túl kellene skálázódni azon, kénytelen volnál te is egy "problémásabb" megoldást alkalmazni.

Szerk: Egyébként milyen esetben hiányzik a szálak kezelése a PHP-ból? A tipikus felhasználás webes requestek kezelése. A párhuzamosítás inkább úgy történik, hogy több processz dolgozik egy szálon, mindegyik egy-egy requestet kiszolgálva. Tudsz olyan esetet mondani, ahol volna értelme annak, hogy threadeket csinálj PHP-vel?

Websocket server/daemon eleg jo pelda? (Annak is Go-ban kezdenek neki, pedig nem szeretem a Go-t annyira)

Lenyeg websocket servernek a php es a nodejs is alkalmatlan (mindketto a single thread vs egy port miatt)

Tobb gepre skalazasnal inkabb pont ott kezdodik a gond hogy DB (foleg relacios adatnal szazmillio soroknal). Az szukebb keresztmetszet.

Akár jó példa is lehet, csak nem konkrét. Az tény, hogy a PHP nem alkalmas erre a célra, de nem is erre találták ki, hülyeség elvárni egy asztaltól, hogy csóválja a farkát, hiába van négy lába.

Minden más egyéb feladatra, amire viszont tökéletes, arra továbbra is az lesz, lehet hogy jobban is, mint egy go (vagy akár node) alkalmazás.

Arról viszont nem vagyok meggyőződve, hogy egy node app ne lenne alkalmas websocket szerverként. Miért is? Csak mert nem tud több szálat kezelni (ami szintén nem igaz már)? Attól csak lassabb lesz, nem alkalmatlan, ráadásul erősen feladatfüggő. Mi az, ahol szükséges az, hogy te nagyon gyorsan tudj kommunikálni több szálon futó kóddal.

"Csak mert nem tud több szálat kezelni (ami szintén nem igaz már)?"

Nem kepes tobb szalat kezelni legalabb a Java szintjere optimalizalt thread safe OS szinten lockolt (volatile) valtozoval. Ezert alkalmatlan. Amit fentebb felvazoltam az 100-200x-os sebessegkulonbseg (ket thread + listener + redis + 2 tcp vs azonos memoriaszerkezet es precompiled code es libc gyorsasagahoz kozeli hivasok azonos nyelv primitivjenek vagy akar objektumanak)

De a legfontosabb az az, hogy ezt a 100-200x-os sebessegkulonbseget el is tudom adni a megrendolnek, szep kis grafikonokat lehet rola rajzolni. A megrendelo ugyanis az az embertipus, aki 20 eve elhitte, hogy a DVD regio kod az egy jo biztonsagi feature, a fejlesztok meg hiaba fogtak a fejuket onnantol.

Majd atallnak valami masra. Szep lassan kiresearcholi/kiresearcholte es nyilvanossagra hozza evekre ra egy corporate, aki mar erzi, hogy szar 30 gepen node szerveren futtatni az 1 gepen is elfero millio useres csetjet, es neki majd elhiszitek.

Egyelore "nem eleg rossz" (lasd meg Windows, systemd), es konnyu Javascript es PHP fejlesztot talalni. Elobbinek mondjuk viccesen megy fel az ara, es ennek nagyon csunya vege lesz.

"Majd atallnak valami masra."
Igen a dolgok általában így működnek.

A mérleg egyik oldalán olcsó sok munkaerő-lassú kód (nodejs, php), másikon drága és kevés munkaerő-gyors kód(C, assembly). Nem mindig a sebesség a lényeg, úgy általában inkább a pénz. Pl te is ha annyira hiszel a megoldásodban, meggyőzhetsz cégeket és jó pánzárt optimalizálhatsz nekik. A többit a piac eldönti. :)

"30 gepen node szerveren futtatni az 1 gepen"
Ez azért redundancia miatt se mindegy. 1 gép elfüstöl leáll minden.

Halkan megemlítem, hogy az Instagramnál Pythonnal (pontosabban egy agyonhekkelt Djangoval, Python 3.5 alatt) szolgálnak ki napi 400 millió felhasználót. A Python meg nem nyers gyorsaságáról híres. Létezik más szempont is egy technológia kiválasztásánál, mint a nyers sebesség. Ez esetben a "time to market" mutatóban ver náluk köröket más megoldásokra.

Általánosan nem. Pythonnál ott a Global Interpreter Lock több szál (thread) esetén. Multiprocess módban lehet használni volatile-szerű változókat, de webes környezetben itt is inkább a workeres megközelítés az elterjedt, pl. uWSGI használatával. Ha, tegyük fel, websocketen keresztül akarnék valami élő interaktív tartalmat több felhasználónak mutatni, Redissel oldanám meg a kommunikációt, ott erre találták ki a Publish/Subscribe funkciókat. Biztos meg lehet valahogy oldani csak Pythonnal is, de minek találjam fel ismét a spanyolviaszt, ha használhatok egy céleszközt is.

Szereted ezt az egyetlen sort puffogtatni, hogy "a volatile valtozo csak egy gepen van". Szerinted ez kizarja tcp csomagok kuldeset, vagy mi? ;) Onnan indultunk, hogy a volatile valtozo 100x gyorsabb, de ha tobb gepre kell skalazni akkor tcp+microservice

Mit nem ertetek azon, hogy attol meg hogy a masodikat tudja a node (meg minden mas is), az elsot meg nem fogja, es fontos performance-szal kapcsolatos szerepe lesz egy meret felett?

1) Tudja a node mindkettőt. Csak nem úgy, ahogy te várod

Hanem hogy?
Mondjuk legyen a feladat egy performáns RDBMS megírása (tfh le akarod cserélni a mysql-t). Hogy csinálod ezt Javascriptben, ezzel a "nem úgy, ahogy te várod" megoldással?

Tekintsünk el attól a megoldástól, hogy keresel egy C-ben megírt embedded multithreades RDBMS-t, és írsz köréje egy JS network layert... :D

Jézusom, hogy jön ide az adatbáziskezelő?

Konkrétan az egész szál a szerveroldali weboldal renderelésből indult ki. Nyilván nem node alatt fogsz megírni egy db szervert. Nyilván a megfelelő eszközt a megfelelő célra. Te komolyan ennyire hülyének nézel, hogy javascriptben állnék neki ilyet írni?

Vagy attól szar mindenre a node, php és társai, mert nem lehet benne oprendszert írni?

És hogy lesz szerveroldali weboldal renderelésed db szerver (vagy vele funkcionálisan ekvivalens réteg) nélkül? Mondjuk az esetek 99%-ában, amikor erre szükség is van?

Igazából az én véleményem a JS felmagasztalásáról annyi, hogy az igazi problémát (shared adat hatékony megosztása és feldolgozása) nem oldjuk meg vele, csak áttoljuk a döglött lovat a szomszéd telkére (db layer), aztán oldják meg ott...

Remek ez a szál. Eljutottunk onnan, hogy a JS fejlesztők nem akartak PHP-t tanulni backendhez (így létrejött a nodeJS), oda, hogy szar a JS, mert nem lehet benne adatbázis szervert írni. :D

Mi a búbánatos fenének akarna valaki JS-ben RDBMS-t írni? Nem akar senki ilyet. NodeJS-ből is el lehet érni akármelyik adatbázist, ha szükség van rá.

Van par inmemory adatbazis, amit irtak mar nodejs-ben. Egyiket se probaltam.
Vagyis de, egyet hasznalok:
http://www.tingodb.com/

De ezt azert tulzas lenne adatbazis szervernek hivni.
En arra hasznalom, hogy onjaro legyen a programom,
es ne kelljen rogton adatbazis az indulashoz. Amolyan fallback.

(lehet a githubos linket kellett volna direktben irni:
https://github.com/sergeyksv/tingodb )

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> Ellatja, de 1 millio user/sec folott is?

Nehez olyan chatszobat elkepzelni, ahol 1 millio user beszelget *egymassal*.
Ha meg nincs megse 1 millio user, akkor szet lehet osztani tobb gepre,
"szobakat/csoportokat" pakolgatni ide-oda, ahogy a terheleseloszlas megkivanja.

Nem eletszeru amit irsz.

Inkabb gyere olyan peldakkal, ami tipikusan egy gepen fut.
Mondjuk egy CAD tervezoprogram:) Azokat milyen jo lenne javaban megirni!

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Azt észrevetted, hogy nem csak microservices-en lehet megoldani, hanem volt egy link is a több szálú végrehajtásról?
Itt egy másik és még egy.

Van több eszköz és a feladatnak megfelelőt kell használni, ha kell microservice-ek a skálázhatóságért, ha kell, akkor több szálú végrehajtás a gyorsaságért. Természetesen vannak megoldások, ahol a kettőt lehet vegyíteni is (ugyanaz a kód futhat így is, úgy is), js alatt nem tudom van-e ilyen, Scala alatt biztosan.

PHP-ban meg van shell_exec, meg C-ben is lehet Perl kodot bash-en keresztul behivni ennyi erovel (lasd az a "tehetseges" dev az Apple-nel anno).

A lenyeg itt az lenne, hogy minel kevesebb nyelv memoriaszerkezetevel meg azok minel kevesebb hulyesegevel es kulonbozosegevel kelljen bajlodni (a fejlesztonek is, meg a compilernek is)

"js alatt nem tudom van-e ilyen, Scala alatt biztosan."

:DDDD

Amugy a worker process-ek letezeset JS-ben egy masodpercig se tagadtam. A linkekben nem lattam, hogy hogy hasznaljak ugyanazt a memoriabol kivasott egyszeru valtozot parhuzamosan.

A workerek arra jok JS-ben, hogy ahany cpu mag, annyi reszere oszthatod a kepernyon a canvasokat az animacioidhoz, de ha lockolni kell par resource-ot backenden, ott mar brutalis overhead lesz.

Itt üzenet küldéssel van megoldva a konkurencia kezelése a lock, synchronization helyett. Természetesen mindkét eszköznek megvannak a maga előnyei hátrányai, így itt sem hirdetnék győztest.
Az üzenetküldéses konkurencia kezelés egyik legfőbb előnye, amit már írtam is, hogy ugyanúgy működhet két thread között és két (micro)service között is, amik akár a világ két eltérő végén futnak. Tehát nem csak felfelé skálázható (scale up), hanem szélességében is (scale out).

Persze, de üzenetküldést bármilyen platformon lehet csinálni (én írtam Perlben multi-node elosztott rendszert), viszont rendes, kényelmes shared-memory alapú párhuzamosítást meg nem - és a való életbeli problémák igen jelentős részében ez utóbbi bőven elég skálázhatóságot ad (hány core-nál is tartunk per socket? 22? 28? mihez nem elég 2..4x22..28 cpu core?), miközben jóval kevesebb az overhead.

Szóval arról beszélünk, hogy míg a jobb platformokon választhatok, hogy az adott feladatra melyik a jobb megközelítés, addig az ilyen single-thread-alapú megoldásoknál kénytelen vagyok mindent üzenet alapon megoldani. Ami működhet, persze, de azért nem véletlen, hogy a db layert nem javascriptben szokták írni... ;-)

a való életbeli problémák igen jelentős részében ez utóbbi bőven elég skálázhatóságot ad (hány core-nál is tartunk per socket? 22? 28? mihez nem elég 2..4x22..28 cpu core?)

Pl.:
- sok felhasználó egyidejű kiszolgálására,
- földrajzilag elosztott rendszerekhez,
- hibatűrő rendszerekhez (egy gép elromlik, akkor is üzemeljen tovább),
- deadlock és szinkronizációs hibáktól mentes kód egyszerű készítésére

Még egyszer, egyik sem silver bullet, van amire egyik jobb, van amire másik, most is csak arra hoztam példát amire kérted, hogy mikor jobb az üzenetküldős rendszer, a shared-memory-nak is meg vannak az előnyei.

Szóval arról beszélünk, hogy míg a jobb platformokon választhatok, hogy az adott feladatra melyik a jobb megközelítés

Teljesen egyetértek, én is sokkal jobbnak tartom pl. a Scala-t.

a való életbeli problémák igen jelentős részében ez utóbbi bőven elég skálázhatóságot ad

Ebben tér el a véleményünk, én a való életbeli problémák jelentős részénél jobbnak tartom az üzenetküldőset.

> szoval most akkor visszamozdulunk a szerveroldali generalashoz?

csak egy szo: google.

Bar mar igerik, hogy a js tartalmakat is ertelmez a google bot,
de azert az meg hagy kivannivalot maga utan.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( DirtY_iCE | 2017. 07. 06., cs – 20:40 )

vilagga megyek

I hate myself, because I'm not open-source.

( sj | 2017. 07. 06., cs – 21:34 )

jelenleg jquery, de egy zoldmezos projektnel megneznem a fent emlitett 2-t is...

--
Allitsuk meg Andorrat!

Meg

JQuery-t amugy hasznalok, foleg, ha mar a projektben volt eleve, vagy kell regi browserekre support. Meg sokaknak konnyebb jquery kodot irni olvasni, mint vanilla js-t, csak ott sima js-ezek ahol tenyleg akarom hogy gyors legyen minden.

Angulart semennyire sem hasznalok, recruiterekkel is megbeszeltem, hogy vicceljek el magukat a kliensnek, hogy nalam nagyobb az eselyuk fejlesztokent bekerulni, ha kitorlik az Angulart meg a Reactot a CV-jukbol. Aki nem veszi a lapot, hanem elkezd hitteriteni, azzal meg nem kell dolgoznunk, ennyi, tudni fog a recruiter neki masik allast, ahol nem az ido a legertekesebb valuta, es valaki mas mar meggyozott egy hozza nem erto gazdasagi vezetot. :P

Latok use case-t, ahol ez kenyelmes, ja:

https://vuejs.org/images/lifecycle.png

Meg az is tetszik, hogy a reacttal ellentetben nem akarja behivni a fel npm univerzumot dependency-nek.

De altalaban nincs folyamatos domfigyelesre igenyem. Meg le tudom magamnak definialni azt a par listenert ami kell. Olyankor mar ez is overkill.

Ezt hogy kell érteni hogy önmagában is elég okos?:) A framework nem egy új nyelv, hanem egész egyszerűen az adott nyelvben írt jó adag kód, aminek segítségével könnyebben el lehet érni bizonyos célokat, jelen esetben a DOM manipulációt és a renderelést, egy jól struktúrált kódhalmazon keresztül.
Nagyon szuper ha az amit írsz megoldható vanilla js-ben is egyszerűen és emiatt nem kell feleslegesen behúzni egy komplett libet, de ez esetben egész biztos, hogy amúgy sem volt az adott feladatra alkalmas az említett frameworkok egyike sem. Btw a Treeshaking és a Deadcode elimination egyre jobban működik, így még az is előfordulhat (hogy egy kellően erős fejlesztői gépen) semmilyen hátrány nem lesz akkor sem, ha behúzol több száz KB-nyi frameworkot, mert a végén csak annyi marad meg amennyit valóban használsz.

( penztar v | 2017. 07. 06., cs – 21:52 )

Hello!

Amúgy csak érdeklődés szinten a topic nyitó melyik angularra gondolt? Az Angular.js-re vagy az Angular2-re?

Az csak semver. Attol az meg angular2, amit most angular.io nak vagy epp hogy a turoban hivnak.

Engem szemely szerint a typescripttel vesztettek el ( meg megjelent a react native).

Megvan az a hobbim, hogy belenezek a forrasba. Kicsit hulyen nez ki, hogy javascript frameworkot irunk mas programozasi nyelven...
(jo tudom a typescript lenyegeben egy syntactic sugar, de es6 ota kb. nincs erdemi elonye. Altalaban aki elindul ezen a lejton a Go-nal kot ki a vegen...:-D)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

En azt hittem az osztaly az:)

En pont a nodejs-nel nem szeretek semmi pluszt hasznalni (babeljs pl.),
hogy fejleszteskor --watch -csal ujrainduljon (pl. forever, pm2).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( khiraly | 2017. 07. 06., cs – 23:35 )

React.

De csak azert, mert van react native.

Biztos velem van a gond, de ha valamit, akkor az android studios pocsolest lehet utalni.

Egyebkent lehet olyat csinalni, hogy a weboldalt kiexportalja htmlle, es akkor megvan a statikus sitebuild (raadasul kliensoldalon, mert ebben az esetben a kliensnel van minden info (weboldal allapota).
Az visszapostolja api endpointra.

Azert egy puszta weboldalnal agyuval verebre ilyen framework, de pl. egy xls importhoz tok jo.
Csinaltam ilyen xls importot, 20ezer soros tablazatot rendszeresen radobnak.
Egyesevel dolgozza fel a sorokat, szepen van visszajelzes, tok jo ilyenhez valami okpsabb frameworkot hasznalni.

A yarnhoz is lenne par szavam, de igazabol a React Native akkora hozzaadott ertek, hogy ez eddig a legjobb valasztas.

Talan a jovo ev projektje lesz par angular "alkalmazasomat" react ala portolni. De iden mar react only.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( walaki | 2017. 07. 07., p – 09:14 )

Ha tehetem, ezt használom http://vanilla-js.com/ :P
jQuery szerintem egy bloatware, de a legtöbb helyen ez van, régebben, amíg rendesen fejlesztették, mooTools-t használtam, azt szerettem, moduláris és gyors volt.
Angular és React és a többi hipster framework-öt nem használtam, de gáznak tartom, hogy egy egész Paks 2-t kell üzemeltetni, hogy egy ilyen szart használni tudjál... de lehet, régimódi vagyok...

--
www.haiku-os.org

( RobbeR | 2017. 07. 07., p – 10:24 )

Eddig en is VanillaJS-t hasznaltam egy csipetnyi jQuery-vel, de a mostani projektben Reactra tertem at, a Redux-szal egyutt nagyon eros, raadasul meagyazza a React Native tudast is.
--
Software is like sex: It’s better when it’s free.