Názory k článku
TypeScript sa na GitHube stal programovacím jazykom číslo jedna
-
TypeScript je hlavně až překvapivě komplikovaný pokud ho používáte opravdu důkladně. Což vlastně úplně nechcete. Místy skoro až do nečitelnosti. Problémy s tím celkem logicky bude mít i AI. A nevím, jestli bych řekl, že je "pozadu". Pořád je to rovnák na ohejbák, navíc musí (mimochodem z definice což se moc neví) respektovat jak strukturu javascriptu tak jeho syntaxi. Nemyslím, že by se dal přímo srovnávat s jinými platformami.
Jako ano, pravda je, že obsah té zprávičky je jak z marketingového materiálu.
7. 11. 2025, 14:18 editováno autorem komentáře
-
KateStříbrný podporovatel
Tak pokud pomineme tenkou vrstvu JS pro práci s DOM, dá už se na web frontend díky WASM použít leccos, já mám pár menších věcí v Rustu.
-
Jo, jen ta tenká vrstva dělá jaksi vše. Upravuje DOM, poslouchá eventy, volá fetch a ostatní web api, komunikuje s workery a service workerem atd. Ale super, parsování JSON můžete mít v Rustu. Což bude teda pomalejší, protože JS používá nativní implementaci (ne pure-JS), zatímco WASM je ve virtuálce.
Nehledě na to, že zatím kloudna velikost WASM bin vypadne jen pro jazyky bez správy paměti. A jakž takž se dá TinyGo, embed verze Go. Uvidíme až bude WASM GC, jestli to něco změní, když půjde delegovat GC.
WASM na webu dává smysl pro výpočetně náročné aplikace ala Web-AutoCAD. Případně, když chcete použít nějaký algoritmus, co máte napsaný v něčem jiném.
Zbytek je jen zatvrzelé vyhýbání se JS. A i tak ho musíte použít. -
Pokud existuje v daném jazyku dostatečný ekosystém pro wasm, různé frameworky, tak tam žádná vyloženě hranice není. Příklad .NET s Blazerem, nově Kotlin, Flutter ...
Můžeš dělat UI naprosto v pohodě. Na JS občas narazíš, ale ten ekosystém je schopen tě od toho dost odstínit.
Wasm-gc je dost game changer, ale pomůže hlavně těm autorům knihoven a compilerů atp. je už ve všech browserech.Jde hlavně o rozjezd nějakých nových projektů, nejčastěji fullstack, kde hodně převažuje backend v něčem jiném než JS. Frontend tam prostě pak jednoduše doplácneš. A pokud je tam nějaká výpočetně náročná věc, tak tím spíš je wasm lepší volba.
Ale že by došlo k masívnímu odlivu aplikací od JS, to vůbec. Je to prostě další možnost a už velmi slušná.
Jako budoucnost se ale rýsuje čistě wasm řešení i na serveru (wasmer, WASI) a použití wasm jako univerzální platforma, nahrazující např. docker, kontejnery atd - viz. např. https://www.fermyon.com/cloud
-
Pavel TišnovskýZlatý podporovatelTo je zajímavý, že na PyPL nebo Tiobe tedy TS není moc nahoře https://pypl.github.io/PYPL.html https://www.tiobe.com/tiobe-index/ (jasně, každej to měří jinak a něco jiného, ale nějakou korelaci by tam mělo být vidět)
Že by počítali forky forků? :-)
-
Ještě to přepsané není. Jako obvykle, posledních 10% trvá 90% času.
Ten přepis mi přijde trochu jako Andersova hračka. Ono jde hlavně o ten type checker, samotnou kompilaci TS -> JS zvládá rychle už spousta konkurenčních kompilátorů v rustu, go, ....
Ale ten type check umí rozumně jen tsc od Microsoftu.7. 11. 2025, 16:19 editováno autorem komentáře
-
Samotna kompilacia TS -> JS spociva vo vyhodeni anotacii a vlastne iba to tie kompilery v ruste, go robia.
To co je na TS zaujimave ale je v tych anotaciach, hlavne pocas vyvoja. Teda navyse kompiler sa musi vediet zotavit z neuplneho suboru s neplatnou syntaxou. Toto vsetko tsc vie, rozlicne rychle bundlery nie. Takze tsc ako linter, esbuild (alebo ina preferovana alternativa) ako bundler.
-
presne tak, ono totiž okrem syntaxe typovej anotácie skutočne neexistuje rozdiel v JS vs TS (a tento rozdiel má byť zmazaný, viď W3C proposal), okrem toho že sa odstraňujú inline anotácie pre typy vlastne TSC nič iné nerobí a ani sa nedá povedať že TS je programovací jazyk, ale skôr len type aware linter pre JS.
-
Ja stále nechápem prečo JavaScript a TypeScript sa delí do 2 osobitných položiek, keď prakticky neexistuje funkčný rozdiel medzi týmito jazykmi, neexistuje tam rozdiel v API, v rámci syntaxe je tam rozdiel len v syntaxy typových anotácií a TSC ako nástroj je skôr type aware linter (keďže typové anotácie neovplyvňujú ako reálne sú dáta uložené do pamäte).
My v práci používame JavaScript + Lua, máme codebase plne otypovaný, používame Typia na validáciu, atď. Nevidíme v podstate rozdiel proti TypeScriptu, a ani LLM a Copilot, ani nástroje, ani čokoľvek nevidia rozdiel.
8. 11. 2025, 16:41 editováno autorem komentáře
-
Ja v typescripte neprogramujem, ale viem, že má silnú podporu pre generické programovanie, a to nie sú iba typové anotácie a linter, ale samostatný sofistikovaný programovací jazyk, ktorý beží počas zostavenia a je použitý na výpočty s typmi, vrátane overovania, transformácií, prevencie umožnenia reprezentácie neplatných stavov, atď. Podobným samostatným jazykom sú šablóny v C++. Takže sa s tým dajú robiť komplexné veci.
-
"Ja v typescripte neprogramujem, ale viem,"
To vidím....
Tak mi daj sem presný príklad TS kódu s generickým programovaním, ktoré nie je možné docieliť v čistom JS (bez akéhokoľvek vplyvu na runtime). Rád by som videl taký príklad. Ale možno ty čo v TS neprogramuješ vieš lepšie než ja.
Nechcem si honiť ego, ale ak v tom neprogramuješ, nedáva zmysel aby si sa k tomu vyjadroval.
-
Aha, a nenapadlo vás, že generické programovanie je možné aj v iných jazykoch? A že v dvoch rôznych jazykoch môžu platiť podobné princípy, ktoré vychádzajú viac z teórie programovania ako z jednotlivých konkrétnych jazykov?
Čo môže znamenať, že keď má niekto dlhodobé skúsenosti s daným typom programovania v jednom jazyku, tak môže vidieť podobnosti v inom jazyku nielen z hľadiska výrazových prostriedkov, ale navyše aj z hľadiska vývoja porovnávaného jazyka, spôsobov jeho používania vzhľadom na pridávané funkcionality, omyly a problémy, ktorými si ten jazyk v daných etapách svojho vývoja prechádza.
Naozaj sa tí, ktorí programujú v štýle OOP v Jave nemajú vyjadrovať k OOP v C#? Podobne ako sa tí, ktorí píšu funkcionálne programy v Haskelli nemajú vyjadrovať k funkcionálnym programom v F#? Keď tie programovacie jazyky majú niečo spoločné?
9. 11. 2025, 12:08 editováno autorem komentáře
-
"Aha, a nenapadlo vás, že generické programovanie je možné aj v iných jazykoch? A že v dvoch rôznych jazykoch môžu platiť podobné princípy, ktoré vychádzajú viac z teórie programovania ako z jednotlivých konkrétnych jazykov?"
A nenapadlo vás že JS a TS pri typovej kontrole používa úplne rovnaký typový Engine (keď už hovoríme o kontrole v IDE/CLI/počas buildu)?
Absolútne nechápeš že JS a TS je rozdiel asi ako medzi Škoda Octavia RS, kde v jednom si dáš zelenú a v druhom modrú podušku pod ryť. Stále je to pritom stejné auto.
Porovnanie C# a Java? Ako vážne? Tam sú tie rozdiely úplne na inej úrovni, úplne iný runtime (JVM pre C# chceš povedať?) úplne iný princíp fungovania, funkčné rozdiely, API, atď atď.
V prípade TS ak aplikuješ "zero-effort type safety" napríklad známe zo Svelte, tak kód čo dostaneš je plne valídny JS a zároveň TS, nulový rozdiel, úplne nulový. Diff editor ti ukáže 0 zmien medzi JS a TS kódom.
9. 11. 2025, 13:27 editováno autorem komentáře
-
Nemám teraz na takéto veci čas, tak odpovedám neskôr.
Toto je celé nejaký vtip???
A nenapadlo vás že JS a TS pri typovej kontrole používa úplne rovnaký typový Engine
Nie, nenapadlo. Pretože nepoužíva. JavaScript nevykonáva typovú kontrolu v zmysle a rozsahu ako ju vykonáva TypeScript, zvlášť nie čo sa týka generického programovania, o ktorom som písal. Pokiaľ sa teda nezmenilo niečo zásadné, kým som sa pozeral iným smerom. Takže v tomto zmysle JavaScript nepoužíva žiadny typový engine a nástroje, ktoré používate a na ktoré sa odvolávate, používajú TypeScript a to aj keď kontrolujete kód napísaný v JavaScripte.
To nie je nejaký nezávislý modul vytvorený mimo ekosystém TypeScriptu, ktorý by používali TypeScript aj JavaScript nezávisle na sebe. To je jednoducho TypeScript.
Pokiaľ sa niečo náhodou zmenilo, a naozaj to vykonáva JavaScript, tak s ohľadom na to, že TypeScript to vykonával o veľa rokov skôr, stále ten kredit prislúcha TypeScriptu, pretože to bol TypeScript, ktorý si v tomto smere získal programátorov.
Čo sa vášho "čistého" kódu týka, ten kód v JavaScripte je čistý z hľadiska spúšťania, ale nie z hľadiska analýzy. Tie anotácie v JSDoc si TypeScript, spúšťaný na pozadí analytickými nástrojmi alebo VS Code, prevedie do svojho vlastného AST, tak ako keby to bol zodpovedajúci zápis v TypeScripte. A rovnako ho vyhodnotí.
(keď už hovoríme o kontrole v IDE/CLI/počas buildu)?
Nie, nehovoríme iba
o kontrole v IDE/CLI/počas buildu
Súčasťou môjho komentára bolo:
samostatný sofistikovaný programovací jazyk, ktorý beží počas zostavenia a je použitý na výpočty s typmi, vrátane overovania, transformácií, prevencie umožnenia reprezentácie neplatných stavov, atď.
Hovoríme o generickom programovaní všeobecne. To nie sú iba typové anotácie. To je systém, ktorý vykonáva a používa výpočty s typmi. Na čo všetko sa to používa vám tu naozaj vysvetľovať nebudem.
Porovnanie C# a Java? Ako vážne? Tam sú tie rozdiely úplne na inej úrovni, úplne iný runtime (JVM pre C# chceš povedať?) úplne iný princíp fungovania, funkčné rozdiely, API, atď atď.
Nad rámec nedostatkov v prehľade prístupov k programovaniu máte očividne problémy aj s chápaním písaného textu.
Kde v:
Naozaj sa tí, ktorí programujú v štýle OOP v Jave nemajú vyjadrovať k OOP v C#? Podobne ako sa tí, ktorí píšu funkcionálne programy v Haskelli nemajú vyjadrovať k funkcionálnym programom v F#? Keď tie programovacie jazyky majú niečo spoločné?
... je napísané čokoľvek o porovnaní C# a Javy? Kde je tam napísané niečo o API, princípoch fungovania, runtime, JVM?
Je to o diskusii o tom, čo majú v rámci OOP jednotlivé jazyky spoločné.
-
"JavaScript nevykonáva typovú kontrolu v zmysle a rozsahu ako ju vykonáva TypeScript, zvlášť nie čo sa týka generického programovania, o ktorom som písal."
Skutočne? Pretože toto fakt nie je pravda. JS má úplne zhodnú podporu generického programovania.
"Takže v tomto zmysle JavaScript nepoužíva žiadny typový engine a nástroje, ktoré používate a na ktoré sa odvolávate, používajú TypeScript a to aj keď kontrolujete kód napísaný v JavaScripte."
Takže takže TypeScript nie je jazyk ale nástroj? Tak trochu si protirečíte.
"To nie je nejaký nezávislý modul vytvorený mimo ekosystém TypeScriptu, ktorý by používali TypeScript aj JavaScript nezávisle na sebe. To je jednoducho TypeScript."
Uhuh, škoda že vôbec netušíš o čom hovoríš. Tak si pozri prvé commity do TypeScript repa a asi pochopíš.
to že je to v jednom package, neznamená že TSC a TypeScript je stejná vec. Ani to že sú na sebe závislé. Nie sú.
"Pokiaľ sa niečo náhodou zmenilo, a naozaj to vykonáva JavaScript, tak s ohľadom na to, že TypeScript to vykonával o veľa rokov skôr, stále ten kredit prislúcha TypeScriptu, pretože to bol TypeScript, ktorý si v tomto smere získal programátorov."
Podľa tohoto môžeme tvrdiť že JavaScript beží len v prehliadači a nemôže bežať na servery. História je história, súčastnosť je súčastnosť... ja kredit TypeScriptu neberiem. To si si taktiež len vycucal z prstu.
"Čo sa vášho "čistého" kódu týka, ten kód v JavaScripte je čistý z hľadiska spúšťania, ale nie z hľadiska analýzy. Tie anotácie v JSDoc si TypeScript, spúšťaný na pozadí analytickými nástrojmi alebo VS Code, prevedie do svojho vlastného AST, tak ako keby to bol zodpovedajúci zápis v TypeScripte. A rovnako ho vyhodnotí."
Nikdy som netvrdil "čistý kód" ale len "čistý JavaScript" teda bez "primiešavania" iného jazyka na úrovni syntaxe a API. To že aký nástroj to vyhodnocuje je jedno. Inak asi ste zabudli na Closure... a áno rovnako vyhodnotí, veď to celú dobu tu tvrdím. Pretože je to type-aware linter, ktorému podsúvame stejné AST.
"Nie, nehovoríme iba o kontrole v IDE/CLI/počas buildu
Súčasťou môjho komentára bolo:
samostatný sofistikovaný programovací jazyk, ktorý beží počas zostavenia a je použitý na výpočty s typmi, vrátane overovania, transformácií, prevencie umožnenia reprezentácie neplatných stavov, atď."
Tak mi povedz už konkrétne o čom hovoríme, lebo si totálne v tom zamotaný... čo je mimo build a IDE, čo je v runtime iné v JS než v TS? Výpočty s typmi? Však to je súčasť typovej kontroli, overovanie? Aké? Transformácií? áno, tam TSC poskytuje transformery, ktoré zmenia AST a po serializácii aj výsledný kód, to isté čo robí Babel akurát iná implementácia. A či použijem visitor objekt v Babel alebo nejaké ts.factory, alebo čo je už rozdiel nie v jazyku, ale toolingu.
"Hovoríme o generickom programovaní všeobecne. To nie sú iba typové anotácie. To je systém, ktorý vykonáva a používa výpočty s typmi. Na čo všetko sa to používa vám tu naozaj vysvetľovať nebudem."
Vysvetliť nechcete lebo zrejme neviete... tie výpočty, a čokoľvek funguje aj v example čo som tu dal. Ktorý ste zrejme ani nepozreli. Jasne tam bolo vidieť ako vyhodnotilo na úrovni IDE jednu hodnotu ako true a druhú ako false.
"Nad rámec nedostatkov v prehľade prístupov k programovaniu máte očividne problémy aj s chápaním písaného textu."
A vy nemáte? Lebo ste nepochopili 80% môjho komentára.
".. je napísané čokoľvek o porovnaní C# a Javy? Kde je tam napísané niečo o API, princípoch fungovania, runtime, JVM?
Je to o diskusii o tom, čo majú v rámci OOP jednotlivé jazyky spoločné."
OOP je pattern, nie jazyk, ak hovoríme "v rámci OOP" tak porovnávaš jablká s hruškami. Ja som hovoril o jazyku, a aj ty si hovoril o jazyku predtým, úplne tu miešaš všetko cez seba a nevyznáš sa ani vo vlastných komentároch.
Celú dobu bola debata o tom že JS a TS je praticky stejný jazyk, reč o OOP bola tu irelevantná od začiatku a vy ste tu zamiešali nezmyselný argument, a teraz ešte proti svojmu argumentu argumentujete. LOL
-
Vieš čo, myslím že si v tomto urobil riadny guláš tak podme krok späť... jednoduchá otázka:
čo je programovací jazyk?
a) nástroj (ty si to tak nazval)
b) špecifikácia / definícia syntaxe a APIak odpovieš A, tak C prekladané skrz GCC vs Clang sú 2 rozdielne jazyky.
ak odpovieš B, tak čo som povedal že jediný rozdiel je syntax typovej anotácie (inline vs JSDoc) je pravda.pozrime sa ešte raz dobre na GCC a Clang, sami vidíme určitú konštrukty, ktoré sú špecifické len pre jeden z nich (Pozri __builtin_assume napríklad.), takže ak aplikujeme stejnú logiku ako u JS vs TS, tak sú GCC a Clang 2 rozdielne jazyky. Alebo naopak, JS a TS je stejný jazyk.
Potom teda buď GCC a Clang sú 2 rozdielne "C-like" jazyky, alebo JS a TS je rovnaký jazyk. Nemôžeme aplikovať inú definíciu na oboje.
Alebo musíš určiť hranicu koľko % rozdielov musí byť aby to bol iný jazyk, a keďže rozdiel v JS/TS je fakt len syntax typovej anotácie (`@type` vs `:`) tak je to rovnaký jazyk, takže v každom prípade mám pravdu.
11. 11. 2025, 23:58 editováno autorem komentáře
-
Ešte dodávam (žiaľ edit už nie je možný môjho iného komentáru, ktorý čaká na schválenie):
v prípade JS a TS môžem len zmeniť príponu súboru zdrojového kódu a mám zrazu "iný programovací jazyk"?
Tak ok, potom myslím že:
```zig
const std = @import("std");
const parseInt = std.fmt.parseInt;test "parse integers" {
const input = "123 67 89,99";
const gpa = std.testing.allocator;var list: std.ArrayList(u32) = .empty;
// Ensure the list is freed at scope exit.
// Try commenting out this line!
defer list.deinit(gpa);var it = std.mem.tokenizeAny(u8, input, " ,");
while (it.next()) |num| {
const n = try parseInt(u32, num, 10);
try list.append(gpa, n);
}const expected = [_]u32{ 123, 67, 89, 99 };
for (expected, list.items) |exp, actual| {
try std.testing.expectEqual(exp, actual);
}
}
```toto je prog. jazyk Zig (example z ich webu)
teraz ak tento istý kód uložím do súboru s príponou ".mlocik", vytvoril som nový programovací jazyk? Ak ešte dodám že je ten kód spustený úplne stejnými nástrojmi (zig compilerom)?
9. 11. 2025, 13:32 editováno autorem komentáře
-
Váš jazyk mlocik je navrhnutý tak, že je rozšírením Zigu? Pretože TypeScript tak navrhnutý, že je rozšírením JavaScriptu, naozaj je. Takže môžete zobrať súbor napísaný v JavaScripte, premenovať ho na TS, obsahovo je v ňom JavaScript, ale bude bez straty spracovaný TypeScriptom.
Keď teda jedného dňa budete mať vytvorený jazyk mlocik, ktorý bude schopný pochopiť kód Zigu a pridá k nemu nejaké dodatočné vyjadrovacie prostriedky, budete môcť ľubovoľný súbor premenovať zo zig na mlocik a váš jazyk ho pochopí. Pokiaľ teda váš prekladač jazyka mlocik bude napísaný správne.
Keď ale budete mať súbor napísaný v mlociku a premenujete ho na zig, tak sa vám prekladač zigu dá najavo, že asi robíte niečo zle.
-
"Pretože TypeScript tak navrhnutý, že je rozšírením JavaScriptu, naozaj je."
Aké rozšírenie??? V čom TS rozširuje JS? Povedz mi to? Ktorý konštrukt existuje v TS, ktorý v JS nie je možné vyjadriť (i keď za pomoci inej syntaxe ako JSDoc)? Alebo ešte ideálnejšie, aj keď už sa zameriame aj na vyjadrenie podľa úplne stejnej syntaxe, koľko % konštruktov v JS a TS má rozdielnu syntax? (a koľko % je treba aby sme povedali že je to iný jazyk, viď posledný odsek v tejto správe)
Už mi dáte konečne nejaký príklad?
"Keď teda jedného dňa budete mať vytvorený jazyk mlocik, ktorý bude schopný pochopiť kód Zigu a pridá k nemu nejaké dodatočné vyjadrovacie prostriedky, budete môcť ľubovoľný súbor premenovať zo zig na mlocik a váš jazyk ho pochopí. Pokiaľ teda váš prekladač jazyka mlocik bude napísaný správne."
LOL... takže si potvrdil čo som povedal... podľa teba ten kód čo som napísal je skutočne môj vlasntý jazyk. Stačí že urobím fork Zig compiléra a len ho premenujem, bez žiadnej zmeny.
"Keď ale budete mať súbor napísaný v mlociku a premenujete ho na zig, tak sa vám prekladač zigu dá najavo, že asi robíte niečo zle."
uhuh... okay, takže stačí že kúpim Škoda Octavia, vymením na tom poťah na sedadle a môžem to predávať pod svojou značkou (už to Škoda Octavia jednoznačne nie je, to tvrdíte vy). Chápem, však som už urobil nejakú zmenu, takže je to iné auto než som kúpil. Ak toto je váš pohľad, tak potom sa to dá pochopiť.
11. 11. 2025, 23:07 editováno autorem komentáře
-
Okay, tu je príklad toho TS kódu čo sem odmietaš zrejme dať:
https://github.com/Mlocik97/JSvsTS/tree/master/src
Otvor si to v IDE, skús CLI, skús aký typ ti ukáže keď prejdeš kurzorom nad identifikátormi, atď.
Ja tam teda fakt iný rozdiel ako v syntaxi typových anotácií nevidím.
Stejná kontrola, stejná syntax a API pre úplne všekto iné, stejný runtime, stejný typový engine (TSC) ktorý v IDE/CLI robí "type aware linting", stejný output po spustený programu, AST až na výnimku typovej anotácie zhodné, atď.
-
Transpilovať do Lua môžem aj JavaScript úplne stejne, dokonca s využitím úplne stejného package.
A navyše "transpilácia" je už vlastnosť toolu, ktorý môže aj nemusí byť viazaný na jazyk, v prípade TS v podstate nie je...
rozdiel v transpilácii je aj medzi Clang a GCC, znamená to že sú to 2 rozdielne jazyky ktoré to prekladá (ak sú obe použité na preklad súborov ".c"?
9. 11. 2025, 13:25 editováno autorem komentáře
ČLÁNKY DO MAILU