ugrás a tartalomhoz

Why JavaScript Still Sucks

Hidvégi Gábor · 2014. Feb. 7. (P), 17.23
A platformmal még mindig alapvető problémák vannak
 
1

Nem igazán értem az ilyen

inf3rno · 2014. Feb. 8. (Szo), 01.22
Nem igazán értem az ilyen jellegű vitákat, egy darabig én is részt vettem bennük, de semmi értelmük. Minden nyelv más, mindegyiknek vannak előnyei és hátrányai. Ennyi.
2

Ez az írás nem erről szól.

Hidvégi Gábor · 2014. Feb. 8. (Szo), 09.49
Ez az írás nem erről szól.
10

Szerinted.

inf3rno · 2014. Feb. 8. (Szo), 18.22
Szerinted.
52

Épp ellenkezőleg

vbence · 2014. Feb. 10. (H), 14.30
Gyakorlatilag azzal kezdi, hogy a gondolat amit leírsz a probléma egyik fő összetevője.

... the main reason that the language still sucks lies in a certain sentiment of the JavaScript community, the sentiment that JavaScript was a good language all along, it was just a misunderstood language.
54

A probléma fő összetevője ez

inf3rno · 2014. Feb. 10. (H), 23.50
A probléma fő összetevője ez a srác, aki problémát csinál abból, ami másoknak egyáltalán nem az. Rengetegen használják js-t minden fennakadás nélkül. Nem kifejezetten erős oop terén, de a megfelelő stílusban lehet jó kódot írni benne. Ennyi a véleményem.
58

A probléma fő összetevője ez

Hidvégi Gábor · 2014. Feb. 11. (K), 08.37
A probléma fő összetevője ez a srác, aki problémát csinál abból, ami másoknak egyáltalán nem az.
Miért van az, hogy szinte kivétel nélkül mindenki, aki nem procedurálisan programozik, nem a JS beépített prototípus-alapú öröklődését használja, hanem készít egy saját .extend()-et, amivel az egyik objektum tagjait másolgatja a másikba?

Miért van az, hogy egyesek ravasz trükökkel próbálnak meg bizonyos dolgokat rejtegetni mások elől?

Miért jött létre a mixin.js? Azért, mert a JS-ben van megoldás a felmerült problémákra?
59

Ezek mind valamilyen

MadBence · 2014. Feb. 11. (K), 09.23
Ezek mind valamilyen syntactic sugart nyújtanak bizonyos problámékra. Pl az ES6 class szintaxisa is csak egy szintaktikus édesítőszer a prototípus-alapú öröklés megkönnyítésére.
64

ES6 mennyire elterjedt?

inf3rno · 2014. Feb. 11. (K), 09.41
ES6 mennyire elterjedt? Mikortól lehet használni?
Ez a js Harmony jónak ígérkezik...
67

Ha natívan akarod használni,

MadBence · 2014. Feb. 11. (K), 10.26
Ha natívan akarod használni, akkor gondok lesznek (kivéve szerver oldalon), de kliens oldalon számos transpiler érhető el (ha szerencséd van, source map generálás is van hozzá, így a debugolás sem probléma).
69

Komoly, kifolyt a szemem. :D

inf3rno · 2014. Feb. 11. (K), 10.44
Komoly, kifolyt a szemem. :D Ez így túl sok egyszerre... Alapból annyi lib van js-ben, hogy lehetetlen követni, plusz még ez is. :D
80

On

Hidvégi Gábor · 2014. Feb. 11. (K), 12.30
Alapból annyi lib van js-ben, hogy lehetetlen követni
Na, a blogmark például erről is szólt (szerintem a No standard library kimeríti ezt a tényállást) : )
86

Hát szerintem egyáltalán nem

inf3rno · 2014. Feb. 11. (K), 18.04
Hát szerintem egyáltalán nem baj, hogy van miből válogatni... Általában, ha valami célfeladatra kell egy lib, akkor legalább 10 közül választhatok...
60

A js-ben az oop alapból

inf3rno · 2014. Feb. 11. (K), 09.24
A js-ben az oop alapból kényelmetlen. A mixin.js azért jött létre, hogy kényelmesebbé tegye, ne kelljen mindig begépelni pl, hogy Object.create(), etc... Ennyit fog megoldani, és old meg most is, semmi többet.

Sokan megpróbálják ráerőltetni a hagyományos megoldásokat js-re, pl interface, parent vagy $super kulcsszó, ami mindig az aktuális osztály kontextusában van értelmezve, private-protected-public, erős típusosság, annotációk és még sorolhatnám... Ez mind megoldható js-el closure-okkal, Function.toString parsolással, stb..., és mind olyan, hogy egyáltalán nincs szükség rájuk, és idegenek js-től. Nekem is elég hosszú ideig tartott, amíg ezt felfogtam, de azért végül sikerült...

Amikor felcímkézel egy objektumot, akkor jó elrejteni ezt a címkét mások elől, különben az ő kódjuk és a te kódod összeakadhat. Szimplán ennyiről van szó a linknél. Js erre alapból nyújt megoldást már egy ideje a defineProperty-vel. A WeakMap ezt használja ki ahhoz, hogy olyan gyűjteményeket csináljon js-hez, amik alapból nincsenek benne. Pl az object-literal-nál csak String lehet a kulcs, object vagy function nem. Általában ha ebbe belefut az ember, akkor azt tudja csinálni, hogy hozzácsap az object-hez vagy function-höz egy címkét, és arra hivatkozik... Ezt a címkét jó elrejteni mások elől, különben akár simán megjelenhet egy kósza for-in ciklusban is, ami mondjuk config objectet parsol, vagy bármi egyebet csinál, és nem jó, ha látja... Szóval ez kompatibilitási szempontból fontos. Meg lehet persze címkék nélkül is oldani ugyanezt a problémát, csak az jóval lassabb lesz.
66

Miért van az, hogy szinte

Endyl · 2014. Feb. 11. (K), 10.23
Miért van az, hogy szinte kivétel nélkül mindenki, aki nem procedurálisan programozik, nem a JS beépített prototípus-alapú öröklődését használja, hanem készít egy saját .extend()-et, amivel az egyik objektum tagjait másolgatja a másikba?


Ez jó kérdés. Ha automata váltós autón tanultam meg vezetni, és később hagyományos váltós vezetésére kényszerülök, akkor nem állok neki saját mechanikát beleépíteni, ami vált helyettem, hanem megtanulom a kuplungolást, váltást. Vagy ha nagyon nem megy, akkor maradok az automata váltónál (és sofőrt/taxit hívok).

Inkább hiba a JS-ben (vagyis inkább bizonyos használóival, akik aztán terjesztik az "igét"), hogy megpróbálják ráerőltetni az osztályalapú öröklődést (azzal a felkiáltással, hogy ha nincsenek osztályok, akkor OOP sincs...), holott ha tetszik, ha nem, a prototípusos öröklődéssel csak bizonyos szintig lehet ezt imitálni (vagy borzasztó teljesítménnyel). Ebből fakadóan igen szerencsétlen döntésnek tartom, hogy a class kulcsszót vezették be a prototípusos minta lerövidítésére, mert az csak még jobban össze fogja zavarni azokat, akik csak a Java-ig fogják fel a JavaScriptet.

Miért van az, hogy egyesek ravasz trükökkel próbálnak meg bizonyos dolgokat rejtegetni mások elől?


Mint azt már sokszor leírták, az adatrejtésnek nem feltétlen célja a titkoskodás, a szupertitkos adatok elrejtése, hanem a laza csatolás és az objektumok konzisztens állapotának megtartásának elősegítése azáltal, hogy csak bizonyos, "szabványos" módokon lehet hozzáférni. Nyilván, ha változik az igény, akkor bizonyos "adatokat" ki lehet vinni a publikus felületre, de akkor ez egy tudatos döntés, amit dokumentál a kód is, és jó esetben fel is lesz készítve az objektum erre a változásra, és ebben a formában is meg fogja tudni őrizni a konzisztenciáját.
68

A "Miért van az, hogy egyesek

