JavaScript "ökoszisztéma". Mit? Miért? Hogy?

 ( pehsa | 2018. április 12., csütörtök - 12:18 )

Sziasztok!

A címből tudom nem sok derül ki és igen láma kérdésem lenne ezért előre is bocsánat.

A JavaScript-et már hosszú idők óta nem szerettem, mert akárhány kódot láttam, olyan szinten átláthatatlan, spagetti kód volt, hogy hamar elvette a kedvem az egésztől, viszont mivel oktatásban tanítom az alap JavaScript-et, így meg kellett vele barátkoznom. Így egy kliens oldali script nyelvként megállja a helyét, meg már elismerem, hogy jó dolgokat lehet vele csinálni ha tényleg dinamikus oldalakat akar vele létrehozni az ember.

Viszont amiket nem értek:

Rengeteg oldalon azzal találkozom, hogy első programozási nyelvnek ezt ajánlják, meg szerver oldalra, Node.js és társai.

Mivel ad nekem több pluszt az, hogy Node.js-t használok szerver oldalon, mondjuk egy PHP vagy Python-al szemben?

Kliens oldalra miért jobb a React.js, mint hogy natívan JavaScript+HTML+CSS-el csinálom?

Tudom sokan azzal jönnek, hogy ezekkel le lehet egyszerűsíteni a fejlesztést, viszont több programozót is ismerek, aki megtanult használni egy ilyen eszközt, viszont mellette semmit nem ért a natív JavaScript-hez, sőt egy-kettő, még a HTML+CSS-hez sem igazán ért.

A válaszokat előre is köszönöm!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

> Mivel ad nekem több pluszt az, hogy Node.js-t használok szerver oldalon, mondjuk egy PHP vagy Python-al szemben?
Ebben nem vagyok otthon, de főleg az aszinkronitast szoktak kiemelni. De legtobbszor siman helyettesithetok egymassal, alternativak.

> Kliens oldalra miért jobb a React.js, mint hogy natívan JavaScript+HTML+CSS-el csinálom?
Miert jobb Laravelezni mint nyers PHP-zni? Miert jobb Djangot hasznalni, mint nekiallni megirni a komplett HTTP stacket elolrol Pythonban? Termeszetesen ismerni kell a nyelvet, de a tipikus use case-ek 80-90%-at megoldjak helyetted, eleg a lenyegre koncentralni.

A React (Angular, Vue) ugyanezert jok. JS-sel tipikusan machinalni akarod a DOM-ot, hogy dinamikus HTML-ed legyen, ne kelljen minden mozdulatnal ujratolteni a komplett oldalt. Ez vanilla JS-sel horror.

+1 igazából csak azért érdemes pl python-ban a django-t használni, mert gyorsabban célba tudsz érni vele, mintha neked kellene megírnod mindent, plusz a default beállításaival használva megvéd egy csomó gyakori támadástípustól is (SQL injection, XSS, CSRF) még akkor is ha ezekről nem is hallottál.

A szerveroldalon JS véleményem szerint azért lett ennyire népszerű, mert egy kezdő programozó sokkal egyszerűbben felfogja az aszinkron eventes működést, mintha neki kellene foglalkozni azzal is, hogy ne legyen race condition a kódjában. Ha valaki ezzel kezdi akkor neki ez lesz a természetes és nem okoz neki hónapokon át tartó szenvedést (mint pl. nekem anno :DDD), hogy átállítsa a gondolkodásmódját erre.
A másik meg, hogy egy frontendesnek aki már úgy-ahogy ismeri a JS-t nem kell megtanulnia egy új szintaxist ahhoz, hogy pl. Express-ben összerakjon valamit.

Ja és egyébként csak úgy buliból írtam egy egyszerű, több workerrel dolgozó crawlert async.js-el nodeJS-re és meglepően kevés sorból meglepően gyorsan célhoz értem, azzal szemben mintha include threads.h -val kezdtem volna neki.
Ezzel persze nem állítom, hogy ez a cucc jobb (nem is jobb, hiszen async ide vagy oda attól ez még single-thread), de szerintem kellemes a tanulási görbélye.

Az más kérdés, hogyha az alapokon túljut valaki akkor döbben rá, hogy az egész JS a sok ECMAScript verzióval meg a polyfillekkel meg a transpilerekkel egy 'patchwerk monster' de mire ezt realizálod már úgyis késő...

"JS-sel tipikusan machinalni akarod a DOM-ot, hogy dinamikus HTML-ed legyen, ne kelljen minden mozdulatnal ujratolteni a komplett oldalt. Ez vanilla JS-sel horror."

