Hi everybody. Let's answer an age-old question: why is it so difficult to build great user experiences, especially on the web? How did the evolution, and in some cases the devolution, of tools, IDEs, programming idioms, organizational structures, incentives, and even conventional wisdom get us to a place where it takes heroics to build something fun, performant, accessible, and high quality? To dive into this, I'm thrilled to talk with Cheng Lou, someone who balances a deep understanding of the visual and UX world with software engineering and computer science.

He's spent a lot of his professional career and personal time exploring how we can make it easy for developers to build great user experiences, and how we can make that the default instead of something people have to constantly fight for. To touch all of that, we're going to start at the very beginning, which for many of us was Flash: how it kicked off careers in design, development, and the blend between them, and then how everything evolved from there. So this is going to be a fun conversation. Sit back, let's get started. All right, Cheng, great to meet you. For the audience, tell us a little bit about yourself.

I used to work at Facebook on various projects. I worked on React. Js, a little bit on Messenger, ReasonML, and ReScript, and right now I'm at Apple. I started my career doing Flash, which is actually how I met Kirupa, all the way back when I was a teenager pretending to be an adult on the kirupa forum. That was a great time, very formative, and here we are today. It's been a pretty incredible journey so far.

Yeah. One of the things I've seen you working on is a lot of front-end-heavy stuff. Have you always gravitated toward the front end, or is that something you just actively stumbled into?

So I think I first started by drawing stuff when I was six. That's how I developed a liking for visual things. I was a full-stack person later, but yes, I do seem to always gravitate toward the front end. I wouldn't say that's necessarily just because I liked drawing, though. The real influence was when my family and I immigrated to Canada. We brought a laptop, it was a French-speaking place, and I had no friends whatsoever, so I was just on my laptop all the time. It's a slightly stereotypical story, but it is what it is.

I was playing games, and at some point that turned into, yeah, this game isn't doing this right, what if I made my own little thing? And then there was Flash. I think I started with either Flash 5 or 6, with 6 being Flash MX for the OG people. That was fun because you got to draw first, and then the scripting came afterward. It wasn't the cleanest architecture or anything, but for a tiny- to medium-sized thing, especially as a kid, it was more than good enough. Flash also lived on the web. Sure, you could compile to an executable, but basically nobody did that. Everybody was just embedding it on the web.

There were great portals for showing Flash work, Newgrounds being one of them, and there was a Chinese one I used to frequent too. I didn't speak English, but I spoke French, so that shaped things differently as well. I dabbled in native a little too, but over all these years one thing I've noticed is that people who come from graphics and end up doing front-end think very differently from people who start with HTML and hypertext and then do front-end. They just have a different perspective on how to execute things. So I consider myself more from the graphics side that later happened to do the HTML and hypertext side.

I mean, the funny thing is that's something I've noticed too, and I don't have a great theory for why. But one poorly formed opinion that I strongly hold is that Flash was a great onboarding tool, because building a great application, animation, or interactive experience required both a visual component and a logic and programming component. But because the visual side was familiar, front and center, and immediately available, it made it much easier for people like you, who enjoyed drawing and had a more visual mind for these things, to translate ideas into actual output on a screen. That was definitely true for me. My interest was always in drawing, doodling, and scribbling.

Programming was never really part of it. Even when I was using Flash, I used it a lot for the animation capabilities. The programming part was a necessity. It was a necessary evil. I had to learn it to get the visual part done, but I always approached it from a visual-first point of view. How do I translate this idea in my mind, which is very visual, into something that can be represented? I think that approach opened the door for a lot more people.

I'm almost certain that if there had been no Flash and I had to learn HTML from the very beginning to translate my ideas, I never would've done the things I'm doing now. There never would've been a logical connection in my head between raw HTML text and a visual idea I wanted to bring to life. The hurdles involved in going from raw HTML to that visual result would've made me give up a long time ago. I'd probably be doing more visual work with Photoshop or After Effects or things like that, but never in a tool that ultimately allowed you to create something that goes on the screen.

So I do think about this too, and yes, a lot of it absolutely is the education Flash gave us. I'll tell you something unrelated to Flash, and this isn't to start a platform war or anything. Take it purely as an observation. I have my own opinions, but this part is just data. Back when I was on Messenger, I was mostly on the web part, but we sat next to the native teams, Android, iOS, and backend folks who would sometimes dip their toes into those codebases too. I was immersed in that environment for around four years, at least. You watch people who freshly graduated come through those pipelines in parallel.

You watch them evolve. You see batches of people switch jobs and come back, and the people on the native side, for example iOS, absolutely do end up talking about different things than the people on the web. That's just true, and it's kind of sad how little overlap there is between their topics when they're shipping the exact same product. I saw this repeated over four or five years at Facebook. These teams were shipping the exact same product on different platforms, even on the same screen form factor, like the iPad. But anyway, I'll stop there for a second. Thinking back on Flash, this absolutely fits.

One thing I remember is that when I was doing Flash, there was a programmer who was a friend of my parents. He said, oh, you do programming too now, that's nice, it's good to start young. What language do you use, C++ or something? And I said, no, I use this ActionScript thing. Then he told me about C++ and printing hello world, and what stuck with me all these years is that I kept asking him, where are you showing that hello world? He said, well, you print it and it goes into the terminal. And I was like, yeah, but where's the box around it? Where's the button?

Is it really that simple? Flash was so opinionated it would just draw the thing, put up another thing, give you a button, and you could click on it, and you didn't even have to specify handlers first. I couldn't understand that other mentality at all. Obviously, when you later start doing more traditional programming, it clicks. But the mentality really is different, and starting with pixels as the primitive gives you a very different mental model from starting on the web with rectangles.

Yeah, I'm curious to hear your take on why that might be the case. One theory I always have is that our brains have a certain amount of capacity for processing the present, the future, and all these different layers of a problem. If the present is bogged down in technical details, like here's the console, I'm writing at the lowest level, and only later do I add more abstractions, that uses up a lot of energy.

By the time I get to the point where I can draw a circle with some text on the screen in a language like C or C++, and I had to learn the hard way because I didn't know much about graphics libraries, I've already spent so much effort getting there that I just want to stop and take a break. Whereas in Flash, you jump many layers of abstraction. It's like, here's a pixel, here's an object on screen.

