This new API makes your websites way faster

[@t3dotgg]

THANK YOU UNKEY FOR SPONSORING CHECK THEM OUT AT UNKEY.COM

[@james-perkins]

Happy to sponsor you and the team! Thanks for one hell of an ad for our first ever sponsor.

[@AlecMaly]

I understand the need to put ads in videos. I got slight tomatoanus vibes from your ad, lol. Nice. 👌

[@bzbetty1]

you should publish a centralised list of all the services you've advertised to find later.

[@arpitdalal_dev]

This will create more University and job interview questions of "in which order does these print?"

[@wlockuz4467]

Oh my god

[@Crates-Media]

After over two decades in this field, my jaded and fed-up answer to the next guy asking this question is concise: "We'll never know, because I've queued up an entire box of paper for intimate coupons I'm giving to your mother."

[@dumboluzz]

When the frontend framework is so inefficient the browser needs to implement cooperative scheduling for JS LMAO

[@DEVDerr]

React cope here is just on another level

[@fauge7]

While I agree with the sentiment that JavaScript is a dumpster fire for performance, the reality is, computers and more specifically phones are fast enough to overcome the performance differences compared to when it originally was created in 2013

[@zBrain0]

​@fauge7 It's not necessarily JavaScript that is inefficient, but specifically react. Because it will re-render an entire tree of components, because something minor changed. You have these horrible render loops, but more modern Frameworks don't necessarily have this problem. Svelte is much more surgical only updating the exact element that needs to be updated. People keep using React because it's what they know and there are a ton of tools out there that make building a React app easy because you can grab many things off the shelf but the reality is We are seeing update after update of people trying to fix problems in react that are ultimately fundamental to the framework and eventually you just need to start using a better tool.

[@diadetediotedio6918]

Well, technically speaking async/await already is cooperative scheduling

[@dumboluzz]

@@diadetediotedio6918 Yeah JS is inherently that way because of the event loop. But in this case it's a bit different because we are not interrupting because we need to wait on something, but because we don't want to hog the single thread for too long. It just highlights the difference in how we use JS today and how it was designed a while ago.

[@keithjohnson6510]

Maybe an even easier way to describe it, "scheduler.yield" allows interaction events to continue mid draining the macrotask queue. SetTimeout on the other hand requires the full macrotask queue to drain first. Basically the new feature feels like in say windows event loop on long running tasks, you could do the good old single "PeekMessage" / "TranslateMessage" / "DispatchMessage", to basically do out of flow event loop processing. Delphi had the "Application.ProcessMessages" to do the same thing, this was common practise to say show a progress dialog on a none threaded long task preventing GU lockups.

[@audiocorps2334]

Am I interpreting correctly? What you're saying is that setTimeout will wait for all running tasks in main thread to finish before working on any the scheduled task(s). Then we have yielding which allows jumping from the current task mid-execution in the main thread to popping out a scheduled task into the main thread, executing it, then returning to the mid-execution task?

[@RoyaltyInTraining.]

I thought we left cooperative multitasking behind in the 90s... Really, this new API just brings the inadequacy of browser design to light. People keep saying that modern browsers have become small operating systems, so why not take that literally? Give browsers proper threads, so you can have one that does the rendering while another handles input. And while we're at it, we might as well make WebAssembly the standard for that new concurrency model, so that can finally gain the traction it needs.

[@RandomGeometryDashStuff]

> Give browsers proper threads, so you can have one that does the rendering while another handles input. firefox and chromium already something similar: go to web page with scrollbar, run `for(;;);`, try to scroll

[@Z4KIUS]

the rendering is handled separately, but the script causing render to re-happen isn't separating that may be quite hard

[@RandomGeometryDashStuff]

rendering already happens on separate thread, scrolling works on web pages with infinite loop

[@theairaccumulator7144]

yes, the rendering is multithreaded and gpu accelerated, react however with It's virtual dom and lots of other overhead isn't

[@itsmenatika]

Web pages already do take too much resources (especially ram), especially on simple pages

[@ccccjjjjeeee]

