RedMonk: A JavaScript a király, de jön föl a Python, a CSS és a Swift is

RedMonk: A JavaScript a király, de jön föl a Python, a CSS és a Swift is
2018-03-12T12:51:27+01:00
2018-03-23T08:54:00+01:00
2022-10-19T03:41:50+02:00
  • Hagyjuk már ezt a paypal-os példát

    Mert, miért? Mert kényelmetlen? A korábban linkelt oldalon egyébként van több másik példa is arra, hogy bankok node.js-re váltottak.

    Ha egy kicsit megkaparjuk, arról volt szó, hogy volt egy sz@r, összetákolt framework-jük, amire építették a rendszert, és ahhoz, hogy ezt le tudják váltani, és rendberakni, kitalálták, hogy váltanak node.js-re, és így a management is rábólintott.

    És ezt te honnan tudod? Megírta a The Lone Gunman? Vagy van valami hiteles forrás is erre a sztorira?

    Már annyi ilyen cikk volt, hogy X-et lecseréltük Y-ra, és az mennyivel jobb, közben meg általában kiderül, hogy X-ben is meg lehetett volna csinálni, csak újra kellett volna írni már az új tapasztalatokkal, ami ugye nagyon nehezen megy át a management rétegen.

    Mert miért? És mellesleg ez akkor nem igaz, amikor valami előző platformról pl. Java-ra vagy .NET-re váltottak, váltanak? Vagy akkor szakmailag megalapozott volt a döntés, és mindig csak akkor divatlovagolás, amikor .NET-ről, Java-ről elváltanak egy még újabb technológiára, mint a Node.js?
    Mutasd a teljes hozzászólást!
  • Ha már szóbakerült a bank: a banki rendszereknek érdekes módon egy nagyon kis része az, ami a felhasználó felé megjelenik. A belső rendszerek jó része java/.net-ben van fejlesztve, egyszerűen azért, mert jól definiált interface-re épülő SOA architektúrát használnak, szóval a feladat jó része adatbázis turkászás, adattranszformáció A-ból B-be, üzleti logika/matematikai modell lekódolása, webservice írás, stb. ebben a környezetben a javascript-nek sok szerepe nincs.
    Mutasd a teljes hozzászólást!
  • Hagyjuk már ezt a paypal-os példát. Ha egy kicsit megkaparjuk, arról volt szó, hogy volt egy sz@r, összetákolt framework-jük, amire építették a rendszert, és ahhoz, hogy ezt le tudják váltani, és rendberakni, kitalálták, hogy váltanak node.js-re, és így a management is rábólintott. Már annyi ilyen cikk volt, hogy X-et lecseréltük Y-ra, és az mennyivel jobb, közben meg általában kiderül, hogy X-ben is meg lehetett volna csinálni, csak újra kellett volna írni már az új tapasztalatokkal, ami ugye nagyon nehezen megy át a management rétegen.
    Mutasd a teljes hozzászólást!
  • A kulcsszó a "szerinted". A valóságban meg úgy működik, hogy az alap, hogy a pénzed nem veszik el a számládról

    Na ja. Ez a lényeg.

    de az emberek két bank közül azt fogják választani, amelyiknek szebb és jobban használható a bank felülete

    Nem. Általában azt fogják választani, ami kedvezőbb szolgáltatást nyújt. Pl. olcsóbb hitelt, jobb kényelmi szolgáltatásokat. Ezek közül egy a webes felület. Aztán hogy mobilra mit csinálnak az megint egy másik kérdés.

    Ezek a "selling point"-ok teszi "hű de szuper" technológiává.

    Nem, ezek a pontok a platform jellegéből adódnak nem a technológiájából. Ugyanúgy meg lehetne ezt csinálni teljesen más alapokon is, Pl. xml helyett bináris adatok, javascript helyett python vagy akár java vagy bármilyen más nyelv. Sőt, meg lehetett volna nyelvfüggetlenre is csinálni, ha egy bináris p-kód megy le a kliensre amit bármilyen nyelvből elő lehet állítani, ahelyett hogy fixre bedrótozzák a javascriptet.

    A linkelt blogposztban leírták mire. Olvasd el!

    Olvasnám ha betöltődne.

    Na, mennyi? Ha nem tudod, hogy akár egyetlen sor is van C++-ban vagy Java-ban, akkor miért említed egyáltalán ezeket a nyelveket?

    A C++-t azért, mert azzal lehet legegyszerűbben natív extension-t írni a node-hoz. A javát pedig azért, mert ha felmész a paypalcareers.jobs-ra, azt látod, hogy eléggé keresik őket. Persze nyilván azért, hogy node-os fejlesztőket képezzenek belőlük...
    Mutasd a teljes hozzászólást!
  • Bocsanat, azt mondtad, hogy az, hogy nem vesztik el a penzuket az alap.

    És nem az? Hiszen még te magad is ezt mondtad (hogy ti. az emberek az alapján választanak bankot, ahol nem, illetve a legkevesebbet vesztik el a pénzükből, pl. a számlavezetési díj révén)? Vagy mit is szerettél volna mondani?

    Nem vitatkozom tovabb veled.

    Te eddig sem velem vitatkoztál, hanem a tényekkel, illetve olyan hülyeségekkel, amit ugyan nekem tulajdonítottál, de valójában te találtad ki őket.
    Mutasd a teljes hozzászólást!
  • Bocsanat, azt mondtad, hogy az, hogy nem vesztik el a penzuket az alap.

    Nem vitatkozom tovabb veled.
    Mutasd a teljes hozzászólást!
  • Szóval szerinted az emberek azt a bankot fogják választani, ahol alacsonyabb a számlavezetési díj - akkor is, ha ott elvesz(ít)ik a pénzüket; ha a banknak nincs egyetlen fiókja sem Magyarországon; ha nincs online banki felülete; stb. Igaz?

    Látod? Én is tudok ilyen hülyeségeket adni a szádba, ha nem érteni akarom azt amit leírtál, hanem valami hülyeséget belemagyarázni, amit tételesen nem cáfolnak az állításaid.

    Nem mintha az alacsony bank költségekre ne pont ugyanaz lenne igaz, amit írtam, hogy ti. pont azzal tudja a bank az alacsony számlavezetési költséget biztosítani, ha olyan nyelvet és technológiát használ szolgáltatásai implementálásához, ami a lehető legtöbb platformon fut, a legkisebb energiával teszi lehetővé a legszebb felület felépítését, stb. Csak mondom.
    Mutasd a teljes hozzászólást!
  • Veled beszélgetni, vitatkozni kb. olyan, mint sajtreszelővel ....

    "Amely kijelentésed egyrészt milyen reprezentatív felmérésre, forrásra alapozod? Vagy csak légből kaptad ezt is?"

    "Nem mintha kaptunk volna tőled bármilyen hitelt érdemlő adatot, forrást eddig arra vonatkozóan"

    Mire kijelented, hogy "A valóságban meg úgy működik, hogy az alap, hogy a pénzed nem veszik el a számládról - de az emberek két bank közül azt fogják választani, amelyiknek szebb és jobban használható a bank felülete, több eszközről érthető el, stb."

    Nem mintha kaptunk volna tőled bármit is ezt alátámasztandó.

    S bár nincsenek mindent igazoló reprezentatív adataim, a KSH -tól azért azt tudom, hogy a lakosság nagy része nemhogy megtakarítással nem rendelkezik, de konkrtétan örül, ha a sárga csekkjeit be tudja fizetni. 

    A nemkevés devizahiteles példája is mutatja, hogy nálunk a pénzügyi kultúra nagyjából a béka feneke alatt van.

    Az egyszeri paraszt azt sem tudja, mi az a csoportos beszedési megbízás, ezen kívül nem csak Budapestől áll magyarország (ha maradunk itthon), sokan azt sem tudják mi az a net.

    Itt pedig b#romira nem azt nézik az emberek, hogy milyen a weboldalt, mennyire csicsás, hanem azt, hogy mennyibe kerül a számlavezetési díj, mert nincs annyi (fix) fizetése, hogy megugoraja azt a határt, ahol a havi fix utalás miatt ezt nullázni tudja.

    Örül ha kap SMS-t, meg van telebankja.
    Mutasd a teljes hozzászólást!
  • Azért egy banknál szerintem kevésbé lényeges a csicsás felület mint az, hogy ne vesszen el a pénzed a számláról.

    A kulcsszó a "szerinted". A valóságban meg úgy működik, hogy az alap, hogy a pénzed nem veszik el a számládról - de az emberek két bank közül azt fogják választani, amelyiknek szebb és jobban használható a bank felülete, több eszközről érthető el, stb. A bank pedig utóbbi miatt azt az eszközt fogja választani a felület megvalósításához, amin kevesebb energiából tudja elérni, hogy szebb, jobban használható legyen és több platformon fusson. Ebben pedig a HTML, a CSS és a JS, nem csak együtt, de külön-külön is nagyon erős.

     És a webnek egy rakás olyan selling pointja van ami megkerülhetetlenné teszi: Pl. mindenki ismeri, egy kattintásal el lehet indítani a programot anélkül hogy települne a júzer gépén, stb. De nem azért, mert olyan hű de szuper technológia

    De. Ezek a "selling point"-ok teszi "hű de szuper" technológiává. Az, hogy ezen kívül mostanra már fejlesztői szempontból is igen sok téren ver sok más klasszikus technológiát, már csak ráadás.

    Ehhez azért nem ártana egy architekturális leírás a PayPal-ről. Mert ok, használnak node.js-t, de mire ?

    A linkelt blogposztban leírták mire. Olvasd el!

    Mennyi része van az üzleti logikának a node-os szerveren, ebből mennyi a C++-os addon, mennyi van tárolt eljárásokban a szerveren, mennyi esetleg a háttérben futó nem javás - és esetleg nem is PC-s - rendszereken.

    Na, mennyi? Ha nem tudod, hogy akár egyetlen sor is van C++-ban vagy Java-ban, akkor miért említed egyáltalán ezeket a nyelveket? És ha van is ezekben valamennyi kód, honnan tudod, hogy teljesen más nyelvekben (amikről talán nem is hallottál) meg nincs még 100x annyi kód, mint ezekben?

    Ezek mind olyan kérdések amiket innen nem fogunk tudni megválaszolni, e nélkül viszont elég nehéz megítélni a js szerepét ez ügyben.

    Na, de látod, ahhoz képest, hogy - még saját állításod szerint is - halvány lila gőzöd sincs a bankok, pénzügyi intézetek rendszereinek pontos belső architektúrájáról, és arról, hogy egyes nyelveket milyen mennyiségben, milyen feladatokra, stb. használnak, mégis mindig azzal jössz, hogy de hát a JS-t biztosan nem használják a bankok, mert oda komoly nyelv kell, nem egy weblap. Amiben a legkevesebb, hogy összekevered a feladatot az eszközzel - de a nagyobb probléma, hogy légből kapott feltételezésekkel élsz, egyik és másik oldalon is.

    Úgy általában pénzügyi területeken leginkább javás embert keresnek, esetleg .NET-eset, esetleg PHP-set bár azt már nem annyira a bankok.

    Amely kijelentésed egyrészt milyen reprezentatív felmérésre, forrásra alapozod? Vagy csak légből kaptad ezt is? De ha feltételezzük egy gondolatmenet erejéig, hogy igazad van, akkor is: Szerinted miért keresnek inkább/több .NET-es vagy Java-s embert? Feltétlenül azért, mert ilyenekből többre van szükség? Vagy lehet azért, mert az ilyen emberek esetleg gyakrabban mondanak fel, esetleg lustábbak dolgozni, és gyakrabban rúgják ki őket? Esetleg eleve nehezebb megfelelő jelentkezőt találni, mert több az amatőr közöttük? Ezek mind megnövelhetnék a nekik szóló álláshirdetések számát, akkor is, ha nincs szükség rájuk nagyobb - vagy akár ugyanakkora - mennyiségben, mint más nyelvvel dolgozó fejlesztőkre ezen a területen.

    És ha tényleg több .NET és/vagy Java fejlesztő is lenne banki területen, az szerinted feltétlenül azt jelentené, hogy ezek a nyelvek jobbak és szükségesebbek az ott felmerülő feladatok ellárásához? Nem lehetne, hogy akkor is azért van szükség olyan sok .NET és/vagy Java fejlesztőre banki területen, mert ezek a nyelvek nagyon rossz - de kényszerűségből cipelt - eszközök a banki feladatok megoldására, amivel csak lassabban lehet haladni, amikhez több ember kell ugyanaz a feladat elvégzéséhez, és ezért kell több .NET és Java fejlesztőt felvenni? Ez is teljesen logikus válasz lehetne arra a kérdésre, hogy miért van esetleg többre szükség belőlük banki területen (is), mint mondjuk HTML+CSS+JS fejlesztőkre.

    Nem mintha kaptunk volna tőled bármilyen hitelt érdemlő adatot, forrást eddig arra vonatkozóan, hogy tényleg többen lennének akár csak banki területen is a .NET és/vagy Java fejlesztők, vagy jobban, többször keresnének ilyeneket oda. Csak mondom.... hogy mennyire hibásak és alaptalanok a következtetéseid, még akkor is, ha az - egyébként teljességgel igazolatlan -  alapfeltételezéseidet axiomatikusként elfogadjuk.
    Mutasd a teljes hozzászólást!
  • A különbség az a PayPal és a bankok között, hogy banki számlára nem tud utalni a PayPal közvetlenül (ennek leginkább jogi akadálya lehet, többek közt, mert ugye nem bank).

    Tud. És bank.

     De ez utóbbiban személyesen kételkedek, ugyanis itt jellemzően nagy mennyiségű adatfeldolgázosról van szó, amire a node.js nem a legalkalmasabb.

    Mert miért? És mi alkalmasabb rá? Illetve gondolod, hogy a backend rendszereken több adatot kell feldolgozni, mint a frontenden? Miért? Honnan jön az a plusz adat, ami nem fut át a (node.js-alapú) frontenden - akár bemenetként, akár kimenetként -, de a backenden mégis fel kell dolgozni? És mik ezek az adatok szerinted?

    Belsőleg meg azért nem egy nagy kihívás az egyik számláról a másik számlára utalni egy nyelven sem, hisz jobb esetben db tranzakció kérdése.

    Éppen ezért nincs semmi értelme a bankokkal jönni, mint olyan speciális területtel, amire - legalábbis egyesek szerint pl. a JS - nem jó. Mert hogy de, tökéletesen jó. Sőt, akármilyen másik nyelv is jó lenne rá, még a BASIC és a LOGO is, mert csak számokat kell összeadni, kivonni, meg ide-oda másolgatni.
    Mutasd a teljes hozzászólást!
  • Nem tartom valószínűnek, hogy a weblap --> node.js --> egyenleg-adatbázis tranzakció engedélyezett lenne.

    Nem is így értettem.

    Tippem szerint weblap --> node.js --> tranzakció-queue-temp-adatbázis --> (ismeretlen eszköz) --> egyenleg-adatbázis a valósan megvalósított.

    Én is valami queue szerű dologra gondolnék, valami microservice/CQRS alapon, de erre mondjuk pont jó a node. De tippelni bármit lehet. :)
    Mutasd a teljes hozzászólást!
  • Ami ugye nem igaz. Mert az UI legalább annyira lényeges (sőt, még sokszor lényegesebb) része bármilyen alkalmazásnak, mint az üzleti logika része / backendje. Igen, még egy bankinak is.

    Azért egy banknál szerintem kevésbé lényeges a csicsás felület mint az, hogy ne vesszen el a pénzed a számláról. De amiről én beszéltem az a frontend és a backend aránya. Ami eléggé más egy webes portál és egy nagy üzleti alkalmazás esetén.

    Ráadásul az UI-ra is igaz, hogy nem érdemes olyan eszközzel lefejleszteni, amiben ugyanazt az eredményt sokkal nehezebben, lassabba, több kódból/gépelésből lehet csak elérni, vagy ami sokkal kevesebb platformon működik, stb. - csak azért, mert a rendszernek van egy backend része is, ahol esetleg nem érdemes vagy lehet a frontendben használt technológiákat alkalmazni.

    A webnél eddig nem nagyon volt elterjedt alternatíva, és ha lesz is, nem holnap lesz. És a webnek egy rakás olyan selling pointja van ami megkerülhetetlenné teszi: Pl. mindenki ismeri, egy kattintásal el lehet indítani a programot anélkül hogy települne a júzer gépén, stb. De nem azért, mert olyan hű de szuper technológia, hanem azért mert történelmileg így alakult, anno megcsinálták erre alapozva az első hiperlinkes böngészőt, beleintegrálták a js-t, onnantól kezdve pedig a dolog történelem. De Pl. egy pythonnal még kevesebbet gépelnél.

    Pl. a PayPal példája a Napnál is fényesebben bizonyítja ezt, és mellesleg direktbe cáfolja a banki példádat

    Ehhez azért nem ártana egy architekturális leírás a PayPal-ről. Mert ok, használnak node.js-t, de mire ? Mennyi része van az üzleti logikának a node-os szerveren, ebből mennyi a C++-os addon, mennyi van tárolt eljárásokban a szerveren, mennyi esetleg a háttérben futó nem javás - és esetleg nem is PC-s - rendszereken. Egyáltalán mennyi a saját üzleti logika, és mennyire támaszkodik más banki szolgáltatásokra ? Ezek mind olyan kérdések amiket innen nem fogunk tudni megválaszolni, e nélkül viszont elég nehéz megítélni a js szerepét ez ügyben.

    ami eleve nyilván nem reprezentatív a fejlesztői feladatok vonatkozásában, és amit eleve azért választottál, mert azt gondoltad, hogy na, az aztán olyan spéci terület, ahol teljesen más törvények és szokások uralkodnak, mint úgy általában

    Úgy általában pénzügyi területeken leginkább javás embert keresnek, esetleg .NET-eset, esetleg PHP-set bár azt már nem annyira a bankok. De ha gondolod beszélhetünk a javascriptes kernel modulokról is, ha nagyon spéci területre vágysz.
    Mutasd a teljes hozzászólást!
  • Nem tartom valószínűnek, hogy a weblap --> node.js --> egyenleg-adatbázis tranzakció engedélyezett lenne.
    Tippem szerint weblap --> node.js --> tranzakció-queue-temp-adatbázis --> (ismeretlen eszköz) --> egyenleg-adatbázis a valósan megvalósított.

    Na innen a nagy kérdés, hogy az "(ismeretlen eszköz)" miben van.
    Azért igencsak meglepődnék, ha nem tradicionális típusos, fordítós programnyelv lenne, hanem JS. 
    Mutasd a teljes hozzászólást!
  • Nyugodt vagyok és nem is érzem, hogy behúzott volna a csőbe, hisz én is azt mondom kb. amit te. :) Azzal a különbséggel, hogy annyit kinézek a node-ból (ill. a rá épülő ökoszisztémából), hogy a PayPal belső tranzakcióit (pénzügyi) kezelni tudja, de a külső bankok felé a háttér folyamatokban erősen kérdéses, hogy a node vagy bármi féle javascript szerepet játszana.
    Mutasd a teljes hozzászólást!
  • Nyugalom, Sting csak behúzott a csőbe, nem is feltétlenül tudatosan. Senki sem állította, hogy a PayPal pénzügyi műveletei node.js-en futnának, ahogy nem is így történik. Amikor node.js backendről van szó, az még mindig csak a webes felület hátterét jelenti, nem a PayPal-nál futó szoftverkomponensek összességét.
    Mutasd a teljes hozzászólást!
  • Jó, a azt a kérdést ugorjuk át, hogy a PayPal bank- e, de feltételezem nem hiába hivatkoztál te sem "kvázi bank"-ként korábban.

    (Nyilván azért kellett nekik a luxemburgi bank, hogy bankként működhessenek az EU-ban, mert jogilag az EU, de még az USA sem tekinti banknak.)


    A többiben technikailag igazad van, hisz a többi bank is azt csinálja, amit a PayPal, van weboldaluk, ahol az ügyfelek utalhatnak egymásnak pénzt, de az náluk is a frontend. A különbség az a PayPal és a bankok között, hogy banki számlára nem tud utalni a PayPal közvetlenül (ennek leginkább jogi akadálya lehet, többek közt, mert ugye nem bank). De innentől az egész a háttérfolyamatokról szól, hisz a luxemburgi bank fogja megkapni az utalást, hogy Józsi OTP-s számlájára tegyen ezer Ft-ot. Na, és ennek a folyamatnak a felépítéséről/architektúrájáról nincs fogalmunk, hogy hogyan/mivel oldották meg. Az biztos, hogy az informatikai rendszernek is meg kell felelnie az EU-s szabályoknak, de ez nyilván nem zárja ki, hogy nem lehet pl. node.js. :) De ez utóbbiban személyesen kételkedek, ugyanis itt jellemzően nagy mennyiségű adatfeldolgázosról van szó, amire a node.js nem a legalkalmasabb. Belsőleg meg azért nem egy nagy kihívás az egyik számláról a másik számlára utalni egy nyelven sem, hisz jobb esetben db tranzakció kérdése.
    Mutasd a teljes hozzászólást!
  • A PayPal nem igazán mutat semmit, hisz nem a klasszikus értelemben vett bank.

    A PayPal az EU-ba banki engedéllyel rendelkezik, bankként van bejegyezve. Pont.

    Nem mintha nem lenne teljesen lényegtelen az itt tárgyalt szempontokból, hogy jogilag micsoda a PayPal. LC maga is a bankokat az általuk végzett tevékenység (ti. pénzkezelés) és annak - legalábbis szerinte - valamiféle "komolyabbsága" miatt pécézte ki, és állította szembe a weboldalakkal (amik szerinte nyilvánvalóan komolytalan, kvázi igénytelen valamik, amikkel szemben alacsonyabbak az elvárások, ha egyáltalán vannak).

    Ami ugye értelmetlen, hiszen ezek a dolgok nem diszjunkt fogalmak (mert hogy egy banknak is van weboldala, webes szolgáltatása, és egy weboldal, webshop is kezelhet bankokat megszégyenítő mennyiségű pénzeket) - de most ezen ne akadjunk le, mert semmi köze a témához, és totális mellékvágány egyébként is!

    Azt meg ugye nem tudjuk, hogy mi az a rendszer ami az igazi banki elszámolásokat végzi mire épül (szerintem! javascripthez nincs köze).

    Ez nem így működik. A PayPal-nak nyilván van egy saját elszámolási rendszere (is). Amin az, hogy más bankokkal is kapcsolatban áll, áttételesen azok szolgáltatásait, eszközeit, stb. is használja, semmit nem változtat. Főleg, hogy ezt más, "klasszikus értelemben vett bankok" is így csinálják. Nem mintha utóbbi ne lenne egy kitalált fogalom, hiszen a bankok működési, tevékenységi köre, stb. az idők kezdete óta fejlődik, egyik bank se pontosan olyan, mint a másik, stb.

    PayPal - PayPal Bank (pl. Luxemburg) - ügyfél kontója valamelyik banknál.

    Egyrészt a PayPal ügyfeleinek nincs külön-külön kontója külső bankoknál (a PayPal-kontójuk vonatkozásában). Nem is lehet, hiszen ahhoz számos személyes adatot meg kellene adniuk, és azokat ellenőrizni kellene, amit a PayPal nem csinál meg.

    Másrészt ha ez nem így lenne, a PayPal akkor sem egy VPN vagy proxy-, hanem továbbra is pénzügyi közvetítő szolgáltató lenne, ami ebből eredően mind architekturális, mind biztonsági szempontból éppen olyan különálló backend rendszere lenne, mint akármilyen másik banknak is. Nem pedig - ahogy te próbálod beállítani - csak valami frontendje, amihez a backendet valami másik cég biztosítaná. A PayPal akkor sem egy webes kliens lenne más bankok backendjéhez, hanem egy önálló pénzügyi elszámoló rendszer - pont olyan, mint amilyent akármelyik másik bank is üzemeltet.

    De hát ugye ott kezdődik a történet, hogy - mint el lett mondva - a PayPal nem az ügyfelek számláját kezeli más bankoknál, legfeljebb kihelyezi (immár a saját nevében) az ügyfelei egyébként nála vezetett betéteit máshova is, illetve, fizetéseket is fogad és teljesít az ügyfelei megbízásából. Ami végső soron ugyanaz, amit minden más, "igazi" bank is csinál. Ami persze nem meglepő annak tükrében, hogy ugye a PayPal is igazi bank, jogi szempontból is; csak legfeljebb máshol van a hangsúlya, más szolgáltatásokra, ügyfélkörre fókuszál, mint mondjuk egy OTP.

    A paypal példáját pont ezért nem érzem cáfolatnak. Ebből annyi amit tudunk, hogy a PayPal node.js-t IS használ. Ez számomra nem cáfolat.

    A te érvelési hibád: Személyes kétely



    Lényeg a lényeg: teljesen értelmetlen lovagolni azon, hogy a PayPal nem bank, mert egyrészt, de, az; másrészt, mert ha nem lenne az, akkor is fejlesztői szempontból az elszámoló rendszerei éppen úgy néznének ki, mint bármelyik banké.

    Harmadrészt azért is értelmetlen lovagolni a PayPal témán, mert korábban linkeltem egy oldalt, ami számos, egészen biztosan és minden értelemben, vitán felül "igazi" bankot sorol fel, amik szintén JS-t használnak a backendjeikben, is.
    Mutasd a teljes hozzászólást!
  • a PayPal példája

    A PayPal nem igazán mutat semmit, hisz nem a klasszikus értelemben vett bank. A pénzügyi transzfer szolgáltatás, ami kb. a frontendje a banki szolgáltatások egy bizonyos részének. Ezért is alapítottak bankot többek között Luxemburgban. Azt meg ugye nem tudjuk, hogy mi az a rendszer ami az igazi banki elszámolásokat végzi mire épül (szerintem! javascripthez nincs köze). Mert ugye valami ilyesmi folyamatnak kellene lennie:
    PayPal - PayPal Bank (pl. Luxemburg) - ügyfél kontója valamelyik banknál.
    A paypal példáját pont ezért nem érzem cáfolatnak. Ebből annyi amit tudunk, hogy a PayPal node.js-t IS használ. Ez számomra nem cáfolat.

    kvázi bank

    Közben látom, hogy Te is kvázi bankról beszélsz. Igen, kvázi banki szinten valóban példa. :)
    Mutasd a teljes hozzászólást!
  • Ez azért erősen függ attól hogy mit csinálsz. Ha hírportált vagy hasonló tartalomszolgáltató oldalt raksz össze naponta ahol a mögöttes logika elenyésző, és akkor valóban. De Pl. egy bank esetében nem annyira a UI a lényeg, hanem a mögötte lévő háttérszolgáltatás.

    Ami ugye nem igaz. Mert az UI legalább annyira lényeges (sőt, még sokszor lényegesebb) része bármilyen alkalmazásnak, mint az üzleti logika része / backendje. Igen, még egy bankinak is.

    Egyrészt azért, mert azt is csak emberek fogják használni, akik nem fogják tudni jól és hatékonyan megtenni ezt, ha az UI nem teszi ezt lehetővé. Másrészt azért, mert az UI az ami legnagyobb részben eladja az adott szoftvert, mint terméket. Utóbbi - vagy annak legalábbis üzleti / backend része - ugyanis hiába jó vagy funkcionálisan helyes, ha közben az UI-ja ronda, nehézkes, vagy egyáltalán csak nem követi a divatot, nem úgy néz ki és viselkedik, mint amit a felhasználó megszokott és elvár, akkor a termék sem lesz sikeres.

    Ráadásul az UI-ra is igaz, hogy nem érdemes olyan eszközzel lefejleszteni, amiben ugyanazt az eredményt sokkal nehezebben, lassabban, több kódból/gépelésből lehet csak elérni, vagy ami sokkal kevesebb platformon működik, stb. - csak azért, mert a rendszernek van egy backend része is, ahol esetleg nem érdemes vagy lehet a frontendben használt technológiákat alkalmazni. Ami ugye ráadásul nem is tekinthető alapvetésnek - ti. hogy klasszikusan (vagy legalábbis egyesek által) frontend-hez kötődőnek tartott technológiákat ne lehetne backendben, üzleti logika írására is használni.

    Pl. a PayPal példája a Napnál is fényesebben bizonyítja ezt, és mellesleg direktbe cáfolja a banki példádat (ami eleve nyilván nem reprezentatív a fejlesztői feladatok vonatkozásában, és amit eleve azért választottál, mert azt gondoltad, hogy na, az aztán olyan spéci terület, ahol teljesen más törvények és szokások uralkodnak, mint úgy általában - miközben persze nem). Hiszen a PayPal esetében egy pénzügyi szolgáltatóról van szó, ami eredetileg JS+HTML+CSS-t használt frontendben, és Java-t backendben.

    Ugyanakkor és annak ellenére, hogy kvázi bank, amikor a PayPal egységesítette a frontend és backend technológiáit, hogy hatékonyabbá tegye a fejlesztési folyamatát, nem a Java-t őrizte meg a backendben és váltott át szintén Java-ra a frontendben is (amit pl. a GWT révén simán megtehetett volna), hanem éppen fordítva: a backendjét is a frontend JavaScript-jére állította át. Nyilván nem véletlenül. És annak ellenére, hogy kvázi egy banki szolgáltatásról beszélünk.

    Ennyit arról, hogy mire alkalmas és mire alkalmatlan a HTML+CSS+JS, vagy hogy mennyire kompetitív más technológiákkal szemben - akár még olyan speciális területeken is, mint a banki. Ahol egyébként nem a PayPal az egyetlen, aki ilyen irányban mozog.
    Mutasd a teljes hozzászólást!
  • Akkor nem értettél meg. Vannak dolgok, amiket CSS-ben a büdös életben nem fogsz tudni megcsinálni.

    Nem, te nem értettél meg. Amit HTML+CSS-ben nem fogsz tudni megcsinálni (vagy egyszerűen csak nem érdemes abban megcsinálni), ahhoz nem a HTML+CSS-t kell használni. Amitől viszont még mindig sokkal több feladatra lesz jobb és hatékonyabb eszköz, mint a konkurensét képező prezentációs technológiák legtöbbje - ezért pedig népszerűbb is. Ha majd ez már nem így lesz, akkor majd ő is elindul lefelé a rangsorban, ahogy azt a régi, elavult vagy elavulófélben lévő többi nyelvek és technológiák  is teszik jelenleg.
    Mutasd a teljes hozzászólást!
  • Akkor nem értettél meg. Vannak dolgok, amiket CSS-ben a büdös életben nem fogsz tudni megcsinálni.  Nem fogsz tudni szimplán CSS-ben parancssorról beolvasni user inputot, validálin és feldolgozni azt, asszinkron hívásokat indítani, stb...
    Mutasd a teljes hozzászólást!
  • Akkor mutass légyszíves egy css-ben írt linux kernel modult

    Te leragadtál Sting első mondatánál? Mert ilyat is írt: Ahol ez nem igaz, ott nyilván továbbra is használják a Go-t meg a C++-t.
    Mutasd a teljes hozzászólást!
  • Pl. egyszerűbben és gyorsabban.

    Akkor mutass légyszíves egy css-ben írt linux kernel modult. 
    Mutasd a teljes hozzászólást!
  • Ugye a döntő itt az, hogy manapság a fejlesztők legnagyobb része és az idő nagy részében nem prímkeresést ír, hanem UI-t épít, esetleg drótoz össze triviális logika mentén az adatbázissal vagy valamilyen háttérszolgáltatással.

    Ez azért erősen függ attól hogy mit csinálsz. Ha hírportált vagy hasonló tartalomszolgáltató oldalt raksz össze naponta ahol a mögöttes logika elenyésző, és akkor valóban. De Pl. egy bank esetében nem annyira a UI a lényeg, hanem a mögötte lévő háttérszolgáltatás.
    Mutasd a teljes hozzászólást!
  • Kíváncsi vagyok, hogy HTML -el, CSS-el hogyan oldja meg bárki azt, amit mondjuk valaki más GO-val, vagy C++ -al.

    Pl. egyszerűbben és gyorsabban. Nem feltétlenül - hiszen a feladattól függ, hogy mi a hatékonyabb eszköz erre. De nyilván egy UI-t, animációt, stb. általában egyszerűbb ezekben a nyelvekben deklaratív módon felépíteni, mint Go-ban vagy C++-ban imperatív módon létrehozni. Prímkeresést meg nyilván utóbbiakban célszerű megírni.

    Ugye a döntő itt az, hogy manapság a fejlesztők legnagyobb része és az idő nagy részében nem prímkeresést ír, hanem UI-t épít, esetleg drótoz össze triviális logika mentén az adatbázissal vagy valamilyen háttérszolgáltatással. Ami célszerűbb eszközzé teszi számukra a HTML+CSS-t, mint a Go vagy a C++ használatát a feladat megoldására.

    Ahol ez nem igaz, ott nyilván továbbra is használják a Go-t meg a C++-t. De akkor is lehet, hogy a front-end-et különválasztják, és azt azért HTML meg CSS segítségével  hozzák létre, és csak az üzleti logikához használják az imperatív nyelvet.

    Minden a konkrét részletektől függ - de mivel az egész iparág alapvetően az említett egyszerű drótozás, az elosztott, internetes hálózatok, többplatformos megoldások, illetve a szolgáltatás jellegű termékek, stb. felé tolódik, illetve tolódott el az elmúlt két évtizedben, ezért a webes és a JS+HTML+CSS (ami maga meg ugyanebben az időben elképesztő fejlődésen mentek keresztül) is egyre több területre tört be, és váltotta ki részben vagy teljesen az ott korábban használt platformokat, technológiákat és nyelveket.

    Ennek a folyamatnak az eredményeit látjuk az ilyen és hasonló felmérésekben, statisztikában.

    Arról nem is beszélve, hogy időről időre felkerülnek ezek a listák ide, aztán minden alkalommal lefutjuk ezt a kört. A múltkoriban pl. a PHP messze nagyon hátul volt, egy másikban a C# kihalásra ítélték, ahány vizsgálat, annyi eredmény.

    Amiről már el lett mondva, hogy ez nem jelenti azt, hogy itt valamiféle ellentmondás lenne. Más statisztikák más dolgokat mérnek - illetve attól függően, hogy mit és hogyan mérnek, az eredményeik másként értelmezendők. Amitől azonban még nagyon erősen egy irányban mutatnak, és igazából megerősítik egymást.

    Adatbáziskezelőket hasonlítsunk össze más adatbáziskezelőkkel, mert nyilván, egy MariaDb-t nem lehet összehasonlítani a CSS népszerűségével.

    Össze lehetne, és semmi baj nem lenne ezzel az összehasonlítással sem. Itt egyébként ez nem történt meg - de megtörténhetett volna. Ettől az összehasonlítás nem lett volna értelmetlen - csak helyesen kellett volna tudni értelmezni az eredményeket. Ez utóbbi az, ami sokaknál hibádzik, akik csak feketén fehéren látnak, vagy szeretnének látni a világot.

    EDIT: nem mellesleg a CSS-t ide keverni.. hát, van annak bármiféle alternatívája? Csodálkoznék, ha lenne.

    Persze, hogy van. Hiszen még a direkt webes, böngészős projektek esetében is sokszor más nyelvekből (LESS, SASS, stb.) konvertálják, generálják a CSS-kódot; arról nem is beszélve, hogy pl. egy mobil vagy Windows alkalmazásban millió más prezentációs nyelv és keretrendszer képezi az alternatíváját.
    Mutasd a teljes hozzászólást!
  • Szerintem nem kéne Emesézni, mert van igazság abban amit mond.

    Kíváncsi vagyok, hogy HTML -el, CSS-el hogyan oldja meg bárki azt, amit mondjuk valaki más GO-val, vagy C++ -al. Mondom, sehogy. Éppen ezért teljesen helytálló volt az autós hasonlat.

    Ezen kívül én sem igazán látom a kontextust, így akkor már legalább ketten vagyunk.

    Arról nem is beszélve, hogy időről időre felkerülnek ezek a listák ide, aztán minden alkalommal lefutjuk ezt a kört. A múltkoriban pl. a PHP messze nagyon hátul volt, egy másikban a C# kihalásra ítélték, ahány vizsgálat, annyi eredmény.

    "Legalább ki lehetne tűzni, hogy milyen környezetben nézzük a népszerűséget"

    Ebben is van igazsága. Adatbáziskezelőket hasonlítsunk össze más adatbáziskezelőkkel, mert nyilván, egy MariaDb-t nem lehet összehasonlítani a CSS népszerűségével. 

    A múltkor meg olyan listát láttam, ahol a bootstrap megverte a jqueryt és a CSS -t is.

    EDIT: nem mellesleg a CSS-t ide keverni.. hát, van annak bármiféle alternatívája? Csodálkoznék, ha lenne.
    Mutasd a teljes hozzászólást!
  • A mondandóm lényege az volt, hogy a PHP, a JavaScript és a CSS összehasonlítása egy nevetségesen értelmetlen dolog, mivel ugyan annak a dolognak az alkotóelemei, nevezetesen bármilyen PHP-t alkalmazó webes fejlesztésnek.

    De én meg mondtam, hogy egyrészt utóbbi félmondat sem igaz, mert konkrétan pl. a JS-t manapság már minden területen alkalmazzák, nem hogy a PHP-től és a CSS-től, de a webtől is teljesen függetlenül, asztali és mobil alkalmazásokban is. Másrészt, hogy ez egy rakás másik nyelvről is elmondható - pl. hogy a legprominensebbet mondjam, az SQL-ről is.

    Harmadrészt manapság már eleve piszok ritka az, hogy egy-egy programot csak egyetlen egy nyelvben írjanak - ha másért nem, hát azért, mert a mai programok kódjának legnagyobb részét nem az alkalmazásfejlesztő írja, hanem mások, és előbbi csak felhasználja ezeket könyvtárak formájában; illetve mert sok alkalmazás távoli szolgáltatásokat hív és használ, amiket a legritkább esetében írnak ugyanazon a nyelven, mint amiken a kliens oldali részeit. (Adabáziskezelőkről és hasonlókról már nem is beszélve.)

    Ezért is teljesen értelmetlen kipécézni a PHP+JS+CSS triót - mert hogy szinte bármelyik másik nyelven készült nem triviális alkalmazásról elmondható, hogy a részét képező kódok nem egy nyelvben készülnek.

    semmit se segít azon, hogy volt egy külföldi oldal mérése

    Nem külföldi, hanem nemzetközi. Lehetnének az oldalnak a szerverei akár Magyarországon is - az nyilván semmit se változtatna sem az adatokon, sem azok érvényességén. Ezért is teljesen értelmetlen ezt is felemlegetned.

    ami alapból kijelentette, hogy csak egy száraz adatot tesznek közre, ami nem is pontos, de pláne nem lehet belőle semmit levonni

    Szerinted. Amiről már el lett magyarázva, hogy nem igaz.

    pusztán egy adat, erre egy magyar oldal átveszi, mint a programozási nyelvek népszerűsége

    Mert, hogy az.

    Ez egy pitiáner amatőr hiba, ami oly jellemző a magyar sajtóra, hogy ész nélkül fordítgatnak és vesznek át mindent gondolkodás nélkül, szimplán cikkgyár a még több kattintásért.

    Amatőr hiba az, hogy úgy kezdesz el kritizálni valamit, hogy még alapvető dolgokkal sem vagy tisztában vele kapcsolatban. Pl. hogy hogyan készült a felmérés - lásd korábbi válaszom!

    A velem való kötözködés helyett pedig lehetne pl szakmai diskurzust indítani, pro kontra érveket hozni, ilyesmi.

    Pontosan ez történt. El lett magyarázva neked, hogy milyen pontokon tévedsz tárgyszerűen. Amin az, hogy te ezt esetleg még mindig nem érted meg, nem változtat semmit.

    Ha esetleg a cikk irójával állnál kapcsolatban

    Én vagyok a cikk írója.

    akkor pedig talán lehetne venni a fáradtságot, és egy korrektül megfogalmazott cikket összedobni

    Megkérdezném, hogy hol és miért nincs korrektül megfogalmazva.... de mindketten tudjuk, hogy teljesen értelmetlen, hiszen az alapprobléma az, hogy te olyan dolgot kritizálsz, amiről semmit sem tudsz, és hogy csak erről a tényről akarsz hárítani, terelni.

    valami releváns témában (nem is merem megemlíteni, hogy esetleg saját kutatási eredményeket használva, amolyan bónuszként).

    Egyrészt te itt is valami teljes fogalomzavarban vagy, tudatlanságban leledzel. Egy hírszerkesztőnek ugyanis nem feladata kutatni - az a kutató feladata. A hírszerkesztő csak megírja mások eredményeit, hivatkozva az eredeti forrásra - ahogy itt is történt.

    Másrészt miért lenne jobb egy saját kutatás, mint ez? Egy kutatás alaposságát, hitelességét, tényszerűségét, stb. nem az adja meg, hogy te csinálod vagy sem, hanem az adatkészlet, a mérési metodika, illetve az, hogy az eredményekből esetleg milyen és mennyire logikus konklúziók kerülnek levonásra. Amiről azonban teljesen értelmetlen beszélgetni addig, amíg valaki annyira nincs tisztában előbbi adatokkal, és annyira képtelen a logikus érvelésre, mint te.
    Mutasd a teljes hozzászólást!
  • a még több kattintásért

    Ebben sajnos pont te vagy a hibás: a cikk megérdemelten nem váltott ki semmiféle érdeklődést, amíg hozzá nem szóltál.
    Mutasd a teljes hozzászólást!
  • A mondandóm lényege az volt, hogy a PHP, a JavaScript és a CSS összehasonlítása egy nevetségesen értelmetlen dolog, mivel ugyan annak a dolognak az alkotóelemei, nevezetesen bármilyen PHP-t alkalmazó webes fejlesztésnek. A példám továbbra is korrekt. Utána, hogy belekötöttél a fogalmazási pontatlanságaima és abba h ilyen is van meg olyan is, semmit se segít azon, hogy volt egy külföldi oldal mérése, ami alapból kijelentette, hogy csak egy száraz adatot tesznek közre, ami nem is pontos, de pláne nem lehet belőle semmit levonni, pusztán egy adat, erre egy magyar oldal átveszi, mint a programozási nyelvek népszerűsége. Ez egy pitiáner amatőr hiba, ami oly jellemző a magyar sajtóra, hogy ész nélkül fordítgatnak és vesznek át mindent gondolkodás nélkül, szimplán cikkgyár a még több kattintásért. Lehet engem fikázni, de akkor is ez van. Nem volt célom a személyeskedés, és nem is szoktam ilyen dolgokat kommentelni, de kezdem unni, hogy a net magyar felén lassan csak hülyeséget lehet találni. A velem való kötözködés helyett pedig lehetne pl szakmai diskurzust indítani, pro kontra érveket hozni, ilyesmi. Ha esetleg a cikk irójával állnál kapcsolatban, akkor pedig talán lehetne venni a fáradtságot, és egy korrektül megfogalmazott cikket összedobni, valami releváns témában (nem is merem megemlíteni, hogy esetleg saját kutatási eredményeket használva, amolyan bónuszként).
    Mutasd a teljes hozzászólást!
  • PHP-t, CSS-t és JavaScriptet hasonlítgatni kb olyan mintha azt vizsgálná valaki, hogy a diesel motor, a karosszéria, vagy a fényezés-e a népszerűbb...

    Ami ugye egy teljesen hamis hasonlat - hiszen míg minden autóban van fényezés, motor és karosszéria, addig
    1. nem minden szoftverben van PHP, CSS és JavaScript is, és mert
    2. amelyik szoftverben az egyik van, nem feltétlenül van bármelyik másik is benne.
    Esetleg valami más, helyes(ebb) hasonlatod van?

    Mindenféle kontextus nélkül bármit összehasonlítani, alapból értelmetlen.

    De hiszen nem kontextus nélkül vannak a dolog. Csak legfeljebb te nem érted mi a kontextus. Ez óriási különbség.

    A programozási nyelvek sem ugyan arra születtek mind.

    Az állítás úgy helyes, hogy nem teljesen ugyanarra. Amitől egyrészt még rendkívül sok feladat bármelyikben megoldható. Másrészt, ami ha nem lenne így, se tenné értelmetlenné valamiféle összehasonlításukat. Így rejtély, hogy egyáltalán miért hozod fel ezt, miközben nyilvánvalóan a statisztika - legalábbis szerinted - értelmetlenségét akarod bizonygatni.

    Legalább ki lehetne tűzni, hogy milyen környezetben nézzük a népszerűséget..

    Ezt is lehet, és vannak is ilyen statisztikák. Meg lehet mindent egybe venni is. Ez most egy olyan.

    Az eredeti cikk szimplán a GITHubon lévő projektek nyelveinek eloszlását vizsgálta

    Nem, nem csak azt vizsgálta. És a GitHub-on sem a projektek, hanem a commit-ok számát vizsgálta. Legalább olvastad volna el a metodológia bemutatását, mielőtt kritizálni kezded!

     Pl egy PHP projektben simán lesz JavaScript és CSS és mégsem fog megjelenni a számokban

    Ez elismert korlátja a statisztikának. De te majd csinálsz egy olyant, ami nem szenved ilyen problémáktól. Hajrá!

    szóval még az eredeti adat is kérdéses, de az átfordítása full értelmetlen

    Attól, hogy valami nem tökéletesen pontos, nem teljesen értelmetlen. Sőt, a való világban gyakorlatilag nincs olyan statisztika, ami tökéletesen pontos lenne - mégse kiabálja senki, hogy azoknak nincs értelmük. Egyszerűen a legtöbb dolgot általában
    1. nem lehet tételesen és darabra pontosan megszámolni, illetve
    2. nem lehet diszjunkt kategóriákba sorolni.
    Ezért szinte minden statisztikának van egy bizonyos, elismert hibahatára - ami viszont csak annyiból releváns, hogy érdemes figyelembe venni. De semmiképpen sem teszi értelmetlenné a statisztikát. Sőt!

    Ez a cikk így nagyon amatőr.

    A fentiek tükrében csak meg szeretném köszönni az értékelést, Emese!
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd