Komentáře k článku

Co se mi nelíbí na JavaScriptu

Když jsem v 90. letech s JavaScriptem začínal, tak jsem ten jazyk nesnášel. Hlavní důvod byl ale ten, že co jsem napsal pro jeden prohlížeč, nefungovalo v druhém. Když jsem pochopil, že to není až tak problém jazyka, ale rozdílného API v prohlížečích, tak jsem si JavaScript postupně začal oblibovat, až se stal mým druhým nejoblíbenějším jazykem. Navíc je mnohem elegantněji navržený než PHP a temných zákoutí je v něm mnohem míň.

Zpět na článek

44 komentářů k článku Co se mi nelíbí na JavaScriptu:

  1. skybedy

    A co včil...
    V době, kdy jsem se po 10 letech v PHP rozhodl, že TEĎ se konečně do toho JavaScriptu pořádně ponořím, je to trochu demotivujíci čtení a nezbývá než doufat, že následné komentáře javascriptařů, v které doufám, mému, už tak těžce zkoušenému elánu, pomůžou jít dál. Každopádně, z mého pohledu, výborný text od autora, za kterým něco je, díky.

    1. Honza

      Re: A co včil...
      Já jsem se po 11 letech strávených s PHP a JS rozhodl vyzkoušet Python a Ruby. Nakonec jsem zůstal u Pythonu a jsem rád, že nemusím řešit žádná „temná zákoutí“ jazyka. Tak bych doporučoval porozhlédnout se i jinde. Pokud ale zvítězí JS, tak doporučuji rovnou CoffeeScript, který tě odstíní od temných zákoutí JS.

      1. Bystroushaak

        Re: A co včil...

        Nakonec jsem zůstal u Pythonu a jsem rád, že nemusím řešit žádná „temná zákoutí“ jazyka.

        To proto, že ho neznáš dost dobře. Viz podnadpis Temné kouty: Python poznámky.

    2. NoxArt

      Re: A co včil...
      S JS klidně pracuj, ke každému jazyku jde napsat odstavce co je na něm špatně. Pravda u JS jsou různé podivnosti, ale stejně je to zajímavý jazyk. K PHP je JS vhodné, když se to tak často kombinuje (nemusí to tak člověk používat sám, stačí při procházení cizího kódu). Minimálně ti to rozšíří obzory, čím víc jazyků a knihoven, tím lehčeji se učí další.

  2. Pavel Dvořák

    Dart
    Také jsem hledal… A našel. Dart. Vlastně řeší 90% nedostatků vypsaných v tomto článku a ještě není syntaxí příliš vzdálený od původního JavaScriptu a je přehledný jako PHP. Spokojenost :-)

      1. Pavel Dvorak

        Re: Dart
        Tak samozrejme, ze syntaxi se blizi Jave (mnoho lidi ma kvuli tomu vuci Dartu predsudky), ovsem bere si z Javy jenom to nejlepsi. Ale kombinace PHP a Dartu je treba pro me hodne dobra

  3. Clary

    CoffeeScript
    Jak Jakub sám říká, spoustu nedostatků odstraňuje CoffeeScript – odstiňuje od prototypové dědičnosti, iterování přes pole a objekty je triviální, velmi mi rovněž vyhovuje klíčové slovo when. Funkce pro nalezení objektu v poli např podle id se pak dá napsat elegantně na jeden řádek:

    findUserById: (id) -> return user for user in users when user.id is id

    Zásadní však pro mě bylo to, že jsem po letech chtěl vyzkoušet jinou než C-like syntaxi.
    Poslední poznámka – callback hell se dá částečně vyřešit použitím návrhového vzoru promise.

  4. Ondřej Žára

    Doplnil bych, že Objekt v JS není dokonce ani HashMap – je to jen prostá neuspořádaná množina klíčů a hodnot. Specifikace o tomto pokud vím mlčí, nicméně dle mých informací objekt v žádné mainstreamové implementaci nedovoluje přístup v (amortizovaném) konstantním čase. Samotného by mne zajímalo proč a jestli nás v tomto směru čeká nějaké zlepšení. Možná ES6 [Weak]Map?

    Dále bych rád znal autorův názor ohledně funkcionální iterace, která se mu kvůli callbacku nelíbí. Druhým parametrem forEach a dalších je přitom „this“, takže odpadá nutnost vizálně nehezkého explicitního bindu (viz jeden z dalších popisovaných nedostatků). Jaké problémy tedy u této iterace zůstávají?

    Vposled bych prosil o rozvedení věty „Když už pominu paměť zbytečně alokovanou při vytváření objektu přiřazovaného do prototypu potomka“. U typizovaného zápisu „var parent = {}; var child = Object.create(parent);“ nikde žádnou zbytečně alokovanou paměť nevidím; možná se výtka týká spíše operátoru „new“ (a nezvyklé duality posloupností funkcí a jejich prototypů)? Navíc při definování vztahu předek-potomek přeci žádné konstruktory volat nemusím; to udělám až při instancializaci potomka (kdy v jeho konstruktoru za správné parametruzace volám konstruktor předka, opět korektně parametrizovaný).

    1. Jakub VránaAutor příspěvku

      Děkuji za doplnění.

      Na forEach se mi nelíbí vlastně jen to, že přidává syntaktické smetí – nutnost psát function a předávat this, navíc až za definicí funkce (fragment }, this); mému oku taky zrovna nelahodí).

      Funkce Object.create nealokuje žádnou paměť? Vzhledem k tomu, že má v popisu práce vytvořit nový objekt, tak by mě to překvapilo.

      Poznámka o volání konstruktorů naráží na dobu před Object.create, kdy se vztah dal vyjádřit pomocí Child.prototype = new Parent(), což je celkem přirozené, ale kvůli nemožnosti předat parametry konstruktoru bohužel nepoužitelné. Takže je nutno dělat v článku zmiňované opičárny s vytvářením prázdného objektu. Osobně si Object.create ještě kvůli starým prohlížečům používat netroufnu.

      1. Ondřej Žára

        Re:
        Jasně, Object.create paměť alokuje, ale neřekl bych, že zbytečně – je to hlavní náplní jeho práce a takto alokovaná paměť se následně využije. Jak v případě var child = Object.create(parent) (tj. používání dědičnosti bez funkcí), tak v Child.prototype = Object.create(Parent.prototype) (při emulování tradiční class-based dědičnosti).

        Child.prototype = new Parent() je zhůvěřilost, ano.

        Použití Object.create vnímám jako velmi bezpečné i u starých prohlížečů, pokud nepotřebujeme použít druhý parametr s deskriptorem. Lze buď napsat triviální polyfill s použitím new:

        Object.create = function(proto) {
        var tmp = function() {};
        tmp.prototype = proto;
        return new tmp();
        }

        ve kterém ale skutečně dochází ke zbytečné alkoaci (ale koho to u polyfillu trápí?), nebo využít zajímavý trik zmiňovaný na konci článku na https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create – takovýto polyfill dle mého názoru nic zbytečně nealokuje a přesto funguje všude.

    2. Ondřej

      Re:
      To o tom JS objektu by mě zajímalo. Já to nikdy nehledal a předpokládal jsem, že je to hash mapa. I když jsem si dělal nějaké rychlostní srovnání, tak dotazy na existenci klíče v hash mapě vycházely řádově rychleji než prosté lineární vyhledání prvku v seznamu. Jak je to možné, když má být objekt neuspořádaná množina klíčů a hodnot?

      1. Ondřej Žára

        Re:
        Nu, já se prostě optal vývojářů SpiderMonkey a V8 a dle jejich odpovědí to hashmapa nebyla. To ale neznamená, že se při přístupu ke klíči musí dělat „full scan“ (lineární vyhledání), klíče mohou být třeba v nějakém stromu, který vede na lepší (logaritmickou) složitost. První verze V8 například při iteraci klíče vracely v abecedním pořadí, nezávisle na pořadí vkládání (to dává tušit leccos o implementaci). Časem bylo toto chování tuším upraveno tak, aby korespondovalo ostatními implementacemi (přestože standard o pořadí iterace mlčí). A možná ještě ne: https://code.google.com/p/v8/issues/detail?id=164

        1. Ondřej

          Re:
          Strom už by to teoreticky mohl být, ale z toho popisu „je to jen prostá neuspořádaná množina klíčů a hodnot“ jsem myslel, že to není ani to.

          A kde jste se jich ptal? Mě by tohle docela zajímalo, sám jsem o tom moc nenašel. Ani v tom odkázaném vláknu toho zase tak moc užitečného nepíší. Pořadí klíčů může být uloženo bokem, to taky není nijak pevné vodítko.

          1. Ondřej Žára

            Re:
            Za V8 mám vynikající zkušenost s Vyacheslavem Egorovem (nyní už tuším dělá Dart VM), přímo (ptal jsem se ho buď přes jabber, nebo naživo).

            Za SM jsem to s někým diskutoval – ale už je to nějaká doba zpátky – na konferenci jsconf.eu. Jméno bohužel nevím, ale jak psal Jirka Kosek: zdrojáky jsou veřejné a to by mělo stačit :-)

  5. HonzaMarek

    Function.bind(this)
    V ES6 se dají použít arrow funkce, které this zachovávají.

    pole.forEach((item) => this.neco(item));
    
    pole.forEach((item) => {
        return this.neco(item)
    });
    
  6. Lemming

    Cimrman
    Jojo, zvlášť co se týká prototypové „dědičnosti“ a chování this si říkám, že autoři museli být zamilovaní do Cimrmana a jeho pokusů s vyfukováním tabákového kouře do vody.

  7. Lumír Balhar

    A co Python?
    Netvrdím, že je Python vhodný na stejné aplikace jako Javascript nebo PHP, ale má také velmi širokou škálu možných použití – webové aplikace nevyjímaje – je dobře čitelný a rychlý.

    1. zbyso

      Re: A co Python?
      to urco, akorat me teda mrzi, ze se nejak vyrazneji neprosazuje ve webove sfere. to je v podstate primarni duvod, proc jsem se do nej nezadloubal vic, a porad holt vevodi Javascript i pres vyse uvedene nedostatky.

      1. pavel

        Re: A co Python?
        Server-side python docela frci, rozhodne vic nez JavaScript. Ale tys zrejme myslel browser-side. Tam bohuzel python neni k dispozici, tedy ne ze by to nezvladl, ale bohuzel nema podporu ze strany vendoru. Ano jsu tu snahy o prekladac Py->JS ( Skulpt, ale je to ve stadiu experimentu.

        1. Bystroushaak

          Re: A co Python?

          Tam bohuzel python neni k dispozici, tedy ne ze by to nezvladl, ale bohuzel nema podporu ze strany vendoru. Ano jsu tu snahy o prekladac Py->JS ( Skulpt, ale je to ve stadiu experimentu.

          Brython je na tom docela dobře. Já ho třeba pro svoje amatérské věci používám rozhodně radši, než javascript.

  8. petr b

    Čárka, čárka stolička sněhulám
    Ona ta čárka na konci má totiž v js geniální (sarkazmus) význam. V JS totiž lze napsat a = [,,,], a ono si to mezi čárky doplní Undefined. Z toho logicky plyne, že za tu poslední čárku si taky musí doplnit undefined. No, mě bylo dost líto, že ten chlap už není šéf mozilly, protože takhle je nebezpečí, že se bude mít čas a něco zase vymyslí,

    1. Míra

      Re: Čárka, čárka stolička sněhulám
      Zdravím,
      čárka za posledním prvkem pole nebo objektu je zlo. Čárka má oddělovat jednotlivé prvky pole, takže když vidím čárku očekávám pokračování dalším prvkem. Zejména v kombinaci se špatným odsazováním je to spolehlivý způsob jak vytvořit zmatený kód.

      1. Taky Míra

        Re: Čárka, čárka stolička sněhulám
        Souhlasím, přijde mi to dost zvláštní. Překvapilo mě, že v node js coding guide jsem to zahlédl (snad se teď nepletu) jako ukázku „jak by se to mělo dělat“. S čárkou nakonci. Pamatuji si, že staré verze IE na tomhle v js padaly.

      2. Jakub VránaAutor příspěvku

        Re: Čárka, čárka stolička sněhulám
        Chybějící čárka za posledním prvkem je problém u tohoto formátování kódu:

        return {
          x: this.x,
          y: this.y
        }
        

        Když chci přidat další prvek, nemůžu to udělat prostým zkopírováním a úpravou posledního řádku, musím ho i upravit. Když to udělám, diff pak vypadá takhle:

           x: this.x,
        -  y: this.y
        +  y: this.y,
        +  z: this.z
         }
        

        Že jsem jen přidal jeden prvek, je v tom zbytečně zamlžené. Navíc to znehodnocuje blame – když chci vědět, kdo přidal řádek s y, tak se to prostým pohledem na daný řádek nedozvím. Stejné problémy samozřejmě nastávají, pokud chci poslední prvek naopak smazat – nestačí smazat jeden řádek, musím upravit i ten před ním.

        Takže tady máme tři nevýhody (pracnější úprava, složitější diff, znehodnocený blame) a jednu zdánlivou výhodu – přehlednější kód. Ale tato zdánlivá výhoda má aspoň pro mě osobně nulovou hodnotu, protože následující kód je úplně stejně přehledný:

        return {
          x: this.x,
          y: this.y,
        }
        
        1. jehovista

          Re: Čárka, čárka stolička sněhulám
          naprosty nesouhlas s Jakubem. Blbe se to cte. Neodpovida to „normalnim“ programovacim jazykum, ani jazykum neprogramovacim. Jestli te vazne prudi ze pak mas diff na dva radky, tak to muzes zapisovat takhle:

          x: this.x
          ,y: this.y
          ,z: this.z
          

          Kazdopadne blame je sam o sobe dost na prd. Vzdycky je potreba podivat se na diff.

          1. Jakub VránaAutor příspěvku

            Re: Čárka, čárka stolička sněhulám
            Tento způsob zápisu jen přesouvá problém z posledního řádku na první. Navíc pokud se máme bavit o čitelnosti, tak tohle je naprostá tragédie.

  9. pb

    scala?
    Jaký je Váš názor na Scalu? Četl jsem všechny Vaše zmíněné články a přijde mi, že je asi nejmenší zlo. Sám ji používám už delší dobu a (po týdnu zvykání na syntaxi) je to extrémně silný a pohodlný jazyk.

    1. satai

      Re: scala?
      Scala ma spoustu prima vlastnosti, ale IMO uz je prilis slozita. Pokud jde jenom o to zbavit se bolesti Javy a pridat zakladni moznost neproceduralnich jazyku, tak bych sel do Kotlinu. Je to o neco pragmatictejsi pristup a je ocividne zamereny na moznost pokracovat tam, kde konci Java, spis nez na to napsat co nejvic paperu o language design.

  10. Míra

    Podivností v JS
    Každý jazyk má své výhody a nevýhody. Platí to i pro některé špeky v PHP. Proč se v php používá např. speciální operátor „.“ na sčítaní řetězců? Už hodně krát jsem na tuhle nelogičnost naběhnul. Všechno ostatní se sčítá přes „+“, ale při pokusu sčítat řetězce z toho vyjde nesmysl.

    Pokud jde o vnořování callbacku tak to není nutné psát všechny callbacky inline. Stačí místo inline definice napsat referenci na funkci. Tím dostanu lineární seznam funkcí v jednom objektu.

    1. Jakub VránaAutor příspěvku

      Re: Podivností v JS
      Oddělení operátoru pro sčítání a zřetězení naopak u dynamicky typovaného jazyka dává velmi dobrý smysl. Když uživatel do formuláře zadá třeba 20 a 15, tak a.value + b.value vrátí v JavaScriptu 2015. Abych dostal 35, musím napsat např. +a.value + +b.value, což není úplně vzhledné. Naopak $_GET['a'] + $_GET['b'] v PHP funguje bez problémů. V PHP se pomocí + sčítají čísla, nikoliv „všechno ostatní“.

      Reference na funkci je často ještě horší – proměnné používané ve vnější funkci si musím explicitně poslat pomocí bind, kód se navíc fragmentuje na často jednořádkové funkce. Takže místo toho, aby funkce byly nějaké logické celky, tak jsou to jen fragmentu kódu, které samy o sobě často nedávají žádný smysl.

      1. Míra

        Re: Podivností v JS
        Tady se evidentně neshodneme. Pokud sčítám řetězce, tak chci aby to byl zase řetězec. U čísel zase čekám jako výsledek číslo.

        Pokud se týká callbacků tak předávání přes parametry nebo dokonce uzávěry do inlinovaných funkcí je opravdu cesta do pekel.
        Měl jsem na mysli konstrukci kdy místo callback: function(param) {tělo funkce} napíšu konstrukci callback: this.mujCallback a v tom samém objektu ve kterém je aktuální funkce nadefinuji i metodu mujCallback. Vše je lineární protože jde o dvě metody stejného objektu.

  11. tomkisw

    Není to tak špatné
    Iterace polí pomocí forEach je naopak velmi příjemná a nápomocná, přeci jen fci pro implementaci iterace lze znovupoužít pro více iterací (a mnohdy se i takto děje).

    U objektu bych implicitně předpokládal chování jako HashMap nikoliv LinkedHashMap, přeci jen spoléhat se na pořadí klíču u mapy není zrovna zdravé a zavání to špatným návrhem.

    Callback hell – již dávno není problém, naopak se pro asynchronní programování velmi hodí a při využití Promises se stává velmi mocným nástrojem, chainovaní promis v node.js napomáhá čistému a především neblokujicímu kódu.

  12. flv

    JS a php
    Mam ted rocni zkusenost s PHP, nekolik let s JS ale spis paberkovani a zatim jsem nepotreboval vic nez jQuery.

    Puvodne jsme javista, asi 7 let a ted delam prave rok s PHP a po roce prace s PHP si na tenhle jazyk nemuzu porad zvyknout.

    Co me osobne vadi je vysoka nevyhoda PHP pri refaktoringu, nebo asipon nevim jak spravne refaktroing delat.

    Refaktoring je pro me zakladni nutnost pri vyvoji OOP aplikaci, protoze neustale delate vyssi a vyssi abstrakce, presuny, konsolidace, proste ten objektovy model je zlvi a neustale se vylepsuje , tak jak se projekt postupne vyviji.

    No a v PHP mam s timhle problem, refaktoring tam moc nefunguje. Pokud se rozhodnu pro treba zavedni nejak nove abstraknti tridy, kdy se ukaze ze proste vice objektu z ni benefituje, tak je to v PHP dost porod v podstate jen na zakalde toho, ze si neni schopny overit zachovani zakladni kompilovatelnsoti.

    Me osobne to pak casto odrazuje vubec nejakou zmenu v PHP delat, protoze si nejsme jisty kde to pak vyelze na produkci. Ano testovani je dobre, ale treba testovat nejkou view vrstvu jen kvuli tomu, abych pochytil ze jsem nekde nenapsal spatne jmeno metody mi prijde jako plytvani lidskymi zdroji.

    Nevim no, po roce prace s PHP nemuzu byt zadny expert na nej, to snad ani nejde, nicmene stale se na ten jazyk proste nemuzu naladit a tapu.

    1. Jarda

      Re: JS a php
      Souhlasim s tebou. Muzu jedine poradit, ze trochu pomuze dobre IDE (treba PHPStorm). Porad to neni idealni, souhlasim.

  13. vojtech.dobes

    Re: Podivností v JS
    Ta neshoda je podle mě vyvolaná právě výrazem „sčítání řetězců“. Řetězce se pochopitelně nedají sčítat v původním významu tohoto slova (dají se spojovat, skládat, konkatenovat…). Teprve protože se používá stejný operátor (sčítací plus) pro tyto dvě různé operace, tak se naskýtá formulace „sčítat řetězce“ a z toho vyplývající logika, že když sčítám řetězce, výsledkem by měl být řetězec.

  14. snehuliaik

    Neverim vlastnym ociam...
    …ked sa pozriem na datum kedy bol tento prispevok zverejneny a na fakt ze NIKTO – auto ani v reakciach nespomenul JAVASCRIPT STRICT MODE… Moderne browsery ho podporuju uz par rokov a riesi napriklad problem s globalnymi premennymi a dalsie veci… Pred par dnami som sa musel ponorit znovu do Perlu a po JavaScripte je to hruza – hlavne rozlisovanie co je scalar, co je dictionary, co je pole…
    Python je pekny ale tiez nie genialny, dospel som tiez ku hviezdickovym konstrukciam ktore vyzerali ako pointre v C++ a prehladne to bolo rovnako…
    Idealny jazyk neexistuje ale Javascript ma z mojho pohladu k nemu najblizsie. :)

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=13930