Zoufalý stav JavaScriptových IDE

Už pár let je ve světě “běžného” softwarového vývoje jasné, že se JavaScriptu nedá a nebude dát vyhnout. Máme teď v Agiliu rozpracované tři projekty a každý z nich JavaScript víc nebo míň používá, ať už na klientu (a tady nejde jen o browsery, ale i o instalované aplikace) nebo na serveru (Node.js). JavaScript je už dneska skoro všude a ani do blízké budoucnosti to nevypadá, že by se trend měl nějak otočit.

Proto jsem čekal, že pro něj budou existovat dobré nástroje. A když říkám dobré, tak nemyslím editor, který podbarví kód a trochu tuší, co v kódu je identifikátor kvůli snazší navigaci. Myslím tím normální IDE, jako existují snad pro každou jinou technologii, tj. kontrola kódu, vychytaná navigace po symbolech, mechanismy pro dělení větších projektů na menší celky (knihovny), ladění atd.

Jaká je realita v roce 2012? Upřímně, docela zoufalá.

Visual Studio se v nejnovější verzi chlubí skvělou podporou JavaScriptu, jejich evangelíci pořád dokola opakují, jak je nyní JavaScript “first-class” jazykem atd., ale z Visual Studia je bohužel na hony cítit, jak Microsoft JS vývoji “nerozumí”. OK, přidali docela chytrou IntelliSense (doplňování kódu), která dokáže pracovat i s dynamicky vytvořenými proměnnými (např. v cyklu vytvoříte proměnné i1, i2i10 a hned za cyklem vám Visual Studio tyto proměnné nabídne), ale to je asi tak jediná pozitivní věc, kterou jsem ve Visual Studiu zaznamenal. Všechno ostatní je takové “nejavascriptové”. Např. dokumentační komentáře nepíšete ve standardním JSDocu, ale podivnou syntaxí s třemi lomítky, navíc ještě uvnitř funkce, nikoliv před ní. Visual Studio rovněž nerozumí konceptu knihoven, všechno jsou pro něj soubory uložené přímo v hlavním projektu, což má řadu nevýhod (knihovní kód se hůř sdílí, do vlastních JS souborů je potřeba přidávat explicitní reference, aby vůbec fungovalo napovídání, musí se bojovat s tím, aby statické kontroly nekontrolovaly externí knihovny typu jQuery apod.) Integrace se standardními nástroji typu JSLint / JSHint jsou věci, na které MS nemyslel vůbec, a jsou na více či méně spolehlivých pluginech třetích stran apod. Prostě IDE s dobrou podporou JavaScriptu si představuju jinak.

WebStorm je takový “cool kid on the block” a aspoň snaha je tam cítit asi největší – tento nástroj se snaží podporovat Node.js, různé šablonovací jazyky (třeba Jade), testovací frameworky (Jasmine, QUnit atd.), prostě je znát, že JetBrains vědí, co je pro reálný JS vývoj potřeba a snaží se to v jejich IDE podporovat.

Přesto nemůžu říct, že bych byl z toho nástroje úplně nadšený. Jednak mám problém se samotnou “platformou” (IntelliJ IDEA), která mi oproti konkurenci připadá horší skoro v každém ohledu (logika ovládání, umístění položek v menu a jejich názvosloví, intuitivnost klávesových zkratek atd. atd. – prostě typický produkt JetBrains). No a potom mě zarazilo, že údajně nejlepší IDE na JavaScript nepodporuje tak základní scénář, jako je jeden HTML soubor plus jeden externí JavaScript. Takže třeba jedna stránka plus externí jQuery.js je ve WebStormu nepodporovaný scénář, čemuž pořád ještě nemůžu uvěřit.

Eclipse je obecně mé nejoblíbenější IDE, protože podle mého názoru vzalo kupu věcí za správný konec: používá platformově nativní widgety (takže vzhled je OK), i pokud se někomu vzhledově nelíbí, tak většina úkonů se v Eclipse dělá rychle a intuitivně, dále má rozumný model knihoven a editor kódu patří mezi IDE vůbec k těm nejlepším (zatímco třeba mezi Visual Studiem a Sublime Textem je propastný kvalitativní skok, mezi Eclipse a ST2 je ten rozdíl relativně velmi malý). Koukal jsem proto, jak je na tom Eclipse s podporou JavaScriptu.

Jako u ostatních věcí v Eclipse, ten směr není špatný – např. v projektu snadno označíte, co jsou “knihovny” (externí kusy JavaScriptu, u kterých chcete napovídání jejich funkcí, ale už ne syntaktickou kontrolu) a co jsou vaše zdrojáky. Ten model funguje úplně stejně jako u jiných jazyků typu Java nebo PHP, což se mi líbí (třeba VS se k JavaScriptu chová principiálně jinak, než k jiným jazykům, což nechápu). Bohužel jsem však v Eclipse narazil s nějakou konkrétní knihovnou, kterou jsem potřeboval používat – její editor neuměl externí kód “pochopit”, tj. co jsou “classy”, co jsou její “metody” atd. a tím pro mě bylo editování v Eclipse ve výsledku neužitečné. Rovněž mi vadí, že práce na JSDT (JavaScript Development Tools, ta část Eclipse, která je pro toto důležitá) probíhají jen velmi volně, za posledních pár měsíců např. nejsou skoro žádné commity, a to si moderní IDE, které to s podporou JS myslí vážně, nemůže dovolit.

