<story><title>Firefox’s new streaming and tiering compiler</title><url>https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/</url></story><parent_chain><item><author>flavio81</author><text>&amp;gt;JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.).&lt;p&gt;DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs.&lt;p&gt;Mark my words.</text></item><item><author>sjrd</author><text>Nice article.&lt;p&gt;Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like &amp;quot;Why don&amp;#x27;t you compile to wasm to make your stuff faster?&amp;quot;. That includes absurdities like &amp;quot;We should write a compiler from JavaScript to wasm to make all our JS faster!&amp;quot;</text></item></parent_chain><comment><author>pcwalton</author><text>I&amp;#x27;m nearly certain that this will not be the case. Once you reinvent everything that the DOM does, it&amp;#x27;s highly unlikely you&amp;#x27;ll end up faster than the DOM.&lt;p&gt;Everyone thinks that the rendering engines in browsers are easy to beat in terms of performance. I thought that too, until I implemented one. They are definitely beatable, but not &lt;i&gt;easily&lt;/i&gt;, and certainly not with an architecture like that of Qt or GTK.</text></comment>
<story><title>Firefox’s new streaming and tiering compiler</title><url>https://hacks.mozilla.org/2018/01/making-webassembly-even-faster-firefoxs-new-streaming-and-tiering-compiler/</url></story><parent_chain><item><author>flavio81</author><text>&amp;gt;JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.).&lt;p&gt;DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs.&lt;p&gt;Mark my words.</text></item><item><author>sjrd</author><text>Nice article.&lt;p&gt;Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like &amp;quot;Why don&amp;#x27;t you compile to wasm to make your stuff faster?&amp;quot;. That includes absurdities like &amp;quot;We should write a compiler from JavaScript to wasm to make all our JS faster!&amp;quot;</text></item></parent_chain><comment><author>kowdermeister</author><text>No, the DOM will stay for a long time, since CSS is actually a really great way to build UI-s.&lt;p&gt;Last time I checked C&amp;#x2F;C++ based UI libraries even text selection was a problem. If there were a cross platform way to build UI-s as good and feature rich as a modern browser is now, then it will slowly die.&lt;p&gt;That&amp;#x27;s the reason we have so many Electron based apps, because it makes UI building really simple.</text></comment>