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

Internet: PHP, CGI, stb.

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!

  • 4097 megtekintés

( nxu | 2018. 04. 12., cs – 12:22 )

> 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.

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)

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.

> 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.)

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.

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.

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

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?

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

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

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.

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

( cherockee v | 2018. 04. 12., cs – 12:51 )

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.

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

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

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

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.

( BehringerZoltan | 2018. 04. 12., cs – 13:30 )

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.

( Wabbitseason v | 2018. 04. 12., cs – 15:23 )

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=PL55RiY5tL51qxUbODJG9c…

( Hevi v | 2018. 04. 13., p – 21:39 )

Op meg elmenekult a flamewar lattam :)

( raavi | 2018. 04. 17., k – 10:03 )

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.