You still have a lot more mental capacity left to ask, can I make this move, can I make it spin, how do I add sound, how do I share this with a friend quickly, what if multiple cursors are involved, what if I want to create more at once? It's almost like the opportunities and possibilities were just more open to us because, at least in my case, my naiveness about what wasn't possible was completely redefined by what Flash made available. I didn't learn C++ or Visual Basic before that. Flash was my first real experience of visual programming, so I had no concept of the complications other people had gone through.

I just took it for granted, and I think that kind of arrogance actually helped me in some ways when I look at what I do now.

I thought about this a lot, actually, and, as always, it's a multidimensional kind of thing. Here are the few things I can think of that allow you to have visibility over the full stack. First is Flash. It wasn't general purpose, right? Usually, what you ship has a graphical component to it. You ship these interactive experiences. It's not for microcontrollers or scaling servers. That's one thing. Suddenly, the scope is narrower. Within that narrow scope, you get way more assumptions to work with, and you get to make a much more polished world. If you're a backend developer and, hypothetically, there's ActionScript for the backend, what is the stage even for?

It takes up 80 percent of your screen, and what are you dragging and dropping? The impedance mismatch is pretty huge there, but it's very low when 90 percent of the time you work with drag-and-drop objects. That's one thing. The other thing is that it was a very, very vertically integrated experience. There was no scene considered the glue between two projects, where one person owns one open-source component, I own mine, and then there's Google. Ultimately, as programming scales up and the dimensionality scales up, I think Richard Hammond, or somebody like that, said it's actually mostly glue. It's crazy, but the core components don't matter as much.

You start working with the glue and the topology of that glue, and people go wild with all sorts of patterns that historically don't work out. Anyway, that glue disappears when you're in a vertically integrated stack because the pieces just talk to each other; they're supposed to talk to each other. That's another thing. A third thing is that it was well executed. The fourth, extremely important thing is that they were very good at controlling the entropy of what they were doing. They were very good at controlling complexity, and I believe this is a trait of graphics people too. They're pushing the boundaries, so the medium pushes back against you.

Do that for five years and you learn how to force the entropy down. I wouldn't say that, currently on the web, we're thinking much about these things. You think of a tiny thing and someone bloats it into a gigantic, 10,000-line thing. Then you have people who don't seem to realize that you have a fixed budget for this kind of holistic thinking. If you have 10,000 lines, you need to start thinking about resource allocation. But if you don't think about resource allocation because you're making your own little component on the side, you may think open source solves everything. I love open source; my career took off thanks to it.

But if you think it solves everything and you've already blown up to 10,000 lines, suddenly that little piece becomes a black box. Now that you have a black box, guess why you need glue. You don't get to a vertically integrated system nearly as well. With Flash, the amount of code I had to write to achieve the effect, versus if I wrote my own thing, was a stark difference. To be clear, there's a lot more code behind the scenes that does the work. But you could traverse the stack, as you said, from very low to very high.

It could output stuff at a low level too, especially near the end of it. Near the end, it had some pretty cool 3D acceleration. You could traverse the whole stack, draw the thing, and actually make a component that's shareable. Nobody really did that, but you could share components too. That ability heavily relied on shrinking the amount of code and saying, 'Good enough here; let's not double down on this, because now the code size will explode fivefold. Let's do the next piece, and the next piece.' If it all fits within 100,000 lines of code, let's say, a professional can still fit it within a brain.

If not, you still have to inject pieces and boundaries, and you won't have a holistic vision anymore.

No, what you described essentially sums up almost decades of extremes in IDE, framework, and language development. Vertical integration is a great example. With vertical integration, if done well, you get simplicity and ease of use, but you don't get the flexibility. You can't do all the things you might want to do. If you wanted to use Flash on the backend, for example, as a headless app, that really wasn't the concept of it. Whereas with something like C++, where I'm starting from the ground up, I can go in many directions and pay the complexity cost as a result. The same applies to the lines of code as well.

In many ways, as you mentioned, many things we typically call base class libraries or core language frameworks were simply built into the Flash runtime. Even though you're writing two lines of code to animate something from one side to another, probably a million lines of code were already precompiled into the runtime, so you didn't have to see or worry about them. In a world where that abstraction wasn't provided, for various reasons, you would have to provide all those mountains of lines yourself. A developer who likes to tinker tends to say, 'Let me make a minor change here. Let me fork it now.

Let me keep my own dependency.' Then you create fragmentation, which has pros and cons, but if your goal is a simplified experience, you probably want to reduce it as much as possible. Another point you brought up that resonated was that Flash gave you opinionated, friction-free onboarding. You didn't have much choice. You could either choose between ActionScript 3 and ActionScript 2, and you had some superficial choices around frame rate and form factor, but those could all change after the fact. You happened to have these things, but the idea was that you had only one major entry point and a few minor levers you could pull to change your overall experience.

That was it. You were very narrowly constrained. We could see that play out when Flash evolved into Flex, where you could see the actual markup that generated the visuals. We knew markup was being generated, but Flash hid it away. You could never see the MXML in the Flash world for typical things; maybe you could later. When Flex came out, all of this was exposed, and you could actually see the build system. You could see the scripts that were running behind the scenes to compile all your various ActionScript files into the final output. You could actually see the markup being generated.

With that, we saw many developers who used to be traditional in the Flash world fall by the wayside. For them, the magic and simplicity that Flash provided weren't there, especially the affordances we talked about. There's a common statement about development tools: you want to solve the problem in the domain you're in, so a visual task is best solved visually. If you're drawing a rectangle or circle, you want tools that let you draw it visually. You don't want to take a visual item, like a shape, and write 20 lines of XML-like syntax to get it going.

You can, and that's what people do today in the HTML world, but that's not how our brains have really been wired and optimized for many years. Everything you touched upon here goes into detail about the extremes and the choices Flash made. Those choices made it successful and ultimately not successful as well. The SVG thing annoyed me a lot. It's nice to know how it works under the hood; that's good knowledge. I always think we should understand at least one good level below us and one level higher. But people tweaking SVG by hand is baffling.

You don't tweak a painting pixel by pixel or brushstroke by brushstroke unless you're doing some statement about generative art and all that. People actually do that as a manual compression strategy: 'Oh, this path goes there.' It's all XML, and it blows my mind. We're not talking about a full programming language, so to speak. This is the perfect thing where you use a tool, drag the stroke itself, and use immediate, direct manipulation. The fact that people do it with code is astonishing. You know how many kids are lost? I'll tell you: you would have lost me long ago if this were the way to draw. It doesn't scale.