Nem olyan nehez az vanilla JS-sel sem (felteve hogy szarsz az IE9-nel regebbi bongeszokre). De nem trivialis megerteni, hogy hogy mukodik, az teny, de tenyleg csak erteni kell hozza.

Topiknyitonak meg: node az kuka. Szarul skalazodik tobb core-ra ami ironikus, mert tobb gepre amugy jol skalazodna. Aki bevezette nem gyoz tole megszabadulni.

Biztos én vagyok kőkorszaki szaki, de nekem a jquery mai napig elég, sőt, egyre kevesebbet használom azt is, de biztos, hogy van amiről nem tudok, hiányosságom, csak sose futok bele. És nem, nem új js eszközöket használok a jquery kiváltására, egyszerűen csak megtanultam pár alapot abból is, és tényleg nem futottam még bele abba, ami ne működne.

Node-os kommentedhez: ez trend-szerű, amit írsz? Pár éve amikor indult viharosan vette mindenki fel mint jújdejót, most meg láthatóan kevesebb cégnél látom használatban, több cégnél láttam java és php helyett kutatási project-ként váltást node-ra, majd 2 év múlva nyom nélkül még csak nem is beszélnek róla, de egyáltalán nem reprezentatív mérés, csak érdekel ez lehet-e mögötte.

Nem te vagy a kokorszaki, az angularosok meg a reactosok jarnak tevuton.

Pedig próbálkozom megérteni, hátha én nézem rossz szögből, és mégis teherautó, de mindig olyanba futottam csak bele, amiről megmutatták, hogy ez-az milyen jó funkció (2-3 dolog), mindegyik igazából 10 alatti óra fejlesztéssel megoldható, egy framework független lib-ként. Értem, van haszna sok jó dolognak együtt, de amikor a legtöbben tényleg csak épp ezt-azt használnak belőle...(nem reprezentatív minta, megintcsak)

Ahogy olvastam a lichess.org ezért használ pl. snabbdom-ot.
--
♙♘♗♖♕♔

> Pár éve amikor indult viharosan vette mindenki fel mint jújdejót...

Vegre felnottek a hipszterek is?

De. A reaktiv komponensekhez kepest az "aggassunk mindenre change / click" eventet horror.

Ez pont a rossz megkozelites.

<select onchange="MyClass.someFunction(this);" ... >

mint html attribute sokkal elegansabb

Dehogy elegánsabb. A HTML kód az markup, nem a viselkedést (JS), és nem a kinézetet (CSS), hanem a logikai struktúrát kell leírnia.
Ezek szerint te szereted az inline style-okat is.

Ez ilyen "valaki egyszer azt mondta, es azota ezt mantrazzuk" szoveg.

Ezzel szemben a valosag az az, hogy szinte az osszes tobbi GUI leiro nyelv inline layoutot es inline esemenyvezerlest tartalmaz, csak az elbarmolt HTML-nel "nem ajanlott". Ld:

https://en.wikipedia.org/wiki/QML
https://www.xamarin.com/forms
https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language
https://www.adobe.com/devnet/flex/quickstarts/coding_mxml_as.html

Nyilvan, az, hogy a HTML az alapjaitol el van baszarintva ahhoz, hogy GUI leiro nyelvkent lehessen hasznalni, az nem zavarja a verpistikeket, hogy tapsikoljanak oromukben, mert elhitettek veluk, hogy kezi szarlapatolas helyett milyen meno dolgot is csinalnak.

Szerk:

Legjobb, mikor indirekt van rakotve az esemenykezelo az id-re, ja nem a class-ra, ja nem, tobb class egyuttesere, ja nem, hanem egy CSS selectorral van raaggatva a viselkedes. Aztan meg probald meg megtalalni, hogy epp mi is triggerelte az adott viselkedest. Ahelyett, hogy odatenne az ember azt az egy szem contollert, hogy a masik paraszt is lassa egyertelmuen, hogy mi a fene is tortenik. De neeeem, hiszen nyilvan vannak olyanok, akik szeretik szopatni magukat, en viszont inkabb dolgozni szeretnek, nem tokonloni onmagamat.

Mekkmesterek minden szakmában vannak :)
--
♙♘♗♖♕♔

+1

id-kat meg html-ben felejtsuk mar el. Kiveve ha 10000000%-ig biztosak vagyunk benne, hogy nem lesz az az elem ketszer.

Nem csak akkor, amúgy is el kéne felejteni az id-t, mert globális javascript változókat hoz létre.

Segítek: shadow dom :D

Cirka 10-15 ev kellett csak hozza nekik, hogy implementaljanak vegre valami komponens kezelest... mondjuk meg nem probaltam, de a jelenkori webes technologiakbol kiindulva valoszinuleg ezt is szarul implementaltak :)

