JS-hez való viszonyod?

Internet, Közösségi média

Ebből élek.
6% (31 szavazat)
Utálom, tűzzel-vassal írtanám ezt a rákot.
20% (96 szavazat)
Ez a korszellem, elviselem, nincs vele bajom.
32% (154 szavazat)
Érdekel, foglalkozok vele.
16% (77 szavazat)
Csak az eredmény érdekel, leírom, egyéb.
26% (124 szavazat)
Összes szavazat: 482

( joco01 v | 2016. 05. 15., v – 09:54 )

A Closure+Polymer felállás nekem eléggé bejön, azért megvan a maga baja, de dolgozok a jobbátételén. Viszont olyat is ismerek, aki visszasírja a GWT-et utána, és azért még mindig jobban bejön a szerver oldal nekem is, de a kihívást nem adom fel :P.

--

( Jason v | 2016. 05. 15., v – 10:19 )

első ÉS második :D
Azért utálom, mert kiismertem...

( tmarkee | 2016. 05. 15., v – 10:33 )

Ez a korszellem, elviselem, nincs vele bajom + Ghostery :-D

( carlcolt | 2016. 05. 15., v – 10:39 )

App dev vagyok, webeztem is, nagyritkan most is kell webeznem. Latom hogy a hardcore JS munkak tudnanak egyedul tobbet fizetni annal, amit csinalok, tobbszor nekiestem, legutobb is mar node alapu apit akartam csinalni korabbi gyorsan hataridore konnyeden elkeszult PHP-sok helyett.

Aztan rajottem: nem vagyok annyira megszorulva, hogy JS-sel foglalkozzak. Lehet hogy egy PHP devnek jol jon a dupla penz amit a JS piac fizet, vagy egy game devnek akar az igen szignifikansan tobb penz is lehet, de nekem akkor is meredek, hogy ennyire kombinaltak a "mindent ujradefinialhatosag"-ot az event driven developmenttel, es mindemelle rendes namespace-ek sincsenek. Sok esetben egyszeruen _nincs_ proceduralis kod, vagy ha van, igen hideous syntax-szal ered el. A prototype based class-okat is szoktak meg szidni, de azt az egyet legalabb tenyleg meg tudnam szokni.

Es nem csak a nyelv a baj. A bower, az npm, a githubos open source libek amiket odabasznak peldakod nelkul, mert "jol nez ki a plusz sor az oneletrajzba'", de kozben gyakorlatilag hasznalhatatlan, meg mindemelle az a teny, hogy a normalisabb JS frameworkoknek is brutalis tanulasi gorbeje van, etc.

Ahogy a legtöbb szoftverfejlesztő, én sem úsztam meg teljesen a JS-ezést :-). De mindig olyan érzésem van, hogy "ezt most gyorsan összetákolom, aztán úgy csinálok mintha nem én csináltam volna". És ha valami komolyat kellene csinálni benne, akkor tuti, hogy valami rendes típusos nyelvben írnám a programot, amit aztán JS-re fordítanék automatikusan. Vagy kevésfelhasználós esetben még működnek a szerver oldali komponens keretrendszerek, azokkal is lehet haladni.

+1. Most kezdtem el azzal szórakozni, hogy régi demoeffekteket leimplementálok javascriptben. Gyakorlatilag az időm jó része azzal ment el, hogy elírásokat
javítgatok, amit csak persze on-the-fly jönnek elő. Aztán ilyenek, hogy de jó, van már class. És lehet benne class level változót csinálni? Hát, azt nem, nem
a következő verzióban.... no comment, nem véletlen, hogy egy csomóan typescript-et meg gwt-t használnak...

A static nem igazán jó pattern amúgy sem, legalábbis úgy, ahogy a ma elterjedt OO nyelvekben meg van valósítva. A valóságot sokkal inkább modellezi, ha a static membereket egy globális objektum példány szintű membereiként kezeled. Ruby-ban van ez talán a legérdekesebben megvalósítva.

Nagyon fontos, javascriptben a 

class

csak syntax sugar a prototype-based OO felett.

"a githubos open source libek amiket odabasznak peldakod nelkul"

Na ezt a PHP-rol is el lehet mondani. Sokszor csak ki vannak csapva a PEAR-be ezek a cuccok, erdemi dokumentacio nelkul, aztan ugy kell vadaszni a kodokat hozza koders.com -on.

En nem tornek palcat egy masik nyelv felett csak azert, mert szar munkat vegeznek benne. Meg C-ben is lehet szar munkat vegezni.

--
Blog | @hron84
Üzemeltető macik

( gelei v | 2016. 05. 15., v – 11:27 )

(x) Egyéb

Fejlesztőként hál' Istennek sosem kellett vele foglalkoznom.
Userként whitelist alapon tiltva van a legtöbb helyen.

