Why JavaScript Still Sucks
A platformmal még mindig alapvető problémák vannak
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Hojtsy Gábor:
"Karaktersorozatok sebessége" PHP-ben
Balogh Tibor:
Három kiterjesztés a Zend motor működésének megismeréséhez
dtaylor:
PostgreSQL telepítése és beállítása
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
Nem igazán értem az ilyen
Ez az írás nem erről szól.
Szerinted.
Épp ellenkezőleg
A probléma fő összetevője ez
A probléma fő összetevője ez
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?
Ezek mind valamilyen
ES6 mennyire elterjedt?
Ez a js Harmony jónak ígérkezik...
Ha natívan akarod használni,
Komoly, kifolyt a szemem. :D
On
Hát szerintem egyáltalán nem
A js-ben az oop alapból
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.
Miért van az, hogy szinte
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
classkulcsszó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.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.
A "Miért van az, hogy egyesek
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.
Elvileg az ActionScript is
Prototípusos is
Passz, én sosem használtam
off: Személy szerint nem sajnálom, nálam napi szinten száll el még a youtube-nál is néha...
AS
Más nyelv, más "trükkök". Az
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?
Imho alapvetően nincs semmi
Csak, hogy kiegészítsem. A
Elég sok marhaság van a
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:
for (var i=0; i<arr.length; i++)rather thanfor e in arr?JS-ben is lehet egyszerűen iterálni:
for(e of arr), vagyforEachGondolom 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).
+1
-1
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?
Az OOP a legtöbb programozó
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.
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)
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).
El kéne fogadni, hogy a JS
É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?
Szerinted melyik mögül állnak
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).
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)
Megfelelően mature modulokat
míg a JS-nél (nem csak
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.
Nem igazán értem az
PHP standard könyvtárról volt
Ráadásul bármilyen gyors
Keress ra es olvass utana asm.js nek...alig lassabb mint egy Cben irt alkalmazas (ha jol emlekszem 20-30% kal)
asm.js
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.
Az a helyzet (ahogy azt
Sok kicsi sokra megy.
nem kell megtanulnod másik
Ha JS-nek lenne mondjuk egy
Szükség van erre? A
Ha a fejlesztő kliens-oldalon akar MD5-öt számolni, akkor használjon erre írt userland modult.
Az md5 egy kiragadott példa,
Már miért kéne egy standard
Az OOP a legtöbb programozó
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...
Nem hasonlítok én semmit se
Nem igazán értem, hogy ez
+1 Annyit azért hozzátennék,
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...
Használj promicokat.
Milyen műveleteknél van szükséged aszinkronitásra?
Milyen műveleteknél van
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.Próbáltam valami frappáns közmondást találni, de csak azt dobta a google, hogy
»Milyen műveleteknél van
Ennek az az oka, hogy a php
event loop
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).
Nem ez a lényeg. Persze meg
Kódolj procedurálisan, és
Probaltal mar nodejs ben proceduralisan kodolni? Mert elobb lovom fejbe magam mint hogy kiprobaljam
Hát, igen, ott nem lehet,
Es mennyivel jobb ha egy
Mennyivel? Miért kéne egy
nem kell itt single page
Az nyilvánvaló, hogy grafikai
Hogy ennek megvalósításához
É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.
akárhogy írod meg egy ilyen
Véletlenül épp a Preziéhez
nem az egy fos projektekre
mi a baj a bind call apply al?
Nem egyedüli meló, többen
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.A bind-nál a legjobb, ha
A call-os fejtegetésedet nem tudom értelmezni.
call
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.
Ha nem tetszik a hosszú neve,
pedig pont ezek teszik
nincs abstract method, nincs
Olyan statikus elemzőt használsz, amilyet jólesik. A Closure pl. tudja mindezeket.
A generátoros-promise-os megoldás azért elég jól néz ki.
Igen, a yield az jó, de mikor
Egyre inkább úgy látom, hogy
Mennyivel egyszerűbb lenne,
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.
Aszinkron
whileciklusba, 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).node
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.
Szerver:Az aszinkronitásnak
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)
Ha te valamit lekérsz az
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.
Ki akadályozza meg, hogy mást
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.
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 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.
Egy program (jelen esetben a
Egy program (jelen esetben a
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...
Imho js-nél nézhetjük más
De itt aszinkron hívásról van
var cachedValue = yield redis.get("bacon:delicious");A yieldnek hogy sikerül visszatenni a kontextust a függvénybe?
A yield kulcsszó eleve csak
Ha jól értem ez a traceur és
Ahogy nézem még egy darabig várni kell a teljes körű supportra: http://kangax.github.io/es5-compat-table/es6/
És mi lenne, ha a háttérben a
A generátorok mindenképpen
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á?)
vekony kliensnel amit
sok helyen ezt nem varhatod el a felhasznaloktol
az asszinkronitas nem feltetlenul bonyolitja el az alkalmazast...csak masfajta gondolkodasmodot igenyel
Élmény
A fejlesztő dolga, hogy a
Kicsinyes... No OOP: attól,
Komolyan utána kellett
Személyeskedés
Az én személyemre biztosan
Azt írja a szerző, hogy ezek
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á...
off: A gyerekkori traumán jót
Problémák
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).
No standard library.Ott van
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.
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...
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.
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.
»Client and server JavaScript
Ohh. Hát én más irányt
Client and server JavaScript
A Java-n kívül melyik más nyelvben nincs ez ugyanígy?
Js-ben.Van lehetőség
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.
Hmm egyébként jó ez a
https://github.com/xdissent/k
Ú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...
jo latni, hogy azert a
az ilyen utalkozo cikkeket sosem ertettem...ebbe meg erot befektetni hogy a csopogo utallatat kifejtse
Hát biztos sok ideje van,