these ad reads have been beautiful

[@developer_deepak_bhattarai]

The ads man , they look entertaining

[@roelhemerik5715]

also funny to see how Theo is still a bit awkward with it, but quickly gets better in presenting them.

[@shubitoxX]

Hello coroutines: Coroutines are computer program components that allow execution to be suspended and resumed, generalizing subroutines for cooperative multitasking. Coroutines are well-suited for implementing familiar program components such as cooperative tasks, exceptions, event loops, iterators, infinite lists and pipes.

[@yudistiraashadi6643]

Lydia's video is the best at explaining the event loop because she shows animation and explain so clearly. Her other videos are also very good to watch

[@BrentMalice]

i understood several of these words.

[@Cuca-hn3md]

Its very simple if u understand what an event loop is, in very very simple terms is a loop of queues that execute tasks by order, when a task/async/promise is not done yet it push the task back again in the queue and moves to the next task. With this new Scheduler.yield API instead of pushing the task on the back of this queue will put on the front, so the next run of the loop, your async function's chunk will be executed first. (it loses purpose if u use it too much) In a async function the "await" keyword yields the execution, which means that everything inside the function before the "await" keyword will be executed on the first run of the loop, and everything after the "await" keyword will be executed on the next run of the loop, putting back on the queue. This way you execute ur function in chunks, thats how u can executing things almost at the same time. If u want things to be real parallel, then u must use system's threads, and u can yield on those threads too, releasing cpu time to other tasks.

[@BrentMalice]

@@Cuca-hn3md that is a lot better explanation lmao ty

[@echobucket]

LOL Theo been in React land so long he doesn't remember how to use setTimeout. That made me chuckle.

[@zwanz0r]

14:40 Ryan Carniato with the awesome additional remarks about queueMicrotask and setTimeout with zero. What a legend! ❤

[@fmkoba]

I understand that losing vercel support was bad, but I actually enjoy watching your sponsored sections, congrats

[@the-avid-engineer]

async/await/Task.Yield is probably the greatest feature C# ever made.. love to see it being adopted in other languages

[@abates3747]

Omg, it's not just react, but anything doing a threading style process. And you could already do a yield by just awaiting a timeout call.

[@redditrepo473]

I feel the same way about React that Theo feels about Golang (and vice versa, for that matter); I hate programming in it, but the technology is super interesting on a conceptual level

[@jarrodhroberson]

this is just “cooperative multitasking” this is how we programmed the Amiga in 1985

[@brunoais]

8:51: Reads like a band aid to a problem that should have never existed in the first place...

[@markg5891]