It scales to one icon, then 10 icons. To scale to 20 icons, you start clamping down on restrictions. They all have to be the same size and use the same line maximums. You force uniformity upon them because that's the only way you can scale with that mental model and way of manipulating things. You're not going to make a single scene in Flash that way. Am I saying everybody should make everything in Flash on the website? No. But you don't even provide them a ramp to go into that world.

People need to realize there's an entire world out there, then come back and apply these graphics techniques to their web page and make it better. Thankfully, this tradition has been inherited by game people because they have no choice. Besides text adventures and idle games, games have to be visual and interactive. Think about the usual optimization that we reach for on the web. For the past five to 10 years, people have talked about the usual web optimization of statically extracting little snippets into a declarative format or whatever. In a game, there's almost nothing to extract.

Some structures are static, but if your character stays still, for example, it still has micro-movements, and the leaves on a tree still blow in the wind a little. You don't get to say, 'Let's make this completely static so I can extract some snippet into this kind of declarative format.' By then, you're making something else instead of a game; you end up making a web page. Right now, our experiences are extremely static. If you go to Hacker News or sites where people are extremely used to static experiences, the way they talk about transitions feels like a bunch of teenagers talking about transitioning, if I can say that impolitely.

They're like, 'The web page moves around, and that's disturbing.' It's disturbing if it's done wrong, because nobody is doing it well anymore. It wasn't that hard to do well. I'm not talking about flying text over you while you scroll. That's the scarecrow argument they're constructing. We lost the capability of doing tasteful transitions because nobody was learning to make transitions in the first place, make mistakes, come back, and properly and tastefully make them work anymore. Anyway, I don't want to go on a tangent too much, but these are topics always on my mind that I can't get rid of. Our entire talk is designed to be entirely tangential.

I really want to go deeper into this because our world isn't static; it's fluid. There's movement and a certain speed to things. A lot has been written over the years. I think Disney did a really good job characterizing the top principles of motion to provide a pattern for representing movement realistically. Game development is probably one of the last frontiers today where you mix procedural, programmatic visuals and static visuals, with interactivity and an openness that gives your building a lot of magic. You really are building worlds in this case, as opposed to purely building a spreadsheet, a cell in a table, or a document.

The requirements are so high that you don't have room to do obviously unrelated, weird stuff. You need to push the pixels and vertically integrate many pieces. It's not always the best thing, but it teaches you to traverse the entire stack. Game engineers often understand everything from assembly and language-making to GPUs, graphics, game editors, the game experience itself, and the artistic aspect. How many people like that exist in web development? I would say very few compared to games. Game developers traverse the entire stack because they have to compress it, because the medium demands that kind of thing.

That's becoming less true, but the people pushing the boundary are still generalists who can traverse the entire thing. That might end in 10 years, but we'll see. This also goes to the fact that there are many more web developers, because you can get away with specializing in one area and still make a career and build projects. A great game developer is very difficult to find, whereas game developers often traverse the entire stack. Even simple games have teams of developers: five, six, seven, or dozens who specialize in areas so deep that their entire mental capacity is occupied by one task.

That specialization is replicated across other layers of the stack, and everyone contributes to creating high-quality games. That's another thing I always found very interesting about Flash. It was easy enough, and did little enough damage to how quickly you could get something out, that a team of one could handle the full end-to-end process. You could rely on sound resources, such as FlashKit's popular sound library. If you needed sound, you went there, got royalty-free sound, and were good to go. There were font libraries too, so you were able to scale it as well.

One person with minimal knowledge, or maybe some hours of effort, could go from having no idea how to create something to creating something semi-interesting. It might not be high quality, but at least it got you closer than any other tool out there. After a few hours of tinkering, you knew exactly what needed to be done.

Hopefully, Unity feels a role nowadays, but, I think Unity is quite big now and, you know, the starting template is very- it feels very- different than like flash. You're not drawing a stroke or anything like that. And also, a one real constraint is Flash being 2D.

At the beginning, at least, it helped a lot, right, because, if you're directly going to 3D, I think you will have lots, lots of people because now we're talking about modeling and polygons and then you're dragging, let's say, Maya, like, obviously, you know, I don't think many kids start with Maya or 3ds Max, but yeah, if you, if you look at the, for example, I made a gallery recently. Right, it's just mostly like a symbolic kind of thing. Like that I was, I would dare say, to have a transition in that Gallery are not disruptive, right, they're not there to wave in your face.

Look at me, I can do this, right, like I can put a transition there because I, right, I, it doesn't, it wasn't done like that, right, it was, it was mostly hopefully tasteful and thinking in terms of just pages will have killed transition completely. And yes, I've seen like these kind of like you know, people ask me about, like my opinion, like this kind of transition apis, right, that magically transform between one page or another, like it works for the web, like 80 percent of time. It's good enough, right, but it's not. It doesn't give you any mentality for working, with a transition.

It's always, I feel like, you know, whenever these API come out, it feels like transition is like okay, okay, fine, we'll have a transition. That kind of mentality it's not like okay, how do we design an experience like?? Some people used to say some kind of Storytelling mechanism, right, like the images there and it is zoomed there because it has a purpose, let's say it's an overly romantic way of seeing about this, but ultimately, the fact that I give is a, I think, pretty apparent and that Gallery, you know, that was also like a, like a proof that it can be done without any dependency, right, not yet.

Obviously, One Day You're Gonna reach for something, but not for like something like that, like it's a grid, come on right, and that was without the data. That was like 400 line of code. I actually asked people to estimate how many lines of code is. I ask various developers from various framework communities and all that and like their estimate blow my mind like they think. Like it's a 2000 line, plus dependency, three thousand. Someone said ten thousand lines.

If you set 10 000 lines, then I think there's a very huge discrepancy between your mental model and what the mental model should be right, and your, your entire architecture, when you called ordinary, an ordinary web app in your company, your entire mentality is different. Right, if it's ten thousand line, then you the architecture, you choose the code, you choose dependency, you drag in kind of it becomes a self-fulfilling prophecy of the kind of app you build. Right, it's kind of like a Conway's law before for a single person, for single person's brain, right? Speaking of which, allow me to go on another tangent.

I remember Mr Colin mock, who was a very generous with me, like back then when I was a kid, pretending to be an adult, using my dad's email, and I was just I didn't know what I was doing and I was just sending him emails asking questions about the book he wrote which is like action script for Flash MX, the definitive guide.

Yeah, that was so cool and like I didn't know O'Reilly back then there's this like eel that that twirled around like it was green and it was nice professional, but no, he was very generous and he replied back lots of, lots of my email and that also has been very formative in my career. I just wanted to give a shout out to him to let him know that you know, there's this kid with broken English that actually, you know, did something, and it was a lot, in large part thanks to his generosity.

So, that that aside, like he also wrote a book called action script, essential action script 2.0 and then essential action script 3.0. The thing is- and those are good books- that they're like good manual, good tutorials and all that. But for me personally, when I transition to action script two points to 3.0. Right, I, actually I and I use all these patterns like MVC observables, like reaction, this and that and that.

That was like 15 years ago and it, just there, there's flash makes you realize that you're not getting work done, like pure code, doesn't make you realize that it's, that it's that much of an impact because Flash is your ultimate integration and unit tests, because you look at the effect right at the end it's: the screen is always open. You build and the screen is open, and even as a kid, you iterate and it's just like, hey, nothing is happening. What's going on? Okay, I don't understand NBC.

Let me go back and like re-architect this code and then you make another effect and no, it's just that nothing was happening in my brain, like I just used to attach a script onto a button and it worked right, and I'm not saying that's the best architecture, but it scales surprisingly well and whereas MVC, I think, and all these kind of things that's happening on the web. The problem is not that they cannot scale up. I actually think that in some time management they can scale up.

The big problem is that they cannot scale down right, because the activation energy needed to make one pixel work, one triangle, one button, is huge, right, and when it's not huge, it's usually because they crafted a golden path especially for that case and all that. But anyway, that that was my impression, I think. And speaking of action script two and a 223 like this is truly like a history repeating itself, right, like sometimes we say that, but it's not true because, it's not really similar. What comes before and after. But for action script too, I had to remind people, right, it's literally based on ecmascript.

It's the same spec as JavaScript. They run the same way and they look the same way, so I'm not making a superficial comparison. And what happened with action script 3? Well, they decided, hey, we're going to add a real class system and throw away the Prototype base inheritance. That sounds familiar, right, and we're going to add a static type system because we can optimize some code like that, and we're going to have a brand new VM. It's going to be fast and this is literally typescript plus Chrome's jit, plus like whatever, whatever is happening nowadays, and it's just. It truly is history repeating itself, without the stage anymore, but yeah.

Because of this shows that we've been doing this for just a long time that we actually got to see this. You know, people often say that you've been living in a city for too long. When a stadium gets built and it gets torn down while you're still living there. I think we're seeing the coolant that the programming world, or we were there at the beginning when we saw the shift from two to three and how the gaps, the language and the syntax made it difficult to create a high quality application, so more guardrails and more formal formalities, I guess, were added.

And then we're doing the exact same thing I can mention right now with with how JavaScript, I think. Well, it just took almost 20 years to get to where we are right now, which I guess is the same as the betamax VHS Blu-ray, you know all these kind of come kind of camera, because, like comparisons, where it takes time for people to realize what we're doing, some of the things that we are doing, but the fast feedback that flash provided, was something that was really magical. In many ways, it was like you had of the convenience of consulate law.

They get on the web today, but the output is not text. It's not just something in the console, it's actually the context of your finished application, the actual movie frame that we'll be displaying your animation and the final creation and agreed, I think, when you always do it from that mindset, whether it is we often talk about MVPs and making sure we ship products quickly and iterate based on real life feedback and so on. Flash made that more apparent.

The development lifecycle world where you didn't- you almost never spent like more than a few minutes writing something before you hit control and enter and just make sure it worked properly in The Flash Player before you went along and did something else, which is very different today, because right now you're probably in a, your tunnel vision into one particular problem for like maybe multiple days on end and by the time you step back and look at you're like, okay, this looks good or, worst case, I invested way too much time and getting to the state I'm gonna sacrifice quality or performance or something like that, and that, multiplied by ten hundred thousand times, ended up getting us.

In my opinion, the state of the web today, which is the most average web page, is about 1.4 megabytes or so. Some popular chat applications like 32 megabytes and I'm like what is going on there: quite 32 megabytes of dependencies and so on for, essentially, display playing, an input field and a collection of text fetched from a database somewhere in a remote server. Yeah, and I agree with you and some people there was, they would defend that blow by saying: well, first, picture and video. It will take even more bandwidth, which is true. But we're not talk, we're not comparing the same bits.

Like 32 megabyte of code says something about your code base, right, maybe a video is way bigger than that, but that's not the same, right, we can compare it like that. That's one thing. It's an indicator of chaos and entropy in your code base. And then the second argument they will use is: well, along the same argument, they will say: our computers have much more memory now, it's true, but again, like humans, don't humans haven't changed very much, right? One MB worth of code that I can handle. 32 MB, I cannot, right. And second thing is they say they say they, you know there's way more features now.

There are some newer features. But if you look at, like the some of the stated R in the past, even though iOS development and all that, like they actually surpass you in terms of features and in terms of Polish, in terms of the holistic experience, were within a very small form factor, than whatever you bring up. And yes, there there are more features. But, honestly, after having done this for a while, I keep questioning myself: is this super linear? Is it? Is it really like that? By my conclusion, is at least in the scope of the web? No, it's not.

Like you add one feature and it shouldn't justify like 10 megabytes more, like it shouldn't be super linear, like that. Right, like 10 features should not. Yeah, sure, surely, anyway, and also, there aren't, there aren't that many more features. So to speak, honestly, like if you can't understand this, right, MSN has more features than 95 of chat apps out there. Right, and you know it wasn't the prettiest thing because the design language back then was image immature. Right, like it was gratuitous views of gradients here and there.

But in terms of features, that, if you really think about what MSN did, like the Emojis, the pictures, the videos and the text and the real-time status updates and all that and all sorts of random like corporate kind of widgets that they crammed into that. That is still smaller than the random corporate stuff that they were cram into a normal, typical chat at right and so, yeah, I think I don't know.

I just even MSN itself, like it makes me feel like red of China, and I wasn't saying IRC, I'm not asking you to go to the terminal and like cheat by saying, oh, I don't have to build an interface. Therefore, it's a northern magnitude less code, because I don't literally don't draw anything. No, right, NSN was a full-blown native app with all sorts of weird Windows decisions there too, right, they were, the programmers were not were great, but like, they're also not the ex extreme great end of program or anything like that.

So, because people usually say, well, you know, if you're an expert programmer, of course you can do that, but no, MSN was, you know, it was an app, right, it was not like The Cutting Edge or anything like that. So I feel like we can make a very safe comparison that there is real bloat going on here. Right, it's not, like it's not very justifiable and yeah, I mean we can, we can talk about this a long time, but ultimately it's just I don't know what to do. It's about incentives as well.

You know, having been at Microsoft when the MSN app was Rewritten and having seen some of the conversations around how to migrate from a legacy Tech stack that was performed and it worked, to what was then the managed code world, where everything be Rewritten- innet and windows presentation foundation and so on- which brought with it a lot of developer benefits, but no one would ever say that it was faster than a thing that replaced and with so many layers of abstraction removed, where I'm calling an API. But API brings in like 80 megabytes of you know working set memory and things like that.

And as a developer on these kind of products, you had to realize, like, okay, how much bandwidth and political Capital do I have to go against the grain on some of these things? We're just going to resign myself the fact that, okay, I can control these things with limited amount of turbulence and these things.

I'm going to resign myself the fact that how it is going to be done is the way it's going to be done, because I'm almost certain that if you talk to any developer who worked on any app that ends up becoming like be in a 32 megabytes of JavaScript or extremely slow and sluggage performance and so on, they'll all be the first one to say, like no, I care about code quality, I care about very compact, minimal, thinking about user experience and so on, but it's the typical death by a thousand paper cuts and sometimes it's actually a gigantic.

You know, chainsaw, it's gonna be things where you just can't control it and you're just gonna have to resign yourself. The fact that, yes, I want to do a great thing but my hands are tied because of organizational Dynamics, just Technical headwinds and other complications that the user is not the primary motive for we're doing things. There are other complications at play and the thing is like that Conway's law actually applies bi-directionally. For an organization- and one argument that people will reach is: hey look, if it's a good dependency and all that, why does it matter? Right? And for an MVP, that does not matter. But the thing is right.

But because some people may say, I might say, like in that 32 megabytes of, MB of stuff, like a good 25 of our dependencies, that that doesn't actually help. As a matter of fact, when I try to code and I try to stay honest with myself and like, count the transitive dependencies in the line of code, yeah, because you it's not true that you can eject that into into somewhere else, and then not worry about it as a first naive touch animation. If your functioning is very complicated- it's 100 line.

You can wrap it yourself into a single function, call a Check, put to literally put that code into node module, if you want, or like a mono repo kind of style, whatever thing right. And you will say, oh, it's one, one single line of code. Why do I need to count the extra 100 line of code? But no, that that should not work like that, right, at least your first layer of dependency is not a transitive one should absolutely Contour you, when they don't, you end up creating these artificial boundaries.

And the thing that people never talk about is that you might accidentally slice your entire mental model or Worse your team structure or Worse your inter-team intro team organizing its own structure across these boundaries. Because the moment I check a dependency, this becomes something that can be maintained at least superficially, like in parallel, by someone else. But I don't know if that's the right boundary to divide my code. I just know I wrapped it because I don't want to see it too often, right, and so that cross cutting really ends up like, like I said, a reverse Conway's law. It ends up dictating that.

You know, the most famous example would be something like microservices and all that. But it's true for MVC too, like, like you know. At one point, you know, you end up with people thinking that, oh, I can maintain this independently of that part of the View and all that, but it's just never true, and at least it's not true if you want to do a great job at it. One thing I think we don't teach in computer science, schools or in the industry, really. One thing I don't think about, are we teach in school or in the industry?

In computer science is what we do teach how you should modularize code- right, you should. How you should encapsulate code and, and split things apart so that they are easier to iterate on. But we never teach someone to centralize code, to properly recognize that this is a problem that is centralized by nature, and that you're not supposed to try to divide this into smaller pieces, because if you do, you're going to succeed and it's going to be even worse because the centralization nature still exists, but you just pretend you don't see it anymore, right?

Yeah, I see people like, divide these code into two pieces and like I, ultimately they're like, wow, you can work on on only this file. But then what the truth is- and people know that it's the truth- that you just end up jumping between file and file and, oops, at that point, like this part ends up being used by another call sign and it calcifies forever because you can no longer change it. Yeah, it's a big tension between what is academically the right thing to do versus practical knowledge. I do find that you know every discipline. When you talk to someone, they always talk about the same thing.

It's like what they learn formally and what is being done in the real world often don't fully match up. Maybe because I'm so close to the space, working with computers and also having gotten a computer science degree, I find that the feedback loops never quite get closed in computer science.

I still feel like today, even now, people are being taught patterns and ways of doing things that are completely decoupled from reality, especially when you start thinking about how do you scale an app Beyond just a particular class project or something that's just being done, work done by me and my college roommate or something to a group of teams- distributed time zones, different languages and all these things. How do you maintain coding standards and proper ways of engineering practices?

That just cannot work if you apply an academic lens to it, or sometimes you just have to be in situation where sub-optimal Solutions are the right thing to do for the long run.

Well, it's like a greedy algorithm, right, so sometimes it does work out and people refuse to acknowledge it, but the greedy algorithm absolutely is approvably one of the best way to do things in many cases, right, especially, when you're confronting, like, unknown information in the future and all that. Right, Academia work a little bit differently and like the end goal is a bit different. Like I remember to be found. This is true in the current industry as well. Like but they will make an app and somehow the entire tutorial or the entire class.

There was not a single screenshot of what the app looks like, right, Steve John famously said you got to go from the product back to the technology, right? You know, I and I've been in the react community and it's a little bit worrisome for me to see that all these new tutorials, all media, more on the on their blog or whatever, they can show an entire coding pattern. Right, they can show an entire coding pattern and not show a single screenshot. Like the there's no discussion of whether the button should be placed here and there for them.

It's almost like a different discipline and that there's like a real cut there and it's. It's pretty uncomfortable to see actually, because, because, because you get started getting this alignment of agreed, because the end result is you're building for other people, you're building for human beings and humans are visual creatures. If your final output is going to be something visual, I would expect the first thing to be emphasized greatly would be the final user experience. What is the initial State look like where the transitions when you hover over something? What are the when you navigate from? What are the error States, things like that.

I think more formal applications tend to do a pretty good job with this kind of stuff, but most people are learning. That's the point when they need to be introduced to best practices, not much later on. But I want you to learn things the wrong way. It's very, very hard to retrain and unlearn something unless you have a strong motive for it, which, as we've seen, the motors are never strong enough, no matter how many incentives go to people to do the right thing.

We can see that with chrome and their Cobra vitals and trying to index search Pages higher rank, give them higher ranks based on performance, and so on. That, I think, is one step in the right direction, but we need to go even more fundamentally. That's part of you building it. If your mental model is, I'm going to just do an npm package, install that's going to add like 200 megabytes and off that, maybe 10 of it will actually be shipped to the user itself. It doesn't developer time dependency, it's actually a runtime dependency.