> a jelenkori webes technologiakbol kiindulva valoszinuleg ezt is szarul implementaltak :)

Jól gondolod, az eredeti shadowdom specifikációt már át is nevezték v0-ra, elavultnak nyilvánították és kiadták a v1-et (ami persze nem kompatibilis az előzővel): https://caniuse.com/#search=shadow%20dom%20v1
(V0 is scheduled for deprecation starting in April 2018 and removal in April 2019.)

Polymer 2/3-at érdemes megnézni, nagyon masszívan épít a webes technológiákra, pár hete tartottam belőle előadást :) (kb. egy éve használjuk)

Link a slideokra / videóra, vagy nem hisszük el :)

Cégtelenitem, és kirakom githubra :)

thx - jó anyag :-)

A dolgozó népet szolgálom. Ha van esetleg ötlet, hozzászólás, hiba amit találsz, stb. akkor szólj bátran, és javítom.

Mi koze a shadow domnak az id-khoz, es hogy erdemes-e oket egyaltalan hasznalni?

Ezt ertem, azt nem ertem, miert volt ez a kommentemhez "segitseg"? Annyit allitottam hogy keruljuk a html id-k hasznalatat. Ahhoz hogy jon a shadow dom?

Szerintem azért írta, mert a shadow domként létrehozott komponensedben lévő id nem ütközik az oldalon lévő id-kkal és mivel komponensről beszélünk, valószínűleg nem akkora a layout, hogy az ismétlődős ezenbelül gondot okozhasson.

De amúgy teljesen egyetértek azzal, hogy ne használjunk id-kat, ahogy fentebb is írtam.

Koszi

Hat igen, ertem hogy lehet jo ez a shadow dom, de az id-k hasznalatanak ujrakezdese nem er annyit, hogy csak amiatt elkezdjem hasznalni. Ott vannak data attributumoktol kezdve minden amivel faszan meg lehet enelkul is kerulni.

Ha hozzáadod még a template-et, a custom-tag-et (mind böngésző támogatott) akkor eljutsz a webkomponensekig :) (polymer és társai).

Azért a data-attribute-al óvatosan:

$(".foobar"); 376,180 ops/sec
$("[data-foo='bar']"); 6,467 ops/sec

Jquery is tul bloat. De neha muszajbol azt azert hasznalom. Pl. webplugin amit talaltam hasznalja, etc.

A példákat végig scrollozva szerintem kevés olyan fejlesztő van, aki a jobboldali kódot olvasná/írná szívesebben.

Szerintem a jQuery elég jól eltalált API és nem nevezném bloatnak sem, kevés olyan feature van benne amit sosem használtam. (bár mostanában vdomozok, de ráz ki a hideg, ha régi jQuery-s kódba kell belenyúlni)

Hat akkor most talalkozol eggyel (en). Es a performance miatt. Jquery akar 100-200x lassabb is lehet, mint vanilla JS.

A kedvencem viszont az az angularos forEach amit a Safari ugy kioptimalizalt, hogy gyorsabb, mint a nativ JS foreach-ek/for in/etc. De minden mas bongeszoben tetulassu.

> Hat akkor most talalkozol eggyel (en). Es a performance miatt. Jquery akar 100-200x lassabb is lehet, mint vanilla JS.

Ez regi jquery eseteben igaz lehet (amikor meg nem volt nativ querySelector, igy js-ben volt implemetalva), de az uj verzioknal mar nincs akkora kulonbseg, sot akar gyorsabb is lehet:

var a = document.querySelectorAll('.alpha'); 261,212 op/s
var b = $('.alpha'); 585,587 op/s
var c = document.querySelectorAll('[data-bravo]'); 146,960 op/s
var d = $('[data-bravo]'); 117,609 op/s
var e = document.querySelectorAll('[data-bravo="charlie"]'); 145,891 op/s
var f = $('[data-bravo="charlie"]'); 120,365 op/s

via https://jsperf.com/attribute-versus-class-querying

pont akartam kérdezni, hogy vajon a sima class selectornál milyen trükköt csinálnak, amitől gyorsabb lesz? Van egy lokális cache?

Valószínű getElementsByClassName-t használ ebben az esetben a jquery

Kérdés, hogy qsa miért nem teszi ezt meg, de nem egyedi eset, hogy a böngésző "natív" funkciója lassabb, mint a js-ben megírt (akár polyfill): Why are native ES6 promises slower and more memory-intensive than bluebird?

A tesztből hiányzik a getElementsByClassName(...), elképzelhető, hogy a jQuery (pontosabban a Sizzle, amit használ a selector kezelésére) azt használja ilyen esetekben.

