How it feels to learn JavaScript in 2016

HUP cikkturkáló

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717d…

"No JavaScript frameworks were created during the writing of this article." :D

  • 11100 megtekintés

( sunmao v | 2016. 10. 05., sze – 13:40 )

Köszönet érte! Többször hangosan felnevettem, aki foglalkozott már ezekkel az át fogja ezt érezni. :D

Valahol a cikk 20%-ánál éreztem visszatérni azt a viszketést a tarkómnál, amit a startup rendezvényeken és hackatlonokon éreztem néha, és azóta is maradtam a jquery-nél, mert hogy nem volt vele bajom (súgok, üzleti szoftverekkel foglalkozom, js csak frontend nálam). Kiváncsi lennék, hogy manager szemszögből a legacy library-k (amik itt kb. félévente tonnaszám termelődnek ki így) támogatása mekkora overhead-et jelent, és az újak betanulása is. És hogy ez megtérül-e, vagy csak jól esik új dolgokkal játszani production környezetben? :)

Szerk.: "-Ever heard of Python 3?" ezt mint punchline nem értem, nem vagyok képben python-ban.

részben off, de a "its {{year}} now!" kijelentésre, vagyis inkább érv-helyettesítésre hangos röhögéssel tudok csak válaszolni politikai-szociológiai vitákban is, itt is csak ezt tudtam tenni...nekem semmi bajom azzal, ha valaki kutat-keres-kipróbál, de nagyon meglepne, ha egy új tech-be belerakott idő megtérülne a következő, új tech bevezetéséig, pusztán a fejlesztési órákból (/ developer). és újra: kutatni kell, csak termelni se árt.

Igazából /r/python-on találtam rá a cikkre. :) Szóval a Python közösségben korábban elég nagy vitát kavart a 2 vs 3 témakör. A Python 3-ban van pár visszafelé nem kompatibilis változtatás, és pár éve még volt egy rakás népszerű library, ami egyáltalán nem ment 3.x alatt, vagy épp csak elkezdték portolni rá, holott 2020-ban lejár a 2.x ág támogatása. Manapság már lecsendesedett a dolog, az az általános javaslat, hogy ha új kódot kell készíteni, akkor válasszuk a legfrissebb 3.x kiadást. De ha valami miatt mégis 2.7-et kell használni (pl. egy régi lib miatt), az se tragédia, csak pár formai szabály betartásával maradjon névlegesen 3.x kompatibilis is a kód. (Így ha később mégis 3.x alatt kell futtatni, akkor ne kelljen szinte semmin se változtatni.)

Amit a cikk is említ, a jqueryvel (és egyéb, tisztán html-manipulációra használt microlibbel) az a gond, hogy ahogy nő a "szoftver"* úgy egyre nagyobb lesz a spaghetti kód.

A sok lib, tool, stb. amit megemlít az több fő kategóriába sorolható, mindegyik kategória próbál valamit megoldani. Ez nem újdonság amúgy. Ha ismered a JavaEE (vagy ugyanígy a .Net) világát, akkor találkozhattál a problémával: kapsz egy hatalmas, HATALMAS toolsetet, egy szintén hatalmas dokumentációval, és azt sem tudod, hogy mit akarsz, vagy mit kell ezek közül használni. Itt azonban rosszabb a helyzet; egyrészt az elnevezések néha teljesen randomnak tűnnek (mimózaJS, cycle.js, etc.), másrészt mivel nem egy hatalmas projekt alá tartoznak, más-más megközelítést alkalmazhatnak.

Nem megyek bele hitvitába, hogy akkor react/angular/jquery/vanilla JS alapú stackben érdemes-e 2016-ban nekiállni valaminek, inkább másik oldalról fogom meg a dolgot. Szerintem (hangsúlyozom: SZERINTEM) el kell dönteni mit akarsz: ha valami content-heavy dolgot, ahol a JS mintegy "rásegítésként" van jelen (egy táblázat populálása async módon, vagy esetleg egy commentbox bonyolultságú dolog), akkor voltaképp majdnem mindegy, mivel állsz neki, lehet az jquery is. Ha viszont egy funcionality-heavy, mondhatni: Webappon dolgozol, ott már gyakori kívánság, hogy újrafelhasználható részletek, szép szeparáció, stb. legyen. Erre jó egy framework, legyen az a "régi" idők ExtJS-e vagy az újhullám react.

*:igazából már kifejtettem az előző bekezdésben. Amíg csak apróbb szkriptekkel variálunk, nem lesz spagetti kód, mivel nincs _sok_ kód, viszont amit bonyolódik az alkalmazás, egyszercsak jó lenne nemcsak szkriptelésként, hanem szoftverfejleszésként gondolni az egészre.

Na nézzük, hol tartunk így 2016-ban, cirka 25 évvel a web feltalálása után.

- Van egy nyelv, amit mindenki használ, de se nem igazán oo, se nem igazán funkcionális, se nem igazán teljes, se nem igazán átgondolt (lásd Date object és barátai).
- Van egy csomó lib, amivel mindenféle valós vagy vélt problémákat akarnak megoldani emberek, és vagy használhatók, vagy kevésbé.
- Van egy infrastruktúra, ami általában jó, de néha nagy gebaszt produkál.
- Ja, a nyelv nem type-safe, úgyhogy kitaláltak rá egy ... hmm ... wrappert, amiben lehet fejleszteni, amit aztán egy fordító lefordít az adott nyelvre (értitek, egy kvázi metanyelvből fordítunk egy szkriptnyelvre...)
- Van egy közösség, ahol minden super awesome, mindenki hero, minden shiny, new, bright, cool, de valahogy mégis vérízzadás egy-egy function-heavy dolgot összerakni.

Na meg ugye van itt még némi HTML, CSS, stb, ami kell, de

- Nincs olyan tényleg de facto standard toolkit, amivel a mára már standarddá vált UI komponenseket (inputok, buttonok, lista, table, stb, ami pl egy bármilyen desktop toolkitben default) szépen lehet kezelni
- Nincs hozzá tényleg használgató GUI builder (de ez már lehet, csak nekem fáj, végülis manapság úgyis a hand-crafted markup a menő...)

Nos, szerintem anno szegény Tim Berners-Lee nem egészen erre gondolt...

Vagy lehet, csak én vagyok élhetetlen troll, hihetetlen elvárásokkal, amikor arra vágyom, hogy így, 25 évvel a feltalálása után, lehessen már ugyan összerakni egy webalkalmazást mondjuk legalább hasonló szinten, mint mikor egy Qt / WinForms / WPF / Swing desktop szoftvert fejlesztünk...

Majdnem mindennel egyetértek a fentiekből.

