Názory k článku
Náhrada za editor Atom je jeho fork Pulsar
-
Microsoft bol vždy viac orientovaný na vývojové nástroje, než na tvorbu operačných systémov.
Ich prvý operačný systém bol Unix, lebo mu predpovedali budúcnosť. MS-DOS proste kúpili, keď IBM nebolo úspešné pri rokovaniach s DRI. Windows NT a Windows 95 sa proste nejak stali, keď Microsoft nasrala spolupráca s IBM na OS/2.
Operačné systémy mali proste nič moc, ale nástroje boli fajn. Spomínam si na prechod z Borland C na Visual studio, to bolo pre mňa nebe a dudy.
-
Mám to podobně.
Narazil jsem letos v létě na ambicozní projekt https://theia-ide.org/. Jsem byl nejprve nadšený, pak mě to rychle přešlo. Ale je to postavené nad jádrem z ms vs code, je to součást eclipse foundation, úplně tomu nerozumím, ale nejspíš si velcí hráči hrají na opensource se stejnými hračkami :-)
-
Já jsem před lety objevil Sublime Text (ST), sice není zdarma, ale udělal na mě hlavně dojem tím, jak byl rychlý a také jak byl schopný otevřít i textové soubory o velikosti několika set megabajtů. Tak dlouhé zdrojáky sice fakt nepíšu, ale občas se to hodí. Licenci jsem si pořídil (a od té doby myslím jednou platil ještě za upgrade). Objevil jsem pak i Atom, VSCode. Ano, je to hezké, umí to různé další užitečné věci. Ale jak je to v tom Electronu, tak rychlé jako ST to asi nikdy nebude. A navíc on i ten ST je občas trochu vylepšován a některé zajímavé nápady se do něj postupně dostávají...
Ano, není to plnohodnotné IDE, ale jako rychlý textový editor, ve kterém tedy napíšu i dost kódu v Pythonu, kdysi i v PHP, HTML, etc. se to osvědčilo víc než dost.
Pokud chtějí z Atomu udělat pořádný fork, nejlepší by asi bylo pokusit se o přepsání do něčeho jiného, než ten Electron. :-)
-
Filip JirsákStříbrný podporovatelK čemu by bylo dobré napsat od nuly úplně nový editor a pak na něj jenom přelepit logo Atomu? Kdyby chtěli psát úplně nový editor v jiných technologiích, tak to udělají a nebudou forkovat Atom.
Mimochodem, editorů zaměřených na rychlost je víc – vedle zmíněného Sublime třeba ještě Zed přímo od autorů Atomu. -
Filip JirsákStříbrný podporovatel
A jakou platformu byste tedy použil pro GUI aplikaci psanou pomocí webových technologií (tj. výkonný kód v JavaScriptu), aby to nebyl Electron?
-
Filip JirsákStříbrný podporovatel
RDa se ptal, proč od nuly, když můžete použít stávající kód. Tak hodně štěstí při použití kódu napsaného v JavaScriptu pro Electron pro novou aplikaci psanou v C++ s Qt nebo v C# s AvaloniaUI.
-
priama nahrada NW.js, ktory je len o malo nenazranejsi ako Electron, ale pribaluje aspom cerstvejsie chromium. Ak to nepotrebuje chromium ale staci mu webkit tak tauri. Ak tomu staci nativny brovser tak neutralino... To neutralino by mohlo byt najzaujimavejsie, co sa tyka velkosti a zabranej pamate - https://github.com/neutralinojs/evaluation
-
Filip JirsákStříbrný podporovatel
Máte pocit, že něco z toho bude znatelně rychlejší, než Electron?
-
Hlavně link výše je 6 let neaktualizovaný projekt. Ale existují aktuální alternativy, které využívají systémový prohlížeč. Problém je, že šetřïte jen download size a disk space. Rychlé je to stejně a ještě řešíte odlišnosti prohlížečů. V případě macOS je navíc systémový prohlížeč "současný Internet Explorer" (bugy, včetně výkonnostních).
-
To repo, z pred 5 rokov, je priklad pre porovnanie electronu, nwjs a neutralina. Repo pre samotne neutralino je tu https://github.com/neutralinojs/neutralinojs
3. 1. 2024, 23:47 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Já jsem to nezkoušel. Ale vím, že Blink i V8 jsou opravdu hodně optimalizované, překvapilo by mne, kdyby měl někdo výrazně rychlejší řešení se srovnatelnou funkcionalitou (samozřejmě mohou existovat renderovací jádra, která umí něco malinko z HTML a CSS, která budou rychlejší – ale to je nepoužitelné. To samé s JavaScriptovým enginem). Takže pak zbývá možnost, že by bylo pomalé to „lepidlo“ Electronu mezi – ale také mi nepřipadá pravděpodobné, že by tam byl velký prostor pro zlepšení.
Samozřejmě může být rozdíl v rychlosti startu, pokud máte menší jádro které poskytuje méně služeb. Rozdíl v době běhu by pak mohl být způsobený obsazenou RAM a swapováním – ale upřímně, RAM je dneska tak levná, že pokud má někdo pomalý editor, protože má 4 GB RAM, to je prostě problém nedostatku RAM a zdaleka nejefektivnější řešení je přidat RAM.
Obecně budou určitě problém neefektivně napsané pluginy, ale to nemá řešení v použití žádné jiné technologie. To je prostě rozhodnutí rychlost a málo funkcí × hodně funkcí, rozšiřitelnost ale to znamená i spoustu nekvalitních pluginů.
-
RAM levná není. Už i spousta PC notebooků ji má pájenou, a v takovém případě jste rukojmím výrobce, který si vyšší kapacitu hodně nacení (skoro stejně hodně jako Apple).
> To je prostě rozhodnutí rychlost a málo funkcí × hodně funkcí, rozšiřitelnost ale to znamená i spoustu nekvalitních pluginů.
Velký souhlas. Ae spousta lidí to řeší jednoduše tím, že na ten software hodí větší hardware. Ten je totiž nejlevnější v historii.
-
Filip JirsákStříbrný podporovatel
RAM je levná. I když jste odkázán jen na to, co nabízí výrobce, pořád je to pár tisíc. Za stejnou cenu, jako tu RAM, si možná můžete pořídit jeden rychlejší editor – ale co ostatní software? Ten bude pořád stejně pomalý.
Velký souhlas. Ae spousta lidí to řeší jednoduše tím, že na ten software hodí větší hardware. Ten je totiž nejlevnější v historii.
Takže je RAM levná :-) Protože to je rozhodující. Nic s rotačním diskem snad už dnes nekoupíte ale hlavně při editaci textového souboru snad rozdíl HDD/SDD nepoznáte. Stejně tak nepoznáte rozdíl pár taktů procesoru – a pokud byste měl nějaký vyloženě pomalý mobilní procesor, nezachrání to zase ani Sublime. -
Filip JirsákStříbrný podporovatel
Mícháte dohromady věci, které spolu nesouvisí. Kvalita kódu nesouvisí s potřebou RAM. To, že je kód napsaný nějak, neznamená, že by jeho autor nebyl schopen napsat kód jinak. To, že někdo jede autem, neznamená, že by nebyl schopen jet na koni. A dnešní počítače, které mají podstatně více RAM než měly počítače před 20 lety, mají zároveň daleko nižší spotřebu. Takže vývoj počítačů ekologii v tomto případě pomáhá, ne škodí.
-
> Mimochodem, editorů zaměřených na rychlost je víc – vedle zmíněného Sublime třeba ještě Zed přímo od autorů Atomu.
Pro zajímavost, tento program je jedním z příkladů, jak na Mac s Apple Silicon masivně přecházejí vývojáři (ten procesor je pro kompilování kódu ku*evsky rychlý, i base verze v pasivně chlazeném lownedu).
-
To už ovšem přecházejí dost dlouho. Vývojáři kolem mě mají Macy dost masově už roky a to napříč firmami. (Ovšem většinou mimo korporáty.) A to i v době, kdy jely na Intelu. Ono to jen tím CPU fakt není. Navíc výkonný je obecně, opravdu ne jen "pro kompilování kódu".
Ostatně kdyby na jejich hardware bez problémů běhal Linux, taky bych celkem neváhal, co za železo si pořídit. Ale macOS je sice dobrý a skvělý pro manželku, ale nikoliv pro mě.
2. 1. 2024, 15:51 editováno autorem komentáře
-
U bráchy v korporátu Macy tiše trpěli, ale nebyl to problém, protože tam jel standardní x86 Windows (VM nebo dualboot). Problém byl s přechodem na ARM, kdy se muselo aktivovat IT oddělení a udělat podporu oficiální. Ta nyní už funguje (např. ARM verze VPN klienta do Windows on ARM virtuálky - x86 verze nedovolila běžet v x64 OS a x64 emulace byla tehdy ještě zabugovaná).
-
msmucrBronzový podporovatel
Ad výkon,
opravdu s tím máte u VSCode reálně problémy?Osobně to používám jako obecný editor i na C, C++ soubory, Python, web JS, XML a občas s zklonuji, procházím a edituji i docela velké projekty a nenarazil jsem na to, že by mě to nějak brzdilo. Na desktopu vůbec, ale i na jednom deset let starém Ultrabooku, s 1.3GHz CPU a 4GB připájené RAM. Samozřejmě, kdybych na tomhle stroji pouštěl kompilace a sestavování, tak by to bylo znát. Nicméně zdaleka největší bottleneck je vždycky moje hlava ;)
Občas si pomůžu s klasickými ctags (je k tomu doplněk do VSCode), což je fajn, protože to pak můžu použít na skákání po definicích v projektech i třeba Vimem, když je to někde na serveru.Rychlost s obrovskými soubory pro mě nemá moc velkou prioritu v rámci všech vlastností daného editoru. Potřebuju to možná jednou do roka, když bych třeba řešil úpravu nějakého SQL dumpu pro migraci opravdu velké databáze. Ale tam bych stejně radši vyextrahoval nějaký malý kousek, odladil si regex a pak na to pustil třeba in-place sed, co to udělá v podstatě rychlostí čtení a zápisu na disk.
ad ElectronJS,
tak nevybrali si to asi kvůli F12 :) To rozhodnutí o konkrétním vývojovém prostředí a architektuře má asi víc aspektů, něž jen kolik to sežere paměti a jak rychle trvá první spuštění, ne?
S TypeScriptem (resp. JS) dnes můžou pravděpodobně počítat s daleko větším zapojením ostatních vývojářů a firem, než kdyby udělali třeba základ v C/C++ a nějaký svůj interní interpret pro vývoj doplňků (a la Vim). Ten ekosystém (rozšiřitelnost JS doplňky, LSP..) okolo VSCode je jedna z jeho největších výhod. A těží z toho i ostatní IDE se stejnou koncepcí, např. zmíněná Theia.
Navíc můžete snadno udělat variantu, co běží z jakéhokoliv moderního prohlížeče - https://vscode.dev případně nějaké sdílené verze.
No a když už tedy TypeScript/JS, CSS pro vývoj aplikace, tak ten ElectronJS se zdá být asi dnes nejlepší varianta.
- je tam jeden z nejrychlejších JS virt. strojů
- pro kritické části se dá použít WASM
- používá to spousta ostatních softwarů, aktivně to vyvíjí, vychytávají problémy, optimalizují, je tam už uděláno mnoho práce
- solidně to funguje napříč desktopovými platformami (Win, Linux, macOS) -
> Ad výkon, opravdu s tím máte u VSCode reálně problémy?
Treba ja jsem pri psani dizertace v LaTeXu musel prejit z VSCode zpatky na vim kvuli tomu jak se to sekalo (zdrojak s par tisic radky). Jsem zvykly mit cely dokument v celku a pouzivat foldy na rychlou navigaci v textu. To sekani bylo nejhorsi pri foldovani a prechazeni pres foldnute sekce, ale sekalo to nahodne i pri psani textu. Je mozne, ze za to muze nejake rozsireni, bez nich pro mne ale VSCode straci smysl.
-
msmucrBronzový podporovatel
To je samozřejmě možné, já v tom nikdy nic s LaTeX projekty nedělal. Plus případné zpomalení bude jistě odvislé i od toho, jak je napsaná a efektivní konkrétní podpora pro daný jazyk resp. rozšíření.
U spousty z nich tam může být nějaký analyzér, helper na pozadí, co asynchronně komunikuje přes LSP s IDE a poskytuje doplňování, kontroly atp. Taktéž pak jak je např. implementovaná detekce foldů.
Třeba i u toho zmíněného Vimu tohle hraje s velkými soubory zásadní roli. Pár tisíc řádek asi v pohodě, ale pamatuji si, že jsem editoval nějaká hierarchická data v JSONu (před importem do různých systémů), řádově vyšší desítky MB a folding se taky hodil. Pokud jsem ve Vimu použil nejspolehlivější foldmethod=syntax, tak se ty foldy detekovaly snad 5 min. Když jsem pak vyladil nějaký externí prettifier, a použil foldingmethod=indent, už bylo to asi 100x rychlejší. Kdybych to používal častěji, asi by bylo namístě zařídit si lepší detekci foldů, přes nějakou chytřejší expression.
Notepad++ (Scintilla) v podstatě zhebnul, neměl jsem na to trpělivost :).
VSCode byl pak po vynucení (standardně vypíná syntax a folding pro velké soubory) použitelný, všechny foldy bez chyb, dalo se s tím dělat, ale sežral asi 40x víc paměti než Vim.Stran těch rozšíření, můžete si je rozházet do profilů, třeba podle jazyka, aby se urychlil start a snížila základní paměťová náročnost.
Takže ano, bude dost záležet, co konkrétně se ve VSCode dělá a co kdo potřebuje. Psal jsem to samozřejmě čistě ze svého pohledu/zkušenosti a spíš reagoval i na to, že mě vlastně nijak nevadí, že je to v Electronu.. a nejsem úplně přesvědčen, že případná zpomalení jdou automaticky na jeho vrub. Jasně, bude tam vyšší paměťová náročnost, zvlášť ještě pokud třeba ta rozšíření běží ve svých sandboxech, ale to taky nemusí být nutně problém, pokud nemáte velké soubory (a zdechlý ultrabook bez RAM jako já ;)).
Koneckonců u těch JetBrains IDE, co běží nad JRE, jsem taky X krát slyšel, že někoho štve, že je to "v Javě" a proti tomu hromadu dalších lidí, co na to nedali dopustit, s tím že je to vzhledem k funkcím a benefitům toho prostředí irelevantní.3. 1. 2024, 00:05 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
S VSCode nemám problémy s výkonem (mám problémy s tím, že oproti JetBrains nástrojům to je neschopné). Přesně jak píšete – při psaní kódu nejvíc zdržuje hlava, a pokud potřebuji napsat víc kódu najednou, zdržuje mne víc to, pokud editor nemá dobré našeptávání a šablony a nutí mne doopravdy psát.
-
ST, různé nadstavby nad vim používám na denní bázi úplně na vše (vč. Javy a C++), nejsem primárně vývojář, nejedu per projekt, ale jsem zvyklý mít namapovaných stovky repositářů do jedné složky a nad tím pak otevřený editor.
Když tohle udělám s Atomem/Pulsarem, VSCodem, InteliJ, celé se to rozbije a neskutečně laguje.
Jsem stará škola, rád kódu rozumím, rád se naviguji přes fulltext a stromovou strukturu, rád kód čtu, rád ho píšu, aby vypadal vizuálně přehledně. IDE jde proti mně a nikdy jsem si na něj nezvyknul.
Mám rád čisté UI s minimem ovládacích prvků, nepotřebuji na vše ikony, nevadí mi si pamatovat a zapisovat příkazy či zkratky. ST má pro mě ideální UI.
-
Nejsem sice primarne(mozna tercialne :-) progros, ale v zivote jsem nekolik ide (nepocitam-li osmibity) zkusil. Za mne nejvetsi neprehlednym,nestabilni, upgrady rozbijejici hnuj byl Eclipse, ktery jsem zel musel v minulem megakorporatu protrpet. Proti nemu VSCode je svou rychlosti,prehlednosti,pluginy jako vesmirna lod enterprise v porovnani s konskym povozem.
3. 1. 2024, 10:53 editováno autorem komentáře
ČLÁNKY DO MAILU