Ritkan hasznalok querySelectorAll-t, altalaban getElementsByClassName a baratom (mint fentebb irtak a jquery is arra transzformal ki).

Ellenben erdekes, hogy a jquery mar akar gyorsabb is lehet, a konnyen rosszra megirhato nativ kodnal (nem az enyemnel :P ).

A példákat végig scrollozva szerintem kevés olyan fejlesztő van, aki a jobboldali kódot olvasná/írná szívesebben.

Kirakod őket egy-egy függvénybe és máris ugyanolyan egyszerű lesz a fejlesztőknek, mint a bal oldali.

--
Ickenham template engine

Miert nincsenek akkor ezek meg kiszervezve egy lib-be?

Kivannak = jQuery :)

A saját függvény a legjobb, annál rosszabb a lib, annál még rosszabb a framework.

--
Ickenham template engine

Milyen szempontból? Én szívesebben vennék részt egy olyan projectbe, ami már egy általam ismert libet használ (pl. az ajax hívásokhoz) és nem a saját függvényt ír.

Rengeteg oka van, röviden KISS, YAGNI, Occam's Razor, ..., vagyis több megoldás közül mindig az egyszerűbbet válaszd!

Hosszabban, a saját függvény azért jobb, mint a lib, mert:

1. Pontosan csak annyit tud és úgy tudja, ahogy neked jó.
2. Ha valamin változtatni akarsz, akkor könnyen megteheted.
3. Ha egy libből új verzió jön ki, akkor szükség lehet a kódod módosítására.
4. Nem tudhatod biztosan, hogy egy-egy lib adott verziója nem tartalmaz-e biztonsági kockázatot.
5. Ha a lib függ más libektől, akkor előfordulhat, hogy egy lib frissítése miatt egy csomó másikat is frissítened kell.
6. Ha a lib függ más libektől, akkor előfordulhat, hogy egyik lib egyik függősége összeakad egy másik libed függőségével. Rossz esetben emiatt előfordulhat, hogy el se indul a programod, vagy elindul, de hibásan működik, ahol a rossz verziót használja.

Még biztosan lehet sorolni, hirtelen ennyi elég szerintem.

--
Ickenham template engine

A gyakorlatban a projecteknél akik saját maguk próbálnak mindent megírni:
- 0 dokumentáció
- Fél év múlva már a project tulajdonosa se tudja mit hogyan kéne használni
- 0 tesztelés
- Böngésző inkompatibilitás
- Értelmetlen hibaüzenetek
- Legalább annyi biztonsági hiba, mint a publikus libeknél

Ezek teljesen függetlenek attól, hogy használsz-e lib-et vagy sem.
Ha egy fejlesztő csapat úgy dolgozik, ahogy leírtad, akkor ugyanígy fog libek nélkül is és libekkel is.

--
Ickenham template engine

Ez igaz, de nem mindegy, hogy azok a részek nincsenek ledokumentálva/tesztelve, amikhez nem kell hozzányúlnom vagy az a lib amit használnom kéne.

Azzal is vitatkoznék, hogy az mennyire felel meg a "KISS, YAGNI, Occam's Razor..." feltételnek, ha saját magad fejleszted le az ORM/Routing/VirtualDOM libeket, ahelyett, hogy a meglévőkből választanál.

Ha pontosan ugyanazt készíted el, ami megvan egy külső lib-ben, akkor ugyanaz a bonyolultsága a két megoldásnak.
Ha egy sokkal egyszerűbbet készítesz el, akkor sokkal kisebb lesz.

Ha az a feladatod, hogy rövid idő alatt csinálj meg valamit, akkor sok esetben az nem megoldás, hogy saját magad fejleszd le magadnak nulláról az adott funkciót. Ha viszont az nem megoldás, akkor a következő legkevésbé bonyolultat kell választani, ami a lib használata. Ha az sem megoldás a problémádra, akkor jöhetnek a több libek és a framework-ök.

Tehát nem arról van szó, hogy lib vagy nem lib, hanem arról, hogy ahol csak lehet, ott ne legyen lib.

--
Ickenham template engine

-1

https://en.wikipedia.org/wiki/Code_reuse (Reinvent the wheel)

Illetve fentebb pont arrol volt szo, hogy "ki kell tenni fuggvenybe, es ugyanaz mint a jQuery". Utana mar csak egy lepes feltenni egy nyilvanos repoba egy namespace alatt == lib.

Ha beleolvasol abba, amit linkeltél, akkor láthatod, hogy a Code Reuse-nak is vannak fokozatai:
- saját, belső kódok újrahasználata,
- saját belső lib-ek használata,
- külső libek használata,
- framework-ök használata.