Kétféle fejlesztői model létezik:
- Framework alapú. Itt minden integrálva van, ami csak kellhet az adott fejlesztéshez. Előnye, hogy szinte mindent készen kapsz. Hátránya, hogy nem flexibilis, ha valami nincs vagy nem úgy van megoldva, ahogy neked kellene, akkor jön a kínszenvedés.
- Library alapú. Kis eszközökből van összerakva. Előnye, hogy nagyon flexibilis. Hátránya, hogy neked kell összeválogatnod az eszközöket. Ha már össze van válogatva és integrálva, akkor általában nem nehezebb vele dolgozni, mint a framework-kel. Ilyenre más területen is sok példa van: Unix filózófia, VIM és pluginjei.

Egyébként vannak webalkalmazás készítéséhez framework-ök, ahol nem kell ismerned a HTML-t, CSS-t és Javascriptet. Több tucat van Java, PHP, Python, Ruby, Scala, ... nyelvekhez. (Javascript-hez is van, de ott ismerned kell a Javascriptet :-)

Na oké, de a vége mindnek az, hogy javascriptre / html-re / css-re fordítja a kliens oldali kódot. Nem?

Értem én a library alapú fejlesztést, de pl Java-ban is válogatni kell, mégis jobban van szervezve a dolog. C++-ban is van egy rakás lib, mégis valahogy van néhány, amik de facto szabványok, plusz a GUI toolkitekhez általában van (több) builder, meg van egy raklap IDE, amikkel igen szépen lehet építgetni a formokat, painless. (Lásd: Visual Studio, Qt Creator, stb)

A weben meg kissé úgy érzem magam, mint egy botanikus kertben, ahova összehordtak mindent, aztán ott hagyták burjánzani évekre kertész nélkül...

Na oké, de a vége mindnek az, hogy javascriptre / html-re / css-re fordítja a kliens oldali kódot. Nem?

Így van, ahogy a QtCreator is lefordítja a kliens oldali kódot a cél rendszernek megfelelő kódra. Egyik esetben sem kell ismerned semmit sem a cél rendszerbeli kódról.

a GUI toolkitekhez általában van (több) builder, meg van egy raklap IDE, amikkel igen szépen lehet építgetni a formokat, painless.

Itt is van egy raklap IDE, a Javasokhoz pl. Eclipse, IntelliJ, Netbeans, ...
GUI toolkitekhez is van builder, lásd pl. a ZK framework-höz a ZK Studio, vagy a GWT-hez a WindowBuilder (screenshot).

Az a baj ezekkel, hogy még mindig csak a periférián létező dolgok. Jó, eléggé impozáns a "kik használják" lista, de nem mondhatni, hogy ez a bevett mainstream, mint pl egy WinForms / WPF.

Vicces ez amúgy. Láttam már hasonló megoldást anno sok éve. Ott PHP-vel próbáltak valami hasonlót összehozni frontend-re is. Még egy teljesen fancy GUI builder is volt hozzá. Sose terjedt el...

Aztán ott volt a Dart. Értelmes nyelv, nagy lehetőségek... kuka.

Szóval csak nem bírunk kitörtni ennek a fránya Javascript-nek a bűvköréből, és talán ez a legnagyobb probléma. Meg az, hogy - ahogy egy egyébként maximálisan hozzáértő ismerősöm megfogalmazta - Javascriptben minden csak design pattern...

Az említettek csak példák. Java JSF-hez eleve van több editor, RichFaces-hez szintén és még hosszan lehetne sorolni.