Egyébként nem gondolom, hogy teljesen rák lenne. A rák nem ez, hanem bizonyos felhasználási módjai.

( BaT | 2016. 05. 15., v – 13:34 )

Egyéb: love-hate kapcsolatom van vele. :)

Felhasználóként szeretem, ha egy webalkalmazás a javascriptet okosan használva sokkal reszponzívabb, okosabb, kevesebb adatforgalmat használ. Nem szeretem, ha a javascriptet feleslegesen használva egy weboldal nehezebben használható, lassú (különösen mobilon probléma ez).

Fejlesztőként szeretem, hogy funkcionálisan programozható, tetszenek az ES6 újdonságai (aminek nagy része syntax sugar). Nem szeretem, hogy gyengén típusos (related), hogy az implementációs hiányosságokat polyfillel/transpilerrel kell pótolni.

( gazsiazasz | 2016. 05. 15., v – 13:16 )

A Javascript még csak-csak, de a JÁVÁT kéne kiírtani és a nyomát is beszórni sóval. Az információs társadalom rákfenéje.

Ezt a fajta hozzaallast kellene kiirtani es a nyomat soval beszorni. Az informacios tarsadalom rakfeneje.

Es ezt most halalosan komolyan mondom. Van egy csomo szoftver Java nyelen irva, amik tok jo cuccok. Van egy csomo, ami tok szar. De egyikrol sem a Java, mint nyelv tehet.

Kicsit olyan ez, mintha azt mondanam, nezd mar, mennyi gyilkos meg pedofil szuletett magyarorszagon, hat irtsuk mar ki az osszes magyart! Ok a tarsadalom rakfenei!
--
Blog | @hron84
Üzemeltető macik

( suti | 2016. 05. 15., v – 13:21 )

dzsunkaszkript, nemsokára mennek ők is a flash után a kukába/kapálni a havasalföldre a románcigányoknak.

( horvathlg | 2016. 05. 15., v – 13:27 )

Úgy vagyok a Javascripttel, mint Etus a kemény rock-al: Kapaszkodjon meg, szeretem!

Azért nem teljesen. Minden nyelvnek vannak hülyeségei, csak egyes nyelveknek több :). Konkrétabban a nyelven belüli meglepő dolgokra, belső inkonzisztenciákra, fölösleges de szükséges körökre és hasonlókra gondolok. A JavaScriptben vannak meglepő dolgok, a PHP már belső inkonzisztenciában is igencsak bővelkedik, stb.

Úgy is mondhatnám, hogy a "mire való" kétféleképpen értelmezhető: amire a fejlesztői szánták, és amire tényleg jó, és ez a kettő nem mindig vág egybe.

--

A PHP-t eredetileg html közé pár soros szerver oldali inline blokkok készítéséhez rakták össze. A javascriptet hasonlóképpen kliens oldalon a böngésző viselkedésének egy-egy apró kiegészítésére.

Mindkét nyelv jelentősen túlnőtt az eredeti célján, éppen ezért küzdenek tervezési problémákkal: az elején meghozott tervezési döntések egyáltalán nem fedik a mostani igényeket, de kompatibilitási okokból nem, vagy csak nagyon nehezen lehet változtatni rajtuk.

Éppen ezért nem értek veled egyet! A nyelv arra lenne igazán jó, amire a fejlesztői szánták - csak éppen a jelenleg elterjedt felhasználás nem egyezik azzal, amire a nyelv tervezve lett.

"de kompatibilitási okokból nem, vagy csak nagyon nehezen lehet változtatni rajtuk."

Szerintem nem volna olyan nehéz megoldást találni. Tény, hogy a JS foltozgatásával nem jutunk sehova, és ahogy írtad változatni nehéz. A megoldás egy új nyelv lenne, vagy legalábbis a JS egy új, az előzővel nem kompatibilis változata. Ennek párhuzamosan kellene élnie egy darabig a mostani JS implementációval, ami idővel kivezetésre kerülhet majd, ahogy egyre kevesebb weboldal használja. Vagy nem, ott is maradhatna a JS támogatás amolyan legacy pluginként a böngészőkben.

Csak le kellene valakiknek ülnie, és elkészíteni ezt a nyelvet, lehetőleg egy olyan csoportosulásnak, amiben képviselteti magát minden major böngésző fejlesztő. Érdekesmód a Google próbálkozását mindenki utálta (dart). Nem mondom hogy a dartnak nem voltak furcsaságai, de legalább valaki megpróbálta.

Ezért kell valami olyat kitalálni amit a böngészőgyártók is szívesen vesznek, akár őket bevonva, vagy rájuk bízva, hogy közösen kitalálják mi az ami optimálisan helyettesíthetné a JS-t.