Vannak akik nem értenek egyet a Code Reuse mindenhatóságával, pl. Rob Pike:
"Code reuse results in dependency on the component being reused. Rob Pike opined that "A little copying is better than a little dependency"."

ki kell tenni fuggvenybe, es ugyanaz mint a jQuery

Ha pár dolgot kiteszel függvénybe, amit használsz, attól még nem lesz ugyanaz, mint a jQuery, ami egy-pár nagyságrenddel többet tud.

--
Ickenham template engine

> Kirakod őket egy-egy függvénybe és máris ugyanolyan egyszerű lesz a fejlesztőknek, mint a bal oldali.

Most akkor ugyanolyan egyszeru lesz, vagy sem?

Ha csak ennyi, hogy kirakod oket fuggvenybe, akkor azt miert ne tolthetned fel githubra, miert ne linkelhetne mas is? Hiszen csak ki kell tenni egy fuggvenybe, es ugyanolyan egyszeru a fejlesztonek.

Szoval nem ertem. Ha egyszeru, akkor a lib is egyszeru (leftpad), tehat semmi kockazat nincs benne (kiveve leftpad), szoval nyugdotan lehetne belole includeolhato JS libet kesziteni, hogy ne mindenkinek maganak kelljen copy-pastelgetnie a netrol mindenfele scripteket.

Persze, fel lehet rakni GitHub-ra, használhatja bárki más is.

Amit nem értesz az az, hogy az egyik esetben van cirka 5 fv-ed, amit magad írtál magadnak, jQuery esetben meg van pár száz, amit mások írtak mindenkinek (vagy maguknak).

--
Ickenham template engine

Hasznaltam sokat, ma mar fejbol megy :P

Igy van, pontosan erről van szó. Ha shadow dom-ot (és webkomponenseket) használunk, akkor egy csomó problémától megkiméljük magunkat.

Volt már olyan problémám, hogy többször kelett kitennem ugyanazt a DOM-ot kicsit más tartalommal. Tehát generáltam a HTML-t.
ID=PREFIX__ vagy valami ilyesmi volt...régen volt talán igaz sem volt :)

Nem

Mert a CSS ellajta a feladatat, inline css meg hosszu es csunya.

A JS-nel viszont sokkal jobb a html elemen onclick/onchange attribute es a csapatot is rakenyszeriti a scope-ok es JS class-ok helyes hasznalatara. A fuggveny es nevtere igy kenytelen lesz rovid lenni. Ahogy a parameterlistaja is egyertelmu. Meg debuggolhatobb is. Meg masik JS kodbol generalva is jobban atlatod mi hova kerult. Meg amugyis: angularosok nagy kedvence az "ng-click" ami nagyjabol ugyanez, kiveve hogy elhiszik a fejlesztok, hogy nem kell erteniuk a scope-okat.

JS-sel tipikusan machinalni akarod a DOM-ot, hogy dinamikus HTML-ed legyen, ne kelljen minden mozdulatnal ujratolteni a komplett oldalt. Ez vanilla JS-sel horror.

Vanilla-JS frameworkkel ;-) sem horror manapság már a dom manipulálása, és sok más "igazi" framework szolgáltatásoknak is van vanilla js megfelelője, lásd itt.

Megéri-e vanilla js-t tanulni?
Erről olvashattok itt.

--
Ickenham template engine

Azzal, hogy első nyelvnek javasolják nem igazán értek egyet, de lehet csak mert kellő tudásom nincs JS-ben. Jelenleg azt látom, hogy egyrészt az aszinkronitás jó dolog lehet BIZONYOS feladatokra, másrészt az, hogy a JS-ben kifejezett kín szinkronitást elérni eléggé megkérdőjelezi számomra azt, hogy első nyelvnek ajánlanám-e. Javítsatok ki, ha le vagyok maradva, van-e már olyan megoldás, ami tetszőleges, tényleg tetszőleges parancsokat eröltetetten szinkron módon futtat le (vicc, hogy magyarul ez pont az ellenkezőjét jelenti, mindegy :) )?