Those are things that are going to become Accord to how you think the default World behaves, because you're gonna be like that's how you've always done it. I'm not going to bother changing, and that's the hard part. I don't know how to encourage good practices when at the very beginning, because it's not easy, nor is it fun sometimes. Well, [Music], yeah,. There are several things I want to talk about regarding this. And you're right, like just because it's you can, just because you can Deadpool, eliminate doesn't mean working. It works in your mind. Right, like I go into a fight, I can definitely eliminate my mind.

Like I just see the entire freaking file. I want to debug the thing. I can't really do that either. And so, like I think that's very people who dragging too much and then say, oh, we're just using that and tree shaking will take care of rest, like I think that's overly naive. That's like a very small subset of what I care about. Right, I need to be able to read the code and like and, but the thing you Dragged In, like it does 10 things, and like also that version, like this button, all these kind of concerns that you're you're not putting into your a theoretical model, right?

Well, one problem we have- maybe maybe we can be a little bit more specific about this, because I don't want to sound like someone who who rehashed these argument that I'm sure, like people have heard lots of time. One real problem is: it seems to me that lots of- this is not something beginners, this is, and this is not something that lots of senior programs do. It's the Belk, the middle of the bell curve. The people who became are becoming good programmers, but not yet they do, which is they have this extreme tendency to compress things, to prematurely compress things.

If you model your, let's say your- knowledge of your code, like as you write as like a just, let's just say a stream of things, right, they will compress the first few bits, see the next few bit, compress the internet, and then it kind of calcifies your compression algorithm, right, because you're not seeing the holistic picture. Like, you're not supposed to prematurely compress that early on, right? Like lots of these abstractions- I would say like maybe 95 of these abstractions- they're not actually abstractions, they're just, like pretty poor encoders, yeah, and that is actually still okay. But the thing is, we have not learned how to decode in the industry.

Like if you have a and b and then you encode it a certain way and C comes in, and if if there was no encoding at all, then you would have encoded ABC differently than if you just have a, b and then plus a c appended to it, right, and so what's the right thing to do when C comes in is for someone to do the Pretty brutal work to go into that: decode first, right, and then re-encode, right, no, but. But nobody will do that in a typical code base, right, because obviously in the industry this is just way too much trouble.

So the only thing you can do is just to delay that encoding as much as possible through Simplicity, through like performs by by default and not trying to reach for some weird patterns, and all that through. Ultimately, the only thing you can rely on is through low entropy, which is, you do exactly the thing you do, right, with no decoding, with no premature encoding snaps, right, so to speak, compression, by encoding I just in case we lost the track of thought here. But by encoding I mean compression.

I meant, abstractions and all that right, excessive reuse of, like two lines of code, for example, and so the only way we can do that right now is to just delay that so that some way in the future, hopefully, they're smart enough to know when they need to actually start compressing things. Right, because the moment they do it, you can trust nobody else is going to go and redo it, unless there's a rewrite, unless some Engineers first go into that path. But that's not really aligned to anyone's performance reviews.

So to speak, when you say I've been decompressing someone else's abstraction, I've been in line in things, but we know it's the necessary thing to do, right, it's just nobody's going to do that on a larger scale. So what, what can we do about this? Well, I don't know. Like, maybe we do need some kind of automatic cooling, maybe we need some kind of language Paradigm that that does that for you, but maybe we need something that is, well, you know, like AI is a hot.

I don't want to dive into that too much right now, but like, you know, the more you're looking to react for real, as like an engineer, not as like a philosopher or kind of like a user, but as an engineer, you realize. Well, essentially it's about compression, right, it's about search in a multi-dimensional state space and going to the lower entropy position as much as possible. Like the whole purpose of back, back prop is kind of bad, right.

And, I sought a very good blog post, recently where they train a neural network to do just binary Edition and see if it converges toward like a binary adder in a in a CPU. Turns out, no, it converges towards something that exists before and then that that was designed by human actually. So, they turned an analog signal into the digital ones and do obviously these songs of transformation and then you, then you know it clicks for you that that they are able to reach that low state of entropy and the good thing is, when you retrain them, basically it's a natural decompression and recompression, right.

So, unfortunately, in our current industry. The only usage to control the entropy- which will be a great tool to teach newcomer- is cyclomatic complexity, which is not much. Nobody really uses it, right, everybody knows well if you have too many, if it if else is, you should do something about it. But the same thing is cyclomatic complexity doesn't understand your code. It doesn't know that it needs actual 10 ifs, right, it just says that's too much, please, please, break it off. And all the people I've seen who use that tool, actually they just break five of the if into a different function and then it calls it a day.

But then now I have an extra layer of indirection and the actual complexity that I have to read again, right, so yeah, I just maybe where you reach the most we can do, with a human in the loop, with that kind of traditional coding mechanism and that traditional theory, stem from math, of composing these kind of abstraction and then scaling them up. I don't know, but, Andre capati has a good blog post about a very comfortable blog post about software 2.0, where one of the point is that it actually scales down and not homogeneously, and it gets to redo the entire thing.

But we do not currently in the industry have the financial incentive to hire developer to undo the previous developers- so-called abstraction- in order for the next developer to redo it. Because what? What is? You know? What is my incentive here? Right?

Getting back to what you talked about, let's tie it to the gallery example you showed. There are a lot of subtle details in it that are done really well. On the surface I see a grid of images. As I scroll up and down, the content loads as needed, so it's not a case where the entire DOM is being flooded with useless elements. It's virtualization done really well. Then there's the hover behavior. When I move my mouse over an image, there's this slight magnetic drag effect. It's not just a normal hover state. It tilts a little, shifts a little, almost like my hand is sticky and I'm nudging it along.

That's very nicely done too. And then when I click an image, it takes over the viewport in a way where I can still see just enough of the previous and next images to keep moving around. That sense of orientation is there. You mentioned that you asked people how many lines of code they thought all this took, but I don't think you ever answered it. How many lines of code did it actually take to create all of these effects?

So it's a single HTML file with no comp compilation, built for the iteration speed. Yeah, and people, my complaints not in typescript, but look, I've done a programming language before statically typed and I dare I say it was the Touch system was pretty good, right, I think Studio camo folks and all that we've worked that off from them, but no, the iteration speed is just that much more important than yeah. Sure, we'll add typescript once it becomes like a real project. I'm sorry, the girl dog is yeah, so how many? How many lines was it?

