Przyszła wersja przeglądarki Google, jeszcze w wersji beta, przynosi kolejne nowości, w tym godna szczególnej uwagi jest możliwość wykonywania kodu C i C++ bezpośrednio wewnątrz przeglądarki. Ma to zdecydowanie ułatwić tworzenie rozbudowanych i jednocześnie wydajnych webaplikacji. Native Client, bo tak nazywa się ta technologia, jest brakującym ogniwem pomiędzy klasycznymi aplikacjami instalowanymi na komputerze, a webaplikacjami, które uruchamiane są w przeglądarce.

Google ma powody, żeby rozwijać tę technologię, w końcu wprowadzeniem Chromebooków chce przekonać wszystkich, że sama przeglądarka plus webaplikacje wystarczą do pracy na komputerze. Jak na razie wydaje się to być mocno śmiała teza, bo wiele programów instalowanych lokalnie jest wciąż niezastąpionych, ale nie od razu Rzym zbudowano. Google ciągle intensywnie pracuje nad realizacją swojego planu.

Kod C/C++ będzie wykonywany w środowisku izolowanym, podobnie jak ma to miejsce w przypadku JavaScript. Pewnie nie przeszkodzi to w powstaniu nowych zagrożeń, z którymi twórcy przeglądarki będą musieli się zmierzyć. Projekt Google jest open sourceowy, ciekawe kiedy inny producenci przeglądarek postanowią go wprowadzić, lub zakwestionować jego przydatność.

Z zaciekawieniem wyglądam nowych, bardziej zaawansowanych webaplikacji, które bądź co bądź, będą częściowo uruchamiane lokalnie. Na pewno możemy spodziewać się gwałtownego rozwoju gier w przeglądarkach, które coraz bardziej zyskują na popularności, a wraz z tą technologią mogą zaprezentować coś, o czym gry Flash’owe mogą tylko pomarzyć. Patrząc na firmę Zynga i Facebooka nasuwa się ogrom nowych możliwości, w tym również zarobku dla deweloperów tego rodzaju produkcji.

Mówię o grach nie przez przypadek, ponieważ w nowym Chrome domyślnie uruchomiony jest również Web Audio API, który umożliwia zaawansowaną obsługę audio, w tym rozmaite efekty dźwiękowe, jak choćby dźwiękową symulację otoczenia, np. zamkniętego pokoju. Jeśli ktoś używa najnowszych wydań beta, lub chce się pobawić zaawansowanym ustawaniem flag w Chrome, może wypróbować działanie Web Audio API wchodząc na tę stronę.

Po więcej technicznych szczegółów zapraszam na blog Google Chrome.

Spodobał Ci się tekst? Poleć znajomym:

iStore