De mondom, nem kellene egy teljesen más nyelvnek lennie. Ha fognák a JS-t, és megpróbálnák megjavítani úgy, hogy nem foglalkoznak a visszafele kompatibilitással, és ezáltal keletkezne egy új nyelv már sokat elérnénk.

Elég nagyot néztem, amikor megláttam, hogy az arrow function nem csak syntactic sugar, hanem a this is máshogy működik benne. Most ezt megint újra meg kell tanulni, ami jó, de egyszerre kell tudni két dolgot, két világ él együtt, ami annyira már nem jó. Amúgy transpilerrel, shimekkel megoldható, hogy menjen régi böngészőn, én ezt látom kisebb problémának.

--

( asusu | 2016. 05. 15., v – 18:12 )

ES6-ot tanultam meg, elötte csak "muszáj"-ból foglalkoztam vele. ES6 egy nagyon pozitív élmény lett a korábbi *****-hoz képest.

( uid_720 | 2016. 05. 15., v – 19:39 )

Szerintem a JS az egyik leghitványabb nyelv, amit valaha "terveztek", nem csoda, hogy annyi technológia készült a leváltására, beleértve az ES4-et is, amit végül dobtak.
De nem lehet elmenni amellett, hogy ma már minden eszközön van interpretere, és ez túl nagy piac ahhoz, hogy veszni hagyjuk.

Nem szeretem (=utálom), de használom (Ha lehet, TypeScriptről fordítok JS-re).

Fuszenecker Róbert

( xclusiv v | 2016. 05. 15., v – 20:29 )

Szavazatom: "Utálom, tűzzel-vassal írtanám ezt a rákot."

Bővebben kifejtve: ahol a munkám miatt kellett js kódot "alkotnom", ott megoldottam. Minimál, működik, problem solved.

Ahol problémám van vele, az a "civil" web-es felhasználás. Ahol arra használják amire való, ott nincs vele probléma. De sajnos többnyire nem ez a helyzet.
Manapság elszabadultak a js-mániások, akik mindent csak ebben képesek (vagy hajlandóak) megcsinálni. Ott is, ahol erre semmi szükség nincs. És mindezt megoldják szarul bloatware és procigyilkos kóddal, és persze 23 oldalról include-olnak js lib-eket, aztán mindig az a vége hogy az egész elmegy szarni.

Szóval no, thanks. Noscript, és ahol tényleg szükség van rá ott engedélyezem ha szükséges. Ha olyan a lap. Ha nem olyan, akkor keresek alternatívát, pl. ezért költözök éppen digitalocean-ről. Ezért is, de főleg ezért.

Amikor kikerül a 'bloatware procigyilkos kód' nem veszik észre? Ezek nem próbálják ki? Volt már olyan, hogy a lapos ventije elkezdett pörögni, úgy kellett utánakeresnem mi volt az ok, és hát az egyik fül alatt a böngészőben valami „sima szöveges” weboldal miatt.

Erős példa a HVG oldala, ami a nemrég történt frissítés előtt egy hulladék, lassú, erőforrásgyilkos szar volt, de most az új egyszerűen sokkal rosszabb mint eddig. Mégtöbb funkció, teljesen fölöslegesen, mivel egy sima híroldalról van szó, de szerintem még a szemmozgást is követik. Telefonomat kinyírja.

☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)