Szóval eljutottunk onnan, hogy nincs egy se (nem lehet összerakni egy webalkalmazást mondjuk legalább hasonló szinten, mint mikor egy Qt / WinForms / WPF / Swing desktop szoftvert fejlesztünk,
odáig, hogy túl sok van belőlük (nem mondhatni, hogy ez a bevett mainstream, mint pl egy WinForms / WPF.)

A javascript nyelvvel van pár gond, nade vannak alternatívák, amikkel tudsz .js-t készíteni, ez kb. annyi hogy az assembly sem kényelmes, de nem is azt írod közvetlenül.

Milyen toolkit kell? Millió toolkit van. Ezek közül van amik újak, van amig régiek de elhaltak, régiek de még élnek, stb stb. Azért mert most már kevésbé divatos a Delphi és nem tudsz egy TDBComboBoxot rádrag'n'droppolni egy formra, azért még nem áll meg a szoftverfejlesztés, hanem meg kell tanulni, hogy akkor mi az új tool.

Szerinted mi a standard C++ toolkit mondjuk desktopra? A wxWidgets, vagy a gtkmm, vagy a Qt? Esetleg fltk, fox, és akármennyi ami még elérhető? Mi a standard C++ toolkit webre? És a csapatban a designer mennyire tudja átszabni ezeket a UI komponenseket?

Kellett már írnom Vaadin és hasonló cuccokkal is webappot, meg typescript/webpack frontendes java backendes appot is, és az utóbbi sokkal kényelmesebb volt, szóval szerintem ez abszolút megkönnyíti a munkát.

Csak annyi hogy haladni kell a korral, és folyamatosan tanulni. Sok régi fejlesztőn azt látom, hogy belesüppednek az 5 éve megtanult dolgokba, és mindenre ugyanazt a kalapácsot akarják használni. Mert végülis bármilyen toolt adsz, a feladatok megoldhatóak. Tudunk c programból is html-t generálni, socketeket kezelni, tehát azzal is össze lehet hozni egy webalkalmazást, de ez nem az evolúció csúcsa.

"Sok régi fejlesztőn azt látom, hogy belesüppednek az 5 éve megtanult dolgokba, és mindenre ugyanazt a kalapácsot akarják használni."

Van ilyen is.

Meg van olyan is, aki latja, hogy az epp aktualis csilli-villi megoldas miert nem lesz hosszutavon jo. Mert 5 eve megtanult egy technologiat/metodologiat, ami mar evek ota folyamatosan bizonyit, igy kicsit szkeptikus az uj, par honapos, vilagmegvalto dolgokkal kapcsolatban.

Ld. evek ota toljak a JavaScriptet, hogy igy milyen kiraly, hogy nincsen rendes type system, ugy milyen kiraly, hogy mennyire flexibilis, de alapvetoen ez is kezd strongly typed iranyba menni, mert azt a spagetti halmot, ami a JS-bol altalaban kijon, hosszu tavon lehetetlen/tul sok effort karban tartani.

A regi, jol bevalt megoldasok nem azert nepszeruek, mert mindenki begyoposodott. Hanem azert, mert bizonyos teruleteken mar bizonyitott.

A példád pont ellentmond annak, amit előtte írtál. A régi megtanult technologia/metodologia az a javascript, az az epp aktualis csilli-villi megoldas pedig a Typescript, Scalajs, ClojureScript, ...

Azzal a résszel egyetértek, hogy van ilyen is, meg olyan is.

Vannak akik "belesüppednek az 5 éve megtanult dolgokba", pedig már van jobb és vannak akik minden féle "epp aktualis csilli-villi megoldas"okat használnak eszük nélkül.
Illetve vannak olyanok is, akik az "epp aktualis csilli-villi megoldas"-okat kipróbálják, tesztelik és, ha beválik, akkor használják.

Szerintem az elég egyértelmű, hogy a js vacak találmány, mert nem lehet refaktorolható kódot írni, ezért is van pld. egy ilyen oldal: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-c… - de ha már készített valaki több .js fájlból álló projektet, akkor pláne lehet látni. Millióféle megoldással próbálják ezt elfedni, nekem a legszimpatikusabb megoldás jelenleg a typescript - ezért remélem, hogy ez fog győzni.

Az, hogy egy release készítéséhez webpackot vagy makefile-t használunk az már akár mindegy is lehet, de ha az ember vesz egy kis fáradtságot hogy megismerje a webpackot, akkor rájön hogy van amire azt célszerű használni. Pedig az még nem bizonyított, a makefile-ok meg igen. Meg a maven és a pom.xml is már bizonyított, ettől függetlenül jobban örülnék ha már rég a múlté lenne, és a gradle sem fenékig tejfel.

Nyilván kell valami backup plan, de azt továbbra is fenntartom, hogy a legtöbben azért late adopterek, mert nem akarnak újat tanulni, és nem azért mert úgy kalkulálták, hogy túl nagy a risk. Az új technológiákat divatos 'divatos'nak nevezni, ennek a szónak a rossz értelmezésével.

---

Aztán van egy másik filozófia, hogy már mindent kitaláltak régen, akár hátra is dőlhetünk. De: itt van pld. az OOP. Egy egyszerű szemlélet, hogy hogyan szervezd a programodat - vannak ezek az objektumok, akik a saját attribútumaikat a saját magánügyükként kezelik, és más objektumokkal meg üzeneteken keresztül kommunikálnak. Most meg kitalálta valaki hogy ojjé, legyenek microservice-ek, akik mit is csinálnak? A saját attribútumaikat ... blabla nem írom le megint. Szóval felismerjük a párhuzamot, hogy hát ezt a modellt már láttuk. De ez most ok arra, hogy ne tanuljunk meg dockert használni, ne tanuljuk meg, hogy hogyan deployolhatunk egy kubernetes felhőbe? Ha nem próbálod ki, akkor lesz egy akadémikus szemléleted valamiről, amiről csak olvasmányélményeid vannak.

Szóval nem azt mondom, hogy ész nélkül kezdjük el production-ban használni ezeket a rendszereket. De nézzük meg, hogy mik vannak, milyen problémát oldanak meg, és hogy ezek tudnak-e segíteni a napi munkában, a tesztelésben, az érthetőbb kód írásában, az egyszerűbb deployolásban, vagy bármi egyéb dologban.

Emlékszünk a 4 hónappal ezelőtti történetre, amikor egy nodejs library (ami kb. két számot adott össze vagy mifene...) megborított komoly production rendszereket egy név/névtér átnevezési probléma miatt? Ez a github-on "közésségben"/csapatban fejlesztett JS set-re építkezés nem a legjobb ötlet.

A docker-t is ilyennek vélem. Nem látjuk még mire jó (lehet generálni példákat, amiket eddig is megoldottunk), próbálkozunk, ideológiát gyártunk. Majd beleőrülünk a sokszínűségbe...

Mondjuk ez bárhol máshol is fent áll.

Ha hirtelen az Apachenál megsértődne valaki, s az összes commons Java libet törölné mindenhonnan (mert a leftpadet törölte a szerzője, minden repoból), akkor, ahol nincs lokális cache, törne...

(mondom ezt úgy, hogy nem szívügyem a js)
--
blogom

( laja | 2016. 10. 05., sze – 14:58 )

Ez tipikusan az öreg ember mentalitása: minek új technológiákat megtanulni? :)

De nem kell állandóan valami újat feltalálni csak azért, "mert meg tudom csinálni". Pont ez a régi mentalitás. A startupoknak igazuk van abban (már ha jellemző rájuk), hogy valós problémára/igényre kell válaszolni. A kényelmi szempontok már csak másodlagosak (lásd ingyenes appok), a "mert unatkoztam" pedig harmadlagos.

Akinek az az érzése, hogy a világ kész van...annak igaza van, nagyrészt kész vagyunk.

Hogy egy példát is említsek. 123 féle routing megoldás létezik a webes rendszerekhez, amik az URL alapján meghívnak egy függvényt. Mindegyik ugyanazt csinálja, csak kicsit finomabban, néha csak a formátum más. Én amiatt használom az AltoRouting-ot, mert régi és nem része semmilyen szuper frameworknek. Csak 95%-os megoldás, de megy vele minden.

> Akinek az az érzése, hogy a világ kész van...annak igaza van, nagyrészt kész vagyunk.

„A fizika fontosabb alaptörvényeit és tényeit már mind felfedezték. A jelen pillanatban az alapok olyan erõsek, hogy az a lehetõség, hogy új felfedezések valaha is kiszorítsák õket, rendkívül távolinak látszik... A jövõ felfedezései az eredményeket legfeljebb a hatodik tizedesjegyben befolyásolhatják.”

Tessék megkeresni, ki mondta, mikor, s mi történt azóta.
Azért ilyet kijelenteni erős...
--
blogom

Akkor csak en erzem, hogy kesz vagyok? Nem vagyom semmire, ami uj, kiveve a mestersegesen gerjesztett műigenyeket. Pontositok, nemregen vettem egy drónt, de eddig is eltem nelkule.

De ekkora embermennyiseget nem tud eltartani egy ujabb geforce kifejlesztese vagy egy 14nm-es procicsalad. Az airbnb pedig egy kenyelmi szolgaltatas, nem tart el 20e embert.

Szoval szerintem unatkozunk, lomha a vilag, uncsi van. Szabadidoben feltalalok egy uj js keretrendszert, termeszetesen a legjobbat! :)

És voltunk a Marson, elhagytuk a naprendszert, megoldottunk minden gazdasági egyenlőtlenséget, jólét uralkodik a bolygón, minden szociálisan érzékeny és/vagy gondolkodni vágyó egyén hátradőlhet, pukkanjon a pezsgő, és töltsük csőrre a puskát, tartsuk a fejünkhöz, utolsó kapcsolja a lámpát, good night for all.