iStore

  • http://blog.end3r.com/ Ender

    Brzmi bardzo ciekawie – z pewnością jest to godny uwagi i dalszego śledzenia plan Google.

  • http://www.facebook.com/ksawciu Ksawery Karwacki

    Zdecydowanie kolejny kamień milowy na drodze osłabienia pozycji systemów instalowanych na komputerach na rzecz aplikacji sieciowych. Zdecydowanie +1 dla Google.

  • http://www.facebook.com/kamil.trebunia Kamil Trebunia

    Zobaczymy co z tego wyniknie – boję się tylko tego, że takie ficzery mogą kompletnie zdestabilizować rynek przeglądarek, który na tę chwilę obraca się wokół otwartych standardów, ujednolicania możliwości przeglądarek wszystkich producentów itd. Raczej nie ma takiej opcji, żeby MS coś takiego u siebie zaimplementował, Apple… również powątpiewam. Więc jeśli developerzy zaczną tego używać, to może się okazać, że za chwilę znów nie będzie wyboru i jedyną używalną przeglądarką na rynku będzie Chrome.

    • Jan Rybczyński

      I to jest bardzo słuszna uwaga. Google już stosuje rożne chwyty, jakie znamy z dawnych czasów IE, to znaczy wydaje jakieś nowe demo i mówi, żeby uruchomić w Chrome. Na innych przeglądarkach niby nie działa, ale wystarczy kazać przeglądarce udawać Chrome i nagle okazuje się, że działa również na Firefoksie np.

      Jest tu pewien konflikt, czym przeglądarka ma się odróżniać od reszty, czym przyciągnąć użytkowników, skoro wszystkie obsługują to samo. To z punktu widzenia biznesowego.

      Z drugiej strony mamy już w swojej historii epizody, kiedy to strony działały dobrze tylko na jednej określonej przeglądarce i wiemy, że nie wyszło z tego nic dobrego.

      Zbieram się do tego, żeby napisać dłuższy tekst na ten temat, ale wymaga to szerszego przygotowania. Tak czyi siak, bardzo słuszna uwaga.

    • rafał

      od jakiegoś czasu zauważam idiotyczny – z mojego punktu widzenia – trend polegający na „wybijaniu” się danej przeglądarki przed szereg właściwościami, które owszem dają więcej możliwości programistom, ale niestety tylko w tym jednym danym produkcie. I niestety jakoś nie zauważam, aby takie podejście było specjalnie krytykowane, tak jak na przykład kompatybilność ze standardami IE6.
      I z jednej strony mówi się głośno o potrzebie tworzenia spójnej specyfikacji i implementacji standardów internetowych a z drugiej Google coraz śmielej zaczyna kpić z tej idei pokazując jaki to jest fajny. Zresztą coraz częściej widzę w sieci strony na których otrzymuję komunikat „Ta strona nie jest dostosowana do twojej przeglądarki” (używam Opery) i coraz częściej zaczynam to porównywać do czasów kiedy to tak właśnie tworzyło się strony – pod konkretną przeglądarkę. Paranoja – przecież, przechodziliśmy już przez to i nie wiem czy jest sens ponownie w to wchodzić.

      A jeśli net tak bardzo potrzebuje interaktywności, czy nowych możliwości to może wszyscy powinni się zrzucić, kupić np. od Adobe Flasha, uwolnić go i rozwijać, dając tym samym wszystkim sprawdzone, działające, KOMPATYBILNE WSTECZ, narzędzie do tworzenia „cudów” na stronie. Zresztą, podejrzewam, że w momencie uwolnienia flash przestałby się rozwijać a i z kompatybilnością nie byłoby najlepiej. Kolektywy rzadko potrafią stworzyć coś sensownego (albo sensownie coś rozwijać np. xhtml).

      Robi się to wszystko po prostu niesmaczne.

  • anemus

    Ok, ale co to ma wspólnego z webaplikacjami?
    To raczej rozszerzenie umożliwiające uruchamianie lokalnie programów, których kod może być każdorazowo ściągany z sieci lub nie – mogą to być tak naprawdę programy lokalne. To tak naprawdę przyznanie Google, że aplikacje strikte chmurowe to ślepa uliczka. Po prostu Google tworzy nowy język paraskryptowy na bazie ugruntowanych standardów, którego interpreter będzie wbudowany w przeglądarkę.
    Owszem ma to zalety jak wieloplatformowość, ale dominują wady w postaci wolniejszego wykonywania kodu oraz ograniczonej możliwości zamknięcia kodu programu, choć to drugie to nie tak do końca…

    • Rudy

      Niestety, ale tak to nie działa. Programy NaCL będą własnie nieporównywalnie wydajniejsze, bo będzie to skompilowany kod uruchamiany od razu na procesorze, a nie poprzez wolniejsze interpretery javascriptu wbudowane w przeglądarkę. To coś jak flash, tylko o wiele wydajniejszy. I ze standardami nie ma to nic wspólnego

      Google wcale nie sugeruje tym że aplikacje chmurowe to ślepa uliczka, tylko chce ‘na lewo’ rozszerzyć możliwości przeglądarki do bardzo, bardzo szerokiego poziomu, niekoniecznie w ustandaryzowany sposób (patrz komentarz wyżej Kamila i odpowiedz Jana)

    • http://komunikacjajestdlaludzi.blogspot.com/ Zonk

      anemus: Ok, ale co to ma wspólnego z webaplikacjami?

      Poczytaj sobie => http://www.wthr.us/2011/03/28/nacl-overview-and-performance-experiment/

  • Królik

    No dobra, ale to już kiedyś było. Ktoś pamięta jeszcze ActiveX?

    Wady:

    1. Potencjalnie znacznie większe zagrożenie niż Java / Silverlight / Flash / JS – jest o jedną warstwę pośrednią kontrolującą co robi aplikacja mniej – poleganie na zabezpieczeniach systemu operacyjnego przy wykonywaniu niezaufanego kodu może skończyć się taką dziurawą porażką jak ActiveX. Pożyjemy, zobaczymy, w końcu możliwe, że Google zrobił to lepiej.

    2. W C/C++ pisze się ZNACZNIE wolniej niż w językach dostępnych na .NET/Java/JS. Nie za bardzo widzę sens pisania w tym, jeśli są lepsze narzędzia.

    3. To jest zależne od platformy. Czyli jeśli chcesz np. wypuścić aplikację aby działała zarówno na 32 i 64 bitowych systemach, to trzeba osobno dostarczać. Poza tym, co z biblioteką standardową? Przecież biblioteka standardowa C++ to śmiech. Już widzę, jak internauci będą czekali kilka minut aż im się 100MB statycznie linkowana binarka ściągnie…

    4. Nie ma toto żadnej przewagi wydajnościowej nad .NET i JVM.

    • http://www.facebook.com/kamil.trebunia Kamil Trebunia

      1. „double sandbox” etc. – nie wiem czy faktycznie jest mniej warstw – mało czytałem, ale chyba nie jest to takie proste z tym dostępem do pamięci chociażby (co m.in. sprawia, że można pisać szybkie programy).
      2. true!
      3. Kompilujesz „na NaCl” raz a nie na konkretne procesory. Reszta to pewnie prawda.
      4. Daj benchmarki :)

    • http://komunikacjajestdlaludzi.blogspot.com/ Zonk

      Królik: No dobra, ale to już kiedyś było. Ktoś pamięta jeszcze ActiveX?

      NPAPI od Mozilli też pamięta.

      Wady:1. Potencjalnie znacznie większe zagrożenie niż Java / Silverlight / Flash / JS – jest o jedną warstwę pośrednią kontrolującą co robi aplikacja mniej – poleganie na zabezpieczeniach systemu operacyjnego przy wykonywaniu niezaufanego kodu może skończyć się taką dziurawą porażką jak ActiveX. Pożyjemy, zobaczymy, w końcu możliwe, że Google zrobił to lepiej.

      Wiesz, co to sandbox ?

      2. W C/C++ pisze się ZNACZNIE wolniej niż w językach dostępnych na .NET/Java/JS. Nie za bardzo widzę sens pisania w tym, jeśli są lepsze narzędzia.

      Warto poświęcić nieco więcej czasu na klepanie kodziku, żeby po skompilowaniu moduły .NET/Java/JS zostały zmiecione. Zgadzasz się ?

      3. To jest zależne od platformy. Czyli jeśli chcesz np. wypuścić aplikację aby działała zarówno na 32 i 64 bitowych systemach, to trzeba osobno dostarczać.

      Wymień jakikolwiek procesor czysto 32-bitowy w architekturze x86 będący aktywnie wspierany przez producenta.

      Nie ma toto żadnej przewagi wydajnościowej nad .NET i JVM.

      Additional features in NaCl include a subset of POSIX threads, and SSE instructions for parallel computing.
      Taa, żadnej…

    • Królik

      1.

      Additional features in NaCl include a subset of POSIX threads, and SSE instructions for parallel computing.

      No tak, bo Java i Silverlight wątków i SSE nie umieją. LOL. :D Człowieku, w jakich Ty czasach żyjesz? Wątki to jest domena zeszłej epoki (a szczególnie w wydaniu POSIX). Popatrz sobie lepiej na to co oferuje programiście w zakresie równoległości np. Scala – zjada C++ na śniadanie. Do tego jeśli chodzi o wątki to JVM potrafi robić takie optymalizacje, o których kompilatorom C++ się nie śniło i pewnie długo nie będzie. O ile w aplikacjach jednowątkowych, jak się dobrze przysiądzie nad kodem w C++, to ma się szanse zrobić program działający o te 30% szybciej (jak to czasem w benchmarkach wychodzi), to w przypadku wielu wątków C++ jest już na mocno straconej pozycji – kompilator C++ sam z siebie kompletnie nic o wątkach nie wie, więc ma związane ręce – wszystko musisz robić sam – jak będziesz mieć w wyniku tylko 10x tyle kodu źródłowego, co równoważna funkcjonalność w Scali, to jesteś gość.

      2.

      Warto poświęcić nieco więcej czasu na klepanie kodziku, żeby po skompilowaniu moduły .NET/Java/JS zostały zmiecione. Zgadzasz się ?

      Jakoś w ostatnich testach Google, które zostały opublikowane, w pierwszej rundzie Java nie została w ogóle zmieciona przez C++ – był remis; C++ nieznacznie wygrało w dogrywce tylko dlatego, że koleś od Javy stwierdził, że nie chce mu się dalej optymalizować. Jak poszukasz też dobrze na sieci, to znajdziesz też fajny opis ile się musiał natrudzić pewien microsoftowy guru od C++ aby dorównać wydajnościowo na szybko naskrobanej aplikacji w .NET.

      Poza tym szczególnie w webie liczy się „time-to-market”. Pisząc w C++ będziesz mieć zwyczajnie mniej czasu na jakiekolwiek optymalizacje – ja będę się biedził, żeby mój kod Java/.NET działał szybciej, a w tym czasie Ty będziesz się biedził, aby Twój kod C++ miał choćby połowę założonej funkcjonalności, nie miał wycieków i nie wywalał segfaultów przy byle okazji.

    • http://komunikacjajestdlaludzi.blogspot.com/ Zonk

      Królik:
      CIACH

      Co Ty mi tu ze Scalą wyjeżdżasz ?
      Native nie oznacza klepania natywnych programów!
      Tylko tych partii webappek, które są krytyczne np. ze względu na opóźnienia czasowe.

      Spójrz tutaj => http://www.wthr.us/wp-content/uploads/2011/03/performance-rate-of-increase.png

      BTW.
      The results show pretty much what one would expect with the native code executing significantly faster than the JavaScript. The only results not included are for Firefox 3.6.15 in Linux (outlier, too slow) and Internet Explorer 8.0 on Windows XP (way too slow, lost patience and killed it mid-test).
      LMAO

      za http://www.naclbox.com/about:
      I have read a lot of stories in the media regarding Native Client. Some commentators seem to get it, but I am struck mostly by the lack of imagination. When I hear people talking about Chrome OS and complaining that they will be stuck in a browser I want to shout: Native Client! I am disappointed to see commentators compare it to (inevitably) ActiveX rather than a (naively) more appropriate comparison: an in-browser VMWare. I don’t blame these people though. There have been very few examples of Native Client in action.

    • Królik

      Tylko tych partii webappek, które są krytyczne np. ze względu na opóźnienia czasowe.

      Do tego nie trzeba natywnych, wystarczy .NET lub JVM, wydajność jest bardzo zbliżona. Na dotatek, ta technologia już jest, zainstalowana na >80% kompów, chodzi pod każdą przeglądarką a nie tylko Chromem.

      Co Ty mi tu ze Scalą wyjeżdżasz ?

      A czemu nie? Służy do pisania webappek i wykonuje się jako kod natywny (zarówno za pośrednictwem JVM jak i .NET, a port na LLVM w drodze), więc jest zdecydowanie w temacie.

    • http://komunikacjajestdlaludzi.blogspot.com/ Zonk

      Królik:
      ta technologia już jest, zainstalowana na >80% kompów, chodzi pod każdą przeglądarką a nie tylko Chromem.

      Ten mechanizm jest tworzony z myślą o Chromebooku, Chromepadzie oraz Chromech**wieczym :D
      Jak stoi sytuacja z sandboxingiem .NET i JVM ?

    • http://komunikacjajestdlaludzi.blogspot.com/ Zonk

      Zonk:
      Jak stoi sytuacja z sandboxingiem .NET i JVM ?

      I co z patentami oraz opłatami licencyjnymi ?

  • Królik

    Rudy: Niestety, ale tak to nie działa. Programy NaCL będą własnie nieporównywalnie wydajniejsze, bo będzie to skompilowany kod uruchamiany od razu na procesorze, a nie poprzez wolniejsze interpretery javascriptu wbudowane w przeglądarkę. To coś jak flash, tylko o wiele wydajniejszy. I ze standardami nie ma to nic wspólnegoGoogle wcale nie sugeruje tym że aplikacje chmurowe to ślepa uliczka, tylko chce ‘na lewo’ rozszerzyć możliwości przeglądarki do bardzo, bardzo szerokiego poziomu, niekoniecznie w ustandaryzowany sposób (patrz komentarz wyżej Kamila i odpowiedz Jana)

    Ten poziom będzie tak szeroki, że Chrome stanie się przeglądarką działającą w dwie strony – Ty przeglądasz Internet, Internet przegląda Twój komputer. :D

    A co do natywnego wykonywania kodu, to Java robi to od 10 lat, Silverlight od początku swego istnienia, więc nie ma się czym podniecać.

    • ulow

      czemu nie ma ‘plus jedynek’ do komentarzy… :)

  • http://komunikacjajestdlaludzi.blogspot.com/ Zonk
  • bb

    hmm… jakos znow nic nowego. ostatnio testowalem dystrybucje linuksa uruchamiana w przegladarce ze skompilowanego kodu, podobnie tez gralem w przegladarce w doom… i to chyba w obu przypadkach dzialalo w chrome i firefoksie

  • http://www.facebook.com/kryszan Krystian Kościelniak

    Powoli dojdzie do tego, że uruchamiając Chrome uruchomimy system operacyjny w systemie operacyjnym ;)

  • Królik

    Google raczej zrobił to po to aby uruchamiać w tym stare natywne aplikacje bez konieczności tłumaczenia na inny język. I jako takie zastosowanie, to całkiem fajny pomysł. Natomiast nie wierzę, żeby programiści masowo rzucili się na to i zaczęli pisać w tym nowe aplikacje. C++ jako język pisania nowych aplikacji (nie gier 3D) nie ma obecnie racji bytu.

  • http://maclife.pl Kuba

    Apple już od paru lat na to pozwala w okrojonej przestrzeni – Dashboardzie. Sporo widgetów prócz warstwy html/css/js zawiera w swojej paczce również binarki uruchamiane z poziomu htmla i wykonujące określone czynności/zbierające dane.

    • http://marsjana.net/ marsjaninzmarsa

      Sidebar pod Vistą i 7 również. :P

  • http://komunikacjajestdlaludzi.blogspot.com/ Zonk

    Ktoś pamięta jeszcze wstawki .asm w TurboPascalu Borlanda ?

    • Królik

      Tak ja. Kompilator Turbo Pascala był tak słaby w optymalizowaniu kodu, że wtedy wstawkami można było dużo zyskać. Obecnie coraz rzadziej ma to sens – trzeba być naprawdę zjeść zęby na specyfikacji procesora aby wyprodukować lepszy kod niż dobre kompilatory. Ale co to ma do tematu?

    • http://komunikacjajestdlaludzi.blogspot.com/ Zonk

      Królik:Ale co to ma do tematu?

      Ano to, że w założeniu moduły NaCl mają pełnić rolę analogiczną do wstawek assemblerowych w Pascalu.

    • Anonim

      Zonk: Jak stoi sytuacja z sandboxingiem .NET i JVM ?

      Był tam zanim jeszcze Google’e napisał pierwszą linijkę NaCl, tzn. od samego początku.

      Zonk:
      I co z patentami oraz opłatami licencyjnymi ?

      Java jest na GPLv2 (OpenJDK) oraz alternatywne implementacje JVM są zwolnione z opłat lincencyjnych za patenty. W przypadku .NET jest podobnie.

    • Królik

      Zonk: Jak stoi sytuacja z sandboxingiem .NET i JVM ?

      Był tam zanim jeszcze Google’e napisał pierwszą linijkę NaCl, tzn. od samego początku.

      Zonk:
      I co z patentami oraz opłatami licencyjnymi ?

      Java jest na GPLv2 (OpenJDK) oraz alternatywne implementacje JVM są zwolnione z opłat lincencyjnych za patenty. W przypadku .NET jest podobnie.

    • http://marsjana.net/ marsjaninzmarsa

      alternatywne implementacje JVM są zwolnione z opłat lincencyjnych za patenty

      Google tworząc Dalvika również wyszło z takiego założenia…

  • http://agencjainteraktywna.dtl.pl guci0

    A co na to System operacyjny?
    I to jest ciekawe… Bezpieczeństwo, ah.

  • Pingback: Powitajmy Chrome 14 – nowa stabilna wersja przeglądarki Google