A szokásos probléma jellemző. Addig írják amíg elkezd működgetni.. oszt készen van. Avagy nem érezte a fejlesztő, hogy a 12 magos Xeonján az egyik mag elköszön amikor fut a kis kódja. No meg amennyi hulladékot include-olnak manapság (a legjobb amikor 4-5 helyen írva pár sor nem browser dependent kódot a cuccok fele simán kiszórható).
A másik meg, hogy ok, hogy egy oldal. De a facebook csingilingitől, a google bizbaszon át a Disqus cuccig megy minden. Plusz a reklámok. Mindez lehetőleg animálva. PHP is hasonló nyűggel küzd. Nevelni kéne kicsit a programozókat.
Nem tudom, hogy akarom-e tudni, hogy mit hoz a webassembly, ha ilyen a hozzáállás.
De őszintén az Adobe CEPHtmlEngine fiaskó (https://helpx.adobe.com/x-productkb/global/high_cpu_usage_cephtmlengine…) után hova nézzen az ember jó példáért?

### ()__))____________)~~~ ########################
# "Do what you want, but do it right" # X220/Arch

"Nevelni kéne kicsit a programozókat."

Csakhogy nem a programozók döntik el hogy mi kerül a weboldalra. Nem a programozó hibája, ha valaki kitalálja, hogy bizony legyen ott 20 social plugin, meg 5-6 tracking kód. Azt sem rónám fel a programozónak, ha nincs ideje a kódját optimalizálni, mert "minek dolgozol még rajta, hiszen működik"...

Nem mondom azt sem, hogy hibátlan mind. De néhány seggrúgást máshova is lehet(ne) kiosztani.

Igazából ez nem performance issue, de azért hozom példának: Telenor weboldala, bejelentkezel, az első oldal ami szembejön az egy listaoldal, ahol az előfizetéseidet láthatod. Itt kiválasztod az előfizetésed, és úgy jutsz ténylegesen el oda, hogy tudj is valamit csinálni. Sokaknak egy előfizetésük van, számukra ez egy extra felesleges lépés. Ésszerű volna tehát akkor mutatni, ha van mi közül választani. Meg is írtam javaslatként az ügyfélszolgálatuknak. A válasz az volt, hogy ez üzemszerű működés, és "üzleti döntés következménye". Ennyi. Hiába okos a programozó, hiába lehetne valamit jobban, kevésbé időpocsékolóan, néha csak robotmód meg kell csinálni amit mondanak.

Azért néha a programozók is megérdemlik a szégyenmozdonyt... Amikor production-ba megy a kód úgy, hogy a fooo_debug.js meg a some_framework_dbg.js jellegű, böszmeállat scripteket kell kitolni, mert csak... Néhány MiB fölösleges trutymó, csak azért, mert "nem tesztelték" a nem debug verzióval. Miközben azért volt idő a fejlesztő által kimondott "kész" és az élesítés között... Az meg külön élvezet, amikor szellősen, bő lére eregetett kommentekkel, és crlf-es sorvéggel örvendeztették meg a t. felhasználókat.

Kód optimalizálás indoklására mind a google, mind az Amazon háza tájáról jött már több forintosítható érv.

http://www.globaldots.com/wordpress/wp-content/uploads/2012/11/infograp…

Az "üzleti megfontolás" dolog pedig sajnos nagyon gyakran bullshit.
Hacsak nem tudnak mögé rakni egy A-B tesztet legalább.

### ()__))____________)~~~ ########################
# "Do what you want, but do it right" # X220/Arch

( radzeer | 2016. 05. 15., v – 20:30 )

Muszáj foglalkozni vele basszus!
Olyan technológia, amit nem tudok megkerülni. Versenyelőnyt nyújt az adott helyen az a része amit nézek. Viszont egy okádat maga a nyelv. Az egyetlen jó dolog a JS-ben az a chrome debuggere.
Szóval, 1+2+4 :))

( uid_17784 | 2016. 05. 15., v – 21:59 )

Csak hozzaallas kerdese; aki utalja, az nyilvan nem jol all hozza, ill. nem tud jol hozza allni bizonyos hianyossagok okan.

Vegul is nem kell hasznalni, hasznaljak masok, es ha mar hasznaljak, kihasznaljak; de ehhez erteni kell, nem csak a szintaxist, a celokat es az okokat is. Ebben a C++ sem kulonb, es a Python sem, aki nem erti a nyelvet, csak a szintaxisig jutott, soha nem fogja kihasznalni.

A Java meg szandekosan "szarra" volt tervezve, es szar is lett, de hat megvolt a maga pszichologiaja abban a korban, amikor megjelent, es hat sokan kivalasztottak maguknak, de ettol meg nem jo, csak hat a ronda felesegeket is szoktak szeretni, mert nem valja be senki, hogy egy ronda szar tehenet valasztott maganak egy eletre.

Hogy lehet jól hozzáállni ahhoz, hogy az

if (a = 2) alert("kettő");

mindig feldobja az ablakot?
Értem én, hogy annak idején értelmetlen módon, válogatás nélkül vették (vette át Eich) a feature-öket C-ből és Jávából, de ha akkor egy kicsit többet gondolkodnak (gondolkodik Eich), akkor bele sem kezd egy ilyen borzalomba.

Az egyetlen dolog, ami JS-ben tetszik, az a prototipikus öröklődés. Az zseniális, de nyilván ezt sem ő találta ki.

Fuszenecker Róbert

"Hogy lehet jól hozzáállni ahhoz, hogy az
if (a = 2) alert("kettő");"

Mi ezzel a baj? az a=2 kifejezés értékadás, a kifejezés értéke 2, a 2 pedig true-ish érték. Szerintem ezzel nincs probléma, sőt... mondj egy olyan nyelvet, ami nem kényszeríti ki, hogy boolean legyen az ifben lévő kifejezés végeredménye, és nem így működik (a darton kívül).

"a 2 pedig true-ish érték"
Itt van a baj. Mitől lenne egy szám igaz logikai érték?

"mondj egy olyan nyelvet, ami nem kényszeríti ki, hogy boolean legyen az ifben lévő kifejezés végeredménye"
Összekevered a boolean (true, false) és a truthy/falsy dolgokat. Nem kéne.