A react.js és általában a framework-ök kérdése egyben az absztrakció kérdése is, én webfejlesztőként semmit nem tudok a hardware-ek fizikai működéséről, hasznos lehetne, de nem futottam még bele olyan feladatba, ahol egyáltalán megérte volna belekezdeni fizikai hardware ismeretekbe mélyebben. Szerintem a legtöbb framework-nél az elterjedtség csak a kérdés, ha elég elterjedt, akkor megtanulva nem lesz probléma találni sok project-et, ahol azt használják, ha nem elég elterjedt, akkor egy egzotikus programnyelvként kell kezelni, amit megtanulva nem sokkal vagy piacképesebb, mint aki egy alig ismert nyelvet használ. A másik, hogy szerintem ha a sajátosságait, hibáit nem is, de egy react.js fejlesztőnek is érdemes ismerni a js+html+css működésének alapjait, http alapokat, de csak azért, mert még mai napig lehet a react.js-nek vagy bármelyik framework-nek hiányossága, aminél egy szintel alább kell nyúlni, és mert később egy új framework betanulását könnyítheti.

> Javítsatok ki, ha le vagyok maradva, van-e már olyan megoldás, ami tetszőleges, tényleg tetszőleges parancsokat eröltetetten szinkron módon futtat le

Van az async/await, de abból pont a tetszőleges kritériumnak nem felel meg. Ez számomra is eléggé kellemetlen megkötésnek tűnik. Miért kell mindenhol átírnom a function hívást await-re, ha bele akarok rakni egy adatbázis lekérdezést oda, ahol eddig nem volt?

Szerintem szekvenciális futtatásra többször van szükség, így a fordított, by-default sync és opcionálisan async szerintem logikusabb lenne. Pl. Python-ban a gevent így működik.

import gevent
import gevent.monkey
import urllib
import time

gevent.monkey.patch_all()

urls = ["https://google.com", "https://hup.hu", "https://index.hu"]

def getUrl(url):
	return urllib.urlopen(url).read()

# Sync

s = time.time()
results = {}
for url in urls:
	results[url] = getUrl(url)
print "Total bytes: %s" % sum([len(result) for result in results.values()])
print "Done in %.3fs" % (time.time() - s)

# Async

s = time.time()
result_greenlets = {}
for url in urls:
	result_greenlets[url] = gevent.spawn(getUrl, url)
print "Total bytes: %s" % sum([len(greenlet.get()) for greenlet in result_greenlets.values()])
print "Done in %.3fs" % (time.time() - s)

Output:

Total bytes: 493116
Done in 0.976s
Total bytes: 493792
Done in 0.260s

Az elmúlt évek alapján nekem is ez a tapasztalatom, látva, hogy a JS jelenleg majdnem minden ECMA kiadás után attól hangos, hogy na most végre lesz egy tiszta szintakszisú, tényleg mindenre kiterjedő szinkron megoldás. Megértem, hogy induláskor ez egy alapvetően eseményorientált nyelv és technológia kellett legyen, és annak jó is (bár ott is agyrém nekem, hogy adott részek nem köthetőek szinkron egymás utániságba), de pl. szerver oldalon nem igazán értem miben több az async egy többszálú programnyelvnél (tudtommal php, python, java támogatja, miért váltanánk akkor node-ra, mi nem jó ott?). Főleg úgy, hogy közben azoknál a feladatoknál, ahol a sync fontos lenne, ott nem lehet elérni egyszerűen.

Hangsúlyozom, keveset js-ezek, ha valaki cáfolni-kiegészíteni tud, tegye meg, azért vagyok itt. Kedvelem alapvetően a js szintakszisát, több eleme tetszik, de nem látom értelmét jelenleg az alapvető felépítésének.

"tudtommal php"

A PHP ebben hasonloan foghijas, mint a JS. Csak ott legalabb a koncepcio is fire and forget (amibe belefer tobbszaz parhuzamos fire and forget script egyidoben), nem egy single thread webserver.

Azért ha kell kezelni 20-30000 nyitott connectiont, az a mai napig problémát szokott jelenteni a Java-s világban (nem azt mondom, hogy nem lehet! csak hogy gyakran problémát szokott jelenteni, a default embereknek a default eszközeikkel), a PHP és hasonlókról pedig ne is beszéljünk ilyen kontextusban.
Szerintem a "node-ra váltás" mint olyan kevésbé értelmezhető, szerintem senki nem akar "váltani", max ebben vagy abban csinálni valamit.
Szerintem a jelenlegi node ökoszisztéma és közösség baromi jó, az elkészült kód többnyire lényegre törő és kifejező - nekem nagy felüdülés volt, olyan szívesen kódoltam bármit, mint anno dedósként Turbo Pascalban.

És a node jól / jobban kezeli a 20-30e connection-t?

Váltás alatt azt értettem, hogy komplett infrastruktúrákat is, de nagyobbrészt új fejlesztéseket már csak node-ban akartak indítani néhol, elvi szinten ezt mérlegelték, beszélgettek róla, new trendy fancy stuff jelleggel imádták nézni a node-ot.

Nem kicsit jobban, első körben pont amiatt kezdett elterjedni :)

