Google Earth Ported To Browsers With WebAssembly (infoq.com) 51
The Google Earth team recently released a beta preview of a WebAssembly port of Google Earth. The new port runs in Chrome and other Chromium-based browsers, including Edge (Canary version) and Opera, as well as Firefox. From a report: The port thus brings cross-browser support to the existing Earth For Web version, which uses the native C++ codebase and Chrome's Native Client (NaCl) technology. Difference in multi-threading support between browsers leads to varying performance. Google Earth was released 14 years ago and allowed users to explore the earth through the comfort of their home. This original version of Google Earth was released as a native C++ based application intended for desktop install because rendering the whole world in real time required advanced technologies that weren't available in the browser. Google Earth was subsequently introduced for Android and iOS smartphones, leveraging the existing C++ codebase through technologies such as NDK and Objective-C++. In 2017, Google Earth was released for the Chrome browser, using Google's Native Client (NaCl) to compile the C++ code and run it in the browser.
Port something more useful to WebAssembly (Score:5, Funny)
More people use web browsers than use Google Earth.
Re: (Score:2)
Re: (Score:2)
I read it as "Compile a web browser's layout engine to WebAssembly so that the only pieces of native code in the browser are the JS JIT, the WebAssembly JIT, and WebAssembly's bindings to the operating system APIs."
Re:Port something more useful to WebAssembly (Score:4, Funny)
How about please port a web browser to WebAssembly.
And release it as an Electron "app" -- a browser is something users may want to use stand-alone.
Re: (Score:2)
Re: (Score:2)
The snark is strong with this one.
Re: (Score:2)
How about please port a web browser to WebAssembly.
How about someone first port WebAssembly to emacs, then port the browser and run it from there?
Re: (Score:2)
You mean a nice fresh steaming pile of silverlight.
Web Assemably still doesn't support DOM (Score:4, Interesting)
The use of Web Assembly has its limitations for most "Web Apps" due to the lack of ability to quickly interact with DOM.
Sure for Google Earth, where you are calculating a lot of data at once, it works well (especially compared to Java Script) However most Web Apps are slow not from all the calculating it is doing, but (especially in IE) from rendering changed HTML on the fly. I run a query, my server returns a JSON list of data, in no time, then it takes seconds for the table to render on the page. If I were to take the same generated HTML, and Dump it to a textbox, it would process and complete in a split second.
A Web Assembly for DOM would be much handier, where instead of giving table commands, and having the browser to auto adjust its size, you can contol the rendering at a lower level.
Re: (Score:1)
Browsers have to auto-adjust content to window, that's their job. Your own Web Assembly + DOM custom job would cut corners and be incompatible with some screen sizes, etc.
If you want faster rendering, use fixed sizes via CSS where appropriate, at least that way the browser won't try to re-shuffle the whole page.
Re:Web Assemably still doesn't support DOM (Score:4, Informative)
The use of Web Assembly has its limitations for most "Web Apps" due to the lack of ability to quickly interact with DOM.
It will eventually. Here is the proposal [github.com]. No reason to do it quickly, that's how we ended up with the Javascript mess. Better to take it slow and produce something good.
(Some languages, most notably Rust, have bindings to the DOM already, through some tricky glue code)
Re: (Score:2)
Re: Web Assemably still doesn't support DOM (Score:2)
Re: (Score:2)
I read it as "Will webidl-bindings work in Chrome first and then Safari and Firefox years later if ever?"
Re: (Score:2)
Wasm works with all of the mainstream browsers...there are probably a few that don't support it - but then that's true of any new feature,.
Still third-party code running in your browser (Score:2)
God I hope it kills the current Javascript movement
There's a vocal minority who claim that replacing JavaScript with WebAssembly is like replacing cyanide with arsenic, that WebAssembly in the browser is just as harmful as JavaScript in the browser. To them, abuses by interest-based ad networks have poisoned the well for script in the browser to such an extent that it's time for a return to static documents and installable native applications.
Re: (Score:2)
The idea was originally that JavaScript programs would be short things that just kinda extended HTML a bit (especially before CSS became common). Because you could always see the JavaScript code if you needed to - you could easily verify what it was doing. But with VAST JavaScript programs, aggressive obfuscation tools and transpilers into JS - that's now pretty much a dead idea. So rather than forcing you to use a transpiler when you want to write in a nicer language - why not wasm and unleash some a
Re: (Score:2)
But with VAST JavaScript programs, aggressive obfuscation tools and transpilers into JS - that's now pretty much a dead idea.
And privacy-conscious users have begun to give up script-in-the-browser because "that's now pretty much a dead idea."
So rather than forcing you to use a transpiler when you want to write in a nicer language - why not wasm and unleash some actual performance rather than trying to use JavaScript as though it was an assembly language?
Better yet, if you have a application written in a nicer language, why not offer its client side in source code form, so that a privacy-conscious end user can (optionally) inspect the code, compile it to native code with optimizations for the specific microarchitecture of the CPU and the specific operating system on which it will be used, and install it?
Wasm is pretty fast - about 85% the speed of native code - and it'll get better.
Your "85% the speed" means it leaks you [socialcooling.com]
Re: (Score:2)
I remember back in the days learning x86/DOS assembly. I assembled a program and ran it. Then I wrote the same program in C and compiled and ran it.
The C program ran faster. An oddly enough I did a similar test for such a program in Python, it actually (after a longer load time) ran just as fast as the C code.
Why is that? Low level programming, is exhausting so things like multiplying or diving a number takes extra steps and extra consideration, output too takes a lot of work. So my Assembly code where
Re: (Score:2)
DIM interaction is a really minimal issue. Wasm can access DOM through JavaScript calls - so spend a happy hour or two writing a neat re-usable C++ class that hides the JavaScript calls - and voila you have DOM access. Sure it would be nicer if we could have direct access for speed - but DOM accesses are inherently rather slow - so I don't think that the extra JS call is a gigantic overhead.
If you wrap it all up in a neat little C++ class - then as soon as "native" DOM access DOES arrive - you only have
NaCl? (Score:2)
My doctor told me to reduce my salt intake, you insensitive clods!
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Visual Basic Script was actually supported natively on websites by IE for several releases...
No Oracle (Score:2)
Web Assembley? Why bother? We already had Java plugins for years. Why reinvent an exploit when you already have one ready, proven, and ready to go.
One key difference between WebAssembly and the Java platform is that WebAssembly isn't under the thumb of One Rich American Called Larry Ellison. Another is that WebAssembly allows for languages that use the memory model of C, such as C++ and Rust.
Useless (Score:2)
Does not work with network-streamed KMZ files, just like the shitty iPhone/Droid app.
yes KML is important ! (Score:2)
exactly KML & KMZ loaded from a network location is important feature and actually the reason why many people use ESRI earth
pity google had a chance
GEarth in WASM slow as slugs (Score:1)
Meanwhile, this Google Earth WASM implementation was burning up my CPU, even which I was nowhere near it.
I know, it's beta. Great work. Please keep going! I want to believe in WASM. Please make it work.