"amikor konvenció szerint igaz minden amiben van 1 értékű bit, false amiben nincs, vagyis 0."
Ez egy "C-s" konvenció csak. Csomó nyelvre nem igaz az, amit mondtál. Például Pascalra sem. Adara sem. Javara sem.
Scheme-re sem. Lispre sem.
Csakis azért létezik ez a konvenció, mert így volt könnyű implementálni a feltételes jumpot bizonyos architektúrákon.

Nem teljesen értem mi a baj ezzel, hogy a C megenged implicit ilyen konverziókat, vagyis igazából, ott az if alapból nem nullára tesztel? Amúgy hozzátenném, hogy a többi nem igazán definiálja, hogy néz ki a bool a memóriában, szóval, hogy ott miképp néz ki azt nem tudjuk, főleg nem a javaban.
A bizonyos architektúrák közé meg bele tartozik az x86, meg az ARM...

Lehet ilyen sql styleban kellene:
if is not null (a=2) :)

"Illetve minek kellene történnie, ha a 2-t mint értéket próbálnád egy ifben használni?"
A 2 nem logikai érték. Nem lehet if-ben használni. A logikai értékek: true és false.
Ennyi. Sem a 0, a -1, a 2, a NaN, a null, a nil, az undefined nem logikai értékek.

Mi az, hogy true-ish?
Értem én a logikát, 15 évig C++-oztam, és ott el is fogadom, de mit keres egy ilyen megoldás egy olyan nyelvben, aminek semmi hardverkötődése sincsen.

Mit mondana a feleséged, ha arra a kérdésre, hogy mész-e este inni, azt mondanád, hogy kettő.

Lehet, hogy konzervítív vagyok, de az if-nek kelljen már booleant megadni.
Mennyire szánalmas már az if (2 == a)... Code review-n azonnal decline.

Fuszenecker Róbert

"Mit mondana a feleséged, ha arra a kérdésre, hogy mész-e este inni, azt mondanád, hogy kettő."

Kettő sört iszok. Ezzel meg is válaszoltam, hogy megyek-e inni :)

Azt érted amúgy, hogy egy lazán típusos nyelvről beszélünk... És egy olyan koncepcióról, amit elég sok programozási nyelv követ. Tehát mindegyik szar? Melyik a jó? A C? Nincs is boolean...

Nem mindegyik szar. C-ben történetesen megértem ezt a viselkedést, hiszen nincsen bool.
De JavaScriptben van :-)

Attól, hogy az egyikben (védhető módon) benne van, miért kellene a másikban megtűrni? Azért, hogy könnyebb legyen eladni a C-programozóknak?

Bizonyos hibákat nehéz elmagyarázni a biznisznek (képzelt mondások):
* ja, azért tudta az ügyfél törölni a másik ügyfél adatát, mert véletlen egy helyen lemaradt egy "=" az if-ben.
* hát igen, bizonyos okokból két pozitív szám összege lehet negatív
* Az elsőt ki tudtuk volna szűrni, a másidikkal sajnos nem nagyon tudunk mit csinálni, hacsak nem kapunk újabb két hetet, hogy kijavítsuk a kódot

Én értem a műszaki okokat, de miért tartunk még mindig itt? Egy csomó hibaforrásnak ma már nem is szabadna léteznie.
Többek között meg kellene követelni a statikus és erős típusosságot. Lehet, hogy az ADA átesik a ló túloldalára, de még sokkal jobb, mint a "123aaa" + 1 = 124.

Fuszenecker Róbert

Pár tízezer kódsor után még egy kezemen meg tudom számolni, hányszor hibáztam ott, hogy az if-ben nem csak boolean lehet ruby-ban, js-ben. Persze az elején még benéztem hogy pl az "if 0" blokk az lefut Ruby-ban, de amint készségszinten használod a nyelvet, az ilyesmi már triviális, a gyakorlatban nem hibaforrás. Bikeshed effect.

"Mit mondana a feleséged, ha arra a kérdésre, hogy mész-e este inni, azt mondanád, hogy kettő."

Az alábbi vicc alapján, vélhetően csendben maradna :D 


Egy cowboy lovagol a feleségével. A ló megbotlik. Azt mondja a cowboy:
- Egy!!!
A ló megint megbotlik.
- Kettő!!!
A ló harmadjára is megbotlik.
- Három!!!
Leszáll a cowboy és a felesége. A cowboy lelövi a lovat. Azt mondja erre a felesége:
- Miért tetted ezt szegény lóval???
- Egy!!!

( BlinTux v | 2016. 05. 15., v – 22:26 )

Úgy látom azon kevesek közé tartozhatok, aki kifejezetten szereti ezt a nyelvet :)

( uid_17720 | 2016. 05. 15., v – 23:58 )

Fejlesztőként tűzzel-vassal, userként egyáltalán nem zavar (amíg nem arra használják, hogy a usert idegesítsék mindenféle felugró hülyeségekkel).

( NevemTeve | 2016. 05. 16., h – 11:04 )