Hidvégi Gábor · 2014. Feb. 11. (K), 10.35
A "Miért van az, hogy egyesek ravasz trükökkel" kezdetű mondatommal kivételesen nem az adatrejtést szerettem volna kritizálni, hanem csak egy újabb példát hoztam arra, hogy egy máshol megszokott OOP dolgot (adatrejtés) szeretnének sokan megvalósítani a JS-ben.

Túl sok nyelvet nem ismerek, de prototípus-alapú öröklődést eddig csak JS-ben láttam, mindenhol máshol (Pascal, Java, PHP) osztályalapú van, emiatt nem értem, hogy akkor itt miért ezt (ti. prototípus) választották.
70

Elvileg az ActionScript is

inf3rno · 2014. Feb. 11. (K), 10.46
Elvileg az ActionScript is prototípusos.
73

Prototípusos is

Endyl · 2014. Feb. 11. (K), 10.55
A beépített objektumok prototípusát AS3-ban már alapból nem tudod felülírni, csak bizonyos fordítói opcióval. A háttérben nem tudom pontosan mi zajlik, de van lehetőséged osztályalapú szintaxissal is dolgozni, és akkor osztályokkal dolgozol, vagy speciális objektumokkal (nem emlékszem, hogy hívják őket) amik JS-szerűen működnek. A két fajta működés egy adott objektumon nyilván nem keverhető. Persze lehet, hogy tévedek, mert már rég írtam AS kódot.
74

Passz, én sosem használtam

inf3rno · 2014. Feb. 11. (K), 10.57
Passz, én sosem használtam AS-et. Valószínűleg el is fog tűnni a flash a süllyesztőben a html5 miatt.

off: Személy szerint nem sajnálom, nálam napi szinten száll el még a youtube-nál is néha...
102

AS

vbence · 2014. Feb. 14. (P), 18.19
AS2-ben volt már class és interface. AS3 már típusos változókat (és paramétereket) is támogat.
77

Más nyelv, más "trükkök". Az

Endyl · 2014. Feb. 11. (K), 11.18
Más nyelv, más "trükkök". Az igazi probléma (de ez meg nem csak a JS platform hibája, hanem a globálisan elterjedt platformoké), hogy lassan tud változni. Igazából a cikk semmi olyan problémát nem hoz fel, ami meggátolná jó szoftverek készítését, csak máshogy kell nekiállni (ami nem olyan nehéz, ha nem akarunk mást ráerőltetni, hanem úgy használjuk, ahogy adja magát).

Hasonló "alapvető problémákat" más nyelvekhez is lehetne mondani. Ez nyilván nem oldja meg ezeket a "problémákat" (amik közül jópár igazából "fícsör", vagy legalábbis tekinthető annak, ha az ember hajlandó megtanulni a nyelvet). Ugyanakkor ha tényleg akkora problémák ezek, akkor miért nem lázadt már fel a tömeg, hogy kéretik ezt és ezt bevenni a szabványba?
87

Imho alapvetően nincs semmi

inf3rno · 2014. Feb. 11. (K), 18.06
Imho alapvetően nincs semmi gond js-el. Minél egyszerűbb, annál jobb, és js elég egyszerű, mégis nagyszerű, blabla :D
72

Csak, hogy kiegészítsem. A

inf3rno · 2014. Feb. 11. (K), 10.53
Csak, hogy kiegészítsem. A mixin inkább csak egy játszadozás js-ben. Maga a projekt nem egy nagy szám, és nem is igazán foglalkozik komoly problémákkal. Viszont sok tapasztalatot szereztem vele arról, hogy hogyan kell js-hez fejlesztői környezetet létrehozni. Meg még fogok is. Most pl gruntot tanulom majd, aztán csinálok standalone, commonjs meg amd modulokat. Ez a build egy olyan dolog, amiben még elég kevés a tapasztalatom...
3

Elég sok marhaság van a

MadBence · 2014. Feb. 8. (Szo), 11.45
Elég sok marhaság van a cikkben...

No OOP: attól, hogy a szerző nem elég kompetens ahhoz, hogy objektum-orientált kódot írjon, attól még igenis van. A szerző által említett CoffeeScript is prototípus-alapú öröklést használ (hisz ez van a JS-ben).

No standard library: Ez nem hiszem, hogy a nyelv hibája :). Egyébként kismillió csomagkezelő érhető el (npm, bower, component, stb).

No module system: nodejs: require, RequireJS, ES6 modules

No language resources: Megint csak nem a nyelv hibája. Amúgy a teljesség igény nélkül:
Interaktív:
Könyv-szerű:
A különböző modulok dokumentálása a modul karbantartójának feladata, egyébként a Mozilla elég jó munkát végzett a DOM-hoz kapcsolódó dolgok dokumentálásával, illetve a node referencia is teljesen korrekt.

Client and server JavaScript still completely disconnected: Ismét nem a nyelv hibája, de ha ilyenre vetemedne az ember: meteor, browserify.

Syntax Sugar:
but who would honestly prefer reading for (var i=0; i<arr.length; i++) rather than for e in arr?

JS-ben is lehet egyszerűen iterálni: for(e of arr), vagy forEach

As a side note, the JavaScript version of this loop is actually slower than its CoffeeScript counterpart, do you know why?

Gondolom a szerző itt arra gondol, hogy a CS verzió arra fordul, hogy for(var i=0, l=arr.length; i<l; i++), tehát megspóroljuk minden körben a property elérést. Ha a szerző kicsit utánaolvasott volna, akkor tudná, hogy egyrészt a JS compiler is van ilyen okos, másrészt nem dobálózna microbenchmarkokkal (microbenchmarks are bad)

JSLint: Meglepő módon JSLint nélkül is lehet helyes kódot írni, és CoffeeScriptben is lehet bugosat, nem igazán értem az összefüggést (a szerző azt sugallja, hogy a lintelt kód hibamentes).
4

+1

Poetro · 2014. Feb. 8. (Szo), 12.16
+1
5

-1

Hidvégi Gábor · 2014. Feb. 8. (Szo), 12.59
attól, hogy a szerző nem elég kompetens ahhoz, hogy objektum-orientált kódot írjon, attól még igenis van
Az OOP a legtöbb programozó számára azt jelenti, ami például a Javában vagy Delphiben van (ezt abból gondolom, hogy ezeket próbálják utánozni). Ezt natívan nem támogatja a JS, és az egy dolog, hogy saját nyelvi eszközökkel imitálható az OOP, de azért ez mégsem tökéletes megoldás.

No standard library: Ez nem hiszem, hogy a nyelv hibája :). Egyébként kismillió csomagkezelő érhető el
És a kismillió csomagkezelőből melyiket használja az ember? Kompatibilisek egymással? Ha az egyiket nem fejlesztik tovább, amire a projektjeim épülnek, akkor nagy bajban vagyok? Tegyük fel, hogy letöltök egy modult, ami a PostgreSQL1 nevű csatolót használja, egy másik modul meg a PostgreSQL2-t. Akkor kétszer csatlakozzak az adatbázishoz, vagy írjam át valamelyik modult? A php-ban van egy postgresql könyvtár, és azt használja mindenki, amiről lehet tudni, hogy hivatalosan támogatott, és lehet rá alapozni. node.js esetében ez hány modulról mondható el az ötvennyolcezer csomagból?

No language resources: Megint csak nem a nyelv hibája
Akkor kié? A php.net, mysql.com és társaiknak van központi referenciája, az általad felsoroltakat meg az embernek kell megtalálnia valahol, ami vagy sikerül vagy nem. Minél több idő telik el és minél nagyobb az internet, annál kisebb az esély, hogy valaki megtalálja ezeket. Pont itt, a weblabor fórumán a kezdők általában olyan amatőr kódokat vágnak be, amiből nyilvánvaló, hogy az általad említett irodalmat nem olvasták, azaz mégsem olyan egyértelmű, hogy mi a jó és mi nem az.

A kérdésem a következő: a felsorolt linkjeidet évek során gyűjtögetted össze, vagy pedig van egy hely a neten (pl. javascript.com), ahonnan csak bemásoltad?
6

