- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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.
- A hozzászóláshoz be kell jelentkezni
első ÉS második :D
Azért utálom, mert kiismertem...
- A hozzászóláshoz be kell jelentkezni
Mi nem tetszik? :)
- A hozzászóláshoz be kell jelentkezni
Ez a korszellem, elviselem, nincs vele bajom + Ghostery :-D
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+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 hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Bocs, félreérthető voltam. Ilyet nem lehet:
class X{
var name;
}
tehát osztályban változót (az osztályszintű tényleg zavaró volt, nem a staticra gondoltam, hanem a member változóra)
- A hozzászóláshoz be kell jelentkezni
Érdekes class-levelről beszélni egy olyan nyelven, ami prototípus és nem class alapú.
Meg kell érteni a prototípus alapú öröklődést.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
class X {}
X.name = "...";
simán megteheted. Nem szép, és lehet, hogy az IDE se fog segíteni ilyenkor.
- A hozzászóláshoz be kell jelentkezni
igen, így lehet megcsinálni. Se nem szép, se az IDE nem segít:D
- A hozzászóláshoz be kell jelentkezni
Ezzel az a baj, hogy X prototípusába nem kerül bele a name.
- A hozzászóláshoz be kell jelentkezni
Miért kellene belekerülnie? Statikus változóról van szó.
- A hozzászóláshoz be kell jelentkezni
Jogos, nem olvastam el rendesen. Illetve fent még arról volt szó, hogy nem statikus kell. :)
- A hozzászóláshoz be kell jelentkezni
Bocsi, akkor én nem olvastam :)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
+1 Az igazi kódgányoló bármilyen nyelven képes sz@r kódot kiadni a keze alól. :-P
- A hozzászóláshoz be kell jelentkezni
(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.
- A hozzászóláshoz be kell jelentkezni
Így van, mindent lehet jól és rosszul is használni. De a felhasználási módjáról nem az eszköz tehet.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Hogy a picsába jön ide a Java? Amúgy azzal sincs semmi baj, megfelelően használva ütőképes eszköz.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
- A hozzászóláshoz be kell jelentkezni
> Amúgy azzal sincs semmi baj, megfelelően használva ütőképes eszköz.
+1, különösen a "megfelelően használva" rész miatt :)
- A hozzászóláshoz be kell jelentkezni
Lásd még Kira (applets/midlets are the future!!!)
- A hozzászóláshoz be kell jelentkezni
Troll-e vagy? Mit dolgozol?
- A hozzászóláshoz be kell jelentkezni
Pedig JRE1.2 óta már egész használható :-).
- A hozzászóláshoz be kell jelentkezni
loool, made my day...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
dzsunkaszkript, nemsokára mennek ők is a flash után a kukába/kapálni a havasalföldre a románcigányoknak.
- A hozzászóláshoz be kell jelentkezni
Úgy vagyok a Javascripttel, mint Etus a kemény rock-al: Kapaszkodjon meg, szeretem!
- A hozzászóláshoz be kell jelentkezni
A baltát vagy a csavarhúzót szeretem? Pont annyira mint a kalapácsot..
Csak meg kéne tanulni mindent arra használni amire való..
---
Referrall https://goo.gl/7S2vlp (koding) | https://goo.gl/muWzKz (digitalocean)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Az ES4-et sem sikerült átverni a böngészőgyártókon. Szerintem a JS örökre berágta magát a webes világba.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"Tény, hogy a JS foltozgatásával nem jutunk sehova, és ahogy írtad változatni nehéz."
Szerintem ennek ellentmond az ES6.
- A hozzászóláshoz be kell jelentkezni
Az ES6 nagyon jó, de kevés. Nem fogja tudni megoldani azokat a problémákat, amikkel együtt kell élni a visszafele kompatibilitás megtartása végett. Mert azt meg kell.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 :))
- A hozzászóláshoz be kell jelentkezni
-- dupla --
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
nyilván ezt hosszú évek java fejlesztői tapasztalatával mondod...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Javaban speciel ez le sem fordul, az a=2 kifejezés típusa nem boolean.
Az ifben pedig csak boolean típusú érték lehet.
- A hozzászóláshoz be kell jelentkezni
Igen, ezt a "feature-t" C-ből vette át.
Minden normális nyelvben ez egy hiba (természetesen Jávában is).
Jávából nekem toString() ismerős, illetve a Date.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
Na és ez..?
$ ruby -W0e "puts 'bazmeg!' if a = 0"
bazmeg!
:)
- A hozzászóláshoz be kell jelentkezni
A Ruby nálam válóok!
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
A Ruby nálam válóok!
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
"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 hozzászóláshoz be kell jelentkezni
Biztos hozzászokott Pascal-ban, hogy az értékadás az a:=2 lenne :-P
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Inkább az a kérdés, hogy mitől nem amikor konvenció szerint igaz minden amiben van 1 értékű bit, false amiben nincs, vagyis 0. Mivel bájtos szervezésű a memória, vagy akár több bájtos, egy bites típusokról nem érdemes beszélni.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Igazi programozók vs. hátulgombolósak? :-D
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
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) :)
- A hozzászóláshoz be kell jelentkezni
Az a baj az implicit konverzióval, hogy könnyen elsiklasz felette. A compiler meg nem szól, mert nyelvileg teljesen helyes a dolog. Minden dolog, ami implicit, abban rejlik egy csapdahelyzet: "jajj, nem gondoltam rá, elfelejtettem, siettem" stb.
- A hozzászóláshoz be kell jelentkezni
Itt szerintem az "a=2 vs. "a==2" keveredése okozhat problémát, de hátulgombolósok úgy is "a:=2"-vel adnak értéket :-P
- A hozzászóláshoz be kell jelentkezni
"e hátulgombolósok úgy is "a:=2"-vel adnak értéket :-P"
De az igazán hátulgombolósok LET A = 2-t írnak.
- A hozzászóláshoz be kell jelentkezni
"Mitől lenne egy szám igaz logikai érték?"
Mitől lenne hamis logikai érték? Illetve minek kellene történnie, ha a 2-t mint értéket próbálnád egy ifben használni?
"Összekevered a boolean (true, false) és a truthy/falsy dolgokat"
Ezt miből vetted?
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
#define logikai_érték
Érdekes ez a nem lehet... Simán lehet használni a kettőt logikai kifejezésben elég sok nyelvben, és ahol meg tudtam hirtelen nézni, ott "igaz"-ként kerül értelmezésre.
ha valami lehet true/false/null, arra mit lépsz?
- A hozzászóláshoz be kell jelentkezni
Normális nyelvekben nem fordul le, mert amíg lehet null, addig optional, s nem logikai érték.
Kevésbé normális nyelvekben npe a null.
--
blogom
- A hozzászóláshoz be kell jelentkezni
"ha valami lehet true/false/null, arra mit lépsz?"
Az nem Boole-logika, ez a nagy helyzet.
Hány olyan programozási nyelvet ismersz, amelyben az if() háromállapotú eredményt ad, azaz nem csak egy else, hanem egy elsenull ága is van?
- A hozzászóláshoz be kell jelentkezni
de attól még logikai érték, csak nem két, hanem három állapotod van. Mint a H, L, Z érték a 3state kimenetű kapuáramköröknél :-P
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
MInt fentebb volt, a megfelelő lint szól, hogy az if-ben a feltételt hátulgombolósan írta valaki, egy egyenlőségjellel :-P
- A hozzászóláshoz be kell jelentkezni
Tehat mostmar van egy "opcionalis compiler" JS-hez is. Hurra!
- A hozzászóláshoz be kell jelentkezni
Nem csak egy van, van több is! :)
Én nem vagyok nagy JS szakértő, de még én is ismerek többet: pl. JSLint, JSHint. Illetve a WebStorm is rengeteg funkcióval bír, az a sejtésem, hogy még az is tudja ezt.
Ráadásul nem most lettek, hanem elég régóta vannak.
- A hozzászóláshoz be kell jelentkezni
"Azért, hogy könnyebb legyen eladni a C-programozóknak?"
Viszont magukra is haragitottak oket rogton a "'" es a '"' felcserelhetosegevel :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Én sem szoktam.
Ugyanezt nem mondhatom el a gyakornokokról vagy junior kollégákról.
Persze egy senior fejlesztővel is megeshet időnként.
A tesztek meg vagy lefedik, vagy nem.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
C/C++ programozóként rühellem a javascriptet, ha ez megnyugtat. ;)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Get dropbox account now!
- A hozzászóláshoz be kell jelentkezni
"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!!!
- A hozzászóláshoz be kell jelentkezni
Normális fejlesztői eszközkészlet esetén ilyenre hibát kapsz, pl. a JSLint ezt mondja: "Expected a conditional expression and instead saw an assignment."
- A hozzászóláshoz be kell jelentkezni
Korrekt, hogy szól, mert hátha Pascal-on nevelkedett programozó írta a kódot :-P
- A hozzászóláshoz be kell jelentkezni
Úgy látom azon kevesek közé tartozhatok, aki kifejezetten szereti ezt a nyelvet :)
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
kb. +1
lehet, egyszer kellene belefeccölni néhány napot, megtanulni részletesebben.
--
blogom
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az implementációk (böngészők) csodálatos működése az, ami miatt ilyennek tűnik... Szerintem :-P
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Typescript-et tudnám javasolni, vagy gwt-t (java), vagy bármilyen típusos nyelvet, ami js-be fordít.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Ezek működéséről tudnál mondani egy-két mondatot? Miért jó, hogy működik a gyakorlatban, mi a munkamenet?
Cözi
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
"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 :)
- A hozzászóláshoz be kell jelentkezni
A webprogramozas nehez, es egyre tobb mindent kell hozza tudni, valoban :/
- A hozzászóláshoz be kell jelentkezni
Definiálni kellett volna egy "virtuális gépikódot" (mint a .NET IL-je vagy a Java bytekódja) annak idején, amire mindenki úgy fordít, ahogy akar.
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
Főként nem ez a baj. Hanem az, hogy nincsen egységes implementáció az API-k mögött sem. Nem csak a nyelvi implementációk különböznek (azok a legkevésbé), hanem a különféle W3C API-k implementációi. Ez utóbbin nem segít semmiféle bytekód.
- A hozzászóláshoz be kell jelentkezni
É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]
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"Szerk2: amugy tudunk sikeres, nagy volumenu Node projectrol?"
PayPal, Netflix.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
netflix nagy resze szerintem azert java
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
> amugy tudunk sikeres, nagy volumenu Node projectrol?
Mapbox. Kb mindenük Node.js, nagy része open-source, rengeteg kód dolgozik mögötte.
- A hozzászóláshoz be kell jelentkezni
Na erre azert kivancsi vagyok :)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Az irtanám szerintem rövid i-vel helyes.
- A hozzászóláshoz be kell jelentkezni
JS az itt mit jelent? Javascriptet?
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
igen
--
blogom
- A hozzászóláshoz be kell jelentkezni
Locky containert. ;)
- A hozzászóláshoz be kell jelentkezni
Találós kérdés JS mestereknek: miért ezt írja ki:
[] + []
""
[] + {}
"[object Object]"
{} + []
0
{} + {}
"[object Object][object Object]"
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
Mert... mert... de amugy mas nyelvben is vannak ilyenek!!11
- A hozzászóláshoz be kell jelentkezni
Wat ;)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Igazából egy belső céges JS tréningen tanultam, de lehet, hogy az oktató a watról vette.
Régen a 4. eset NaN-t adott, úgy látszik, azüta változott (a Chrome konzolja).
Fuszenecker Róbert
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ezt nem értem.
Itt szó nincs utasításblokkról.
Egy-egy utasítás van itt, összeadás kifejezés mindegyik.
A + egyik oldalán sem állhat utasításblokk, ezek object literalok:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-object-in…
- A hozzászóláshoz be kell jelentkezni
Az én verzióm magyarázza a 3-as és 4-es (Wat-beli) eredményét is, illetve te magad is kipróbálhatod repl.it-en. :) Bővebben kifejtettem itt.
- A hozzászóláshoz be kell jelentkezni
Akit érdekelt: szerintem fény derült a dologra:
http://hup.hu/node/147535?comments_per_page=9999#comment-1989101
- A hozzászóláshoz be kell jelentkezni
Jahogy ezt hivjak intuitivnek!
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
Akinek még nem ment el a kedve a nodejs fejlesztéstől itt egy lelombozó írás :)
https://kev.inburke.com/kevin/one-year-of-node-js/
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Funkcionális szemszögből nagyon barátságos és csupa vidámság javascriptben programozni :)
hát ES6-ban lehet, hogy így van, ES5-ben egyáltalán nem mondanám :)
- A hozzászóláshoz be kell jelentkezni
Ramada fagylaltban is fenomenális (sacc/kábé a negyedik generáció viszo a cukrász mesterséget...), bár a webes megjelenés, mondhatni kissé ódivatú: http://ramadabufe.uw.hu/
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Csakhogy a JS már nem csak egy scriptnyelv, pont arról van itt is szó, hogy rengetegen komplett BE rendszerek fejlesztésére használják.
Ott meg hátrány az, hogy minden kis szarra, ami sokszor használt dolog, kell egy lib.
- A hozzászóláshoz be kell jelentkezni
Az ilyen igény kielégítésére találták ki a framework-öket.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Í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.
- A hozzászóláshoz be kell jelentkezni
Ne kelljen framework (se lib) hogy egy sprintf vagy string.format szintű funkcionalitás benne legyen egy nyelvben.
- A hozzászóláshoz be kell jelentkezni
Az sprintf nem része a nyelvnek C-ben, ezt azért jobb, ha tisztázzuk. A standard könyvtár része. Az, hogy a JS standard könyvtár gyakorlatilag nem létezik, az meg a JS problémája.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Egyik sem.
Elfogadom, hogy sok dologra jó, de ismerem is, ezért noscript nálam alapvető plugin.
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni