6 ms·

> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical

> So instead of [building the browser one feature/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/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the emphasis seems more on "let's get SomeProgram.exe to run" or "let's fix the graphics glitch in SomeGame.exe". Console emulators (especially of the HLE variety) seem to have a similar flow.

jgerrish 4y ago
> Console emulators (especially of the HLE variety) seem to have a similar flow. Good insight. I was going through this same spiel in my head the other day. It's a flow that if properly managed can provide a good feedback system. It provides the developer positive feedback and at the same time successful milestones. Say I'm building an emulator for a simple architecture with a few dozen opcodes... "Alright. Let's start. Where do I start? How about NOP." So you implement NOP. You write some tests for it. Maybe you build a pretty printer into your opcode and you test it on disassembling a single byte file with a single NOP opcode. Suddenly you have a working dissassembler! It's obviously an artificial toy, but it works. Maybe next you add an INC instruction. Add some tests. You'll need registers... Build a simple one INC opcode binary file. Maybe add an executor in addition to a dissassembler. Suddenly you've got registers working. And if if add another INC opcode byte, you can see your emulator changing behavior based on real external input! And so on. It's an interesting flow, you're right.
pavlov 4y ago
This approach works better for Wine where the Windows binaries are a fixed target. On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again.
- actionfromafar 4y ago
  Depends on if your actual goal was getting twitter to work. If Twitter rendered fine, chances are some other site render fine today. The same it was with Wine.
  - ilyt 4y ago
    Sure but Wine is a tool where if 90% of the stuff user wants to run in it works, it's still great. Say if you use it for gaming you can play most of the games and only boot into windows every few months once you hit one you can't. But that's not how you use web. If 90% of the pages worked in browser I wouldn't use that browser, ever, because chances are I'd hit one that didn't at least once every few days.
    - mcbits 4y ago
      It depends on the types of bugs and inconsistencies that show up in practice. If a page (or worse, the whole browser) crashes, that's a problem. If a column of ads doesn't scale right and gets bumped down to become its own lonely row below the main content, that's kind of ugly but almost a feature.
      - ilyt 4y ago
        I've seen pages where buttons outright not worked. In firefox.
    - FastEatSlow 4y ago
      Web browsers tend to degrade a webpage rather than fail to load it. Given that every day using Chrome I'll come across a website that is having issues with rendering, it should be acceptable.
    - cxr 4y ago
      > If 90% of the pages worked in browser I wouldn't use that browser, ever They don't care.
qikInNdOutReply 4y ago
Do we really pretend this is a architecture decision? This is the classic Agile Management wants to show result for reward fast, that leads to huge tech debt build up, as layers are not properly designed and reuseable.
- asimpletune 4y ago
  It’s neither. There’s no management or promotions or really any incentive to do this other than it’s fun. It’s also not an architectural decision, just how they as a team decide what to work on.
  - cudgy 4y ago
    But how does developing a half-baked browser that targets some websites for fun refute that building a browser is impossible? Doesn’t it provide another example that it is impossible, at least for this team?
    - ludston 4y ago
      Doesn't that depend on whether or not they end up making a browser in the end?
      - paulryanrogers 4y ago
        Where is the end? And why claim you're doing the impossible until it's done? It all comes off as puffery to me. Though the vertical slices approach is interesting, so I salute their efforts.
    - asimpletune 4y ago
      Well, it takes time to make something big. And, one way to do it is to choose end-to-end functionality. Idk, it doesn’t seem so controversial to me. I’d wait and see before calling it half-baked.
      - 4y ago
ohgodplsno 4y ago
>Console emulators (especially of the HLE variety) seem to have a similar flow. And emulators that have gone this path have all regretted it, because they end up making hacks to make <popular game> work, because everyone simply wants to play <popular game>. Dolphin is still paying the price of that method years down the line. Project64 took years to unfuck themselves up, ZSNES is forgotten and overtaken by many more that have done the proper thing. So, sure, you can get some initial usage. But making a browser isn't about being able to open twitter.com
- deleted 4y ago
  [deleted]
- troad 4y ago
  I feel like you may have misunderstood what kling is saying. He's not saying "we will cut any corner to get Twitter to load", he's saying "we look at what it would take to get Twitter to load, read through the relevant specs, and try our best to implement the required features cleanly and correctly". Loading Twitter (etc.) is not really the goal, it's more of a prioritisation mechanism for tackling a huge spec. Actually getting Twitter to run is a nice reward for all that hard work though, and a series of such rewards keeps the contributors motivated in the marathon that is building a browser.
  - ohgodplsno 4y ago
    No, I understand what Andreas is saying. But the reality is, when you read and implement specs for a specific website, you end up cutting corners, even accidentally. Maybe Twitter relies on a particular behavior of fetch() that was screwed up in Chrome 97 and has had to be kept for backwards compat this entire time. Maybe it uses some CSS that never got properly documented or specified. By targeting a single website, you end up accidentally writing in those site-specific fixes _in_ your implementation. You only realize it's fucked up because you visited Twitter. but maybe it screws up another site. Maybe something else depends on a quarter of that functionality, and you've accidentally broken it.
    - 4y ago
Waterluvian 4y ago
I really like this approach because it’s a low-effort way to prioritize development. I did this with the CPU for my GameBoy emulator: I picked a game I wanted to work and just kept implementing opcodes each time it crashed with an “opcode not implemented” error.
- account42 4y ago
  It's also a great approach to port games - replace all platform-specific code with assert(false) until it compiles and then fix the asserts as you encounter them until everything works.
alex_lav 4y ago
This is how most games are developed as well. https://www.whatgamesare.com/vertical-slice.html https://www.whatgamesare.com/vertical-slice.html
- Mavvie 4y ago
  I don't think that link supports your comment. It says that vertical slices (at least as described by that article) are generally unrealistic in game dev.
  - alex_lav 4y ago
    You're right! I skimmed the first paragraph, as I was mostly just looking for a description of vertical slices in games. The rest of the content does not in fact validate my statement.
    - favorited 4y ago
      You're right that the "vertical slice" approach has been used very successfully in games development, though. Mark Cerny[0] has been evangelizing[1] the idea that preproduction isn't over until you have a "publishable first playable" (a.k.a., a complete vertical slice) of your game. Basically, you shouldn't switch from "preproduction" to "production" until you can show (A) here is actual gameplay, (B) it is, in fact, fun, and (C) you know how to actually implement it. Until you can demonstrate those things, how are you supposed to estimate how long it will take to build? Or that, once you're done, whatever gameplay mechanics you dreamed up are actually entertaining to a player? [0] arcade game programmer, producer / studio exec who got Insomniac and Naughty Dog to scale beyond their founders, & eventual lead architect of the PS4 and PS5 [1] https://www.slideshare.net/holtt/cerny-method https://www.slideshare.net/holtt/cerny-method, https://www.youtube.com/watch?v=QOAW9ioWAvE https://www.youtube.com/watch?v=QOAW9ioWAvE
      - alex_lav 4y ago
        > You're right that the "vertical slice" approach has been used very successfully in games development, though. Oh I know, I worked in game development for years :). Was really just trying to get a short description.

jgerrish 4y ago

> Console emulators (especially of the HLE variety) seem to have a similar flow. Good insight. I was going through this same spiel in my head the other day. It's a flow that if properly managed can provide a good feedback system. It provides the developer positive feedback and at the same time successful milestones. Say I'm building an emulator for a simple architecture with a few dozen opcodes... "Alright. Let's start. Where do I start? How about NOP." So you implement NOP. You write some tests for it. Maybe you build a pretty printer into your opcode and you test it on disassembling a single byte file with a single NOP opcode. Suddenly you have a working dissassembler! It's obviously an artificial toy, but it works. Maybe next you add an INC instruction. Add some tests. You'll need registers... Build a simple one INC opcode binary file. Maybe add an executor in addition to a dissassembler. Suddenly you've got registers working. And if if add another INC opcode byte, you can see your emulator changing behavior based on real external input! And so on. It's an interesting flow, you're right.

pavlov 4y ago

This approach works better for Wine where the Windows binaries are a fixed target. On the web, you may get Twitter's feed rendering acceptably, and then two days later they ship an insignificant redesign that happens to use sixteen CSS features you don't have and everything is totally broken again.

actionfromafar 4y ago
Depends on if your actual goal was getting twitter to work. If Twitter rendered fine, chances are some other site render fine today. The same it was with Wine.
- ilyt 4y ago
  Sure but Wine is a tool where if 90% of the stuff user wants to run in it works, it's still great. Say if you use it for gaming you can play most of the games and only boot into windows every few months once you hit one you can't. But that's not how you use web. If 90% of the pages worked in browser I wouldn't use that browser, ever, because chances are I'd hit one that didn't at least once every few days.
  - mcbits 4y ago
    It depends on the types of bugs and inconsistencies that show up in practice. If a page (or worse, the whole browser) crashes, that's a problem. If a column of ads doesn't scale right and gets bumped down to become its own lonely row below the main content, that's kind of ugly but almost a feature.
    - ilyt 4y ago
      I've seen pages where buttons outright not worked. In firefox.
  - FastEatSlow 4y ago
    Web browsers tend to degrade a webpage rather than fail to load it. Given that every day using Chrome I'll come across a website that is having issues with rendering, it should be acceptable.
  - cxr 4y ago
    > If 90% of the pages worked in browser I wouldn't use that browser, ever They don't care.

qikInNdOutReply 4y ago

Do we really pretend this is a architecture decision? This is the classic Agile Management wants to show result for reward fast, that leads to huge tech debt build up, as layers are not properly designed and reuseable.

asimpletune 4y ago
It’s neither. There’s no management or promotions or really any incentive to do this other than it’s fun. It’s also not an architectural decision, just how they as a team decide what to work on.
- cudgy 4y ago
  But how does developing a half-baked browser that targets some websites for fun refute that building a browser is impossible? Doesn’t it provide another example that it is impossible, at least for this team?
  - ludston 4y ago
    Doesn't that depend on whether or not they end up making a browser in the end?
    - paulryanrogers 4y ago
      Where is the end? And why claim you're doing the impossible until it's done? It all comes off as puffery to me. Though the vertical slices approach is interesting, so I salute their efforts.
  - asimpletune 4y ago
    Well, it takes time to make something big. And, one way to do it is to choose end-to-end functionality. Idk, it doesn’t seem so controversial to me. I’d wait and see before calling it half-baked.
    - 4y ago

ohgodplsno 4y ago

>Console emulators (especially of the HLE variety) seem to have a similar flow. And emulators that have gone this path have all regretted it, because they end up making hacks to make <popular game> work, because everyone simply wants to play <popular game>. Dolphin is still paying the price of that method years down the line. Project64 took years to unfuck themselves up, ZSNES is forgotten and overtaken by many more that have done the proper thing. So, sure, you can get some initial usage. But making a browser isn't about being able to open twitter.com

deleted 4y ago
[deleted]
troad 4y ago
I feel like you may have misunderstood what kling is saying. He's not saying "we will cut any corner to get Twitter to load", he's saying "we look at what it would take to get Twitter to load, read through the relevant specs, and try our best to implement the required features cleanly and correctly". Loading Twitter (etc.) is not really the goal, it's more of a prioritisation mechanism for tackling a huge spec. Actually getting Twitter to run is a nice reward for all that hard work though, and a series of such rewards keeps the contributors motivated in the marathon that is building a browser.
- ohgodplsno 4y ago
  No, I understand what Andreas is saying. But the reality is, when you read and implement specs for a specific website, you end up cutting corners, even accidentally. Maybe Twitter relies on a particular behavior of fetch() that was screwed up in Chrome 97 and has had to be kept for backwards compat this entire time. Maybe it uses some CSS that never got properly documented or specified. By targeting a single website, you end up accidentally writing in those site-specific fixes _in_ your implementation. You only realize it's fucked up because you visited Twitter. but maybe it screws up another site. Maybe something else depends on a quarter of that functionality, and you've accidentally broken it.
  - 4y ago

Waterluvian 4y ago

I really like this approach because it’s a low-effort way to prioritize development. I did this with the CPU for my GameBoy emulator: I picked a game I wanted to work and just kept implementing opcodes each time it crashed with an “opcode not implemented” error.

account42 4y ago
It's also a great approach to port games - replace all platform-specific code with assert(false) until it compiles and then fix the asserts as you encounter them until everything works.

alex_lav 4y ago

This is how most games are developed as well. https://www.whatgamesare.com/vertical-slice.html https://www.whatgamesare.com/vertical-slice.html

Mavvie 4y ago
I don't think that link supports your comment. It says that vertical slices (at least as described by that article) are generally unrealistic in game dev.
- alex_lav 4y ago
  You're right! I skimmed the first paragraph, as I was mostly just looking for a description of vertical slices in games. The rest of the content does not in fact validate my statement.
  - favorited 4y ago
    You're right that the "vertical slice" approach has been used very successfully in games development, though. Mark Cerny[0] has been evangelizing[1] the idea that preproduction isn't over until you have a "publishable first playable" (a.k.a., a complete vertical slice) of your game. Basically, you shouldn't switch from "preproduction" to "production" until you can show (A) here is actual gameplay, (B) it is, in fact, fun, and (C) you know how to actually implement it. Until you can demonstrate those things, how are you supposed to estimate how long it will take to build? Or that, once you're done, whatever gameplay mechanics you dreamed up are actually entertaining to a player? [0] arcade game programmer, producer / studio exec who got Insomniac and Naughty Dog to scale beyond their founders, & eventual lead architect of the PS4 and PS5 [1] https://www.slideshare.net/holtt/cerny-method https://www.slideshare.net/holtt/cerny-method, https://www.youtube.com/watch?v=QOAW9ioWAvE https://www.youtube.com/watch?v=QOAW9ioWAvE
    - alex_lav 4y ago
      > You're right that the "vertical slice" approach has been used very successfully in games development, though. Oh I know, I worked in game development for years :). Was really just trying to get a short description.