Ještě jsem v rychlosti zkoušel Aptanu a daly by se vyzkoušet NetBeans, ale už nějak nevěřím, že něco opravdu dobrého najdu. Štve mě to, protože dobrý tool by se mi zvlášť teď v začátcích hodil, ale prostě takový asi na trhu není.

Závěrem pro hnidopichy / JS fanboys:

  • Ano, potřebuji IDE, editor mi nestačí. Nedělám ten vývoj primárně, spíš se k němu občas namanu, a potřebuji, aby mi něco ve vývoji pomáhalo a částečně myslelo za mě. Jako v jiných jazycích.
  • Vím, že JS je dynamický jazyk a že jeho podpora je nesnadná. Ale mám pocit, že tím je to jen částečně a že výrobci IDEček dělají úplně elementární, zbytečné chyby – např. VS je nepoužitelný, když nerozumí JSDocu, WebStorm zase neumí pořádně označit externí JavaScript jako knihovnu a Eclipse se snaží každý JS naparsovat do modelu “tříd” a “metod”. No a samozřejmě, JavaScript jako jazyk z praktického pohledu saje :)
13 thoughts on “Zoufalý stav JavaScriptových IDE
  1. Skvělý článek Borku. Ano, prošel jsem si tím samým marastem, abych se nakonec smířil s holým editorem. Ono to má i své přednosti (rychlost, jednoduchost atd.) Co jsem potřeboval jsem si nascriptoval (v JavaScriptu samozřejmě). Proto pro Este.js doporučuji SublimeText. Kontrola syntaxe, testy atd. řeší script přes consoli.
    Ad navigace. SublimeText cmd-r a cmd-p s # a @ řeší 80 % navigace. Proklik na předky a místo deklarace by byl pěkný, a nevylučuji že ho do SublimeText dopíšu, ale v praxi mi moc nechybí, protože myš při vývoji skoro nepoužívám. Samozřejmě chápu, že toto řešení není univerzální, ale mne velice vyhovuje.

  2. Připadá mi, že jsi na ten WebStorm vymyslel zbytečnou záludnost. Ten linkovaný bug přece nic neříká o tom, že to nejde, ale o tom, že v té externí knihovně nejde vypnout analýza kódu.

    Každopádně v bugu aktivně odpovídá vývojář a slibuje podporu do příští verze (která je ve fázi release candidate). Které jiné IDE takhle aktivní podporu má?

    Navíc cena produktů JetBrains je hodně slušná.

    Respektuji, že se někomu nelíbí IDE v Javě, ale produkty JetBrains jsou jednoznační tahouni oboru. Což mimochodem i ukazuje jejich ReShaper, který dělá z cizího MS produktu použitelnou věc :)

  3. Skutečně hezký článek. Osobně používám WebStorm a i přes to, že není zcela dokonalý, tak jak už bylo napsáno výše, ta snaha tam jít tím správným směrem je cítit. Je mi hodně sympatický přístup vývojářů, kteří se snaží přidávat třeba podporu jade apod. a věřím, že v tom budou dále pokračovat a práce zde bude pak příjemnější a hlavně produktivnější:)

  4. Martine, já mám naopak za to, že jsem ve WebStormu vyzkoušel úplně to nejjednodušší, co se u JS IDE zkusit dá – jedna stránka a přilinkované jQuery. On si s tím WebStorm nějak poradí (dá se např. vytvořit globální knihovna), ale z mého pohledu prostě nemají tenhle nejzákladnější use case pořádně pořešený. Jak máš potom nástroji věřit, že bude zvládat komplexní problémy?

    Jinak jsem ani nevěděl, že EAP verze 121.150 označují jako Release Candidate, a docela mě to děsí. V editoru mají třeba zabugovanou tak základní věc, jako je move lines, a nedokonalostí je opravdu kupa na každém kroku. Jak říkám, je to hodně o důvěře v nástroj, a WebStorm ji u mě teda zatím vůbec nemá.

    Nicméně, a to by nemělo zapadnout, znovu zopakuji, že i tak je WebStorm zdaleka nejnadějnější z toho, co jsem zkusil. Přeju jim (i nám, ubohým vývojářům :), aby to dotáhli.

  5. Já nejsem přesvědčen, že IDE je v JavaScriptu dobrý nápad. Argument “jako v jiných jazycích” neberu. Tohle nejsou jiné jazyky! Nauč se JS specifika.

    Každý jazyk má svoje kulturní specifika – když řeknu Perl, Java nebo PHP tak se vám před očima vybaví mnohem víc než jen technické moznosti jazyka: Perl vypadá před i po gzip kompresi stejně, Javě trvá 1k SLOC napsat Hello World, PHP aneb “pojďme hned prasit” apod.

    Jsou to samozřejmě stereotypy, ale vycházejí z kulturního zázemí které si každá komunita okolo jazyka buduje sama.

    V Javascriptové komunitě se prostě IDE nevede (není v tom myslím jediná, např. Ruby komunita k nim také myslím příliš nepřílnula). Můžeme se dohadovat zda je to primárním nasazením těch jazyků, nebo jejich zaměřením na expresivitu, nebo historickou shodou okolností nebo komerčními zájmy/firmami, které za těmi jazyky byly či nebyly.

    Nicméně myslím že Javascript IDE nejsou dobrá nikoliv proto, že je ten jazyk dynamický, ale protože Doug Crockford IDE nepoužívá, Ryan Dahl IDE nepoužívá, Brendan Eich IDE nepoužívá, Isaac Schlueter IDE nepoužívá a tak dále. A protože ho používat nechtějí.

  6. Bořku – aby IDE dobře podporovalo nějaký jazyk, musí být po něm hlad zevnitř. Ne od přeběhlíků z jiných jazyků, ale od expertů z komunity toho jazyka. Od těch, kteří to IDE pomůžou vyvinout.

    Nejblíž se k tomu zkouší dostat Google se svými pokusy okolo Dartu, případně se svými návrhy na a optional static typing přímo v Javascriptu a také s type inferencí v V8 kompilátoru atd. Tohle jsou ty skupiny, které můžou pomoct dobrému JS IDE. Ne výrobci IDEs které se tradičně specializují na jiné jazyky a teď dodělají i podporu pro JS.

    A to že se tak neděje mi přijde podmíněné zvykama/kulturou/názory skupin které Javascriptem hýbou, více než nějakou nepřekonatelnou technickou zábranou.

  7. Jakube, to mi přijde jako tvrdit, že IDEA pro svou excelenci v Javě potřebovala “hlad” či pomoc od Goslinga nebo že Visual Studio / C# IDE se vyvíjelo kvůli potřebám Hejlsberga a jeho týmu. Mám na to zcela opačný názor – IDE podle mě vznikají pro potřeby mas, pro produktivitu běžného Franty vývojáře a ve finále z důvodu, že na tom chtějí firmy produkující IDE vydělat.

    Myslím, že (např.) lidem v JetBrains je úplně jedno, co ke kódování používá Crockford / Eich / Dahl a další – oni nejsou jejich cílovka a ani je k práci na svém IDE nepotřebují, ideově ani jinak. Je to business, je po tom poptávka, tak proč to neudělat. Je vidět jen rozdíl v motivaci – zatímco například Microsoft JavaScriptu “nerozumí”, v JetBrains jsou si evidentně vědomi toho, co se od JS IDE očekává, a mé výtky jsou hlavně okolo celkové nezralosti tohoto produktu, ale v zásadě myslím, že tam za pár let budou. I přesto, že si Crockford bude dále kódit v Emacsu.

  8. Pouzivam PhpStorm a jQuery mi funguje naprosto ukazkove vcetne naseptavani, a to i po nekolikerem vnoreni (napr. JS v HTML ve Smarty sablone).

  9. Jakube, tvuj komentar se mi moc libi a ve vsem tentokrat musim souhlasit s tebou. Mozna bohuzel proto ze pouzivam emacs na javascript, C, PHP, Java, Ruby, BASH, lisp i SQL :)

  10. Jestli to není tím, že v ostatních jazycích (Javou a C# počínaje a PHP ani zdaleka nekonče) se psaly rozsáhlé aplikace používaní i v bankách a telekomunikačních společnostech už před osmi lety. Zato v JavaScriptu se až na pár vyvolených psaly tak akorát validace formulářů a pluginy do Firefoxu. JS intenzivní nástup do světa velkých aplikací zažívá posledních pár let (a můžou za to věci jako souboj jader prohlížečů, internet všude a smartphony všude) a ekosystém na to zatím není připraven (odladit node.js aplikaci na Joyentu je těžší, než na posledním českém free-PHP hostingu, proti tomu jsou JS IDE ještě zlatá).

  11. To je určitě jeden z hlavních důvodů, Jirko. Ten druhý podle mě je, že JavaScript je velmi “nepraktický” jazyk a má kolem sebe velmi divoký ekosystém (do značné míry vyplývá z předchozího) — udělat pro něj IDE je určitě těžší než pro Javu/.NET/PHP.

Leave a Reply

Your email address will not be published. Required fields are marked *

Mete pouvat Markdown: **Tun**, *kurzva*, `kd` atd.