Your naming of the "call stack" is confusing. Usually you have a call stack when your code breaks in a breakpoint. What you mean is the "main thread" or "UI thread", calling it "call stack" means you have no clue what it is as that is just plain wrong. The eventloop runs in each of your threads (well.. up for debate but not to go too deep, assume each thread has it's own eventloop). An eventloop can have a queue but that isn't required for the conceptional working. In general they have a queue though. If you have a big task running and your effect is "hey, nothing works in the browser" then you're blocking the main thread from "processing events". That's the affect of having a while(true){} running on your main/ui thread. The yield thing is just a call that you can run in your heavy task to keep the process - your browser in this case - responding. It's just a call that tells the eventloop on the ui thread to "hey, you can have a slice of time, do your thing then i continue". If you have to use yield then you SHOULD instead run your task in another thread. And if you have a need for threads then you SHOULD get your ass out of a browser, say farewell to javascript, and write a normal desktop application in a normal programming language (c/c++/rust/go).

[@theairaccumulator7144]

It's well known that he doesn't know anything he's talking about

[@keithjohnson6510]

"programming language (c/c++/rust/go)" , yeah, that's don't work too well on the browser, even if you compile to WASM. If you need a really long process that blocks in JS, you use a WebWorker. Yield is not just a JS thing, windows App's have been doing this for years, PEEK/POST/DISPATCH(Message) for GUI updates in blocking code without requiring threads.

[@jacmkno5019]

Wow, this yield new feature is great!

[@saorlandini0]

Oh wait! You are doing the full-blown sketch approach for sponsors! I can't wait.

[@IceQub3]

This is feature is "await". Its not a deal breaker for people who are not stuck with the inefficient and bloated thing called react. While colourless async action is nice, its not a deal breaker, its only because react's jsx create synchronous code, that they break. They could by any mean, render a component partially, put everything else in a callback and continue, but it will break the current react API. this yield is a language level fix for a broken library api, which I am not fond of

[@RyanLynch1]

oh boy, time to introduce way more complexity from systems land into JS! i expect more people to start taking OS classes

[@KittenDome]

Lua guy here, I know what yielding is already, but interesting that they're adding it to the browser. As a core function, it's kind of useful, I can see it optimising large frontend frameworks quiet a lot.

[@jameshickman5401]

Wish we lived in the alternate reality where Netscape embedded Lua rather than slapping a C-ish syntax on a Lisp run-time over a drunken weekend.

[@jimiscott]

DoEvents comes to the browser!

[@m12652]

😳

[@unicodefox]

DoEvents and Refresh... shudders.

[@SharunKumar]

VB6 reference? 👀

[@m12652]

@@SharunKumar VBA 😳

[@SharunKumar]

@@m12652 yeah I guess it's basically the same thing

[@Benjamin-Chavez]

Dude the add was fuckin awesome! I was just listening to your vid and legit couldn’t help but to walk over to my phone to watch it!

[@skeleton_craftGaming]

Is Google doing a Microsoft here [something about EEE]? Is this actually like a web standard that Firefox is going to have to implement to be w3c compliant?

[@codeChuck]

THIS FEATURE IS AMAZING! it frees up so much possibilities! It is like 'stop the world' button. Fun ad plug, not quite get it what the product is still after visiting their site :D Seems like express endoints, but with auth and paid, wut?

[@BackspinZX]

Okay that ad was funny. Well played.

[@codewithmoses]

This is really something I needed to checkout

[@figloalds]

So they worked around React's inefficiency by adding a whole browser "feature" However, not going to lie, just this week I had a situation where sorting a 23k items list was blocking render so I hacked an async "chunked sort" function and called it a day

[@samuelgunter]

this must be working, i got to a boring part of the video, clicked out and did something else for a bit, and now I'm back here to finish the video

[@samuelgunter]

my use of the word "boring" is purely for making the joke work

[@Simon-ir6mq]

seems kinda risky.. if I understand correctly this means that the heap may change in the middle of rendering. So I have state change -> rendering 1 -> state change 2 -> race between finish render 1 and render 2? Or do i misunderstand?

[@jeffreyblack666]

So basically now there are 3 task queues. You have the main task queue, for things like setTimeout. You have the microtask queue, when things get queued with set Microtask. And then between the 2, you have the important queue. So now for the event Loop, it will run through all the microtasks until empty, then all the important tasks until empty, then all the tasks. So when will they add the functionality to queue an important task like queuing a microtask?

[@keithjohnson6510]

No its not another queue, the macrotask queue continues as normal, it's just while it's draining you can `yield`, this does't then continue the main event loop but allows interaction events to process, stopping the UI from locking up. Let's say the main event loop was like -> `while (true) { processEvents() }` , a yield would be like just calling a single `processEvents()` call.

[@jeffreyblack666]

@@keithjohnson6510 This all comes down to how you want to look at it and how it is implemented. You can separate out user events like clicking buttons into a separate queue, or you can try to say everything is all the one queue and you just insert tasks into the correct place.

[@AlexanderMorou]

So it's like VB6's DoEvents? This took twenty plus years to implement? Mind boggling.

[@einargs]

I was literally just telling a friend about why coroutines are subtly different than JavaScript event loop

[@DMZT_dhruv]

I will never ever skip your sponsor clip 😂😉😂😉

[@SteinGauslaaStrindhaug]

I still think React with it's virtual DOM was a mistake, and I don't think this will really fix the performance problems with react. Especially since one of the major issues still is downloading and parsing a mandatory massive js blob that you can't avoid no matter how much you code split and lazy load. Also this is not a revolutionary new thing; as I understand it it's basically just syntax sugar for breaking a long running calculation up into steps and use setTimeout with a delay of 0. Which for sensible vanilla javascript would be something that is a little convenient once in a while; but if you're writing a massive blob like React it's probably practically impossible to split it up manually with setTimeouts.

[@tryitpro674]

Siiick! More non-standard API surfaces.

[@stefankracht]

I like the ads! It says a lot about a company if they don't take themselves too seriously and allow these kinds of ads. If this is what it takes to make this channel work for you, then give me more ads please :D

[@oprio123]

I love this ad sketches, please keep doing them

[@alexbennett5647]

Looking good after the vercel break up. Like the ad spot more than the complexity of that relationship. Also thanks for covering this story.

[@binh1298ify]

honestly I might just start clicking your new videos for the ads read

[@aymenbachiri-yh2hd]

Thanks theo for the video

[@РайанКупер-э4о]

This sounds like webdevs reinventing interrupt request.

[@Pillow_]

oh no i opened the sponsor link because it genuinely looks kinda interesting

[@SilentEdits]

One day Theo will realize that he would love Rust if spent time to learn it. This is basically what Rust has already had for a while.

[@dave_jones]

Firefox is implementing this too, which is sick

[@joshkasap1349]

Lydia Hallie's video is god tier.

[@austincodes]

Going to brush up on my event loop knowledge. BRB

[@anyadatzaklatszjutub]

these new ads are fun

[@rijenkii]

javascript world discovered cooperative multitasking again?

[@0x5D]

Seems like it, yes. Admittedly (and thankfully) this is an API and not a new language syntax like the last two times

[@lastink444]

is it like this with all major JS UI frameworks or this new API was created to fix something in the React??

[@keithjohnson6510]

React's DOM diffing when originally created seemed a good idea, speed didn't seem to be an issue. But as websites have become more complex the flaws of this approach have really become apparent. React brought us JSX and that's been amazing, unfortunately React state & DOM diffing are now a massive mess, and even now having a compiler to help fix it, is absolutely bonkers. If only React had initially gone SoldJS route and seamlessly implement signals for GUI updates, life would be much better in JS land.

[@ChannelSho]

At this point may as well make JS a priority based, pre-emptive, queued, time-sliced runtime language.

[@metadaat5791]

I usually have been doing something like this: function* complex_task() { console.log('doing complex things'); yield; console.log('more complex things'); yield; console.log('take a little break'); yield; console.log('even more complex things'); } let task=complex_task(); let loop=_=>task.next().done||setTimeout(loop,1); loop();

[@jmoo4457]

good informative video thanks Theo!

[@brunoais]

24:30: I can see there's a functionality difference of interest. However, I don't properly perceive how can websites get so bad that you need this to save them. The examples given show bad code design with complete disregard to browser's functionality to make use of its C++ code (E.g. with CSS). I'd like an actual example which doesn't use the Scheduler.yield() as a workaround to bad code design or plain disregard to using browser features.

[@quantum_dongle]

This is fun, I wonder how long it will be until React provides us with a framerate target config option using this API.

[@DM-fw5su]

LOL why did it take the best devs a few years to make this feature? yield() can be implemented as open /dev/null then perform async read for 1 byte, so the blocking read yields. Let the other things run. Then resume read get 0 bytes, close file handle and return control to original task.

[@jamesdavis1239]

Is this basically IRQ's for the browser?

[@SXsoft99]

"was made for the react team" great

[@KyzaMizu]

4:35 SolidJS doesn't have this problem by default.

[@Maxjoker98]

tl;dr: React is so bloated and slow, you can't even load your page on page load, so now Chrome has an API that allows you to yield, so users with non-developer workstations can still load your page without hitting the "this tab is not responding" or whatever message. (only slightly kidding; The new API to yield the browser seems cool, if only useful to horrible and slow applications and maybe some very rare special use cases)

[@srk7kyros]

i wouldnt call myself a programmer as its only an hobby for me (i wrote some react and some solid tho), but wasnt async made to handle the long, blocking task, such as while loops? if i hade a component showing the current time, implying its constantly fetching it from an api using a while block, id probably just make it async? maybe im missing some practical aspect of writing this code, but, from what ive seen which is basically just this video, the scheduler.yield just sounds like a bad solution for a problem that has been solved already…

[@stevefan8283]

Tokio also have yield_now, but this could be in a different context

[@monstercameron]

why not just make the event loop multithreaded in the background?

[@jatiquep5543]

The ads is sweeter than the actual videos 😅😅😅

[@abrudner]

I love when my browser tries to RTOS, not like I don’t get enough of that already.

[@jarrodhroberson]

rediscovering how we wrote programs in the 1980s. Cooperative Multitasking

[@wiktorchojnacki9746]

INP stands for Interaction to Next Paint of course 0:07😉

[@bagofmanytricks]

Reminds of yield for threads in C++

[@chantastic]

i'm cracking up that those stickers are still on your mics

[@besknighter]

JS is slowly becoming Unity's EventLoop.

[@uchennaofoma4624]

Could this help effect-ts?

[@ndykman_pdx]

I honestly feel bad for developers trying to do app like things in the whole web ecosystem. You haven't had features available to desktop application frameworks for more than ten plus years (in some cases, thirty). Seriously, React is really clever because it has to be. And that whole metaphor that the UI is a function of the state? Change the app, just(!?) change the state. That's not an app, that's a report. Nobody makes a new text editor and when it displays text goes: "Well, that's the hard part done, the rest is just changing a string". I honestly do not understand why web developers are so allergic to MVC and it's derivations. They've only been used effectively for 40 years now.

[@chakritlikitkhajorn8730]

The whole UI is function of state is is how word processing app was made. The document rendering is a function of file format (.docx, for example) and the Word itself. If that is not the case then you can't have consistent output opening same file in different machines. That is also how they sell "Rich text editor component" in the past. In around the end of 199x I used to work for a company who bought WinForms custom component license to edit rich text. And the output is a function of Rich Text you put in. Same rich text, same style. The UI is function of state is the model that provide the best consistency and complex desktop UI also adopt this model to certain degree since 199x. It is not just being advertised or prominent because at the time you should "buy some DLLs and unlock it with our license key" instead of doing this on your own.

[@miquelvazquez4544]

Have you tried to use react and see how it feels and behaves?

[@ndykman_pdx]

I have. Made me miss WPF(!?) in a lot of ways. There is just a lot of clunky stuff in JavaScript and the browser runtime and that's not the fault of React. Like how clunky (and limited) custom events are. Also, I never liked the whole mixing of markup and code. Personal preference, but there are reasons it can get problematic and why older versions of it did fall out of favor. Sometimes, it ends up feeling like a fancier version of ASP Web Pages and that isn't so great. It is well documented and they do a great job of explaining why they do what they do. I can see why it has fans, but I can also see there are plenty of developers that use it and have never actually worked in the MVC paradigm and it shows.

[@miquelvazquez4544]

Wow! I have the opposite experience :) I can't ever be paid enough to touch MVC+WPF ever again, I found to enjoy the reactive paradigm much more

