Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
WEB: powrót do języków kompilowanych? Google / Microsoft / Mozilla mówią: TAK.
Trzech potentatów z tytułu wpisu łączy siły aby pracować nad projektem WebAssembly – umożliwiającym… kompilację aplikacji (np. napisanych w C) tak aby działały natywnie w przeglądarkach.
Obecnie mniej lub bardziej podobne tego typu projekty już są rozwijane (przykład to choćby Microsoftowy typescript – nadzbiór JS, który kompiluje się do standardowego Javascriptu, czy asm.js – „an extraordinarily optimizable, low-level subset of JavaScript„).
W przypadku asm.js możemy mieć np. taką ścieżkę jak poniżej, gdzie po drodze wykonywane są m.in. różne optymalizacje. Zatem finalny kod (odpalany w przeglądarce) jest dość szybki (co może być szczególnie pożądane na przeglądarkach mobilnych).
Wracając do WebAssembly – idea jest nieco taka jak powyżej (np. kompilacja C do JavaScriptu) ale finalnie mamy mieć format binarny i to domyślnie 'rozumiany’ przez przeglądarki. Format taki jest zdecydowanie szybszy i mniejszy niż standardowy JS – pierwsze testy pokazały nawet przyspieszenie > 20x podczas dekodowania kodu binarnego vs tekstowego w silniku JavaScript.
Uff wreszcie będę mógł skompilować Wolfensteina3D tak aby działał natywnie w przeglądarce. O nie, w Wolfa-3d można już pograć w wersji HTML5.
–ms
Orientuje się ktoś jak wygląda kwestia błędów specyficznych dla języków C/C++ w kontekście WebAssembly? Można się spodziewać renesansu np. buffer overflow?
Silnik dopiero jest pisany… Też jest mowa o tym ze najpierw chcą zrobić coś działającego, a później rzeczy typu debuggery, itp. A jak z security tego…hmmm chyba na razie za wcześnie żeby coś sensownego powiedzieć.
Ja bym bardziej polecił http://www.quakejs.com
Polecam artykuł Rauschmayera, który tłumaczy to, co panowie z TechCrunch przekręcili: http://www.2ality.com/2015/06/web-assembly.html
W skrócie: to de facto format binarny dla asm.js
@”W skrócie” – dokładnie. Art też bardzo porządny. Thx!
Z tekstu wynika, że kompilowanie C do JSa i użycie binarki jest szybsze, niż napisanie czegoś w JSie samym w sobie. To ja zapytam z innej beczki, czy można będzie kompilować JSa do JSa, żeby uzyskać binarkę? :D Aktualnie właśnie przerzucam się ze wszystkiego na JSa (włącznie z aplikacjami desktopowymi) i zastanawiam się, czy dalej warto.
Trochę ciężko – przewaga takiego C kompilowanego do JS bierze się między innymi na przykład ze statycznego typowania, które Asm.js jest w stanie „udawać” odpowiednimi konstruktami języka, ale bardzo ciężko byłoby Ci coś takiego pisać ręcznie.
Chociaż są już projekty na przykład „kompilowania” takich skryptów wykorzystujących jQuery, więc ciężko, ale trochę jednak wszystko w tę stronę idzie. ;)
Tutaj sporo informacji dlaczego C/C++->JS, a nie JS->JS: http://kripken.github.io/mloc_emscripten_talk/#/
To znaczy, o co tutaj chodzi – jestem starym obiektowcem, właśnie Cpp, jednak od kiedy zacząłem przyswajać sobie JSa, przekonałem siebie sam, że pisze się pod JSem (przynajmniej mi) łatwiej i przyjemniej – może jestem jakimś wykolejeńcem, ale asynchroniczność JSa potrafi być piękna :) Polubiłem środowisko znacznie bardziej niż Cpp i chciałbym je opanować do perfekcji, zwłaszcza, że pisanie aplikacji multiplatformowych (aplikacje serwerowe, mobilne i desktopowe) jest dziecinnie proste i aż chce się robić projekty działające wszędzie i dalej zapewniające dość wysoką wydajność. A tu nagle, pojawiają się artykuły o kompilowaniu Cpp do JSa i stwierdzają, że jest to 20x szybsze rozwiązanie, niż sam czysty JS. Dejmn. Za chwile się okaże, że żeby zachować wydajność i być konkurencyjny na rynku, będę apki z JSa konwertował do Cpp, aby następnie Cpp kompilować do JSa ;P Trochę to nie po kolei. Według mojej czystej profesjonalnej opinii, oni próbują dać upust swojej nienawiści do JSa i jednak wykazać, że stary dobry Cpp jest dalej od JSa dużo lepszy! Tak, to musi być to! Jak napisałem swoją pierwszą aplikację serwerowo-desktopową (z wykorzystaniem node.js), to się popłakałem ze szczęścia. Ani w Javie, ani w Cpp, ani w C#, nigdzie, nie było to tak proste i przyjemne, a wgrywanie gotowych szablonów HTML5, z którymi nie trzeba nic robić, to już było w ogóle fantastyczne :D
bardzo to wszystko pokręcone, mi się wydawało że chodzi o kompilowanie JS do formatu binarnego
Zobacz jeszcze tutaj: http://ejohn.org/blog/asmjs-javascript-compile-target/
Hmm nie ma tragedii, LLJS to takie upośledzone połączenie JSa i Cpp, nie będzie zbyt dużo pieprzenia z tym jak zajdzie konieczność, zwłaszcza, że zastosowania asm.js są dość zwięźle sprecyzowane. Przy np. stronach internetowych (z wykorzystaniem chociażby node.js jako backend) nie będzie zbytniej różnicy między użyciem JSa a asm.js, dopiero przy aplikacjach korzystających z kryptografii czy przy jakiś konwerterach/generatorach asm.js pokazuje znaczną różnicę – czyli w zasadzie tam, gdzie potrzebna jest optymalizacja kodu bo pojawia się jakaś złożoność obliczeniowa. Widzę zastosowanie asm.js bardziej jako uzupełnienie technologiczne, niż zastępstwo i nowe środowisko. Czyli mogę śmiało dalej zakuwać JSa ;)