<story><title>We&apos;re building a browser when it&apos;s supposed to be impossible</title><url>https://awesomekling.substack.com/p/how-were-building-a-browser-when</url></story><parent_chain><item><author>pavlov</author><text>This approach works better for Wine where the Windows binaries are a fixed target.&lt;p&gt;On the web, you may get Twitter&amp;#x27;s feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don&amp;#x27;t have and everything is totally broken again.</text></item><item><author>yellowapple</author><text>&amp;gt; So instead of [building the browser one feature&amp;#x2F;spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com&amp;#x2F;awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives.&lt;p&gt;Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the emphasis seems more on &amp;quot;let&amp;#x27;s get SomeProgram.exe to run&amp;quot; or &amp;quot;let&amp;#x27;s fix the graphics glitch in SomeGame.exe&amp;quot;.  Console emulators (especially of the HLE variety) seem to have a similar flow.</text></item></parent_chain><comment><author>pdpi</author><text>The point isn’t that “getting X to work” is a one-and-done job. Rather, you’re using major websites as indicators for what features to target next, because &lt;i&gt;those&lt;/i&gt; are largely one-and-done.</text></comment>
<story><title>We&apos;re building a browser when it&apos;s supposed to be impossible</title><url>https://awesomekling.substack.com/p/how-were-building-a-browser-when</url></story><parent_chain><item><author>pavlov</author><text>This approach works better for Wine where the Windows binaries are a fixed target.&lt;p&gt;On the web, you may get Twitter&amp;#x27;s feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don&amp;#x27;t have and everything is totally broken again.</text></item><item><author>yellowapple</author><text>&amp;gt; So instead of [building the browser one feature&amp;#x2F;spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com&amp;#x2F;awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives.&lt;p&gt;Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the emphasis seems more on &amp;quot;let&amp;#x27;s get SomeProgram.exe to run&amp;quot; or &amp;quot;let&amp;#x27;s fix the graphics glitch in SomeGame.exe&amp;quot;.  Console emulators (especially of the HLE variety) seem to have a similar flow.</text></item></parent_chain><comment><author>jonhermansen</author><text>Of course you are correct that supporting Twitter or any service is a moving target, so long as it changes. But that doesn&amp;#x27;t mean specific bugs can&amp;#x27;t be captured in a test case.&lt;p&gt;Watch this video of Andreas doing exactly this, albeit for a simpler web app &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=W4SxKWwFhA0&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=W4SxKWwFhA0&lt;/a&gt;&lt;p&gt;At one point, he deletes half the HTML file to isolate &lt;i&gt;where&lt;/i&gt; in the site the problematic code is. In a way doing a kind of binary search. After a few iterations of this, he comes up with a very small case that exhibits the problem he&amp;#x27;s trying to solve.&lt;p&gt;It&amp;#x27;s clear he knows his way around the codebase and where to make changes, but isolating these test cases is probably as important. And presumably if you fixed enough of these issues (while following the specs), 99% of the modern web should work just fine.</text></comment>