[@chakritlikitkhajorn8730]

I would say when I do form based app (ERP, for example) the reactive paradigm is tedious. I mean, all I should do is gathering data from form, validate, execute few business logic and send that to server. “Reacting” to every keystroke is tedious. MVC and WPF is quite easier. But when I do fancy stuff such as kanban board, fancy drag and drop, pdf editor, notification panel that need to sync with data in other area, oh boy. Even in WPF or Swift I need to turn them to functional paradigm to reason about them. I think that many developers never get to build an app that emphasizes on user experience so they don’t understand how reactive paradigm is useful. All they do is “enterprise business app” where user are forced to adopt to the “enterprise workflow”. And this also show. There are good reason why “wizard step-by-step” were the best UI in many enterprise apps during 199x-200x and now it is deprecate. With WinForm or mvc, it’s really hard to put smooth UX with multiple components interacting with each other in one place. and all you can do is split complicated UX to parts. “Installation wizard, step 1 of 10”, anyone remember?

[@acpp23]

Ok, so now we gotta twist browsers to make the frontend more efficient??

[@fabrizio2723]

I enjoy watching even the ads from this guy

[@james-perkins]

I even enjoy paying this guy to make ads for you to enjoy.

[@JTWebMan]

Great just another way to be tricked is some crazy code interview on something almost no one will need to use.