Mi volt az utolsó olyan célod, aminek a megvalósításában valaki megállított?

Csináltuk a dolgunkat, a világ maga nem állt le, de ahhoz hogy a gazdasági lendület is megmaradjon, fogyasztásra van szükség. (Vagy mindenki hazamegy és a saját krumpliját eszi) Erre mondtam, hogy uncsi van. Kicsit demagóg lesz a mondat, de: senki nem vesz semmit, mindene megvan, pontosabban amik nincsenek, anélkül tud élni és nincs is rá pénze. Úgyhogy a nihilben marad.

"Mi volt az utolsó olyan célod, aminek a megvalósításában valaki megállított?" Ezt nem értem, miért kérdezed. De ha már kérdés, akkor válaszolok: Csomó hobbim van, űzöm őket, ha a gyerekek engedik. Nem állított meg senki, csak nem "éri meg" csinálni őket piaci alapon.

off ez már, ezért, és mert nem vagyok képben a témában (fogyasztási adatokban), nem reagálnék bővebben, de azt tapasztalom, hogy az emberek igényei nem eredendőek, hanem függenek az állapotuktól, ezért a fogyasztás lassulását-csökkenését-stagnálását megváltoztathatónak látom

Igényességgel lehetne ezen változtatni: "régen" (sic) egy vállalkozás irodát bérelt, vett sz.gépeket, lettek szoftverek, stb. Most mindezt nulla Ft-ból akarják megoldani. És nem azért, mert nincs, hanem mert sikk lett, nem költenek, tartalékolnak. A kiszámíthatóság (hiánya) miatt.

De tényleg OFF és nem szeretném a világnézetemet a Kedves Fórumtagokra zúdítani.

A startupoknak igazuk van abban (már ha jellemző rájuk), hogy valós problémára/igényre kell válaszolni. A kényelmi szempontok már csak másodlagosak

Nagyon sok startup éppen azért sikeres, mert:
1. meglévő problémára adnak sokkal kényelmesebb megoldást, mint a jelenlegiek (Prezi),
2. valami új dolgot készítenek, ami még nem volt (ebből is látszik, hogy nem vagyunk készen) (Üveg beton).

Rengeteg példát lehet említeni, hogy valami elkészült, már régóta megvolt, mégsem lett sikeres. Aztán az X. próbálkozó sikerre vitte, mert nem úgy gondolta, hogy már megvan (tablet).

Mi a régi és mi az új, az megint érdekes kérdés.

1967-ben "találták fel" az OOP-t, egy jó ideig nem volt sikeres, aztán 1990-től felkapottá vált.
Ezek után az FP-re is mondhatjuk, hogy felesleges ezzel az új paradigmával vesződni. Nos, nem egészen új, csak mostanában egy kicsit jobban elkezdték használni.
1930-as években "találták fel", de eddig nem igazán voltak alkalmasak a körülmények (kevés memória, lassú processzor, "kicsi, egyszerű" programok).
A körülmények viszont folyamatosan változnak, már másnak kell megfelelni (memória olcsó, processzor gyors, ráadásul több magosak, a programok "nagyok és bonyolultak" lettek). Itt már a régi/új FP-nek is egyre nagyobb a létjogosultsága.

( pehsa | 2016. 10. 06., cs – 14:51 )

"I need to display data on a page, not perform Sub Zero’s original MK fatality."

Reggel olvasva a buszon ezen sírtam fel hangosan!

( xclusiv v | 2016. 10. 06., cs – 16:42 )

Na igen. Fontosabb a legújabb sájni lóf*szok használata, mint a használhatóság.

Néha komolyan azt érzem, hogy 2006-ban használhatóbb volt a web, mint amit ezek a js-művészek 2016-ban le tudnak tenni az asztalra.
Vegyünk egy max. párezer karakternyi szöveget és néhány képet tartalmazó weboldalt, így 2016-ban. Ennek megjelenítése a mai "state of the art" módszerekkel több megányi lib betöltése után csak néhány másodperces homokórázásba telik, használat közben pedig már csak alig röccen meg a legújabb i7 procikon. Már ha csak az az egy darab browser tab fut az egész gépen...

mondok jobbat: mobilon ugyan ez, szerintem ott még rosszabb a különbség, mert kisebb a vas, és (sokszor) kisebb a sávszélesség, nem kell messze menni, egy facebook, egy átlagos híroldal...

az új js eszközök egy részében tényleg vannak jó ötletek, de összességében nem az marad meg, vagy az, hogy egyre jobb UX elemek vannak, hanem az, hogy akad, megáll, és teker a ventillátor (kicsit hasonló, hogy egy új win10-es laptop, ügyfél bekapcsolja, kér hogy telepítsem a programot, és keresem, hogy mi a frász fut a háttérben, hogy másodperces reakcióidők vannak, amikor elvileg ez egy friss gép, lehetett bloatware is, ezért csak felületesen hasonló)

Sőt, van aki nemhogy DOSBox-ot vagy x86 virtuális gépet futtat JavaScript-ben, hanem a MESS-t (ahol a sebesség kevésbé fontos, mint az, hogy pontos specifikációt adjon a programkód az emulált HW-ről) fordít C++-ból JavaScriptre...

És így már teljes rendszerek (HW/SW együtt!) lehetnek egy kattintással elérhetőek: https://archive.org/details/software

És persze, lehetne ehelyett azt mondani, hogy itt egy lista az országokról, mindegyiknél feltüntetve a három-négy informatikatörténeti múzeum, ahol néhányat meg lehet nézni ezek közül, többnyire szigorúan az üvegvitrin túloldalán. Vagy (még ha nem is a lehető leghatékonyabb módon) használhatjuk a JS futtatókörnyezetek újdonságait (mert azért egész máshogy fut egy JS ma, mint akár csak 5 évvel ezelőtt) és egy kattintással elérhetővé tehetjük ezeket.

És igen, 10 év múlva lehet, hogy a 15. generációs Core i5-ön 128G RAM kell majd hozzá (de az a többség számára elérhető lesz!), hogy a böngészőben futó JS motor futtasson egy C-ről transcompiled JavaScript qemu-t, amiben ott lesz egy Linux image benne a Wine-al, hogy elinduljon felette egy Quake III Arena demó. De ott lesz, egy kattintásra tőled.
Ha ebből az egész képletből kivesszük a JavaScriptet úgy, hogy nem cserélheted semmire, akkor pl. ezt elbuktad.