Yeah, so if you exclude the data, which can be arbitrary large because you can imagine lines, right, that's all in line. But excluding data is around 400 to 100- 450 lines of code. No dependency at all, including the styling, and no weird tricks where I put like, where I try to Minify manually or something like that, right, I didn't use a prettifier, I didn't use, sorry, I didn't use prettier on it or whatever, but it would be 400, 450 lines of code.

No, it's very impressive, because the thing that got us started on this conversation in many ways was, I believe, someone sharing the latest Netflix UI and what it looked like. I made the offhand comment that this kind of UI is very difficult to build on the web, and you replied that it is difficult, but you can pull it off if you rethink how you approach the problem. Then you gave this example. So I was really impressed, because until then I hadn't seen anything quite like this done at the scale you had it.

People have used WebGL and a lot of other techniques over the years to mimic these kinds of experiences. But in terms of something I could look at, understand from the source, and maybe even try to build myself someday, yours was the first one where I thought, this is really nicely done, logical, clever, not ten thousand lines of code, not WebAssembly, none of that. It's just straightforward HTML, CSS, and JavaScript modifying the DOM.

I just want to say that folks like you, Mr. Colin Moock, and actually a guy called Tony Puff, with the tile-based tutorial and all that, helped a lot in my formative years. I wanted to say that before diving into the explanation. I don't think I would've been able to make something like this without that. I'm quite proud of it, even though it's just 450 lines of code. First, some people who know how this works might have a few criticisms. They'll say, look, this is a mostly homogeneous kind of app, there's not much text, and it's not very webby. I was like, come on, it's webby enough.

I didn't even reach for GL, like you said, right? I always tell them that, if I ever have time, I actually have a demo that a few people have already seen. That demo is more text-based, and hopefully the proof of the pudding is in the eating. You can see that it is also quite a few lines of code, like a full-blown web app, and not just a single gallery with some local maximum or anything people think it is. So one of my goals was to use idiomatic web technology, not that I think idiomatic web technology is the end goal of anything.

It's not that I think idiomatic web technology is the end goal of anything, but it's the most swallowable thing for people. If you're doing GL, people will just say, oh, well, it's GL, so obviously all bets are off. They don't know what that means; they just use that excuse. No, I'm doing it with idiomatic web technology. There's no canvas involved, there's no GL involved; it's all traditional web APIs. That's one thing I care about very much. The other thing is that performance and the UX have to be good, because I don't want people to dismiss it by saying, like I said earlier, oh, well, I don't want these animations anyway.

No, this animation actually helps establish where you are in the gallery, as opposed to many other galleries. You press the arrow key a little too much and you're like, where am I? When you dismiss it, you're wondering, where is the image in my gallery? When you dismiss it after going very far, it moves back into the place it should be, wherever that image zoomed out to. So you asked about that mouse hover. Design-wise, from a UX standpoint, the thought process is that I want to indicate to people that it's clickable.

Most people know it's clickable, but it would be nice because people move their mouse across the screen, and then it suddenly starts moving toward them. They're like, oh, I guess I can click on this because it's inviting me to click on it. It's not like a typical Flash trick, either. But actually, the thought process was the other way around. It goes a little deeper than that, and I'm very happy you asked this question. Not many people ask that particular thing. I didn't start with the UX in mind. You should absolutely start with the UX in mind, but my goal was entirely different when I was making that gallery.

The hover effect—and you've been coding for a long time, so you know what I'm talking about—isn't accomplishable as a discrete, one-off effect in pure CSS. It's not like I hover and it goes 10 pixels above, and then when I hover out it goes below. That can be encoded as an animation, like a CSS thing. I wanted to avoid that because I don't want people to reach for these very strict local maxima. The other thing is that, because I have to change the image all the time, I'm forcing my code not to prematurely optimize toward that particular direction I mentioned earlier, such as static extraction of things.

I started with the code and none of the visuals—again, not recommended for real apps. I thought about these React patterns, Vue. Js, Backbone, jQuery patterns, and all that. I tried to find the patterns that socially, not technically, over the last 10 to 15 years have pushed people toward bad code: the kind of code that seems good in the short term, but isn't really. One would be, oh, let's have this nice little constrained environment, but it's just a button. I have these CSS declarations, but then a designer comes along and tries to adjust a single pixel, and you have to switch the entire paradigm.

Most of the time, this doesn't even happen. You wouldn't switch; you would just tell them off because we can't have that effect, because that's not how our Sass pipeline was built or anything like that. For example, you see CSS tools that statically extract their snippets or parts of them. I don't want any of that. So I basically show the good UX. I try really hard to find a good UX that goes against all these existing frameworks. To echo what you said about how we can start fixing this, it's by showing this kind of UX and saying, well, do you want this or not?

It is good; it is a mature transition. I'm not trying to show off, it's not disruptive, and the user definitely feels the impact. Do you want this or not? If so, you cannot use this or that paradigm. You cannot even virtually diff the whole thing, because this is a core proposition of React. I worked on React and I love it, but I think people are too religious about this, including the virtual DOM diffing part. You have a list of items, like in the gallery, and you render them into a virtual DOM. The virtual DOM diffs the previous and current snapshots and asks: did it change? Yes, yes, no, yes.

Okay, that's three yeses. So we only need to surgically manipulate these three things. But people aren't thinking in terms of latency. I came from a Flash and graphics background, so I think in terms of latency: what is the worst-case behavior? Well, all six items change. What is the virtual DOM doing there? Nothing, because ultimately it goes over all six items: did it change? Yes, yes, yes, yes, yes, yes. Then you have to change the entire thing anyway. Let's say your frame takes 15 milliseconds. You barely crammed it into 15 milliseconds at 60 frames per second.

The virtual DOM made that 15 milliseconds in the best-case scenario into 2 milliseconds, which is great. But in the worst case, when things do change, it turned that 15 milliseconds into 17, and now you're starting to drop frames. How do I fix that? I have to remove the virtual DOM diffing. But there's no way to convey that anymore. When I say it, people are like, ah, whatever. So that entire gallery, the previous demo, the next demo, and the upcoming demo, which is a more traditional web app, all reach for user experiences that developers would say are good to have.

At the same time, they would say, I guess we really can't afford these caching strategies, golden-path-driven, throughput-driven, back-end programming strategies. I would say that's because the back end is much more about throughput than latency most of the time. This started with my graphics perspective, because for me, a frame drop is a bug. For most people now, a frame drop is a P4 or P5, or whatever your company calls it, which means we're never going to fix it. It's part of the web; obviously you're going to drop frames. But no, it doesn't have to be that way.