[@I2ealTuber]

Yield to the king

[@noormohammedshikalgar]

Hello Theo, I just notice that in browser when searching something you put !yt how the hell you did that. Its awesome please do tell me Please its a nice feature

[@gedw99]

so 2 years later its on Safari ?

[@R-5P]

he's cooked at making ads placement 😮‍💨

[@Seedwreck]

Oh, Theo, you don't know Generators?

[@Winium]

So, an operating system.

[@diadetediotedio6918]

Browsers were already called as 'operating systems' for a long time now to be fair, they kinda do a very specific job and many users only use browsers while their computers serve just to store files and run the browsers.

[@eliaspaulinho8435]

what is that terminal app?

[@jameshickman5401]

So ... never done Python Greenlets?

[@cristian91re]

Its basically a sleep in a thread

[@DanSnipe-k8o]

I was doing this in OS/9 in the 1980s.

[@wassafshahzad8618]

At what point so we just call it quits and make a good framework

[@martin_mwiti]

They borrowed Interrupt Service Routine concepts from embedded systems

[@InfiniteQuest86]

Wow, the more I learn about web stuff, the more baffled I am. How did this ever ship without interrupts? It's literally a user interface. That's the ONLY thing you want.

[@vladimircicmanec6103]

One bad library getting its own API because it happens to be developed by a huge corporation is not as much of a W as you might think.