Hogy mások szarul használják? Várható volt. De még mindig jobb, mint mondjuk egy Flash.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az inkább arra vonatkozott, hogy mikorra lesz használható és Jason Scott mikorra tölti fel :) Egyébként AFAIK a DOSBox is emulálja az egész HW-t (máshogy nem futhatna pl. ARM-on), úgyhogy technikailag már meg van az x86 emuláció (a másik közel 1000 architektúrával együtt, amit a MESS/MAME tud), Win 2000 előtti dolgokat még mintha be is tudnál bootolni.
Azt nem tudom, hogy a qemu port hogy áll (úgy rémlik azon is gondolkodnak), akkor majd ipari mennyiségben tudnak előkerülni a 2000 utáni szoftverek is :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az nem egy rossz dolog, hogy komplett architektúrákat lehet vele lemodellezni (lehet rosszul fogalmazok), a nyelv maga szerintem nem rossz, a felhasználása az, mert míg az általad írt feladatnál indokolt, hogy nagyméretű legyen a kód, és összetett, és nem hatékony, addig egy webappnál berántott függőségek nagy része szerintem nem hoz valós előnyt (lásd fentebb amit írtam), nem látom, hogy tényleg spórolt volna magának munkaórákat, gépnek számítási időt, ha totálban vesszük az egész munkafolyamatot (tehát a tanulást, migrációt, új környezet debuggolásának lassúságát) vesszük.

De tény, úgy néz ki, hogy a js-el anno sikerült pont azokat az alapokat eltalálni, amik ugyan nem hatékonyak, de rugalmasak (és hosszútávon tényleg mindegy lesz a hatékonyság).

Most szívatod itt a népet vagy ez tényleg komoly? :) Nem azért lassú az oldal, mert annyit dolgozna a háttérben valami javascript, hanem mert a készítője direkt belerakott egy 2 mp-es késleltetést minden oldalbetöltéshez. :D


setTimeout(function() {
$j('#homepage_wrapper').animate({width: 'toggle'},{
duration: 500,
complete: function() {
$j('#homepage_wrapper').fadeIn();
$j('#homepage_wrapper').children('.inner').fadeIn('slow');
$j('#corner_right').css('display', 'block');
$j('#corner_right_bottom').css('display', 'block');
$j('#slidecaption').css('visibility', 'visible');
$j('#supersized-loader').css({display: 'none'});
}
});
}, 2000);

rosszul fogalmaztam, rendszeresen látom, hogy pl. ajax hívások változó válaszidejére az a megoldás, hogy hát, általában 3 sec alatt megjön a válasz, legyen 4 sec loading sign, és utána töltse be a tartalmat, ha mégse jött meg addigra, akkor ez van, pár másodpercig üres ablakot látsz majd...

(kiokosítom magam js-ből akkor, mert eddig azt hittem, hogy az async js részek is szálnak nevezendőek, azt tudom, hogy valójában nem azok, de nem találom rá akkor a megfelelő szót)

Remélem nem 2010 óta van ott az oldal, és csak a template a régi. Egyébként ebből általában következik, hogy se admin, se semmi, van az oldal és kész, két menüpontot is találtam ami üres volt, vagy csak nem töltött be. De szerintem ez kisebb gond, mint amikor 1-2 éve a norbi update oldala berántott több Mb js-t (nem vicc), és hozzá 1x Mb képet, gyakorlatilag 10 mp alatt no response a böngésző. Akkor még nem gondoltam, hogy ez általános lehet majd.

( hrgy84 | 2016. 10. 13., cs – 05:40 )

En egyelore ennek a szep uj JS vilagnak csak a hatranyait latom. Hogy bakker egy alapvetoen meg csak nem is NodeJS alapu app 100+ meganyi JS libet kotorjon ossze maganak az internet bugyraibol, az mar nem vicces, hanem szimplan csak szanalmas. A jol szeparalhatosagot es az ujrafelhasznalhatosagot meg nem az ujabb es ujabb JS libek fogjak elhozni, hanem az ertelmes kodszervezes, es a jol tervezett kodok. Nem azert van a jQueryhez is tobbszaz library, mert ne lehetne abban is szepen szeparalni, meg ujrafelhasznalhato kodot irni. Jo, nem mindegyik fog ugy kezdodni, hogy LofaszJS.createClass, de IMHO erre nincs is mulhatatlanul szukseg. Amugy ezekben a shiny new frameworkokben pont ugyanolyan konnyu spagettikodot irni, mint jQueryben. Aki eddig spagettikodot irt mas frameworkben, itt is azt fog, aki meg jolfesult kodokkal operalt eddig, annak pedig csak emiatt nincs szuksege uj frameworkre.

Egy kicsit mas: nezegetem ezeket a ReactJS, Angular, meg mindenfele clientside view renderer csodakat, es egyreszt viccesnek tartom oket, masreszt mar latom a usernyuglodeseket, hogy a gyengebb gepeken nem muzsikal jol a weboldal, akkor optimalizaljuk a kodot - olyan gepre, amihez hozzaferesunk sincs, csak kodos infoink rola ("haat... van rajta egy IE9", kosz). Es ettol a hideg fut a hatamon. Mert ha szerveren nem jo valami, azt ki lehet merni, ha sehogy mashogy nem tudunk rajta segiteni, ala lehet tolni meg vasat, vagy szet lehet skalazni, de egy soselatott gepen hogy mersz ki barmit is?
--
Blog | @hron84
Üzemeltető macik

Leirnad pontosan, hogy hogy jott ki a 100Mb cucc, miket adtal ossze, es a backend mit csinal? Mert a cikkben leirt pelda alapjan " displays the latest activity from the users" - akkor a backend kb csak annyit fog csinalni, hogy authentikalja a kerest, aztan a persistence store-bol kiszed 1-5-10-x rekordot, es egy jsonba csomagolva resten visszakuldi. A kliens meg megjeleniti az adatot egy filterezheto tablaban. Se a frontend, se a backend nem igenyli, hogy egy delutannal tobbet foglalkozzon vele az ember.

A cikk felsorol egy csomo technologiat, de ezeket nem egyszerre kell hasznalni. Ez kb. olyan mintha a java appodhoz hasznalnal haromfele dependency injection frameworkot, mert jo az es elfer.

Az app egy elég bonyolult logikával dolgozik, a felület formokat és nézeteket jelenít meg, a legbonyibb dolog benne egy varázsló, tele formokkal. Nem egyszerű, de nincs semmi, ami indokolná ennyi cucc behúzását.

A száz mega meg egy "du -sh node_modules" parancsra jött ki.
--
Blog | @hron84
Üzemeltető macik

Tehat mar nem a cikkrol beszelsz, hanem egy olyan projektrol amin dolgozol? Ahhoz nyilvan nem tudom megmondani, hogy miert hasznaljatok ezt vagy azt a fuggoseget, ezt inkabb a kollegakkal beszeld meg :) Nalunk a backendeknek joval tobb fuggosegeik vannak, mint a frontendnek, pedig van webpack, typescript, karma, ami kell.