Az, hogy milyen fejlesztést miben csinálnak, szerintem - értelmes helyen - a legkevésbé a nyelvi featureökön múlik. Mihez van embered, ők miben _szeretnek_ dolgozni, és ide kapcsolódik az, amit a fentebbiben írtam, hogy én nagyon szeretek js-ben szerver kódot írni és azok is akiket ismerek.
Abban is biztos vagyok, hogy ha kódert kellene keresnem valami fasza cloudos projekthez, akkor ha node.js/go embert keresnék (java, php, stb-vel szemben), akkor nagyobb eséllyel találnám meg azt, akit keresek (érdeklődés, technológiai naprakészség stb szempontjából).

Megerősítést nyert az a kevés ismeretem a node terhelhetőségéről, ez eddig oké, de itt most nem meglévő termék további életútjáról, vagy csapat fejlesztéseiről van igazán szó, hanem arról, hogy egyértelmű superior-e a javascript, mint webszerver, tágabban nézve az async felfogás. (Bár lehet más ok is első nyelvnek javasolni, eltértem persze a főtémától, elnézést érte.)

Nem mondanék ilyet, hogy egyértelmű superior.. van egy (jó pár) use case, amikor igen (webes környezetben több), nem véletlenül jöttek be más nyelveknél is ezek a feature-ök / kiegészítések, legújabban a reaktív dolgok.
Go azért keményen odacsapott a szerver oldali superior értelmezésnek :)

Ha a nyers erő érdekel, akkor a TechEmpower évente tesztel egy rakat web framework-öt.

A NodeJs jelenleg 20% körül tanyázik a leggyorsabb(ak)hoz képest. Ami azért még elég jó, ha pl. összevetjük egy Laravel 0,1% vagy egy Wildfly EE7 2,4%-ával.

--
Ickenham template engine

Azért a nodejs-t nem mondanám frameworknek, így nem fair az összehasonlítás.

Az undertow meg a netty sem framework, csak HTTP szerverek. Mégis sokkal-sokkal gyorsabbak a NodeJS-nél, sőt, a top 20 legygyorsabból 10 JVM-en fut.

Ott van az eredmény első oszlopában, hogy mi a típusa: web alkalmazás Platform, Full vagy Micro framework.

Az összehasonlítás teljesen fair. Ez nem azt jelenti, hogy az első (X) darab jó csak bármilyen feladatra, bármilyen fejlesztő csapatnak, bármilyen költségre, ... Sok összetevő van ami alapján lehet válogatni, ezek közül csak egy a sebesség, és nagyon sok esetben van fontosabb szempont is.

--
Ickenham template engine

A nem fair összehasonlítást a Laravel (full) vs Wildfly (full) vs node (plt)-ra értettem

Ami igazából nem fair itt az az, hogy az Undertow (2.4.0 verziójú a tesztben) ~93%, a Wildfly (8.2) EE7-ben meg az Undertow egy négy éves verziója (1.1.0-ás) van.
Nagy összegben mernék fogadni, hogy magas két számjegyű százalékot érne el a Wildfly EE7, ha 12-es Wildfly szerepelne a tesztben.

--
Ickenham template engine

Bookmark

+1

Azért eléggé limitált helyzetben van szükség 20-30000 nyitott connection kiszolgálására 1 gépről. Tapasztalatom szerint (hacsak nincs nagyon elbaszva a kód) az adatbázis jóval korábban válik korlátozó tényezővé, mint az app logics futtatása és az utóbbi skálázása jóval egyszerűbb is.

Attól függ hol dolgozol. 2018 amúgy is a real time dolgok éve.

+1

"na most végre lesz egy tiszta szintakszisú, tényleg mindenre kiterjedő szinkron megoldás"

Ezt hol hallottad?

Az async/await-től nem fog szinkron futni a kód, de nem is tudna, ugyanis a javascript modellje szerint mindig pontosan 1 szálon történik a feldolgozás, szóval nincs olyan, hogy vársz valami másra.

Ha szinkron alatt az a kérés, hogy közben biztosan ne történjen semmi, akkor while (valami != true) continue; :)

+1

Sztem pusztán azért ajánlják a kezdőknek, mert gyorsan látványos dolgokat lehet vele csinálni egy böngészőben, és ez számukra többet jelent, mint h általában a programozók mit gondolnak a "jó" nyelvekről és h a js mennyire felel meg ennek az elképzelésnek.

[Feliratkozás]

subs

Mivel ad nekem több pluszt az, hogy Node.js-t használok szerver oldalon, mondjuk egy PHP vagy Python-al szemben?