Mármint JS=JavaScript a kérdés? Összevissza tákolt-bákolt vacakság. Pontosan úgy, ahogy mint minden más ebben az iparban.

( Cozi v | 2016. 05. 16., h – 11:42 )

Ha ennyire tákolmány a JS, akkor mit kellene használni helyette? Szeretném tágítani a világképemet. Egy ~20 másodperces rákeresés alapján azt látom, hogy nincs más, mint JS.

Aki eltüntetné, hogyan váltaná ki a honlap interaktív képességeit?

Tényleg érdekel!

Üdv, Cözi

Nem magával a nyelvvel van a fő probléma (bár van azzal is), hanem a felhasználási móddal. Az, hogy egy teljesen átlagos weboldalnál 20-30 request simán elmegy arra, hogy 20-30 különböző JS frameworkot, library-t, akármit behúzzunk, az a nem normális kategória.

Az, hogy teljesen statikus tartalom megjelenítéséhez JavaScript kell, az nettó kiszúrás, még akkor is, ha történetesen a saját munkáltatóm is csinálja.

Az, hogy egy teljesen átlagos weboldalnál 20-30 request simán elmegy arra, hogy 20-30 különböző JS frameworkot, library-t, akármit behúzzunk, az a nem normális kategória

Valóban. Értelmes webfejlesztő ezért használ Browserifyt, Webpacket, akármit, hogy 1 requestből ott legyen minden JS, ami kel.

A Browserifyről tudok beszélni. Egy build tool, ami arra való, hogy NodeJS modulokat böngészőben is lehessen használni, ez pedig magával hozza azt, hogy írhatsz require()-t a kódba.
Lényegében meg tudod írni rendszerezve, fájlokra osztva (egy "Class" vagy modul = egy fájl pl.) a kódot. Ahol kell valamelyik modul, nyomsz rá egy require-t, aztán a végén Browserify-jal buildeled, és lesz egy db (ugyan relative nagy) JS fájlod, ami 1 requestet jelent a 40 helyett, és nem lesz szívás a sorrenddel sem (hogy most akkor melyik JS fájl jön melyik után a script tagek listájában).

"ezért használ Browserifyt, Webpacket"

Én ezektől dobom el az agyam. Alapjában véve nincs baj, de annyi toolt kell megtanulni használni, együttműködésre bírni, stb. Lehetne ez a rész is egyszerűbb...

Én abban bízom, hogy a https2-vel már nem lesz annyira fontos egybecsomagolni a sok js fájlt, illetve hogy eljutunk oda, hogy egységes implementáció is lesz a böngészőkben az es6 importhoz :)

( szotsaki | 2016. 05. 16., h – 18:30 )

Épp egy perce néztem meg egy oldal forrását, benne egy JS függvénnyel. A kommentek mindent elmondanak... 


/**
 * Detect if the browser supports rendering emoji or flag emoji. Flag emoji are a single glyph
 * made of two characters, so some browsers (notably, Firefox OS X) don't support them.
 */

[kód]

/*
 * Chrome on OS X added native emoji rendering in M41. Unfortunately,
 * it doesn't work when the font is bolder than 500 weight. So, we
 * check for bold rendering support to avoid invisible emoji in Chrome.
 */

[kód]

// Chrome has issues comparing arrays, and Safari has issues converting arrays to strings.
// So, we create our own string and compare that, instead.

[kód, majd a rövid függvény vége]

--
The Elder Scrolls V: Skyrim

Többnyire ezért használ az ember keretrendszereket meg shim-eket. Persze van olyan, hogy tüzet kell oldani, meg hülye a böngésző, meg maga a keretrendszer is lehet bugos. De nekem pl. jQuery-vel és Polymer-rel nem igazán jöttek elő ilyen dolgok, szerintem nem ez az általános.

--

( Hevi v | 2016. 05. 16., h – 18:39 )

Sokadszorra vagok bele, de 200 sor utan mindig attekinthetetlenne valik. Lehet, hogy az en hibam, de probaltam mar igy is, ugy is, valahogy nekem ez a dynamic+weak type dolog nem a kenyerem.

Scriptelesre tokeletes(?), komolyabbhoz nekem viszont kellenek a type deklaraciok, hogy tudjam, hogy megis mit varjak az adott valtozotol. Semmi kedvem az egeszet fejben tartani, allandoan olvasgatni az eddigi kodokat meg veginkabb nem. Arra van a compiler, hogy az tartsa ezeket "fejben".

Szerk:

Szoval par soros scriptek bongeszoben: OK
NodeJS es tarsai: Nem OK

Gondolom nem veletlen terjedt el a microservice architektura Node-dal... Valami muszaj, hogy deklaraljon valami fix API-t, ha mar a kodban nem lehet.