Kedves, te most pontosan mi a halalrol is beszelsz? Te kerdezted, idezem:

"Leirnad pontosan, hogy hogy jott ki a 100Mb cucc, miket adtal ossze, es a backend mit csinal?"

Most akkor pontosan mit szeretenel, meseld mar el edes egy komam, mert teljesen osszezavarod az embert.

Igen, tudod a valos eletbeli kodok altalaban nem csak "authentikalja a kerest, aztan a persistence store-bol kiszed 1-5-10-x rekordot, es egy jsonba csomagolva resten visszakuldi", ezek az ugynevezett peldakodoknak a feladatai.

Es csak hogy felreertes ne essek: mivel nem vagyok fejleszto, elhiszem, hogy ezekre a dolgokra szukseg van (pontosabban, hogy a fejleszto kollegak ugy gondoljak: ezekre szukseg van), es en nem fogom megkerdojelezni a kollegaim donteseit, legfokeppen azert, mert nem ez a feladatkorom. En egyszeruen csak a trend miatt aggodok, amit ebben a konkret peldaban ertem tetten, de mar korabban is talalkoztam vele (csak kommentben nem fogok neked eletrajzot irni), hogy ezek a JS libek egyre nagyobbak, egyre szamosabbak es egyre kevesbe ertem, mi szukseg van rajuk.
--
Blog | @hron84
Üzemeltető macik

Hogy bakker egy alapvetoen meg csak nem is NodeJS alapu app 100+ meganyi JS libet kotorjon ossze maganak az internet bugyraibol, az mar nem vicces, hanem szimplan csak szanalmas.

Egyetértek. Attól, hogy rengeteg lib létezik JS-hez, nem kell mindet használni. Meg kell találni a szükséges legkisebb halmazt.

ReactJS, Angular, meg mindenfele clientside view renderer csodakat

Ezek nem csak kliens oldalon használhatóak, hanem szerver oldalon is. A felsorolásba belevenném a Mithril-t és még inkább az Inferno-t, ami az egyik legkisebb és leggyorsabb ilyen lib.
Egy nagyon nagy előnyük van kliens oldalon is az ilyen lib-eknek még (főleg) lassabb gépeken is. Egy-egy oldal dinamikus módosítása általában sokkal kisebb hálózati transzferrel, sokkal kisebb cpu használattal és sokkal jobb felhasználói élménnyel párosul, mint amikor az egész oldalt le kell cserélni minden egyes változásnál.
Pl. képzeld el ezt az oldalt szerver oldali megoldással: dbmonster.

Persze lehet ezt (is) rosszul csinálni, amikor valóban szenved a gép a sok felesleges js kód futtatásától.

Igazad van, tényleg jobb volt a világ, amikor a kódok tele voltak var that=this jellegű hekkeléssel, hasownproperty ellenőrzésekkel, mindenféle bloat kóddal ami azért kellett hogy osztályokat emuláljunk, és hogy a visszafele kompatibilitás is meglegyen, de ne kelljen túl ocsmány kódokat írni. Jobb volt, amikor ebben a káoszban egy IDE se tudott rendesen eligazodni, hogy segítse a kódkiegészítést, refaktorálást, stb.

Tényleg rosszabb így, hogy lehet az ES6 sok jóságát, syntax sugar-t, modulokat, stb használni, és nem kell aggódni külön amiatt, hogy a kód elfusson IE9-en, mert a babel megoldja.

Saját tapasztalat: Irtóztam elsőre ezektől a komplex toolchainektől, mert meg kellett ismerni és tanulni őket. Most, hogy ismerem, csak az előnyeit látom. Lehet, hogy tovább tart egy projektet felkészíteni, de onnantól hogy össze van rakva, nagyon kényelmes fejleszteni, tesztelni, hibakeresni, deployolni (erre van magyar szó?).

És kit érdekel, ha ott az a node_modules mappa többszázezer fájllal. Miért fájjon, hogy a toolchain kövér? Nem befolyásolja a végeredményt, sem azt, hogy a végeredmény hogy teljesít.

valahol kettőtök közt van az igazság, mert persze az új eszközök se véletlen születnek (van köztük hasznos), de azt te is gondolom tapasztaltad, hogy annyi tiszavirág project van js-land-en, mint sehol másutt (szubjektív, nem reprezentatív véleményem)...egyszerűen több a kisérleti gondolat, ami jó is, és veszélyes is

persze ettől még a nyelv lehet jó is, rossz is, sőt, lehet node.js-ben is függőségeket átnézve, saját hoston kezelve, értelmesen fejleszteni, stabillá tenni az egész folyamatot, de a cikkben leírt kb. egy év alatt 30 lib megismerése ÉS bevezetése előzőek helyére azért az öngyilkossággal határos

(és igen, jquery-ben is lehet szépen dolgozni, és biztos lehet ahhoz is jó eszközöket építeni amik még átláthatóbbá-fejleszthetőbbé teszik a kódot, és lehet teljesen új framework-re átállni, csak szerintem üzletileg fenntarthatatlan.)

> annyi tiszavirág project van js-land-en, mint sehol másutt

Szerintem az a helyzet, hogy a többi nyelv előnyben van pár évvel. Az a modern js, amire ráfeküdt a nép, és az az elvárás, hogy komoly és komplex kliensoldali alkalmazások készüljenek relatív új. Eközben java vagy php földjén megvan az a néhány nagy név, amik mellett felejtésbe merül az amúgy (szerintem) ugyanolyan sok tiszavirág életű projekt. Pár év, és le fog ülepedni a vihar itt is.

> a cikkben leírt kb. egy év alatt 30 lib megismerése ÉS bevezetése előzőek helyére azért az öngyilkossággal határos

Az. Nem muszáj leváltani mindent csak azért, mert. Van amit érdemes. Én pl most ezért gyúrok a react-re. Nem gondolom viszont, hogy jövőre a következő nagy "most épp ez a menő" vonalra felülök majd, mert a react vonalat se ezért kezdtem el tolni, hanem mert meggyőzött, hogy nekem jó lesz.

Bocs, de az ES6 kihasznalasahoz minek framework? A syntax sugarok nem mukodnek Angular/React nelkul, nativ JS kornyezetben? Nem tudsz modulokat csinalni pure JS-ben, vagy hogy van ez?

Amugy meg ezeket a kompatibilitasi mizeriakat nem usztad meg, ez bullshit. Az, hogy a framework elrejti eloled az o sajat ganyolasait a temaban, az nem jelenti azt, hogy ne kellene foglalkoznod a dologgal, hiszen a framework megoldasa nem feltetlen fed le minden scenariot.