Az OOP a legtöbb programozó

MadBence · 2014. Feb. 8. (Szo), 13.32
Az OOP a legtöbb programozó számára azt jelenti, ami például a Javában vagy Delphiben van

El kéne fogadni, hogy a JS nem próbál meg Java lenni. Egy nyelv nem attól lesz rossz, hogy nem class-based.

És a kismillió csomagkezelőből melyiket használja az ember? Kompatibilisek egymással? Ha az egyiket nem fejlesztik tovább, amire a projektjeim épülnek, akkor nagy bajban vagyok?
Bármelyiket. Elférnek egymás mellett, a népszerű modulok mindegyik rendszerben ott vannak. A csomagkezelő csak a csomagok telepítésére/karbantartására szolgál, így a csomagkezlő a programra nincs igazán hatással. Az egyedüli különbség többnyire a konfigurációs fájl neve (hiszen package formátum kb ugyanaz). Egyébként mi lesz, ha egyik napról a másikra eltűnik a Maven/Gradle/Composer? Semmi. Tömegek használják, akik adott esetben valószínűleg átvennék a projectet.

Tegyük fel, hogy letöltök egy modult, ami a PostgreSQL1 nevű csatolót használja, egy másik modul meg a PostgreSQL2-t. Akkor kétszer csatlakozzak az adatbázishoz, vagy írjam át valamelyik modult?

Nem igazán reális forgatókönyv (mondj kérlek egy példát erre), de igen, kétszer kell csatlakozni. PHP esetén egy userland modul meg vagy kompatibilis a te PHP verzióddal, vagy nem :) (még csak esély sincs a probléma egyszerű megoldására).
A problémád gondolom ott gyökerezik, hogy mindenre kész, standard megoldást szeretnél. A node core pl szándékosan kicsi (unix philosophy)

A php.net, mysql.com és társaiknak van központi referenciája

Megint egy félreértés. A JS (ECMAScript) egy nyelvi specifikáció. Ennek vannak (egymástól független) implementációi (v8, spidermonkey, stb). Ezek köré épülnek (egymástól független) platformok (node, böngészők, stb), amik köré (egymástól független) könyvtárak/keretrendszerek épülnek (jQuery, express, stb). A JavaScript ecosystem nem egy monolitikus valami (mint a php/java/stb, ami egy nyelv, annak egy implementációja, és hozzá tartozó gigantikus, tehát rugalmatlan könyvtár-gyűjtemény), így nyilván nem is lehet egy központi referenciát létrehozni (persze jó lenne, én legalábbis nem vagyok ellene).




http://devdocs.io/ egy elég jó gyűjtemény a neten fellelhető doksikról.
Egyébként nem értek veled egyet, a többezer oldalas doksik olvasása elég nagy időpocsékolás egy kezdő számára (plána ha nem tudja, hogy hol induljon el).
7

El kéne fogadni, hogy a JS

Hidvégi Gábor · 2014. Feb. 8. (Szo), 14.30
El kéne fogadni, hogy a JS nem próbál meg Java lenni.
Ezt ne nekem magyarázd, hanem a nagy többségnek, aki Javaként szeretné használni. Ha megnézel egy tetszőlegesen kiválasztott JS kódot, ott van benne az Object.extend függvény, szerinted ezt azért implementálja mindenki, mert nincs rá szüksége?

»És a kismillió csomagkezelőből melyiket használja az ember?« Bármelyiket. (...) Egyébként mi lesz, ha egyik napról a másikra eltűnik a Maven/Gradle/Composer? Semmi. Tömegek használják, akik adott esetben valószínűleg átvennék a projectet.
Valószínűleg? Ha odamész a főnöködhöz, aki egy új projektet szeretne veled készíttetni, azt fogja mondani egy ilyen valószínűleg-re, hogy oké, használjuk? Szerinted melyik mögül állnak ki hamarabb, a php/ruby/java vagy a node.js bármelyik modulja mögül?

Nem igazán reális forgatókönyv (mondj kérlek egy példát erre), de igen, kétszer kell csatlakozni.
A PostgreSQL helyére illessz be bármilyen másik csomagnevet, amiből legalább kettő van.

A problémád gondolom ott gyökerezik, hogy mindenre kész, standard megoldást szeretnél. A node core pl szándékosan kicsi (unix philosophy)
A C/java/php standard könyvtárban mindenre van megoldás? Nincs, csak azokra a dolgokra, amire mindenkinek szüksége van. MySQL vagy PostgreSQL csatolóból node-hoz a világon egy darabra van szükség, nem tízre.

És ne felejtkezz el arról, hogy nem csak a node.js-ről van itt szó, hanem a böngészőkben futó JS-ről is. Tegyük fel, hogy szükségem van egy ellenőrző összeg számításra, keresgélhetek a neten md5-öt, ahelyett, hogy ez egy JS standard könyvtár része lenne. Találok kettőt a neten: melyik a jó? Hogyan döntöm ezt el?

A JavaScript ecosystem nem egy monolitikus valami (mint a php/java/stb, ami egy nyelv, annak egy implementációja, és hozzá tartozó gigantikus, tehát rugalmatlan könyvtár-gyűjtemény)
Cserébe rugalmasan keresgélhetsz a neten a modulok közül, aztán vagy jó lesz vagy nem. Ráadásul bármilyen gyors lehet egy JS motor, egy szépen leoptimalizált natív megoldással szemben esélye sincs, sem sebességügyileg, sem pedig memóriahasználatban, lásd mobilalkalmazások, amit nem véletlenül nem HTML+JS kombinációval készítenek el - és azt ne mondja nekem senki, hogy passzióból csinálják, mert olyan nagy élvezet n platformra lefejleszteni ugyanazt.

Egyébként nem értek veled egyet, a többezer oldalas doksik olvasása elég nagy időpocsékolás egy kezdő számára (plána ha nem tudja, hogy hol induljon el).
Cserébe keresheti a modulokat, olvasgathatja azok dokumentációját.
8

Szerinted melyik mögül állnak

MadBence · 2014. Feb. 8. (Szo), 14.38
Szerinted melyik mögül állnak ki hamarabb, a php/ruby/java vagy a node.js bármelyik modulja mögül?

Megfelelően mature modulokat kell használni, ha ilyen miatt aggódik a főnök. A régi php-s mysql modulhoz mikor nyúltak utoljára hozzá? És még mindig működik (egy darabig).

A PostgreSQL helyére illessz be bármilyen másik csomagnevet, amiből legalább kettő van.
XML parserből pl elég sok van (natív és pure JS verzió is), a kettő tökéletesen megfér egymás mellett. Sőt más-más modulok más-más verziót is képesek használni, egymástól függetlenül.

csak azokra a dolgokra, amire mindenkinek szüksége van. MySQL vagy PostgreSQL csatolóból node-hoz a világon egy darabra van szükség, nem tízre.
Jogos, nincs is belőlük 10, a de-factor standard mysql modul a node-mysql. A modularitásból fakad, hogy egy-egy bug azonnal megjavítható, nem kell fél évet várni, hogy a következő release-ben (bugfix-csomagban) benne legyen.

Ráadásul bármilyen gyors lehet egy JS motor...

Bár nem értem hogy jön a JS sebessége ahhoz, hogy nincs egy helyen a dokumentáció, azt elárulom, hogy JS nagyon gyors, viszont a DOM rendering nagyon lassú (ezért vannak gondok a HTML alapú mobilalkalmazásokkal)
9

Megfelelően mature modulokat

Hidvégi Gábor · 2014. Feb. 8. (Szo), 14.52
Megfelelően mature modulokat kell használni, ha ilyen miatt aggódik a főnök.
És azt ki dönti el, hogy mikor érett meg eléggé egy modul, hogy nyugodtan használjam? PHP-nál (és gondolom, a többi hasonló rendszerben is, pl. java, ruby, ezeket nem ismerem) van egy standard könyvtár, ami visszamenőleg (általában) kompatibilis, míg a JS-nél (nem csak node.js-nél!) semmi ilyenre nem számíthatok, mert nincs mögötte egy profi csapat, aki elvégzi a karbantartást és a fejlesztést.

