Hivatalos a JavaScript legújabb változata, az EcmaScript 2022
2022-07-07T11:46:17+02:00
2022-07-12T10:28:22+02:00
2022-07-20T01:51:15+02:00
  • A felsorolt újítások nagy részét már lassan 2 éve támogatják a böngészők. Épp most kezdtem bele egy projektbe ezeket használva, kíváncsi vagyok, lesznek-e kompatibilitási problémák.
    Mutasd a teljes hozzászólást!
  • Én csak pislogok.

    az OOP-vel felépített rendszerek memória igénye nagy, az adatok átfutása - a memória címzés felépíésének megfelelően - többszintes, és sok az overhead. 

    Már bocsánat, de az script-nyelvekre fokozottan igaz. A kód futtatásához képest bizonyos esetekben lényegesen több memóriát és processzort használ a böngésző arra, hogy legyártsa a futtatható kódot a scriptből. A prog.hu-t lefrissítve a chrome 309.8 ms-ot ír a kód fordítására, a prog.hu-hoz használ 6.3 MB memóriát, a google cuccaihoz meg 13.8-at. Nem az OOP-re megy el az erőforrás, hanem a használt lib-ekre.

    A JS esetében pedig épp a nataív sebesség az, ami nagyon nagy előny a böngészőben való futáshoz, tehát bár az OOP alapú megközelítés fejleszthetőbb, de nem minden esetben célszerű, vagy hasznos.

    Tényleg vannak olyan feladatok, ahol az OOP megoldás lényegesen lassabb, mint egy jó natív megvalósítás, szerintem a böngészőben előfordulók nagyon kicsi hányada ilyen. Meg sem tudod kerülni, az oldal elemeinek elérése, képek/videók/mikrofon/hang kezelése mind objektumokon keresztül megy.

    hogy áthídalja az OOP szemléletet a hagyományos JS alapú funkciónális kód struktúrára.

    Az ECMAScript 1997-es (!) szabvány tartalomjegyzék második (!) oldalán szerepel az "Objects" bekezdés. Mi az a "hagyományos JS alapú funkcionális kód"?
    Mutasd a teljes hozzászólást!
  • Regebben is lattam olyat, hogy egy main metodus volt az alkalmazasban es abban futott minden. 
    Spring Boot eseteben is visszatert a main metodus hasznalata backend oldalon, ugyhogy ha gondolod, oda beteheted az 5000 sor kodot vagy eppen amennyi kell azt' mehet :)
    Pull request-nel majd nezd meg milyen visszajelzest kapsz
    Mutasd a teljes hozzászólást!
  • igazabol en semmit sem latnek szivesen helyette.
    hagyjak meg a js-t annak ami kezdetben volt, egy egyszerü nyelvnek ami elfut a böngeszöben.
    jöjjenek hozza ki hotfixet, de erre tenyleg nincs szükseg, hogy uj iranyvonalakat pakoljanak bele.

    nekem nincs kedvem meloban sz@pni az oop-vel. feleslegesen bonyolitja az eletet.
    en siman a proceduralis programozas hive vagyok. siman folyjon a kod top-down iranyba.

    szerencsere a piac is eszrevette, es kezdi az oop kezet elengedni.

    kiveve nehany ilyen gyökeret, akik jopenzert bizottsagi tagkent ülnek kint svajcban es bizonyitas kenyszerük van.

    de ugyis hullaszag van itt a prog.hu-n. szoval jöhetnek az ervek az oop mellett es ellen. 
    max Sting szol meg par haverjanak pörgetni a forumot. XD
    Mutasd a teljes hozzászólást!
  • Mi a baj az OOP-vonallal?
    Miért nincs keresnivalója egy mai app-szerű frontendben? (Nem beszélve a backend-ről.)

    Amit @newbie007 mondott, eléggé sarkos kijelentés, de szakmailag egy dolgot azért nem árt itt figyelembe venni. Az OOP-nak természetesen megvan a létjogosultsága, és használni is kell, de sokan elfeljtik, hogy magát az OOP szemléletet azért vezették be, mert emberközeli szemléletmódot tud nyújtani, szoftveres rendszerek megvalósítására, azaz a programkód szerkezetét valós vliágbeli modellek alapján lehet leírni, és felépíteni. Ez jó a fejlesztőnek, és mindenki másnak is, aki a fejlesztésen dolgozik, de - és itt a lényeg - nem jó a számítógépes környezet számára. Magyarul, az OOP-vel felépített rendszerek memória igénye nagy, az adatok átfutása - a memória címzés felépíésének megfelelően - többszintes, és sok az overhead. Éppen ezért vannak például a C++ -ban mutatók, hogy ezeket át lehessen hidalni, és éppen ezért lehet a C++-ban eldönteni azt, hogy valaki funkcionális, vagy OOP kódbázisú rendszert fejleszt.
    A JS esetében pedig épp a nataív sebesség az, ami nagyon nagy előny a böngészőben való futáshoz, tehát bár az OOP alapú megközelítés fejleszthetőbb, de nem minden esetben célszerű, vagy hasznos. A TypeScript is egy jó dolog, mert segít az OOP elveknek megfelelő JS kódot létrehozni, de ha valaki csak egyszer is ránéz arra a kódra, amit a TS-ből generáltak ki, akkor láthatja, hogy milyen bonyolult struktúrát is hoz létre a fordító annak érdekében, hogy áthídalja az OOP szemléletet a hagyományos JS alapú funkciónális kód struktúrára.
    Tehát a natív JS esetében számomra is a gyorsaság - és az egyszerűség a lényeg. Amúgy is bonyolult kódokat szokás kliens oldalon létrehozni, akkor legelább fussanak le aránylag natív sebesség mellett gyorsan. Tehát én sem tartom elsődlegesnek azt, hogy csak "kényelemért" a JS-be is kellene az OOP szemlélet. A jó szakember a funkcionális struktúrákban is képes dolgozni, éppen ez miatt nem érdemes a JS támadni. Az úgy jó, ahogy van, ezzel együtt kell tudni élni, és tudni kell vele dolgozni.
    Természetesen nem gond, ha kap valamilyen natív OOP támogatást a JS, de ez ne legyen kötelező érvényű benne, mert akkor éppen azt veszti el, amire eredetileg kitalálták.
    Mutasd a teljes hozzászólást!
  • Hali!

    Mi a baj az OOP-vonallal?

    Nincs semmi, hagyd rá, csak a szokásos én-megmondom-mi-a-tuti „fejlesztő”.

    … tényleg érdekel, mit szeretnél inkább látni helyette.

    Lehet, hogy azokat kellene kérdezned, akik értenek is hozzá.

    Mutasd a teljes hozzászólást!
  • Mi a baj az OOP-vonallal?
    Miért nincs keresnivalója egy mai app-szerű frontendben? (Nem beszélve a backend-ről.)
    Sokszor olvastam már ezt a véleményt, tényleg érdekel, mit szeretnél inkább látni helyette.
    Mutasd a teljes hozzászólást!
  • Azért ez így kicsit erős kiejelntés, bár én is inkább a funkcionális programozást preferálom, azért sokan vannak azok akik a mai napig OOP-ben dolgoznak.
    Mutasd a teljes hozzászólást!
  • csontszilankosra törnem a kezet, aki js-ben az OOP vonalat erölteti.
    semmi keresnivaloja frontenden.  söt tovabbmegyek sehol sem.
    Mutasd a teljes hozzászólást!
  • Azért érdekes, hogy az OOP irányt erősítik az igazán hasznos pipeline operátort pedig eltemették.

    A global async tűnik igazán jó pontnak.
    Mutasd a teljes hozzászólást!
abcd