I set out to see how far the web can go toward feeling native. Here’s what I found while building a PWA demo that might just make a full rewrite unnecessary.
1) I thought of giving an easier to read example. I just moved the example to react, so the snippets actually match exactly what's going on in the background.
2) It is true! Though, using shadows on the optimized code doesn't slow it down. I added more toggles to test same effects on transform and top/left implementations.
3) I think it's still interesting to start with some thought and then observe that in practice things are different really. In fact, thanks for all the feedback, as it made me go back and do more investigation.
If you don't mind you can give the article a second look now :)
Thanks for the input! Indeed, the reflows were incredibly fast because I was using position: absolute, which meant the squares were not affecting anything else in the dom, but just their position (so cheap operation). I will add a note on the article on that... also I am improving the 'bad' example so the shuffle button triggers reflow in a significant way.
How do we even see anything on a browser?
How do pixels turn into shapes, color, and movement?
Every time we scroll, hover, or trigger an animation, the browser goes through a whole routine. It calculates styles, figures out layout, paints pixels, and puts everything together on screen. All of that happens in just a few milliseconds.
It’s kind of wild how much is happening behind what feels instant. And the way we write code can make that process either smooth and fluid or heavy and janky.
I wrote an article that walks through this step by step, with a small demo showing exactly how these browser processes work and how a few CSS choices can make a big difference.
A lot of these don’t happen on scroll and hover under normal circumstances. For example smooth scrolling on touchscreens is implemented by only re-running the compositor on each frame, and using the existing GPU-resident bitmap of the text being scrolled. That’s why non-passive onscroll callbacks make scrolling suck, especially on mobile.
What's not stated, is that we used to re-render the text at the bottom each time you scrolled up, and could still do it pretty fast (not quite in 16.67 milliseconds but we could have if computers had been today's speed), and in the meantime, we seem to have forgotten how to do that. Although we also have more pixels now, which probably changes things.
> we used to re-render the text at the bottom each time you scrolled up, and could still do it pretty fast
If you go back far enough, the IBM graphics cards used a text mode where text was accelerated by the graphics card, software would write a attribute byte and a data byte and the card had a bitmapped font to render text. VGA text mode at least could use hardware windowing so scrolling could also be accelerated; not every system used it, but you can set the start address and a line number where it returns to the start of the data area. That makes it easy to scroll without having to rewrite the screen buffer all at once. (If you set the stride to something that evenly divides the screen buffer and is at least as wide as your lines, it makes things even easier)
I think that many projects use wrong architecture, when it's a possibility for business code to block animations.
IMO all the "user" code must run in a dedicated thread, completely decoupled from the rendering loop. This code can publish changes to a scene tree, performing changes, starting animations, and so on, but these changes ultimately are asynchronous. You want to delete an element from a webpage, but it'll not be deleted at this JS line, it'll be deleted at the next frame, or may be after that, if rendering thread is a bit busy right now.
Animations must stay fluid and UI must react to the user input instantly. FPS must not drop.
Browser does it wrong. Android GUI API does it wrong. World of Warcraft addons do it wrong.
Which begs the question - if all of these projects got it "wrong", what's the chance that the "right" thing isn't right at all?
All animation is inherently discrete. No matter how many threads you have, there always has to be the last rendering thread, the thing that actually prepares the calls to the rendering backend. It always has to have frames, and in every frame, in the timestamp T, it will be interested in getting the world state in the timestamp T. So, the things that work on the world state - they have to prepare it as it was in T, not earlier, not later. You cannot completely decouple it.
In one of game projects that I worked on, a physics thread and a game thread actually were pretty decoupled, and what the game thread did was extrapolating the world state from the information provided by physics, because it knew not only the positions of physics objects, but also their velocities. Can we make every web developer to set velocities to the HTML elements explicitly? Probably not.
This has been tried, even in the browser. It just leads to buttons that do nothing when clicked, scrolling to unpopulated areas, infinite loading animations and other such artifacts.
It does not help, you have smooth animations but you feel you're disconnected from the program and trust it less. The UI code just needs to not take much time and offload background stuff to another thread, but not the UI logic itself. It also naturally synchronizes events.
And sometimes it's better to briefly block UI thread as the alternatives lead to worse user experience.
I still feel these issues could be solved one by one.
Button click will automatically disable it, until its handler executed. There could be creative animations translating this state to the user in an intuitive way, so the button does not feel stuck and does not feel doing nothing.
Scroll widget should require some placeholder graphics which will be displayed until loading handler executed and replaced this placeholder with real data. A lot of apps already do exactly that.
That's basically what React Native does/did and it's generally good but turns into a nightmare when you need to synchronize interactions between the two threads. 16ms is a long time - if your UI manipulations eat up most of that time then there's something wrong. Entire video games can run basically on one thread within that time and they do way more.
16ms is not a long time, when interpreted languages like Lua are used.
16ms is not a long time, when GC can suddenly kick in and stop the thread for unspecified amount of time.
16ms is not a long time, when JIT can suddenly kick in and stop the thread for unspecified amount of time.
GC and JIT are good techniques for server-style throughput workloads, when infrequent delays are not noticeable. For GUI, infrequent delays lead to skipped frames and stuttering.
I don't think that it's reasonable to ask the world to develop GUI apps in C or Rust. Probably Swift is a good middle point between usability and predictable performance. But most GUI projects use slow languages and/or languages with GC.
I disagree. Yes, it's less time vs. C but still a long time.
There are plenty of games built with Lua that run very well such as Balatro and Don't Starve. And games are far more sensitive to hitches than GUI projects because they are constantly animating. Your users will not only easily see lag - it can ruin the game for them.
If a basic GUI is performing poorly then the blame almost certainly lies on whoever developed it. Don't blame the language or runtime.
Multithreading in the browser kinda sucks though, it's too slow to share significant data between workers (threads), and if you try it with SharedArrayBuffer you eat the serialisation costs.
Not really something anyone can change at this point, given that the entire web API presumes an execution model where everything logically happens on the main thread (and code can and does expect to observe those state changes synchronously).
Some thoughts I had, after reading too many times how devs go against x or y framework and how they would build things more simply with just html and javascript.. delusional at best
Hi, my name is Lu, and I miserably tried to make a chess.com clone.
I wanted to explore svelte a bit, and thought of an AmAzInG use case for it. I said to myself: I am going to build a chess board so I can play with some of the svelte features.. not quite. Of course, it turns out that there is a lot of board logic and not much svelte magic lol.
Anyways, I spent a fair amount of time on it, so I thought of sharing to give it some justice.. If someone is a decent player, did I implement the rules well?
It does quite a but. It checks that the move is legal, checks and checkmate, promotion (why can I click the X and not promote?), en passant, I forgot to check castling.
Is it possible to add "sandbox" mode to make a arbitrary board instead of playing a game?
The nice touch is that you can set a maxWidth for the swiping to kick in, giving the app a very native feel on mobile devices.
Give it a go and let me know what you think!