Szerk2: amugy tudunk sikeres, nagy volumenu Node projectrol? Marmint olyanrol, amit nem kezdtek el atirni valami normalis nyelvre miutan megvolt az MVP.

Erre van valami forras? Lehet, hogy keverem a PP-t, meg a LinkedIn-t, de mintha valamelyiknel Ruby-t csereltek volna valamire. Szerintem keverem es a LI lesz az.

Meg ugye kerdes, hogy mi van Node-ban irva. Ha csak a webapp, az nem nagy cucc, gyakorlatilag csak a presentation layer a backend es a user kozt, ha viszont minden abban van irva, akkor le a kalappal.

PayPal:
https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
https://www.paypal-engineering.com/2014/04/10/excellent-opportunities-f…
Ezt is a PayPal csinálja: http://krakenjs.com/
Eléggé tolják a NodeJS-t.

Netflix:
http://techblog.netflix.com/2014/11/nodejs-in-flames.html
http://techblog.netflix.com/search/label/node.js
http://thenewstack.io/netflix-uses-node-js-power-user-interface/
Stb.

Azért ekkora forgalmú helyeknél a "csak a webapp" sem egy triviális dolog ám :)

Koszi, megnezem!

Nyilvan nem lefitymalni akartam a dolgot, a "csak egy webapp" reszt az uzleti logika hianyara ertettem. Ott tortennek inkabb a huncutsagok es ott jo, ha az ember kap egy kis tamogatast a fordito reszerol, foleg, ha refaktoralni kell, stb. Jobb, ha a hibak nagy reszet nem futasidoben kell levadaszni. Nyilvan megfelelo teszt lefedettseggel megoldhato az is, de meg mindig csak patkoljuk azt a lovat es emberorakat fecserlunk el arra, hogy trivialis dolgokra is tesztet kell irni, amit amugy automatizalni is lehet.

Szerk: meg azt is megengedem, hogy webappnak a Node jobb valasztas, mint a Java, _ha_ _csak_ a prezentacio a feladata. Foleg sok, es gyorsan valtozo A/B, MV tesztnel, ahol a kod eldobhato, el is fog dobodni, akkor meg minek szenvedjen az ember meg a tipusokkal is.

Node projectrol

hát úgy egy az egyben "node project" valszeg kevés van, főleg nagy volumenű. Node-ot heterogén környezetben használnak, több nyelven fejlesztett, microservices-szerű architektúrákban. Valamennyi node amúgy úgy tudom van pl. a paypalnál meg a netflixnél meg a spotifynál is.

( pink v | 2016. 05. 17., k – 10:58 )

Az irtanám szerintem rövid i-vel helyes.

( b | 2016. 05. 18., sze – 00:09 )

JS az itt mit jelent? Javascriptet?

--
GPLv3-as hozzászólás.

( uid_720 | 2016. 05. 18., sze – 20:49 )

Találós kérdés JS mestereknek: miért ezt írja ki:

[] + []
""

[] + {}
"[object Object]"

{} + []
0

{} + {}
"[object Object][object Object]"

Fuszenecker Róbert

Gondolom innen jutottál ide:
https://www.destroyallsoftware.com/talks/wat

Old, but gold.

Mindenesetre:
http://www.ecma-international.org/ecma-262/5.1/#sec-11.6.1

Azaz a lényeg: először kiértékeljük a bal oldalt mint összeadást, majd a jobb oldalt mint szorzást (szorzás jellegű kifejezést), és primitív értéket csinálunk belőlük.

Ha a jobb oldal vagy a bal oldal primitívje string, akkor konkatenálást végzünk.
Ha egyik sem string, akkor pedig számmá alakítjuk őket, majd összeadjuk.
A primitív értékké kiszámolást ez végzi:
http://www.ecma-international.org/ecma-262/5.1/#sec-9.1

Ezek szerint objektumoknál (az Array is objektum) a defaultValue-t adja vissza a primitív érték.
Ezeknek a szabályai:
http://www.ecma-international.org/ecma-262/5.1/#sec-8.12.8

Azaz mivel az összeadásnál hint nélkül hívjuk a toPrimitive-t, ezért a hint Number.
Azaz a valueOf és a toString metódusokat keresi az objektumban. Ha a valueOf visszatérési értéke primitív, akkor visszatér azzal.
Egyébként a toString értékével, ha az primitív.
Ha egyik sem primitív, akkor kivétel történik.

Nos, az Array típusra létezik a toString és a valueOf.
http://www.ecma-international.org/ecma-262/5.1/#sec-15.4.4.2
Az Array valueOf-ja az Object valueOf-ja.
Nos, az Object.valueOf értéke nem String típusú (hanem a bemenő adatot adja vissza ez esetben, azaz Array), ezért a toString lesz az érvényes.

Ez a toString tulajdonképpen egy join-t hív az elemekre.
A join definíciója:
http://www.ecma-international.org/ecma-262/5.1/#sec-15.4.4.5