[@matthieugindre1948]

So much money is thrown out of the window because of React. And I mean worldwide. As an engineer, I spend so much time babysitting and fixing React performance issues. Please everyone do use Solid or Svelte, and please Google stop making new APIs that will be useless as soon as developers and companies will start to care for their time and money and give up on React.

[@DavidAlsh]

Counter point, imagine if they spent all this development time & effort on finishing web assembly. We could _practically_ use multiple threads and wouldn't even be talking about this problem

[@jimiscott]

Not necessarily so. Yes the non-UI work can be shunted off to another thread, the UI work cannot....in addition you need to interop between WASM and the UI via JS.

[@DavidAlsh]

​@@jimiscott The wasm -> js thunking is only necessary because wasm is incomplete. When (if they ever get to it) it features native dom bindings, that won't be an issue. My comment was specifically throwing shade at the fact that this isn't implemented yet. The UI thread comment you made is a non-issue outside of the browser world

[@keithjohnson6510]

That would be nice, they could maybe even do this by implementing a simple global Critical sections lock for GUI updates, and maybe later update the GUI to be threadsafe bit by bit. eg. gui.lock doStuff. gui.release. If localeStorage became threadsafe you could then just do `doStuff`, maybe this is the reason it's taking time, making everything "threadsafe" from the start. Again, this could be simplified by say having `localeStorage.setItem` etc be implicitly wrapped in a critical section lock, and finer grained thread safety implemented later.

[@CliseruGabriel]

can't wait for the new old set of bugs from the old days when jQuery was trendy

[@PascalVos]

Oh no react in the browser …

[@LambChomp]

We need a petition to ban all people who use the word "sprinkle" from writing documentation.

[@thewayfaringshadow]

I literally clapped when I watched this.

[@dasten123]

Incredible. Instead of fixing how incredibly stupid React's reactivity system is, they add features to Chrome to make it suck less.

[@Pokefanof2009]

mans made me go and do homework on what the hell a even loop is... ill brb

[@Pokefanof2009]

ok back

[@Pokefanof2009]

good vid 👍