Nem szeretem ezeket a finom jovoidoket, hogy "a babel megoldja" es ha nem? Sajnos a vilag nem lett jobb, csak most mar jobban belenyomjak a frontend fejlesztok fejet a valyuba, hogy ne legyen olyan latvanyos a problema. Meg az Edge-dzsel se jott el a szabvanykoveto bongeszok kanaanja.
--
Blog | @hron84
Üzemeltető macik

Azert kell az ES6 kihasznalasahoz valami, mert a bongeszokben az ES6 tamogatas meg nem terjedt el annyira, hogy lehessen ra epiteni. Szoval vagy tesztelsz egy csomo mindent, vagy elkezded osszevadaszgatni a shim-eket, ami hatha mukodni fog mindenhol, vagy keresel valamit, ami pld. ES5-re fordit. Vagy hasznalsz egy frameworkot beepitett shimekkel.

Szerintem egyikhez sem kell sok. De mostmar kivancsi vagyok. Hogyan fogsz hozza a feladathoz? Letoltod a w2ui legujabb verziojat, es bepusholod a verziokezelodbe? Es milyen modszerrel irod meg az automatizalt teszteket, amik megnezik, hogy a megfelelo klikkekre a megfelelo REST kerest kuldi el az oldal, es ha kap valami valaszt, akkor a kivant esemeny tortenik, pld. megjelenik xy adat a tablazatban?

Idealis esetben?

Megirom a REST API server oldali reszet, aztan aki szeret frontenddel szorakozni, az azt csinal amit akar.

Realisztikusan?

Megkapom a design-t a designertol, szentsegelek, elatkozom a JS-t, CSS-t, HTML-t ugy ahogy van, sirok egy picit, hogy tegyenek mar backendre, aztan nagy duzzogasok kozepette osszeutok valamit.

Tesztelni az ilyeneket alapvetoen valami mockolt datasource-szal, esetleg end-to-end teszttel csinalnam, de mint latszik, a frontend nem az en kenyerem, aki akar, az irhat async unit testet is, csak engem hagyjanak ki belole.

Nade pont ezzel a grid fuggosegeddel mit csinalsz: bepusholod a sajat code repodba, es az osszes egyeb fuggoseget is (pld jquery)? Vagy azt mondod hogy: "hat, a java eseteben mondjuk egy pom.xml-be irom be a fuggosegeimet, nem pusholom be a sajat git/egyeb repomba a forrasokat; a c programnal nem pusholom be a libc-dev tartalmat a sajat kod repositoryba".

A frontendnel hogyan oldod ezt meg? Mert vagy bepusholod, vagy elkezdesz hasznalsz valami toolt, ami development / build / test idoszakokra osszerantja neked a megfelelo fajlokat, sourcemapokat general development idoben, buildeleskor megcsinalja a .min.js fajlokat, ide/oda masol, verziozza a release-t, etc etc. Ha ezt az utobbit csinalod, akkor kell legalabb egy csomagkezelo (npm), egy grid implementacio, egy jquery, valami ami mondjuk minimalizal, ez mar negy fuggoseg. Es meg nincs a frontend letesztelve, bar ha irsz egy end-to-end tesztet a kedvenc nyelvedben, azzal mar el lehet lenni.

Azt megertem hogy nem szereted a frontend developmentet, en is nagyon orulok, hogy a less/css fajlokat nem nekem kell megirnom, a designer ezt megoldja :) De ha nekem kene megirni oket, akkor elovennek egy ujabb fuggoseget, pld ezt: purecss.io

Viszont tovabbra sem ertem, hogy a fenti scenariot hogyan lehet csak jquery hasznalataval helyettesiteni.

En ertelek, es igazat is adok neked valamilyen szinten, de azert egy build tool nem egyenlo millio frameworkkel. Masreszt a HTML+JS+CSS szentharomsagot meg mindig alantasabbnak tartom fejlesztoi szempontbol, mint az Adobe evekkel ezelotti Flash platformjat. Egyszeruen nem hatekony. Azok a dolgok, amik akkor mar meg voltak mar oldva, manapsag olyan nagy oromunnep kozepette vannak beharangozva...

Vagy tobb eszed van, mint egy otodikesnek, es felturod a netet, hogy hogyan lehetne a fuggosegeket CDN-rol kiszolgaltatni. Ha eleg keves fuggoseggel dolgozol, akkor nincs szukseged sem build toolokra, sem a repoba valo belekommittalasra. Csak hat ehhez nem divatkodernek kell lenni, hanem tapasztaltnak.

Ha nekem kellene a fenti grides oldalt eloallitanom, akkor feltolnam a jQuery-t, a jQuery UI-t meg a jQuery DataTables-t, es ennyi, a tobbi tortenelem. Ez konkretan 3 darab fuggoseg, amibol ketto egeszen vidaman johet CDN-rol, tehat lokalisan meg se kell legyen. Ennyi fuggoseg kezelesehez nincs az a build tool, ami hatekonyabb lenne a ket kis kezemnel.

Szerk: kozben kiderult, hogy a DataTables is elerheto CDN-rol egy ideje.
--
Blog | @hron84
Üzemeltető macik

Lehet így is, de ezzel még nem oldottad meg a tesztelést, a lintelést, több js fájl kombinálását, kódszűrést (console.log-ok), minifikálást, stb. Persze megcsinálhatod ezeket is a hatékony kis kezeddel, de egy idő után nem is lesz olyan hatékony ez.

Nyilván ez a toolokról szól, nem a libekről, de ha már van egy toolchained, akkor miért ne legyen egy olyan, ami a libeket is letölti neked, és mondjuk naprakészen tartja őket?

Plusz a te példád egy szimpla weboldal minimális scriptelését jelenti. Tény, hogy erre nem nagyon van többre szükség, amit te írsz.

De manapság már komoly kliensoldali alkalmazások születnek, ami nem oldható meg 1-2 fájl cdn-ről linkelésével. Sajnos a JS legnagyobb hibája, hogy alapból nem ad annyi eszközt mint akármelyik más nyelv, ezt kénytelen az ember mindenféle libekkel kiegészíteni, de hogy őszinte legyek csak mert 30 darab leftpad jellegű libet kell használni még nem lesz bloated a kód (jó tool megoldja) és nem is igényel komoly szakmai felkészülést pár ilyen lib ismerete.

Ezzel egyetértek. De a listához veheted az angulart, a react-ot, és a többit, ami a mostanában egyesek szerint "királyság", mások szerint ezzel van a probléma. Azok sem épp olyanok hogy száz helyről kell összebányászni hozzá mindent, amit meg mégis, azokat a régi nagyokhoz is össze kellett ugyanúgy.

