Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Takze to vlastne vobec nebude Javascript ? konecne ! :) https://www.destroyallsoftware.com/talks/wat
Njn, to je fakt, ze uz to nebude javascript ..... ikdyz na druhou stranu asi nebude problem prelozit javascript do nejakeho "vyssiho" jazyka ......
Logickou volbou je C#, ktery ma asi celkem dominantni postaveni i vzhledem k platformam na kterych bezi ....... no, ale myslim, ze COKOLIV, co nebude mit nic spolecneho s tristne zdechlou JAVOU(byt ve jmenu) bude pokrok:o) ............
EDIT: no trosku jsem do toho zabredl .... a nikde (krom wiki) jsem neobjevil, ze by se na tom podilala nejaka z vyse uvedenych firem .... zatim to vypada, ze jde jen o nejakou komunitu zalozenou na w3c, kterou si muze patrne zalozit kdokoliv .... taky ty goaly jsou dost usmevne https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md zvlast polyfill vypada velice podezrele:o) Kdyz teda pujde prelozit C++ do javacriptu, proc by nesel podstatne snaz javascript do C++ ze? Coz asi patrne prohlizece dnes delaji, takze nejaky binarni javascript mi prijde jako peechovina ......
EDIT2: Tak jo, nejaky solo clanek od cloveka, ktery tvrdi, ze je z MS na msdn, nejaky twitter od neznameho cloveka asi z guglu a neco v blogu na mozille a bug ve webkitu .... neco na tom asi tedy pravdy bude, ale kdovi jak moc se tim zabyvaji, spis mi to prijde jako solo aktivita par vyvojaru, nic oficialniho .... a i tak mi stale nejak unika smysl toho, proc dnes psat neco v c++, navic kdyz to bude vzajemne kompatibilni s JS a pujde to prelozit sem a tam 1:1, tak v cem je teda ten benefit? ...
benefitů může být celá řada
- můžete programovat kód web stránek v jakémkoliv jazyce chcete, GWT už nebude muset být překládáno z javy do javascriptu
- v binárním kódu bude více informací než je v javacriptu, např. typy proměnných. Díky tomu bude možné provádět lepší optimalizace.
Javascript není možné přeložit do "vyššího" jazyka, není objektový, nemá typované proměnné atd.
Programovani v C++ ve me furt nejak evokuje to, ze to proste nebude dvakrat bezpecne distribuovat binarni kod a prohlizece budou zase o neco nebezpecnejsi ...... jinak netypovane promenne jsou snad v kazdem jazyce ne? Teda snad krom C a podobnych vyslovene low level jazyku .....
Jako vyslovene se nabizi jako standard C#/XAML, ktery ma dnes absolutni majoritu, ale jak je ve hre gugl, tak ten si bude chtit prosadit neco ...... je jedno co, hlavne aby to nebylo XAML (=cili hlavni konkurent a umiracek jeho kvazidila ve forme univerzalnich aplikaci) ......
Zajima me detailni specifikace te oblasti, kde ma C#/XAML absolutni prioritu.
"v binárním kódu bude více informací než je v javacriptu, např. typy proměnných. Díky tomu bude možné provádět lepší optimalizace."
Bude možné provádět JINÉ optimalizace. Ne lepší. Jestli to bude "typovaný assembler", tak celá řada věcí běžných (a schůdných) v JS bude zase naopak problém. Něco bude rychlejší, něco zase pomalejší. (Samozřejmě, jestli vaším cílem je kompilace Cčka, tak si v konečném součtu polepšíte...)
"Javascript není možné přeložit do "vyššího" jazyka"
Těžko najdete vyšší jazyk než třídu dynamických jazyků podobných Smalltalku/Selfu, do které patří i JS. Netuším, do čeho ještě vyššího byste ho chtěl překládat. Do Lispu? A proč byste to vlastně dělal?
"není objektový"
Nesmysl, samozřejmě, že je objektový. Je odvozen od objektového Selfu.
Co se v téhle komentářové větvi rozumí termíny „vyšší“/„nižší“ programovací jazyk?
Běžně se jazyky označují jako vyšší/nižší podle úrovně abstrakce, pak těžko hledat vyšší jazyk, než JavaScript :-)
JS je určitě vyšší jazyk, než C++, a dá se polemizovat, jestli než C#.
Ale nevidím moc důvod pro překlad mezi JS a C# nebo Javou.
Ani to nijak jednoduše nepůjde, jak chcete dynamicky typovaný jazyk přeložit do staticky typovaného jazyka?
To spíš by dávalo větší smysl všechny ty jazyky překládat do univerzálního bytecodu, takže by programátoři mohli psát skripty pro stránky ve „svém“ jazyce (třeba v C#).
To mi připomělo, že jsem před lety viděl pokusy o interpretaci CIL bajtkódu JavaScriptem. Pak si člověk uvědomí, že je k pláči, když je k vývoji něčeho takového programátor "donucen" :)
Ono to ale není zase tak hrozné. Vtip je v tom, že i takový kód by dobrý runtime pro jazyk podobný JS měl umět zpracovat docela dobře (podívejte se, co v podobné oblasti umí i PyPy pomocí "metatrasování"). Dokonce by mohl zvládnout i meziprocedurální optimalizace za chodu, s čímž se runtime od Microsoftu pokud vím ani neobtěžuje (je-li to dobře nebo špatně, to už si musí každý rozmyslet sám). Možná by to vyžadovalo mírnou spolupráci loaderu toho CIL kódu, ale mělo by to jít.
Je možné, že nějaká rozšířená varianta Scheme by roli obecného mezijazyka pro web zvládla lépe. Eich skutečně něco takového měl na mysli, ale pak ho "kravaťáci" donutili místo toho napsat Javascript...
Na psani se da pouzivat TypeScript, ktery se preklada do JavaScriptu no a v budoucnu snad do tohohle. Vyvojar by tak mohl uplne JavaScript vynechat :D .
To bude vypečených útoků. Zlatý ActiveX :-)
ale vůbec ne, runtime javascriptu v prohližeči zůstane stejný, akorát se jeho část, provádějící analýzu a kompilaci kódu přesune z klienta na server.
A ze snadno analyzovatelného kódu se stane binárka, do který nikdo nevidí. Vo tom to je. Zase budeme vypínat javascripty, jako zamlada.
až budete mít chvilku času, podívejte se na vyhledávací stránku googlu, která sice na první pohled vypadá zcela jednoduše, obrázek, pole pro zadání klíčových slov a pár čudlíků, ve skutečnosti ale obsahuje 800kB !!! minimalizovaného a obfuskovaného javascriptu. WebAssembly bude sloužit jako náhrada za obfuskovaný a minimalizovaný javascript. dekompilací binárek dostanete to samé co teď vidíte v textové podobě jako obfuskovaný javascript. Takže v podstatě žádný rozdíl, pro zpětnou kompatibilitu bude klasický javascript stále podporován.
Sledujete poslední roky, jak ty údajně „snadno čitelné“ skripty ve skutečnosti vypadají?
Často jediný způsob, jak se v tom vyznat, je použít ladicí nástroj v prohlížeči, který dokáže blok skriptu přeformátovat do ± čitelné podoby.
Otevření zdrojáku v Notepadu často nestačí ani dneska a když už to do čitelné podoby musí přetavit nějaký nástroj, je celkem jedno, co do toho nástroje poleze jako vstup.
To preco je to co vyleze zo serveru do browseru necitatelne je prave koli optimalizacii. Vecisnou originalny js (debug verzia prave koli citatelnosti pri ladeniu) sa pri ostrej prevadzke prezenie cez nejaky minifikator ktory, vzhladom na to ze nakoniec to aj tak musi byt validny text pre js parser, z toho vyhodi biele nepodstatne znaky (medzery,zalomenie riadkov a dalsie znaky ak moze), skrati nazvy premennych a funkcii. Tym sa fyzicky zmensi velkost toho script a tym aj traffic. Ale vecsinou to na samotny vykon js a jeho parsing nema zasadny vpliv. No a este to trochu kryje knowhow aj ked to nieje uplne obfuskacia ale za taku polovicnu by sa to povazovat dalo.
Prave jste popsal krasnou bezpecnostni diru. To se pak budou ty binarky i podepisovat ?
V cem je to vetsi dira nez dnes?
Osobně to vnímám jako rozumný krok.
Nevidím moc rozumných důvodů pro transport celého zdrojového kódu a jeho následnou tokenizaci ve webovém prohlížeči; určitě se trochu zmenší i množství transportovaných dat. Další benefit bude (téměř určitě) možnost psát takřka v libovolném jazyce, pro nějž bude kompiler do WebAssembly. Třeba já si oblíbil přehlednou syntaxi Pythonu.
Nemám moc pochybností o tom, že vznikne i dekompiler, ať se mohou podívat paranoici, nebo zvídavci co bytecode obsahuje.
Jako uživatel telefonu s FirefoxOS doufám, že budeme jedni z prvních, kteří tuto možnost dostanou :-).
Dekompiler je v planu jako jeden z prvnich kroku kvuli zpetne kompatibilite.
Nejdeulezitejsi je jestli bude k tomu spolehlivy disassembler. Aby se dalo na to v prpipade potreby podivat a upravit.
Ale vsadím se, že zároveň bude problém i existence toho disassembleru, protože spousta rádoby-webdesignerů dojde k názoru, že když to není čitelné na první pohled, je to „zašifrované“ a je bezpečné tam dávat hesla a podobně.
U té pračky hrozí, že nebude předžvýkán jen ten JavaScript :-D .
Bol by som opatrny v tom vykonnostnom naraste a celkovom posune do plusu a k vyhodam. V zasade toto sa uz dnes deje bezne na urovni prehliadacov. Mierny vykonnostny narast moze byt vdaka tomu ze namiesto minified 500kB-1MB js kodu sa pretlaci k prehliadacu povedzme par kB binarka (tu inak moze byt slusne bezpecnostne riziko). Cize sa znizi load, co je skor vyhoda pre servery ako pre klienta. Tak isto to ze je to uz predzute nejakym kompilerom trochu urychli vykonavanie ale fakt si nemyslim ze parser/lexer v Chrome/Firefoxe zerie az tolko casu pri nacitani stranky (respektive to je dost individualne podla scriptov). Ssamotny vykon sa uz aj dnes deje na urovni nejakeho bajtkodu ktory si vytvori Chrome V8 a potom ho spusta.
Ked to zjednodusim tak zatial to vyzera ze pridaju DOM do c/c++, skompiluje sa tom LLVM a vystup sa posle do browseru ktory potom IF z LLVM bude kompilovat a spustat. Vyznamnejsi benefit skor moze byt z toho ze je to primarne cielene na C/C++ a ze pre tieto jazyky existuje kvantum nastrojov.
Samotny vykon JS uz dnes nieje az taky problem, problemom je skor navrh JS a celeho DOMu. Proste produktivita v JS, PHP a dalsich podobnych netypovych jazykoch je dost problem. Teda hlavne pri vecsich projektoch. Nehovoriac o tom "objektovom" modely v JS.
Hlavnimi problemy javascriptu jsou: 1) K programovani v javascriptu se citi kvalifikovany uplne kazdy. 2) V ramci zpetne kompatibility je nutne udrzovat i zjevne bugy, o nestastnych prvcich navrhu nemluve. 3) Prohlizece porad vidi jako vyhodu, kdyz se v nich v javascriptu neco dela jinak nez u konkurence, misto toho aby zatlacili na standarizaci.
Pokus o naroubovani na c/c++ situaci jen zhorsi, protoze c++ ma toho balastu pro zpetnou kompatibilitu jeste vic, pocinaje samotnym c. A rozdil ve velikosti mezi gzipovanym minifikovanym javascriptem a nejakym bytecodem bude minimalni.
Myslim ze treba rozlisovat c/c++ ako jazyk a c/c++ a frameworky/kniznice okolo toho. Ak aj tento navrh webassembly bude pouzivat na kodovanie c/c++, pochybujem ze budu dostupne vsetky standardne kniznice c/c++. Uz len z bezpecnostneho hladiska to nebude mozne. Skor si asi bude nejaky subset zo standardnych kniznic (pravdepodobne bez io alebo s obmedzenym io aby nemohla web app zapisovat a citat u klienta kde chce a ako chce) a doplnene to bude hlavne o DOM aby sa dalo manipulovat so strankou. Dost mozne ze to este doplnia o nejaky memory management prave koli bezpecnosti. GC asi nie ale mozno reference counting alebo smart pointre ? Rozhodne by som to neporovnaval s plnohodnotnym c/c++ na desktope.
Co sa tyka problemov JS tak tych je vela. Samotny jazyk ale aj jeho pouzitie bolo povodne na jednoduche validovanie vstupov a drobne efekty na stranke. Dnes sa pouziva na tvorenie kompletnych web aplikacii co je proste totalne mimo. Tak isto podla mna netypovost jazyka je dost problem, aj ked to je o uhle pohladu ale ja mam osobne radsej striktne typovy jazyk. No a potom samotnou brzdou je DOM a jeho komplikovanost. Ostatne vecsinu casu travi JS prave spracovanim DOMu a tam je aj najvecsia brzda. Co sa tyka rozdielu velkosti, tak zalezi od projektu ale staci sa pozriet na skompilovane classy z Javy. Rozdiel tam naopak moze byt docela slusny a dnes nieje vynimkov ked ma stranka 1-2MB JS kodu, a bytecode by to mohol vyrazne zmensit.
Výkonnostní benefit tam určitě bude. JIT kompilace není zadarmo takže např. Chakra první průchod částí nekompilovaného kódu interpretuje, protože není zaručeno, že bude spuštěn vícekrát a potom kompilace paradoxně vykonávání zdrží.
Spíše bych krotil nadšení z použití produktivnějších jazyků. Mnoho z nich počítá s podporou na straně runtime a když jsem kdysi zkoušel transpiler z mého oblíbeného C# do JavaScriptu, tak člověk stejně nemohl použít některé jazykem podporované vlastnosti. Dokonce ani TypeScript, ve kterém vývojář může psát kód nevypadající jako bastl dyslektického šílence, má své limity. Přestože podporuje generika, tak za běhu nevytvoříte novou instanci dle typového argumentu. Přestože podporuje interfaces, nezkontrolujete za běhu zda instance interface implementuje atd.
JavaScript nikdy nebyl určen k psaní velkých aplikací, ale bohužel se rozrostl jako rakovina a není tady prostor pro globální revoluci.
Hmm no samozrejme ze bude, interpretacia a kompilacia nejaky cas zaberie a optimalizovanie sa hodi skor pri strankach kde bezi nejaky js framework ktory sa raz natiahne a potom uz obsah stranky sa meni iba cez xmlhttp requesty a vsetko si obstarava js. Ide ale o to kde nakoniec js travi najviac casu na beznych strankach. Nejak som to hlbsie neskumal a webu sa prave pre tento bordel vyhybam, ale najcastejsie, ked nieco nejde, to byva prave bud dotahovanie contentu na pozadi cez requesty (bud je zahlteny server alebo je nejak blbo spracovana poziadavka alebo je to vela dat) alebo potom strasne vela casu zere manipulacia s DOMom - js hrabe do stranky, meni styly, animuje a podobne sprostosti, a tam zasa bajtkod asi az tak moc nepomoze. Teda pokial neurobia nejaky iny interface k DOMu.
Ano js sa v poslednych rokoch znasilnuje k hodne nepeknym veciam. Skor ma desi dnesny trend, veci ktore su zaujimave a skor sa hodia na testovanie alebo ako ukazka moznosti a technologie sa nasadia ako produkcne. Nemam skusenosti napriklad s Node.js, vyzera to zaujimavo a urcite ma zaujimave moznosti ale osobne by som sa bal na server nasadit v produkcii nieco ako node.
A co rovnou přejmenovat JavaScript na Java.
JS nam byl cert dluzen....
Zkuste někde vyhrabat starý jednojádrový Celeron Coppermine 1GHz s 1GB RAM a najet si stránky třeba Alzy. Najede vám úvodní stránka a to bude to poslední, co uvidíte. Interně jsem přejmenoval Javascript na "Zabijáka starých kompů". Ne Windows XP, ale Javascript dělá stará PC "nepoživatelnými". ☺
Si musíte nainstalit nějaký moderní prohlížeč, Chrome nebo FF, a uvidíte, jak všechny web stránky budou běhat svižně i na archaickém HW. Od dob IE6 se diky sw optimalizacím zvedla rychlost provádění javascriptu minimálně 100x. Takže ne Javascript ale zastaralý software dělá stará PC "nepoživatelnými".
Chrome už dlouho nepodporuje starší procesory (kolem verze 25 začal vyžadovat SSE, teď už SSE2). S FF je to trochu složitější - sice jede, ale už dlouho není podporovaný ve smyslu optimalizací. Výsledek je, že jednoduchý jednojádrový Atom v eee je svižnější, než jinak mnohem rychlejší AthlonXP.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.