If you coded the worst case already, you don't have to debug nearly as much or do performance tuning. I barely opened the performance profiler for this thing. Most people don't use the performance profiler, but if you want to achieve that kind of result, you usually have to profile a lot. I barely use it because every time, I'm just wiping that virtualized region and redrawing these cells. I know the worst case will still fit within 16 milliseconds, and on a MacBook Pro M1 or M2, it will be 120 frames per second, except Safari, which caps requestAnimationFrame at 60, but that's another story.

People will say, well, most of the time you're not reaching for this kind of interaction. That's why I add even more interactions like that. When you click into the gallery, the whole 2D grid flies into a 1D one. When they fly like that, everything changes all the time. When you drag your native scrollbar—because I didn't recreate a scrollbar—very quickly with, let's say, 10 000 images, there is no incrementalism in that process that you can leverage. There's no cache; all your caches are bust frame by frame, all the time. The next time you drag, the entire region is very likely redrawn, so there's no reuse you can reach for.

I thought about these things, but I don't have to code them anymore because I already captured the worst-case scenario. If everything changed, it's the same as if nothing changed for me. That's part of why that hover is there. Maybe a designer will come and say, well, actually, in the future, maybe the neighboring images will also move toward you. If it's not too disturbing, then I don't have to code especially for it. You don't have to say no to the designer because you use a CSS pipeline that's far too rigid for this extra incremental UX change, which would require a huge delta of code and architectural change.

So it works like that. It's like a game engine, but with a web render loop. You blow away lots of things and optimize against the upper bound, the worst-case scenario. What optimizations actually work? In this case, like you said, virtualization, which is just occlusion culling if we're speaking normally. I'm not sure why we call it virtualization nowadays; there's nothing virtual in that demo. Then it's also about making the data structure very fast and lean. If you look at the code, when there are loops, I don't even use a break statement. That's because it's so ingrained in us that if you break early, you save some CPU budget.

But in many cases, if you break early, you end up with a pathological case where some other effect or code claims that performance resource. When you do need to iterate through all of them—let's say because it's the last image—people don't think about that. Some process makes you iterate through the entire area while your user is hovering over the last one. Then suddenly you've exceeded your frame budget. So I don't break. Hovering over the first image has the exact same hit-testing, zooming, or whatever logic as hovering over the last one. I don't have to scroll down all the time and test against my last image, either.

People will say, wow, that's a different mental model. Is it hard to learn? It is something to learn, but the code actually becomes simpler because I have very few if statements. What kills latency and causes frame drops and inconsistencies are the if statements, fundamentally. That's where your control flow goes into that path instead of the other one. That's what causes frame drops. When I don't have if statements, my code becomes simpler because I have nothing to debug. It's linear. I don't have to step into a debugger and ask, well, is that condition true or not?

The only if statements I have are the essential ones, like: is it in 1D view or 2D view? Now we circle back to the initial topic, graphics and all that. These are graphics programming techniques, like GPU and shader programming techniques, because when you have an order of magnitude more pixels, you don't get to ask, well, is this pixel that, or that pixel this? Forget about it. You'll be able to draw 10 pixels and never have a game. When you have a million or a billion pixels, you start thinking differently. No more if statements; latency matters a lot, and throughput looks different.

The whole gallery is actually shader programming technique in idiomatic JavaScript and HTML. That's all. However, first I want to thank you again, and all the other people who helped me on the Kirupa forums and other forums. I still remember some of them. I might not remember the names too clearly anymore, but there were definitely experts who helped shape my thoughts along the way. I still remember this person who made that crazy 3D demo in Flash with all these polygons. He made a dinosaur and then made it like a glider, and it was pushing millions of polygons on my terrible laptop back then, which was like 20 years old.

Once someone shows you that order-of-magnitude change, it gives you these emerging phenomena. I was drawing triangles, but I was drawing 10 of them. If you're drawing 10, you can't think of making a dinosaur model with them. But he did that, and it was crazy to me. And you know what? The web, our neighboring community, started drawing triangles too, and they drew lots of them. They drew enough that they discovered this new GPU thing, and that GPU thing spawned the entire ML domain, which has nothing to do with drawing triangles. So one thing I would ask is: what are we missing out on by drawing tens of rectangles?

When I used to be in a programming-language community, there was a conversation where I said, okay, you play Call of Duty; you realize they're drawing billions of triangles in real time, and you're telling me you cannot render 10 rectangles in your web app. Really? What are we talking about here? So what if we can render a billion rectangles? What would that look like? It wouldn't even be a web app anymore, but it could certainly be something worthwhile. There are emerging phenomena there that we never got to discover because our stack has been so calcified.

One last thing: many years ago there was a Chinese Flash forum called Flash Empire, where the admin made the entire forum in Flash. The forum itself was using PHP or ASP; I forget. It was just black and white or whatever; it doesn't matter. But he made an entire forum in Flash, and I could never find it again. I tried for days and hours to find it. If anybody listening knows what I'm talking about—Flash Empire—they made an entire forum with just Flash. I thought it would be such a nice point to prove that this entire software was doable, had all the interactivity, and wasn't expensive to make.

I'll personally keep making these demos too, and show the coding public. But if someone knows how to find it, I'd love to see it again.

Oh, I'll dig around as well. I do remember what you're talking about. I know exactly what you're referring to as well. Wow, because there weren't too many examples. ColdFusion was great for being able to do a lot of back-end things, and the ColdFusion and Flash integration was done really well. There are a bunch of studies on some great examples of Flash and ColdFusion being combined. I do remember a website that was entirely in Chinese. It was like other sites in what it showed, just with a different character set. I couldn't make sense of it, but there was a familiarity.

I remember a forum that was entirely Flash, because when you right-clicked, it was all Flash. It had niceties because scrolling wasn't smooth in our browsers back then; it moved in pixel increments. It wasn't like today, where scrolling has acceleration and so on. That site was new because it introduced a lot of these things to a very traditional, boring problem, which is displaying thread messages. So I'll keep a lookout for that. In the interim, though, it was great chatting with you, Cheng.

This was a lot of fun, and some of the topics you mentioned are very near and dear to things I think about a lot, and I think many audience members think about quite a bit as well. At some point, we need to dive deeper into some of them in the future. I'm looking forward to seeing some of your new examples as well.

I'll be happy to talk about this too. Thank you very much for the opportunity.