Mozilla priprema novi browser naziva Servo

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Mozilla će u junu predstaviti alpha verziju svog potpuno novog broswera pod imenom Servo. Novi broswer bi u konačnoj verziji trebao biti brži i stabilniji od Firefoxa.

Servo je napravljen od nule u programskom jeziku Rust. Planirana je podrška za Windows OS, 64-bitne Linux distribucije, Mac OS X i Android.

[Link mogu videti samo ulogovani korisnici]

[Link mogu videti samo ulogovani korisnici]

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Rust obećava, samo da ne koriste isti engine kao i za nesrećni Firefox.

• 1Ovo se svidja korisniku: E.L.I.T.E.
  
  Registruj se da bi pohvalio/la poruku!

Napisano: 17 Mar 2016 20:24

E.L.I.T.E. ::Rust obećava, samo da ne koriste isti engine kao i za nesrećni Firefox.

Servo je naziv za novi engine

[Link mogu videti samo ulogovani korisnici]

Dopuna: 17 Mar 2016 22:11

Elem, čitao sam malo na temu Servo-a i ispratio dešavanja na drugom kraju a koja se nekako ukrštaju.
Dešavanja na drugom kraju su vezana za WebAssembly.

Ako WebAssembly bude doteran do predviđenih granica, vrlo lako može biti solidan i stabilan sandbox runtime environment koji će takođe biti i cross-platformski jer već danas postoje platform API binderi kao što je Apache Cordova. Onda bi WA mogao da posluži kao compile target (preko LLVM) za mnoga razvojna okruženja i da HTML/CSS/Javascript bude jedino prihvatljiv za web sajtove kojima je potrebna brzina učitavanja. Za sve ostale web apps i cross-platform apps (bilo to mobile ili desktop) bi WA bio i više nego odličan za većinu potreba ... a verovatno za sve client-side potrebe osim embedded slučajeva kojima je potreban što manji footprint, mada i razlika u potrošnji baterije većini nije zanimljiva (JVM se za primer dve decenije koristi u enterprise embedded sistemima).

Dok Servo najavljuje:


Task-based architecture. Major components in the system should be factored into actors with isolated heaps, with clear boundaries for failure and recovery. This will also encourage loose coupling throughout the system, enabling us to replace components for the purposes of experimentation and research.
Concurrent rendering. Both rendering and compositing are separate threads, decoupled from layout in order to maintain responsiveness. The compositor thread manages its memory manually to avoid garbage collection pauses.
Tiled rendering. We divide the screen into a grid of tiles and render each one in parallel. Tiling is needed for mobile performance regardless of its benefits for parallelism.
Layered rendering. We divide the display list into subtrees whose contents can be retained on the GPU and render them in parallel.
Selector matching. This is an embarrassingly parallel problem. Unlike Gecko, Servo does selector matching in a separate pass from flow tree construction so that it is more easily parallelized.
Parallel layout. We build the flow tree using a parallel traversal of the DOM that respects the sequential dependencies generated by elements such as floats.
Text shaping. A crucial part of inline layout, text shaping is fairly costly and has potential for parallelism across text runs. Not implemented.
Parsing. We have written a new HTML parser in Rust, focused on both safety and compliance with the specification. We have not yet added speculation or parallelism to the parsing.
Image decoding. Decoding multiple images in parallel is straightforward.
Decoding of other resources. This is probably less important than image decoding, but anything that needs to be loaded by a page can be done in parallel, e.g. parsing entire style sheets or decoding videos.
GC JS concurrent with layout - Under most any design with concurrent JS and layout, JS is going to be waiting to query layout sometimes, perhaps often. This will be the most opportune time to run the GC.


... što sve ukazuje na cilj da se srede trenutni problemi koji se javljaju kod trenutnih DOM endžina. Na primer svaki web app upakovan kao mobile app ima loše UI performanse zbog problema što obrada layouta nije paralelizovana i što se za skoro svaku promenu pozicije ili stila nekog elementa ceo novo-renderovan layout obrađuje na istom main threadu i onda app postane 'unresponsive'. Naravno, postoje 'najbolje prakse' uz neke od web-to-mobile app frameworkova koji imaju pre-made widgete i koji su koliko toliko prihvatljivi, ali je to opet veliko ograničenje i velika ne-fleksibilnost.
Dakle, Javascript VMs i JITs su već odavno dovoljno brzi ... problem su layout engines u browserima.
Servo obećava da će JavaScript (odnosno HTML/CSS crossplatform) bazirane aplikacije još više zaživeti jer upakovane u Servo će biti poprilično performantne. JavaScript ekosistem je dosta napredovao pa i sama specifikacija jezika (EcmaScript) koja stalno ispravlja greške i poboljšava jezik. React.js je samo jedan od primera da JS prednjači u primenama modernog stila programiranja (npr. FRP) i ko zna gde će dogurati ali je i već danas svakako vrlo moćno dev okruženje ukoliko neko može da se snađe u haosu različitih alata.

Da li ćemo za 10 godina da vidimo mnogo Servo aplikacija ili WASM?

Naravno tu su i rešenja kao React Native i NativeScript koja se takođe ukrštaju sa prethodnim ali je to već minorna priča koju ne gura ceo konglomerat kao WASM...