Azaz üres tömb primitívje a "".

Az üres objektum primitívje még a kérdéses.
Itt is a toString lesz az érdekes. Ami az üres Objektumnál "[object Object]":
http://www.ecma-international.org/ecma-262/5.1/#sec-15.2.4.2

Azaz:
1. Két üres sztring összefűzése az eredmény, ami üres sztring.
2. [object Object] és üres sztring összefűzése
3. ????? Ezt nem tudtam kihámozni a specifikációból semmiféleképpen sem. Mivel az üres tömb primitív értéke mindenképpen String típusú (az üres karakterlánc), ezért nem lehetne itt számmá alakítást csinálni, szerintem ez egy runtime bug.
4. [object Object] és [object Object] összefűzése.

Elkezdtem összeírni a válaszom, ami lényegében csak teória lett volna, nem ismerem a JS belső működését, de aztán kicsit kutattam, és ráleltem erre a bejegyzésre:

http://www.2ality.com/2012/01/object-plus-object.html

Érdemes elolvasni.
Szerk: Aztán látom, hogy mások is megválaszolták már :)

( enpassant v | 2016. 05. 20., p – 08:23 )

Akik utálják azok valószínűleg nem programoznak funkcionálisan.
Funkcionális szemszögből nagyon barátságos és csupa vidámság javascriptben programozni :)

Ehhez tudom ajánlani a Ramda library-t.
Itt elolvasható, hogy miért jó a Ramda.
Könnyen ki is próbálható a Ramda REPL-lel.

Miért a Ramda-t javaslom és miért nem pl. az Underscore-t? Ebből a videóból kiderül, hogy az underscore nem jól csinálja.

Ez az egyik igazán komoly problémám a JS-sel, hogy mindenhez kell egy library.

Nem szeretem a javát. Másra is való. De ha le akarok ülni, és összerittyenteni magamnak valamit, nem valami nagy komoly projekten dolgozom, akkor nagyon sok esetben az amit az alap sdk tud elég rá, és nagyon ritka esetben kell akármi külső függőséget használnom.

Pythonban ugyanezt szeretem. PHP-ban szintén, ott is van amihez jó ha van külső lib, de anélkül is megvan az ember.

Nyilván mind a két megközelítésnek megvan a maga előnye és hátránya.
1. Minél több mindent pakoljunk az alapkörnyezetbe. Előnye: sokat tud alapból, hátránya: nagy.
2. Minél kevesebbet pakoljunk az alapkörnyezetbe. Előnye: kicsi, hátránya: alapból keveset tud

A script nyelveknél ez utóbbit célszerű választani, hogy ne növelje meg nagyon a méretét annak, amibe beépítik.

A framework meg a lib között jelentős a különbség: a framework diktálja az alkalmazásod architektúráját, a lib meg csak egy adott feladat megoldásában segít - ezért integrálható mindenhova.
A JavaEE például framework: nem te ágyazod be az alkalmazásodba az alkalmazásszervert, ha JEE technológiát akarsz használni, hanem a JavaEE framework diktálja, hogy hogyan kell felépítened az alkalmazásodat.
A frameworkök sok esetben nagyon rosszak, mert megkötik az ember kezét.

Így van, a framework eléggé megköti a kezed, a lib kevésbé, de az is megköti, ha magad írod, akkor függsz a legkevésbé bármitől.

Ismét odajutunk, hogy mindennek van előnye és hátránya. Az, hogy készen kapsz dolgokat az előny, mert nem neked kell megírnod vagy megkeresni a legjobbakat, összeintegrálnod ezeket, viszont megköti a kezedet, ha valami nem úgy működik, ahogy éppen jó volna.

Szerintem fejlesztői szempontból mindegy, hogy melyikről beszélünk. Én arról az alap funkcionalitásról beszélek amire építhet a programozó.

A string formázás hiánya pedig fájóan egyértelmű, emlékezz csak vissza a pár héttel (hónappal) ezelőtti hírverésre a leftpad incidens kapcsán. Nem szabadott volna problémának lennie, mert nem szabadna hogy szükség legyen egy 3rd party megoldásra ahhoz, hogy néhány nullával prefixeljek valamit.

Értem, hogy a JS eredendően egy scriptnyelv, és a tömörség volt a cél. Múlt idő. Már nem scriptnyelv, ma már komplex alkalmazásokat építenek benne, ideje hogy felnőjön a feladathoz. Ehhez ilyen apróságok támogatása nem igazán tűnik olyan nagy kunsztnak, ezért értetlenül állok a hiánya előtt.

( zrubi v | 2016. 05. 23., h – 12:00 )

Egyik sem.
Elfogadom, hogy sok dologra jó, de ismerem is, ezért noscript nálam alapvető plugin.

--
zrubi.hu