A böngésző nem tudja, hogy a kapott JS-t miben írták eredetileg. Gondolom úgy értetted, hogy a kugli figyel oda nagyon, hogy a TS-ből transpile-olt kódokból hatékony gépi kódot tudjon a v8 JIT-telni. Ez mondjuk lehet, csak éppen, ha az a kód egy bloathegy, akkor tök mindegy, hogy vanilla JS-ben lapátolták össze, vagy TypeScript-ben.
Ezek az extra szemét megoldások kliensoldalon kb. nem oldanak meg semmit, hacsak nincs feltelepítve a browserbe egy TS compiler/cacheing extension, ami a legtöbb júzernél nem lesz. (Lévén ugye hiába transpile-olta át JS-re a TS kódot kliensoldalon a JS, ha az utána egy F5-től elveszik...hacsak vissza nem küldi a szervernek tárolásra, de akkor az már szerveroldali megoldás. (És milyen rohadt gány már.)) Ha szerveroldalon van a transpile, az nyilván a kliensoldalon már nem fog extra overhead-et jelenteni, de ld. 1. pont.
Én értem, hogy a data-s cucc sokkal többet fog zabálni, de az még mindig kevesebb embert érint.
A telefon / laptop áramfelvétele nem elhanyagolható a szerverfarmhoz képest - pont fordítva: a szerverfarmé elhanyagolható. Miért? Mert data-s szerverfarmból van pár darab, telefonból meg laptopból meg több milliárd. Az emberiség energiaigényének elég tetemes részét a mai okosszarok és személyi számítógépek teszik ki. A data-s szerverfarmok ebből a tortából mekkora részt kapnak?
Ez egyfelől a "nagyanyámnak kereke volna", nyilván, ha kiszerveznék a futtatókörnyezetet külső programba, akkor nem volna olyan nagy egy electronos cucc, csakhogy nincs kiszervezve. Másfelől meg az viszont már hótt mindegy, hogy a betöltendő 100 MB-os szemétfuttató környezet (1 db csupasz Electron-Chromium) az bele lett építve az OS-be programként, mert attól még külön instance-ként fog futni mind és zabálni fog. Harmadfelől ez még csak a tárhely/memóriaigény volt, a sebességről nem is beszéltünk még...és addig jó amíg nem is tesszük.