Hosszabb távon úgyis meg kell tanulni többféle nyelvet és frameworköt, de kezdőknek kényelmes lehet, hogy nem kell másfajta szintaxist fejben tartani, ráadásul ha valaki még azt sem döntötte el, hogy a frontend vagy a backend érdekli-e jobban, könnyebben próbálhatja ki mindkettőt.

Kliens oldalra miért jobb a React.js, mint hogy natívan JavaScript+HTML+CSS-el csinálom?

Nem kell feltalálnod a kereket százmilliárdodik alkalommal is.

Kifejtve: ha nem teljesen egyedül fejlesztesz határidő nélkül és a saját elképzeléseid alapján, akkor
(a) könnyebb új fejlesztőket bevonni, mivel van hivatalos dokumentáció -- te is könnyebben szállsz be mások projektjébe;
(b) a legtöbb feladatot számtalanféle logikával meg lehet oldani, amelyek közül ritka az Egyetlen Helyes Megoldás, így a rendszer által megvalósított megközelítés alkalmazásával nem kell időt pazarolni egymás meggyőzésére;
(c) a projektspecifikáció meg fog változni, és szükség lesz olyan fejlesztésekre, amiket a keretrendszer által már eleve kezelt módszerek lefednek;
(d) ha szükség van valami filterezhető adattáblára, vagy paraméterezhető dátumkiválasztóra vagy egyéb egyedi komponensre, azt jó eséllyel már megírta és közzétette más, és nektek csak be kell emelnetek;
(e) a keretrendszer tesztekekel erősített;
(f) a rendszer által szállított parancssori eszközökkel gyorsan készíthetsz prototípust és a tesztelési és buildelési feladatokat is már mind beállították -- pl. hot reloading, preprocessing, transpiling;
(g) a keretrendszerhez készített böngészőpluginekkel még könnyebb a fejlesztés (főleg a debug).

Természetesen minél többet ért valaki a natív kódhoz, annál jobb, de a webes fejlesztésnél is alapvetés, hogy állandóan képezni kell magunkat, minden irányban, főleg mert mire megtanulsz valamit, addigra már szinte el is avult.

Egyébként a React gagyi: a Vue a király. :) Ezt a rövidke Youtube tutorialt érdemes lehet megnézni: https://www.youtube.com/watch?v=FXY1UyQfSFw&list=PL55RiY5tL51qxUbODJG9cgrsVd7ZHbPrt

Op meg elmenekult a flamewar lattam :)

Sziasztok,
Szerintem alapból a webfejlesztés egy kupleráj.

" olyan szinten átláthatatlan, spagetti kód volt, hogy hamar elvette a kedvem az egésztől "
Szerintem ez nem nyelv függő hanem programozó kérdése. Mennyire igényes a saját munkájára, mennyire szorít a harátidő, vagy nem is igazán ért hozzá csak stackoverflow-ról bemásolt valamit.
Bármelyik nyelven lehet írni átláthatatlan spagettit.
+ Sok helyen csak azt emelik ki, hogy a JS objektum orientált, de azt kevés helyen látom, hogy a prototype based objektum orientált programozás nem a classic C++ objectum orientált programozás.
Alma körte.

"Rengeteg oldalon azzal találkozom, hogy első programozási nyelvnek ezt ajánlják, meg szerver oldalra, Node.js és társai."
Ami nálam a node.js mellett szól, hogy a cliens és szerver oldalon egy prognyelvet kell használni. Sokszor volt, hogy nap végére már azt sem tudtam milyen syntax-al kell programozon és, hogy épp melyik fileba milyen prognyelven írok. (Perl - SQL - PHP - CSS - JS - Jquery) Egyébként ha nem full-stack az elvárás és van külön ember a backend - frontendre akkor meg hát ki mit szeret vagy mi a cégen belül a támogatott, mire vannak skillek.

Hogy miért keretrendszer és nem natív akármilyen kód.
Jellemzően olyan problémákba futottam bele amikre keretrendszerek már adtak megoldást. Nem nekem kellett időt pazarolnom az alapok kialakítására. Normálisabb keretrendszerek security szempontból auditáltak. Keretrendszerek meghatározzák a programozási stílust, így nem kell minden egyes kolegának újra feltaláni a kereket.
Az igazi előnyeit akkor lehet megtapasztalni ha nem egyedül fejlesztgetsz valami alkalmazást hanem egy csapat részeként kell alkotni valamit.

+1

+1

+1

A node.js használatának előnyeihez sorolnám azt, hogy amellett, hogy a programnyelv közös, a megírt kód, a használt libek és keretrendszer is lehet közös. Előnyös az egyébként kliensoldalon renderelt oldalak esetén például.