Igazabol a problema azzal van, hogy tobb, mint 100 lib van csak arra, hogy megallapitsd, hogy egy objektum ures-e.

Hogy ezzel a problema?
- Projectek kozott nincs egyseges, megszokhato fugvenyhasznalat
- Rengeteg trusted third party
- Angular hello world leforditasahoz 32 000 fajlra van szukseg.

"- Angular hello world leforditasahoz 32 000 fajlra van szukseg."

Igen? És? Az, hogy már rég elfelejtettük, hogy ha fejreállunk, akkor sem léphetünk túl a Neumann architektúra határain (különben jön a penalty sebességben és erőforrás-igényben), az hogy már az absztrakció absztrakciójának az absztrakciójánál tartunk, az hogy olyan "appok", amik csak képeket meg szövegeket tesznek ki egy fehér háttér elé, több tíz, esetleg több száz mega ramot igényelnek (miközben a Q3A egy 700 MHz-s gépen meg ~128 MByte RAM-on max felbontással futott már anno 15 éve), azt tessék szépen megszokni.

We are the Web. Resistance is futile!

És jól jegyezd meg, csak az Hero, aki a legújabb, legtrendibb frameworkökkel dolgozik a legújabb programtervezési minták mentén, egy programozó (bocsánat, software engineer, ux engineer, sőt, APP HERO) az ideje legalább 50%-át a tudása naprakészen tartásával tölti (a.k.a. 1000-edik hypernew fancy best framework for the same problem), konferenciákra jár, ahol a többi hiperaktív hipszterrel ömlengenek a legújabb trendek fantasztikus dolgairól.

És ha te nem ilyen vagy, akkor vedd tudomásul, hogy (szerintünk) te egy dinoszaurusz vagy, sőt, nem is vagy igazi developer, mert nem követed a trendeket, és mint ilyen, legjobban tennéd, ha eltűnnél egy logikai buborékban!!!4444444négy!

Ezt a programozó, software engineer, ux engineer-t egy kicsit szerintem túl lett tolva. Vagy neked nem kellett mostanában UI-t fejleszteni, mert én bármit megadnék, ha végre lenne nálunk UX engineer, és
nem nekem kellene azzal szórakozni, hogy hogyan nézzen ki "szépen" egy képernyő, meg ikonokat rajzolgatni, meg hasonló baromságokat. Mert nyilván megoldjuk, de na...

Ilyen hülyeségeket nehogy terjessz rólam, még a végén valaki komolyan elhiszi...

No, de amúgy volt hozzá közöm. Hosszú évek alatt maszekként, aztán egy félőrült ötlettől vezérelve egy szoftverfejlesztő multinál Angular 1 + ami köré van rakva. 10 hónapig bírtam, aztán inkább eljöttem a cégtől (pedig amúgy nem volt rossz munkahely) vállalkozóként Qt-ben fejleszteni. Azóta boldog vagyok, köszönöm.

A nagy választéknak az az átka, hogy nehéz választani, de azért nem lehetetlen. Melyiket mennyien használják, mióta van meg, mennyire aktív a fejlesztése, mennyire értékelt, ...
Android-ra Fitness app-ból közel 300 van.
Mennyi lenne a jó, ha egy lenne, kettő, tíz?

(Szerk.: Ez a probléma már onnan indul, hogy programozási nyelvekből is szép számmal van.)

- Angular hello world leforditasahoz 32 000 fajlra van szukseg.

Ez miért számít? Ha azt írod, hogy milyen sok hely kell neki, vagy milyen sok ideig fordul, vagy milyen nagy lesz a végeredmény, ... arra azt mondom, hogy rendben, ez tényleg gáz. De ez?

"Igazabol a problema azzal van, hogy tobb, mint 100 lib van csak arra, hogy megallapitsd, hogy egy objektum ures-e."

A sok lib részben azért szület(het)ett, mert a régi (

Ha régi böngészőket kell támogatni, akkor esetleg van értelme használni ezeket, de még akkor sem, mert ott a babel. Fejleszthet a csapat a legmodernebb eszközöket használva, és meg lesz oldva, hogy a kód működjön elvárhatóan régebbi böngészőkön is.

Rögtön csak egy, vagy egypár trusted third party-ra van szükség.

Az pedig miért érdekeljen, hogy a toolchain, vagy a libek forráskódja sok fájlból áll? Hol számít az, ha a végeredmény egy kis bundle lesz? Érdekel egy c fejlesztőt, hogy a gtk, vagy a qt hány fájlból áll? Vagy a gcc maga?

Azért van a teszt szerver, amin minden release-ből fut egy verzió, hogy ha valami törik, akkor NEM az éles rendszert kell deguberálni,
hanem lehet a teszt szerveren, ha annyira speciális, akkor WORST CASE csinálsz az éles rendszerről egy DB dump-ot, és betöltöd a
teszt szerverre.

Igy van, én csak annyit mondtam. Éles szerverre minimalizálj mindent, és csomagold össze, ahogy szeretnéd, viszont éles szerveren ne akarj debuggolni,
merthogy nem ott kell. (tudom, hogy emberek php kódot szerkesztgetnek éles szerveren, de azért, mert ez valaki csinálja, még NEM JÓ!)

Hát úgy oldom meg, hogy amikor elindítom a buildet megmondom hogy production ready verziót kérek, vagy sem. Én sehogy nem oldom meg, megoldották már nálam sokkal okosabb fejlesztők amikor összerakták a webpacket, hogy nekem némi betanulás után csak egy pársoros config fájlt kelljen az igényeimre szabni, és automatikusan megtörténjen minden. Szép kényelmesen.

Ok rendben, akkor ti irjatok bele az index.html-be az osszes CDN-es hivatkozott fuggoseget az adott verzioval, ugyanez a css-re, meg irjatok meg a jol karbantarthato refaktorolhato es letesztelt .js kodotokat egy .js fajlban modularizalas nelkul. En mar ugy erzem eleget trollkodtam ebben a szalban.

+1

Most akarom átnézni, hogy van-e értelme a js kezelésben újragondolnom részeket, de ennél én azt biztonságosabbnak tartom, ha egy js fájlba összeállítva kapja a kliens az app-ot. Ha már build folyamat, ez nem kell, hogy azt jelentse, hogy nincs modulárisan, karbantarthatóan feldarabolva a program, függőségek nincsenek kezelve, ...

De hát itt a Facebook új csomagkezelője! Ez majd megváltoztatja az emberiség történetét.
https://code.facebook.com/posts/1840075619545360/yarn-a-new-package-man…

Persze ha ez nem felel meg az embereknek, akkor marad a jó öreg jspm: http://jspm.io/

Természetesen csak tréfálok.

Fuszenecker Róbert