XML parserből pl elég sok van (natív és pure JS verzió is), a kettő tökéletesen megfér egymás mellett. Sőt más-más modulok más-más verziót is képesek használni, egymástól függetlenül.
Erről beszélek. Ugyanarra az atomi feladatra miért van n modul? Melyiket válasszam?

A modularitásból fakad, hogy egy-egy bug azonnal megjavítható, nem kell fél évet várni, hogy a következő release-ben (bugfix-csomagban) benne legyen.
A php frissítéseket sem félévente adják ki.

Bár nem értem hogy jön a JS sebessége ahhoz, hogy nincs egy helyen a dokumentáció
Sehogy. Arra szerettem volna rámutatni, hogy ha lenne standard könyvtár, egy csomó alapműveletet sokkal hatékonyabban lehetne elvégezni.
32

míg a JS-nél (nem csak

blacksonic · 2014. Feb. 8. (Szo), 21.45
míg a JS-nél (nem csak node.js-nél!) semmi ilyenre nem számíthatok, mert nincs mögötte egy profi csapat, aki elvégzi a karbantartást és a fejlesztést.


Legtobb nagyobb konyvtar mogott nodejs nel is mint js nel (pl jQuery, Express) profi csapat van mogotte, plusz a nepes kozossegi tamogatas. Rendszeresen feljelsztik, bugfixelik es supportaljak a dolgokat.
13

Nem igazán értem az

inf3rno · 2014. Feb. 8. (Szo), 18.36
Nem igazán értem az érvelésed. Ennyi erővel composerrel se rántok le semmit PHP-hez, mert mi van, ha megszűnik a könyvtárra, vagy neadjisten a composerre a support. Ilyen hozzáállással a legbiztosabb, ha mindent magam kódolok le, nem?!
15

PHP standard könyvtárról volt

Hidvégi Gábor · 2014. Feb. 8. (Szo), 18.44
PHP standard könyvtárról volt szó, aminek nem része a composer. A composerrel letöltött felhasználói modulok természetesen ugyanolyan stabil lábakon állnak, mint a node.js-éi.
31

Ráadásul bármilyen gyors

blacksonic · 2014. Feb. 8. (Szo), 21.39
Ráadásul bármilyen gyors lehet egy JS motor, egy szépen leoptimalizált natív megoldással szemben esélye sincs, sem sebességügyileg, sem pedig memóriahasználatban


Keress ra es olvass utana asm.js nek...alig lassabb mint egy Cben irt alkalmazas (ha jol emlekszem 20-30% kal)
35

asm.js

Hidvégi Gábor · 2014. Feb. 9. (V), 09.04
Az asm.js segítségével milyen műveleteket lehet végezni? Hadd idézzek az asmjs.org-ról:
low-level subset of JavaScript

A korábban említett md5 vagy sha1 függvényeket meg lehet valósítani asm.js-sel is, de mi értelme, ha a natív kód 20-30%-kal gyorsabb? Ez különösen sokat számít mobil eszközökön, ahol egyelőre nincs kilátásban a jelenleginél jóval hatékonyabb akkumulátortechnológia. Szóval minden a JS standard könyvtár mellett szól.
36

Az a helyzet (ahogy azt

MadBence · 2014. Feb. 9. (V), 12.50
Az a helyzet (ahogy azt korábban is írtam), hogy a JS sebessége nem igazán számít. Egy mobilalkalmazás nem számításigényes (kivéve ha pl játék), így az, hogy egy ciklus milyen gyors (vagy egy md5 milyen gyors) nem igazán számít. Ami számít, az a megjelenítés (renderelés) sebessége, mennyire vannak az újrarajzolások optimalizálva, stb.
37

Sok kicsi sokra megy.

Hidvégi Gábor · 2014. Feb. 9. (V), 13.50
Sok kicsi sokra megy.
38

nem kell megtanulnod másik

blacksonic · 2014. Feb. 9. (V), 19.32
nem kell megtanulnod másik nyelvet
40

Ha JS-nek lenne mondjuk egy

Hidvégi Gábor · 2014. Feb. 9. (V), 19.42
Ha JS-nek lenne mondjuk egy standard "Hash" modulja, annak pedig egy md5 nevű függvénye, akkor miért kéne másik nyelvet megtanulni?
43

Szükség van erre? A

MadBence · 2014. Feb. 9. (V), 21.18
Szükség van erre? A böngészőkben nem tipikus use-case az ilyen jellegű számolás. Szerver oldalon (node) igen, ott van is crypto modul.
Ha a fejlesztő kliens-oldalon akar MD5-öt számolni, akkor használjon erre írt userland modult.
45

Az md5 egy kiragadott példa,

Hidvégi Gábor · 2014. Feb. 9. (V), 21.40
Az md5 egy kiragadott példa, de írtam jobbat is, a sablonozást.
46

Már miért kéne egy standard

inf3rno · 2014. Feb. 9. (V), 21.43
Már miért kéne egy standard sablonozó lib? Php-ban sincsen...
12

Az OOP a legtöbb programozó

inf3rno · 2014. Feb. 8. (Szo), 18.31
Az OOP a legtöbb programozó számára azt jelenti, ami például a Javában vagy Delphiben van (ezt abból gondolom, hogy ezeket próbálják utánozni). Ezt natívan nem támogatja a JS, és az egy dolog, hogy saját nyelvi eszközökkel imitálható az OOP, de azért ez mégsem tökéletes megoldás.


Esetleg ha jobban beleásnád magad, hogy mit jelent az, hogy class based és prototype based language, akkor megértenéd, hogy a js sosem lesz olyan, mint a java, és teljesen felesleges összehasonlítani vele...
14

Nem hasonlítok én semmit se

Hidvégi Gábor · 2014. Feb. 8. (Szo), 18.41
Nem hasonlítok én semmit se semmihez. Annyit írtam, hogy a fejlesztők részéről megvan az igény, hogy osztályalapú OOP-hez, ami nincs meg a JS-ben. Erre egy híres példa a mixin.js extend() metódusa.
17

Nem igazán értem, hogy ez

inf3rno · 2014. Feb. 8. (Szo), 19.06
Nem igazán értem, hogy ez hogy jön ide. Az említett függvény mindössze egyszerűbbé teszi a prototípusos öröklődés használatát. Nem volt célom vele pl az osztályok vagy interface-ek feltalálása...
11

+1 Annyit azért hozzátennék,

inf3rno · 2014. Feb. 8. (Szo), 18.28
+1

Annyit azért hozzátennék, hogy oop terén vannak hiányosságok: nincs abstract method, nincs interface, nincs típus kikényszerítés, nincs annotáció. Ezek hiányában is lehetséges jó kódot írni, ami igazán szükséges az megvan hozzá...

Amit én hiányolok az aszinkron programozás nyelvi megtámogatása. Nem igazán tudom, hogy ezt hogyan lehetne megoldani, nem is igazán érdekel erről az elméleti vita, de a jelenlegi callback-es bind-os megoldás nekem túl nehézkesnek tűnik...
16

Használj promicokat.

Hidvégi Gábor · 2014. Feb. 8. (Szo), 18.51
Amit én hiányolok az aszinkron programozás nyelvi megtámogatása
Használj promicokat.

Milyen műveleteknél van szükséged aszinkronitásra?

a jelenlegi callback-es bind-os megoldás nekem túl nehézkesnek tűnik
Kódolj procedurálisan, és akkor nem kell a this-szel vacakolnod.
18

Milyen műveleteknél van

inf3rno · 2014. Feb. 8. (Szo), 19.11
Milyen műveleteknél van szükséged aszinkronitásra?


Gyakorlatilag bárminél, amit nodejs-hez írsz, vagy ami esemény vezérelt.

A promise-okért nem vagyok oda, valahogy nekem nem nyerő, hogy halmozom a .then()-eket egymás után.

Kódolj procedurálisan, és akkor nem kell a this-szel vacakolnod.


Próbáltam valami frappáns közmondást találni, de csak azt dobta a google, hogy
előbb vágják le a kezem
... :D
20

»Milyen műveleteknél van

Hidvégi Gábor · 2014. Feb. 8. (Szo), 19.27
»Milyen műveleteknél van szükséged aszinkronitásra?« Gyakorlatilag bárminél, amit nodejs-hez írsz
Google-ék a sebesség érdekében feláldozták a produktivitást, a kód átláthatóságát és karbantarthatóságát. Egy PHP sokkal többet ér ebből a szempontból, hiába lassabb – és mondom ezt úgy, hogy a JS szintaktikáját és magát a nyelvet sokkal jobban szeretem, mert sokkal intuitívabban lehet vele dolgozni.
26

Ennek az az oka, hogy a php

inf3rno · 2014. Feb. 8. (Szo), 19.52
Ennek az az oka, hogy a php nem esemény vezérelt, node viszont igen. Persze a php sokkal átláthatóbb, könnyebben használható, ha nem akarsz vissza pusholni a kliens-hez pl sockettel, vagy valamit esemény vezérelten megírni. Én jelenleg nem akarok ilyet, úgyhogy php-t használok. Még az is lehet, hogyha akarnék, akkor csinálnék egy külön chat servert, amin node futna, és ezt támogatná, a maradék kód pedig maradna php-ben. Semmi bajom egyébként node-al, csak amire én használnám, ott inkább hátrány, mint előny a php-hez képest...
29

event loop

complex857 · 2014. Feb. 8. (Szo), 20.47
PHP-val is lehet eseményvezérelt kódot/programot írni, csak mint önálló program (nem fcgi/apache modulként futtatott PHP-val) csak saját magadnak kell megírni az event loopot socket_select()-el.
Másik lehetőség, hogy kész libeket használsz mint pl. React a "look and feel" annyira nodejs, hogy még a a weboldal színvilágát is lemásolta :-P

Azt nem állítom, hogy ez feltétlenül jó ötlet, de a lehetőség abszolút adott. Vannak akik komplett ftp szervert írtak így (igen, még 2003-ban).
30

Nem ez a lényeg. Persze meg

inf3rno · 2014. Feb. 8. (Szo), 20.49
Nem ez a lényeg. Persze meg lehet csinálni PHP-ban is, de a nodejs-t eleve ilyen céllal találták ki, és nem utólag tákolták hozzá az aszinkron részt...
33

Kódolj procedurálisan, és

blacksonic · 2014. Feb. 8. (Szo), 21.48
Kódolj procedurálisan, és akkor nem kell a this-szel vacakolnod.


Probaltal mar nodejs ben proceduralisan kodolni? Mert elobb lovom fejbe magam mint hogy kiprobaljam
34

Hát, igen, ott nem lehet,

Hidvégi Gábor · 2014. Feb. 9. (V), 08.49
Hát, igen, ott nem lehet, böngészőben viszont igen.
39

Es mennyivel jobb ha egy

blacksonic · 2014. Feb. 9. (V), 19.34
Es mennyivel jobb ha egy Javascriptes webalkalmazást nem procedurálisan írnak meg :)
41

Mennyivel? Miért kéne egy

Hidvégi Gábor · 2014. Feb. 9. (V), 19.49
Mennyivel? Miért kéne egy webalkalmazást kompletten JS-ben megírni? Miben különbözik egy "single page webapp" egy hagyományos weboldaltól?
42

nem kell itt single page

blacksonic · 2014. Feb. 9. (V), 21.11
nem kell itt single page webappra gondolni, elég egy komolyabb szerkesztő, például ha Prezis diák editálását teljesen jssel végzed
44

Az nyilvánvaló, hogy grafikai

Hidvégi Gábor · 2014. Feb. 9. (V), 21.35
Az nyilvánvaló, hogy grafikai feladatoknál (mint az általad említett Prezis diák, vagy mondjuk Canvasra való rajzolás) nem kerülheted meg a JS-t, bár hozzá kell tenni, ha valamit pontosan szeretnél pozícionálni, ahhoz még az egér is kevés, és akkor ugyanott vagyunk, ahol a part szakad. Hogy ennek megvalósításához szükséges-e OOP, arról viszont nem vagyok meggyőződve, mert (az általam eddig látottak alapján) nagy valószínűséggel túl fogják bonyolítani.
47

Hogy ennek megvalósításához

inf3rno · 2014. Feb. 9. (V), 21.45
Hogy ennek megvalósításához szükséges-e OOP, arról viszont nem vagyok meggyőződve, mert (az általam eddig látottak alapján) nagy valószínűséggel túl fogják bonyolítani.


És akkor megint a szokásos oop elleni érvelésednél vagyunk, hogy az oop azért rossz, mert akik nem értenek hozzá azok túlbonyolítják, tehát senkinek nem is szabadna használni, mert biztosan mindenki túlbonyolítja.
48

akárhogy írod meg egy ilyen

blacksonic · 2014. Feb. 9. (V), 21.53
akárhogy írod meg egy ilyen szerkesztő bonyolult lesz...ha mindezt procedurálisan csinálod még karbatarthatalan is
49

Véletlenül épp a Preziéhez

Hidvégi Gábor · 2014. Feb. 9. (V), 22.07
Véletlenül épp a Preziéhez hasonló szerkesztőn dolgozom most már évek óta, eredetileg OOP-nek indult, mert úgy gondoltam, hogy jó lesz, de aztán újraírtam, immár procedurálisan, és működik, karbantartható, bővíthető. Nincs benne sehol sem bind, call, apply.
50

nem az egy fos projektekre

blacksonic · 2014. Feb. 10. (H), 12.19
nem az egy emberes projektekre gondoltam, ott eleg sok mindent elkovethetsz amitol meg neked karbantarthato lesz, de egy csapatban hosszutavon evek alatt karbantarthatatlan lesz
mi a baj a bind call apply al?
51

Nem egyedüli meló, többen

Hidvégi Gábor · 2014. Feb. 10. (H), 13.32
Nem egyedüli meló, többen dolgozunk rajta.

A bind-apply-call metódusokkal az a gond, hogy léteznek. A bind azt jelenti, hogy menet közben elveszted a kontextust, azaz folyamatosan figyelni kell, hol vagy. Az apply és a call pedig arra bizonyíték, hogy léteznek olyan adatok, amelyek egy objektumnak sem a részei, emiatt létezniük kéne olyan függvényeknek (tipikus példa az Array.prototype.call(arguments), amit oly sok kódban látni), amelyek nem objektumok metódusai.
55

A bind-nál a legjobb, ha

inf3rno · 2014. Feb. 10. (H), 23.51
A bind-nál a legjobb, ha mindig this-re teszed kivétel nélkül.
A call-os fejtegetésedet nem tudom értelmezni.
57

call

Hidvégi Gábor · 2014. Feb. 11. (K), 08.04
Most nézem, hogy kimaradt a slice:

function fuggveny() {
  var parameterek = Array.prototype.slice.call(arguments);
}


JS-ben (egy-két kivétellel) minden függvény (amit nem felhasználó írt) valamely ősobjektumhoz tartozik, mert abból indulnak ki, hogy minden objektum. Ha lazább volna a kapcsolat (például úgy, mint a php-ban, hogy vannak egyrészről az adatok, másrészről a függvények, és hagyják, hogy a programozó döntse el, mit és hogyan használ), akkor nem lenne szükség ilyen nyakatekert hívásokra.
62

Ha nem tetszik a hosszú neve,

inf3rno · 2014. Feb. 11. (K), 09.32
Ha nem tetszik a hosszú neve, akkor tedd be egy slice nevű változóba, és máris nincs ilyen problémád.
78

pedig pont ezek teszik

blacksonic · 2014. Feb. 11. (K), 11.25
pedig pont ezek teszik annyira rugalmassa a Javascriptet
65

nincs abstract method, nincs

tgr · 2014. Feb. 11. (K), 10.06
nincs abstract method, nincs interface, nincs típus kikényszerítés, nincs annotáció


Olyan statikus elemzőt használsz, amilyet jólesik. A Closure pl. tudja mindezeket.

Amit én hiányolok az aszinkron programozás nyelvi megtámogatása.


A generátoros-promise-os megoldás azért elég jól néz ki.
71

Igen, a yield az jó, de mikor

inf3rno · 2014. Feb. 11. (K), 10.49
Igen, a yield az jó, de mikor lesz már végre böngészőben???
76

Egyre inkább úgy látom, hogy

Hidvégi Gábor · 2014. Feb. 11. (K), 10.59
Egyre inkább úgy látom, hogy az aszinkron kérések több problémát vetnek fel, mint amennyit megoldanak. A magam részéről már elkezdtem mindent átkonvertálni szinkronra.
75

Mennyivel egyszerűbb lenne,

Hidvégi Gábor · 2014. Feb. 11. (K), 10.57
Mennyivel egyszerűbb lenne, ha ezt az egész aszinkron dolgot elrejtenék a felhasználó elől, és akkor nem kéne új kulcssszót bevezetni (yield), meg megtakarítottak volna a felhasználóknak négy év konfúziót (callback hell, promicok).

Biztos vannak olyan IO műveletek, amik jól párhuzamosíthatóak, de eddigi tapasztalataim alapján ilyenből kevés van egy átlagos webes projekt esetében.
79

Aszinkron

Poetro · 2014. Feb. 11. (K), 12.06
Minden felhasználói interakció aszinkron, így csak másképp lehet becsomagolni. Mint például Win32 API-ban egy végtelen while ciklusba, ami szerintem szintén nem a leghatékonyabb módja az aszinkron események kezelésének. Aszinkron események mindig lesznek, és valahogy kezelni kell őket, akkor is ha ez neked nem természetes. Az, hogy történetesen mi az aszinkron esemény az teljesen mellékes, ugyanakkor a várakozást is érdemes valami hasznossal eltölteni, ugyanis JS esetén hagyományosan csak egyetlen szálad van, amivel szintén aszinkron módon tudsz kommunikálni (Workers, child processes stb).
81

node

Hidvégi Gábor · 2014. Feb. 11. (K), 14.24
Szerver:

Egy adatbázisból való lekérdezés nem felhasználói akció, mégis aszinkron (node.js esetében). Azért indítom el, mert szükségem van az eredményére, amivel kezdeni szeretnék valamit a programomban. Amíg megjönnek az adatok, felőlem nyugodtan ketyeghet tovább a node ütemezője, a szoftver szempontjából irreleváns, mert amíg a kért adatokat meg nem kapom, úgysem tudok semmit sem csinálni. Ha nem tudok semmit sem csinálni, akkor számomra lényegtelen információ, hogy a kérés szinkron vagy aszinkron volt.

Az aszinkronitásból leginkább csak a nagy projektek profitálhatnak, ahol rengeteg adatforrással dolgoznak, vagy például elosztott adatbázissal, kis projekteknél, ha egy adatbázisszerver van, például MySQL vagy PostgreSQL, amelyek egyesével, a bejött kérések sorrendjében futtatják le a lekérdezéseket, nincs jelentősége. Ha viszont megnézzük, hogy mondjuk ezer honlapból/alkalmazásból hány számít nagy projektnek, akkor nagy valószínűséggel csak nagyon keveseknek van szüksége aszinkronitásra. Így viszont csak hátránnyal jár, lásd callback hell, promicok és a yield bevezetésének szükségessége. Vagy pedig alapból lehetne minden szinkron (kvázi-szinkron), és majd én eldöntöm, hogy ha mégis aszinkron lekérdezéseket szeretnék futtatni, és akkor vállalom, hogy jöhet a kóllbákk hell.

Kliens:

Tegyük fel, hogy egy szerverről kérek csak adatokat, ami az oldalamnak/alkalmazásomnak szükséges. Megvalósítás szempontjából két választási lehetőségem van:

1, Minden összefüggést a kliensen tárolok (vastag kliens), ami csak egyszerű esetekben működik, különben nagyon nagy lesz a kliens, ami korlátozza a használhatóságát (gyors hardver, sok memória). Az adatok ellenőrzését viszont a szerveren is el kell végeznem, ami újabb hátrány. Szerintem ma az előbbiek miatt nem éri meg vastag klienst készíteni. Az aszinkronitás itt nyugodtan használható, mert a kliens tudja kezelni a precedenciákat és az összefüggéseket. További hátrány, hogy a szerver által szolgáltatott adatokat csak a vastag kliensem tudja jól értelmezni, ez tovább korlátozza a használhatóságot.

2, Minden összefüggést a szerveren kezelek (vékony kliens), a kliens csak az adatok megjelenítésével foglalkozik. Ekkor az aszinkronitást már nem nagyon lehet használni, mert a kliens nem tudhatja, mi mivel van kapcsolatban. Így, ha valaki ész nélkül elkezd kattintgatni, ezáltal n darab párhuzamos lekérdezést indít el, elképzelhető, hogy a végén inkonzisztens adatok jelennek meg a képernyőn, mire mindegyik feldolgozása megtörténik. Ezért szerintem vékony kliensen szinkron kéréseket érdemesebb használni, a felhasználó várja csak meg szépen, mire megjön minden válasz.
82

Szerver:Az aszinkronitásnak

MadBence · 2014. Feb. 11. (K), 16.04
Szerver:

Az aszinkronitásnak itt van a legnagyobb szerepe. Ha te valamit lekérsz az adatbázisból (szinkron), akkor addig a szerver le van fagyva. Nem tudsz már http kéréseket kiszolgálni. A PHP ezt processekkel, illetve thread poolokkal kerüli meg, aminek a skálázhatósága erősen kérdéses.

Kliens:

Vékony kliens esetén is megoldható a sorrendiség, cserébe a felület nem fagy meg a szinkron kérés idejére, a szinkron kérések ugyanis foglalják a szálat várakozás közben, ami UX szempontjából borzasztó. Erre egy megoldás lehet a background workerek használata (amiknek szintén megvannak a hátrányai)
83

Ha te valamit lekérsz az

Hidvégi Gábor · 2014. Feb. 11. (K), 16.47
Ha te valamit lekérsz az adatbázisból (szinkron), akkor addig a szerver le van fagyva. Nem tudsz már http kéréseket kiszolgálni.
Vesd össze:
Amíg megjönnek az adatok, felőlem nyugodtan ketyeghet tovább a node ütemezője
Ki akadályozza meg, hogy mást szolgáljon ki? Elmenti egy változóba, hogy a programnak ezen a részén átadták a vezérlést, majd, amikor megjönnek az adatbázisból az adatok, ugyanonnan folytatja.

Kliens:

Ha rendes kapcsolatod van, a szinkron kérések olyan rövid időre fogják meg a felületet, hogy a felhasználó nem veszi észre. Ha lassú a kapcsolatod, akkor pedig lehetsz aszinkron, kattintgathat a felhasználó, vihet fel adatokat, ha úgysem tudod elmenteni, nem tudsz közben újat lekérdezni.
84

Ki akadályozza meg, hogy mást

Poetro · 2014. Feb. 11. (K), 17.02
Ki akadályozza meg, hogy mást szolgáljon ki?

Az, hogy a Node egy szálon fut, és amíg az a szál áll, addig nem tud mással foglalkozni, azaz nem tud mást kiszolgálni.
Elmenti egy változóba, hogy a programnak ezen a részén átadták a vezérlést, majd, amikor megjönnek az adatbázisból az adatok, ugyanonnan folytatja.

A Node.js, és a legtöbb nyelv onnan is fogja folytatni, de mivel egyetlen szálon fut, nem is tud addig mással foglalkozni (legfeljebb rendszer szintű megszakításokkal).
Ha rendes kapcsolatod van, a szinkron kérések olyan rövid időre fogják meg a felületet, hogy a felhasználó nem veszi észre.

Ha tényleg úgy állnak a csillagok és a hold, akkor igen. Ha a szerver valami miatt lassú, a kliens kapcsolata valami miatt lassú, akkor addig a felhasználó semmit sem tud csinálni az oldaladon, sok esetben még görgetni sem tudja az oldalt. Ráadásul semmit se tudsz mutatni a felhasználónak, hogy hol tart a kérése. És gyakran nem is szükséges a felhasználót blokkolni, nem feltétlen adatot ment, hanem párhuzamosan több tevékenységet végez az oldalon. Például amíg egy widget töltődik, addig a másikban elkezdhet adatokat begépelni stb. Viszont szinkron eseményekkel te megakadályozod ebben.
85

Egy program (jelen esetben a

Hidvégi Gábor · 2014. Feb. 11. (K), 17.51
Egy program (jelen esetben a node.js) mindig azt csinál, amire programozzák. Ha függvényhívás befejezésével egy callback függvényt hív meg a rendszer, akkor le fogja futtatni. Ha úgy programozzák le, hogy függvényhívás befejeztével visszakerüljön a függvényhívás után következő parancsra a pointer, akkor ezt fogja csinálni.

párhuzamosan több tevékenységet végez az oldalon
Mint írtam korábban, vastag kliens esetén van értelme aszinkronizálni, vékony kliens esetén viszont nem így látom.
90

Egy program (jelen esetben a

BlaZe · 2014. Feb. 11. (K), 21.33
Egy program (jelen esetben a node.js) mindig azt csinál, amire programozzák. Ha függvényhívás befejezésével egy callback függvényt hív meg a rendszer, akkor le fogja futtatni. Ha úgy programozzák le, hogy függvényhívás befejeztével visszakerüljön a függvényhívás után következő parancsra a pointer, akkor ezt fogja csinálni.
De itt aszinkron hívásról van szó, ami külön szálon fut, onnan pedig nem fogsz "visszatérni a hívó szálba" (2 különböző stack, lokális változók stb), ezért szokták ezt async callback hívással megoldani, ami vezethet callback hellhez.

Vannak más megoldások is, pl a java Future-je, amin viszont a get() blocking method, ezért a node.js-ben annak nem lenne sok értelme. A Play megoldása elegánsabb ugyanerre, de ez nem tudom mennyire megvalósítható ebben a formában js-ben...
93

Imho js-nél nézhetjük más

inf3rno · 2014. Feb. 12. (Sze), 03.19
Imho js-nél nézhetjük más szemszögből is a dolgot. Kitalálunk egy új nyelvi elemet, ami megkönnyíti az async kódolát, csinálunk hozzá egy build env-et, hogy core js-ben implementálja, és pont. Ha beválik, akkor lehet javasolni új nyelvi elemnek. (Ez a play féle módszer nekem pl kapásból túlbonyolítottnak tűnik.)
95

De itt aszinkron hívásról van

Hidvégi Gábor · 2014. Feb. 12. (Sze), 08.43
De itt aszinkron hívásról van szó, ami külön szálon fut, onnan pedig nem fogsz "visszatérni a hívó szálba"
A tgr által linkelt oldalon ez áll:
var cachedValue = yield redis.get("bacon:delicious");
A yieldnek hogy sikerül visszatenni a kontextust a függvénybe?
97

A yield kulcsszó eleve csak

MadBence · 2014. Feb. 13. (Cs), 00.04
A yield kulcsszó eleve csak generátorfüggvényekben értelmezett. Ha ilyenben vagyunk, akkor a JS tudja, hogy a yield kulcsszó felfüggeszti a futást (részletesebben @domenic ma esti prezentációjában olvashatsz róla, vagy az én prezentációm végén is megnézhetsz egy lehetséges implementációt)
99

Ha jól értem ez a traceur és

inf3rno · 2014. Feb. 13. (Cs), 03.51
Ha jól értem ez a traceur és continuum mind ES6-ot fordít ES3-ra, vagy valami hasonlóra, ami általánosan értelmezett? Lehetséges a kimenetet böngészőben vagy nodejs-ben használni?

Ahogy nézem még egy darabig várni kell a teljes körű supportra: http://kangax.github.io/es5-compat-table/es6/
100

És mi lenne, ha a háttérben a

Hidvégi Gábor · 2014. Feb. 13. (Cs), 08.57
És mi lenne, ha a háttérben a futtatókörnyezet mindent ilyen csillagos függvénybe csomagolna?
101

A generátorok mindenképpen

MadBence · 2014. Feb. 13. (Cs), 12.40
A generátorok mindenképpen overheadet jelentenek, másrészt ezek nem függvények, hanem példányosított objektumok, így nem is lehet őket úgy használni, mint egy szimpla függvény.
Másrészt a yield kulcsszó jelzi explicit a fejlesztő felé, hogy a "függvény" futása meg fog szakadni (vissza fog térni a vezérlés a hívóhoz). A hívónak fel kell készülnie erre, illetve a programozónak fel kell készülnie arra, hogy folytassa a generátor futtatását (hiszen a futtatókörnyezet ezt honnan tudná?)
88

vekony kliensnel amit

blacksonic · 2014. Feb. 11. (K), 21.21
vekony kliensnel amit felvazoltal...es az jo ha a user var? mert felhasznaloi elmenyt egy ilyen nagy mertekben rontja
sok helyen ezt nem varhatod el a felhasznaloktol

az asszinkronitas nem feltetlenul bonyolitja el az alkalmazast...csak masfajta gondolkodasmodot igenyel
91

Élmény

Hidvégi Gábor · 2014. Feb. 11. (K), 23.03
Mi a fontosabb? Ha a felhasználó vár, de biztosan konzisztens adatokat kap, vagy pedig nem vár, de előfordulhat, hogy az oldal bizonyos részein lévő adatok nem felelnek meg a valóságnak?
92

A fejlesztő dolga, hogy a

MadBence · 2014. Feb. 11. (K), 23.06
A fejlesztő dolga, hogy a felhasználónak biztosítja a megfelelő UX-et, és a konzisztens adatokat.
53

Kicsinyes... No OOP: attól,

vbence · 2014. Feb. 10. (H), 14.31
Kicsinyes...

No OOP: attól, hogy a szerző nem elég kompetens ahhoz
56

Komolyan utána kellett

inf3rno · 2014. Feb. 10. (H), 23.53
Komolyan utána kellett néznem, hogy mit jelent ez a szó: http://www.gyakorikerdesek.hu/kultura-es-kozosseg__egyeb-kerdesek__3399832-kire-mondjak-hogy-kicsinyes. Elméletileg a fukar szinonímája, szóval még mindig nem értem, hogy hogy jön ide... Egyébként a személyeskedésnek nem ez a megfelelő fóruma...
96

Személyeskedés

vbence · 2014. Feb. 12. (Sze), 19.22
Pont erre akartam rávilágítani. Talán a kisstílű megfelelőbb szóhasználat lett volna. De nem feltétlenül a személyedre gondoltam, inkább a hozzászólás tartalmára.
98

Az én személyemre biztosan

inf3rno · 2014. Feb. 13. (Cs), 03.40
Az én személyemre biztosan nem, mert nem én írtam...
61

Azt írja a szerző, hogy ezek

tgr · 2014. Feb. 11. (K), 09.32
Azt írja a szerző, hogy ezek voltak a Javascript hibái régen, amik mostanra nagyrészt megoldódtak. Ebben teljesen igaza van, tíz éve nem voltak csomagkezelők, nem volt normális modulrendszer, és olyan nehéz volt jó dokumentációt találni, hogy egy w3schools a google élére tudott kerülni. Aztán a Firefox és később a Google felújította a böngészőháborút, nagyon komoly elméleti hátterű, röptében optimalizáló JS fordítókkal, jött az instant search és aztán a Gmail, a JS menő lett és mindenki nekiállt jobbnál jobb JS könyvtárakat írni. (Meg közben volt egy kisebb forradalom az opensource kódmegosztásban a gitnek és a GitHubnak köszönhetően, az is segített.)

A jelenlegi kifogásai kevésbé meggyőzőek, egyrészt egy dokumentáció nem attól lesz jó, hogy meg van adva a paraméterek típusa, mert ezt bármilyen komolyan vehető könyvtár hozza, és pont a Java könyvtárakra eléggé jellemző, hogy ki is merül a dokumentáció abban, hogy legyártanak egy apidocot, aztán ha esetleg azt is szeretnéd tudni, hogy hogyan kell használni, akkor vehetsz könyvet sok pénzért. A JS dokumentációk ilyen téren pont hogy általában jobbak, talán azért, mert általában webfejlesztők írják őket, akiknek több közük van a UX-hez.

Másrészt meg az egész cikket átlengi egy olyan érzés, hogy a szerző igazából Javát szeretne programozni Javascriptben, ami egy elég fura dolog, mert Javát mégiscsak praktikusabb lenne Javában programozni. Oké, gyerekkori trauma meg minden, de most már biztos van saját számítógépe, nem szól bele a mostohaapuka, hogy mit telepít rá...
63

off: A gyerekkori traumán jót

inf3rno · 2014. Feb. 11. (K), 09.35
off: A gyerekkori traumán jót röhögtem :D
19

Problémák

Hidvégi Gábor · 2014. Feb. 8. (Szo), 19.18
No standard library. Nap mint nap minden JS fejlesztő újra feltalálja a kereket, mert a legtöbbet használt rutinokat innen-onnan halásszák össze a netről. A legegyszerűbb példái ennek az egyszer ellenőrzőösszeg-számítások (md5, sha1), de ugyanide tartozik szerintem a sablonozás is.

No module system. node.js-ben van ilyen, de ez rendszerspecifikus, böngészőben nincs erre natív megoldás, azaz ismét az első pontnál vagyunk. Egy használható modulrendszerhez kéne egy absztrakt interfészt is definiálni, hogy a standard metódusok ugyanolyan paraméterekkel legyenek (például) megírva.

No language resources. A neten szétszórva találhatóak könyvek, de kérdés az, mennyire követik ezek a nyelv változásait.

Client and server JavaScript still completely disconnected. Szerintem ez így jó, mert rugalmas.


Szerintem a JS legnagyobb baja, hogy nem arra használják az emberek, amire kitalálták: kicsit kényelmesebbé tegyük vele a böngészési élményt. Sokmindent lehet vele csinálni, de végeredményben mindenképp szerverhez kell fordulni, és adatokat kell elküldeni, vissza pedig adatokat vagy HTML-t kapunk, és HTML-t jelenítünk meg.

Nyilván egy Canvasra rajzoló programnál nem így van, de az általam eddig meglátogatott oldalak, ahol nagy betűkkel hirdették, hogy a használathoz JS szükséges, semmi nem volt, amit nem lehetett volna hagyományos módon (HTML a szerverről, a JS csak kényelmi/szépség célokat szolgál), ráadásul jóval egyszerűbben megoldani, úgy, hogy a felhasználói élmény pontosan ugyanaz, mint a csak JS változatban.

No OOP. Ha az előzőekben leírtak szerint dolgozunk, talán nincs is rá szükség (kliensoldalon).
21

No standard library.Ott van

inf3rno · 2014. Feb. 8. (Szo), 19.29
No standard library.


Ott van pl az underscore.js, ami mondható hasonló kezdeményezésnek. Nekem mondjuk nem feltétlen jön be az ő elképzelésük arról, hogy hogyan kell egy ilyen lib-nek kinéznie, de azért használom backbone-hoz, és annyira nem rossz. Gondolom vannak más gyűjtemények is ezzel kapcsolatban. Elég egyszer megtalálni a megfelelő könyvtárakat, és onnantól nem kell mást használni. Erre nyilván rá kell szánni 1-2 napot, mert rengeteg ilyen van.

No module system.


https://github.com/substack/node-browserify
Elméletileg lehetséges npm modulokat bizonyos keretek között böngészőben használni. Nyilván ehhez kell egy build...

No language resources.

Nem igazán értem az ezzel kapcsolatos parát. Van egy ECMAScript standard, minden le van írva benne a nyelvvel kapcsolatban. Ezen kívül, hogy az egyes modulok - pl a böngészőben a DOM kezelő - mit csinálnak, egyáltalán nem tartozik a nyelvre. Jó lenne valami központi szabvány arra, hogy a böngészőknek mit hogyan kellene csinálni, próbálkozik is vele a w3c már nagyon régóta, de eddig gyakorlatilag semmi nem lett belőle. Nem véletlen nem fejlődött nagyon sokáig a kliens oldali js, szükség volt egy libre: jquery, prototype.js, ami elfedi a böngészők közötti különbségeket. A nodejs-nél nem volt ilyen probléma, többek között azért is fejlődik ennyire dinamikusan. Na meg azért is, mert jól választották meg, hogy a core mit támogasson, és mit bízzon a fejlesztőkre.

Client and server JavaScript still completely disconnected.

Nem értem, hogy ezalatt pontosan mire gondol. A disconnected azért van, mert HTTP-vel mennek a kérések. Maximum azt lehetne, hogy ugyanazt a DOM-ot felépítjük a szerver oldalon is, mint ami a kliens-ben van, de baromi költséges és értelmetlen lenne. Lehet socket.io-t használni, ha valakinek nem jön be a http protokoll, annál ha jól emlékszem már van olyan lib, amivel direktbe lehet hívni szerver oldali függvényt a kliensből.
22

»Client and server JavaScript

Hidvégi Gábor · 2014. Feb. 8. (Szo), 19.33
»Client and server JavaScript still completely disconnected.« Nem értem, hogy ezalatt pontosan mire gondol.
Erre:

Then Node.js came out with some wanky benchmarks and, more importantly, a promise for code reuse on the client and server, a promise not really capitalized on until recently, with the likes of Meteor and Derby.
23

Ohh. Hát én más irányt

inf3rno · 2014. Feb. 8. (Szo), 19.40
Ohh. Hát én más irányt követek már egy ideje, úgyhogy ehhez nem tudok hozzászólni. Nincs igényem ilyesmire, de ha lenne, akkor maximum ugyanolyan sablonokat használnék kliens és szerver oldalon is, és ennyi. Nem különösebben izgalmas téma.
24

Client and server JavaScript

Poetro · 2014. Feb. 8. (Szo), 19.47
Client and server JavaScript still completely disconnected.

A Java-n kívül melyik más nyelvben nincs ez ugyanígy?
27

Js-ben.Van lehetőség

inf3rno · 2014. Feb. 8. (Szo), 20.01
Js-ben.

Van lehetőség socket.io-val és now.js-el RPC-re: https://github.com/Flotype/now
Van lehetőség browserify.js-el közös kód használatára: http://browserify.org/

Ennél többet szerintem java sem biztosít, de javíts ki, ha tévedek...

Hmm vannak olyan rendszerek, amik egy az egyben generálják a kliens oldali kódot, de azok baromi lassúak. Lehet, hogy arra gondoltok.
25

Hmm egyébként jó ez a

inf3rno · 2014. Feb. 8. (Szo), 19.48
Hmm egyébként jó ez a beszélgetés, lehet, hogy áttérek requirejs-ről browserify-ra, még megnézem, hogy karma-val mennyire összeegyeztethető.
28

https://github.com/xdissent/k

inf3rno · 2014. Feb. 8. (Szo), 20.11
https://github.com/xdissent/karma-browserify

Úgy néz ki teljesen támogatott a browserify a karma-ban, úgyhogy áttérek rá, és elfelejtem a requirejs-t örökre. Sokkal jobb eleve az npm-et használni kliens oldali kódhoz is, nem pedig kézzel töltögetni a netről az új verziókat...
89

jo latni, hogy azert a

blacksonic · 2014. Feb. 11. (K), 21.24
jo latni, hogy azert a tobbseg kedveli a Javascriptet es a vele jaro asszinkronitast
az ilyen utalkozo cikkeket sosem ertettem...ebbe meg erot befektetni hogy a csopogo utallatat kifejtse
94

Hát biztos sok ideje van,

inf3rno · 2014. Feb. 12. (Sze), 03.21
Hát biztos sok ideje van, vagy frusztrált, mert nem tud js-ben kódolni...