Don't feel bad! This is "bleeding edge" (at least for the web). No developer should feel bad if they are not using OMT yet. Do look into it tho and give it a try.
well when they shut down this Rock thats on top of you for illegal business dealings and being a .... MSFT from the 90's .... you won't feel so little they won't have the power to continue however the AI they have developed will most likely eliminate them and us before even that happens and I am a HIGH Security and Love Technology person...but Google doesn't know how to accept the return of an API call properly so no they won't do it correctly.
Never block the UI thread. This was extensively put in practice by OS/2 2.0 in the early 90s, and just recently MS Office has managed that _most_ of the time.
Thank u so much GCD Team for this talk about Web workers I was in a messed up situation of making a highly responsive PWA that offers realtime Maps with shared pointers and data synchronization using Firebase firestore and the experience was pretty choppy. Using web workers to move computational work out of UI thread made my app 20 times responsive and snappy. Now the app feels almost like a native app when added to the homescreen.
Really great video Surma! The lack of easy multi-threading is a severe disadvantage of JS in the coming future, and needs to be fixed. Modern CPUs are getting more cores and threads, with minuscule improvements to clock speed and IPC (for the most part).
I am a random dev desperately waiting for a transparent worker framework to born. If the rendering system of React or Angular automatically make use of multiple workers without forcing code changes a new era is promised.
@@ManishJangir That change still largely single threaded, and likely happens in the UI thread. Concurrent mode is a promising candidate for real multi-threaded rendering to happen. So yeah, the far far future is bright.
Workers are well documented man, check MDN. All these worker API's have been around for over 5 years. Balance network io with worker threads, idb, and XMLHttpRequest. Scales very well and you dont need external libraries.
I realized I'm the main thread at my job. You do all the work and people keep giving you more until you're committing 90% of the new code. I need a different job.
Google Chrome Devs speaker using iPhone on benchmark results instead of Pixel reminded me of that MS guy using Edge to download Chrome during an Azure presentation haha
yeah, sure, a pure text website is going to be fast and reactive but this guy isn't talinkg about text websites, he's talking about web apps. he's even using a videogame as a benchmark
True, the bottlenecks we see in the wild are predominantly from bad layouts and expensive paints. But as I said in the talk: OMT is *not* about making your app faster, it's about resilience. About making your app _remain_ performant (provided it is already), when run on low-end devices.
@@dassurma I agree with the reliability bit - makes certain that you're not unknowingly performing heavy CPU ops on the UI thread. But this implies that reliability today is affected by such CPU ops - which might be true for apps like Prox - but will make little difference in make current web app more reliable.
I've been building around workers for over a year. Network IO, parsing json data, and transactions to IDB with these are a different ball game. First obj, iterator, context and string.replace to transform the json to html with attributes. Can avoid nested loops by separating the processing. Bind in second iterator on main thread.
Pardon my lack of knowledge, but why would a 120Hz screen make 60 updates/sec look bad or sluggish or undesirable? You'd still show 60 updates/sec in a screen that could accommodate 120, but how is that worse than showing it on a 60Hz screen?
Good question! It wouldn't. However, there's (currently) no way for web apps to opt-in to a lower frame rate than what the screen runs at. So on a 120Hz screen rAF and CSS Transitions/Animations will tick 120 times per second. Unless you *block* the main thread the *exact* amount of time to "downgrade" from 120fps to 60fps manually, you will end up with an unsteady frame rate, which is the worst possible outcome in terms of UX. A steady 30fps feels better to the user than an app that has an unsteady frame rate.
@@dassurma Thanks for replying! So, basically this means code running on the UI/main thread gets an update request / invocation once every ~8ms and if it doesn't finish, it stutters. Is that correct?
Because your app wouldn't match the framerate of other things on the system and it would be noticeably slower. You can see the difference between 60 and 120. Not that a 60fps app is that bad to use, but the goal here is to make it feel as close to native as possible.
Emulation is a good start! But real data from real phones is preferable in my opinion. DevTools won't emulate the low-power GPU or the constrained memory. The 6x CPU slowdown is also not slow enough to match hyper-constrained devices.
@@dassurma what do you mean hyper-constrained devices. For years people have been developing as if everybody had the latest model of a desktop PC. Nearly all websites that I frequent do not load at all when I'm on an "H" mobile network (which is about 7mbit/s iirc) while 10 years ago google maps and even youtube (low res) worked on an "H" network on my old G1 phone with 70MB of ram and who knows how slow the CPU was). Facebook and most websites that connect to it load MBs upon MBs of code before I'm even greeted with the logon form. This is just ridiculous. People also tend to forget what the web is mostly used for. 3 frameworks and several MB of CSS might be able to create beautiful animations, even 3D, what who cares? I just want to look up some information, or look up the address of a restaurant and not download 100MB of high res pictures and the code that displays those pictures in a fancy way. Speaking of "H" network, I'm on H+ right now which is 14mb/s(?) And can't even post this comment, which is not even a kb of payload data. Who knows how much data the RUclips app actually tries to send and what the server responds with, when a simple "http status 200 ok" would be sufficient
@@dassurma For maximum compatibility, instead of using CPU I prefer to order a bag of potatoes. One potato or lack of potato represents an individual bit in a register. By manually shuffling potatoes with my hands in a Turing Complete way I was able to slow down performance enough to ensure performance backwards compatibility up to 10,000 BC, which is the first agricultural revolution. Match that, Chrome devs!
Love it as always! This displays a good summary of all Surma and Jake's videos in regards to this subject. We use a lot of Web Workers for our projects the manual way bundled with Web Pack. Thought we never found the API to be that bad to have to use a library such as Comlink; will look into it more though.
If I understand you correctly, the goal is just to make sure the browser gets a chance at least once every 60th of a second to render a frame, respond to user input, and run lightweight events. You are accomplishing this by moving preemptable tasks to a separate thread so the os can preempt that browser thread in order to run the main browser thread. I believe you can accomplish the same thing in the style of cooperative multitasking within the main thread with async and await: jsfiddle.net/evc8y2uk/ It does run slower with the yeilds, but you could write a more intelligent yeild function to only yeild once every 60th of a second no matter how many times it was called. Then you could just pepper your code with calls to yield. Since you are still in the main thread you can still access everything (dom included) and can share variables (almost) without worrying about mutexes since it is very easy to tell when another piece of code will have the opportunity to interrupt you and change something (it can only happen where you explicitly yeild). I believe that this style of safe asynchronous programing is javascript's greatest strength. Admittedly doing things as you suggest makes it harder to accidentally not yeild.
I forgot to say: I agree that asynchronous programming is a strength of JavaScript. But the async code paradigm is not mutually exclusive with real threading. Quite the opposite: By using async programming _with_ threads, you can saturate your device more easily and arguably reach higher performance with less mental overhead.
Why does proxx.app still use a table and DOM nodes despite not being rendered? wouldn't it be better to only use a canvas and handle the events based on x / y positions? Thereby not having the bloat of lots of extra elements, or do some phones not support touch apis? Or is it only on flagship devices where it adds these nodes?
It's a matter of accessibility! You can play PROXX with a Screenreader. Also the feature phones have no touch screen but only a DPad, which works by focusing interactive elements. We would have to ship more code without the table, so it's actually the opposite of bloat. I'd recommend Mariko's I/O19 talk where she explains all of this.
@@dassurma so the trade off of HTML code vs JS code is in favor for HTML code, because of the inherit accessibility it gives you. It is only when you try to update all of these elements at the same time that it causes an issue with low performance devices. Therefore it is better to store the visual state of the changing elements from the app to a canvas underneath the elements. Although I could imagine that it's not that simple in all cases and should be tested thoroughly for every project.
This is an interesting strategy to know about but I suspect for most use cases staying on the main thread might be best for simplicity and speed, especially if most of your users are on powerful phones or desktop.
That was the whole point of my talk. I was trying to show that: a) using workers doesn’t have a notable negative impact on complexity, b) the argument for speed is highly flawed and c) “most users” is often a synonym for wealth and is excluding a _significant_ portion of people even in the most economically successful countries like America.
probably yes, depends though as indexeddb runs on a separate thread by default so i'd make sense if the data generated is quite big and isn't needed by the ui immediately
You demonstrated the impact of screen refresh rate improvements with the impression of performance in ms from the feature phones - which, is probably not important, but just incase you didn't notice it. It is more likely that someone with a high refresh rate screen is going to have a more powerful device, but not to take away from the important underlying message that performance is important and we have emerging markets
Your point definitely still remains (slow accessible hardware, or, increased refresh rates on high end hardware reduce the time available on the main thread before users experience jank), it was just when you said "We barely make it through our calculating styles here" that I thought I should mention something - you would barely make it through calculating styles on a feature phone powering a 120hz screen if we were following the infographic. I'm guna take myself outside and see to myself appropriately xD thanks so much for the talk!
Surma as I commented on your corner booth video that you responded to. NO I WILL NOT develop for a fox and I will not do it with a proxx I will not develop for poor or stale. I will only develop for chrome 5ghz anywhere. But in all reality the only real answer in a world where speed is not increasing but thread count is JS (ahem V8) will have to abandon the single thread mantra and full wrap it's arms around multi-threaded mindset.
How could redux/flux work with web workers? Redux users object comparison for its change tracking so deserialized object will create a complete rerender. I can see this working with reactive/mvvm patterns maybe mobx state tree but I am curious about redux?
Instead of completely copying the state object between worker and main thread every time, you can instead send patches (ImmerJS is a library that can generate patches). That way equality pertains between unchanged substates.
@@dassurma O so keep two stats in sync with jsonPatch. You either need to copy your state before action calls or keep a full copy for reads. That sounds like a nightmare if you want more than one background thread active, and sort of ignores single source of truth. Do you have any examples of this?
I feel like a critical piece of the story is missing here. Those minesweeper updates being sent to the UI mean breaking the minesweeper logic into processing chunks, correct? Otherwise, you still have to wait till all the processing is done (even if on another thread/worker). What does that logic look like? How much more complexity are we adding to an application to provide the perception of speed?
No, that's the benefit of the worker. You now have 2 completely isolated, separate event loops. You can call `postMessage()` at any point to to queue up a `message` event in the _other_ event loop immediately, without changing your logic at all. No change in complexity. If anything, by moving the code to a worker and not having to chunk any more, the code got simpler overall.
@@dassurma Can you explain why the worker appears to be sending updates to the UI in batches? It appears to be processing chunks of UI updates, sending, then processing the next batch. Whereas the non-worker version seems to simply compute once. I've seen this technique used for not tying up the event loop.
@@johnrobie9694 We collect 10 fields that need to be revealed and send that as a single UI update. It's just a number we figured out via trial and error that looked good visually across most devices.
@@dassurma So you're sending 10 at a time? So is that really a fair comparison then? To make it fair, it seems like you'd need to pit the event loop trick against workers, since they'd both be batching their logic.
I year ago this is will be a 30min gibberish.. But here am i nodding my head an concurring to a representation on rails, web workers and threads.. And am even getting some of the subtle awful jokes..😭😭
It seems like you are trying to be snarky, but that’s exactly what I said in the talk: Other languages and platforms have been doing this for a long time.
For large corporations these emerging markets are usually a large source of growth. Google and Facebook and all large tech companies want to secure a large market share in Africa and India. An example of Google already pandering to low end markets would be the 305 byte logo, which replaced the former Serif font logo that used 6 KB.
@@nicholasmaniccia1005 note that eventually time frame. If it takes 10/20 years that personal data is worthless. Most data is worthless a lot faster than that, humans are not static.
well, if they get phone subsidized, do they have actually the money to buy something from you?? 😂😂😂 maybe we're solving wrong problem here, just maybe...😂
Triggered by your use of fake news tactics at 08:26. Thy conflate high refresh rates with low cpu performance, to fabricate a malapropos tabule justifying thine 0.007s celeritate terminum minimum JavaScript code. You're either going to get a low end phone with a low refresh rate, or a high end phone that's fast enough to run your productive* JavaScript code within 7ms. You won't get a low end phone with a refresh rate requiring over 144fps. Graphs attempting to purport otherwise are misleading at best, Trumpian levels of deceitful at worst. Or maybe I'm just triggered by the obsession with 0.016s, where as a citizen of the EU, I'm used to the perfectly acceptable 0.02s standard from PAL. I'll be involuntarily stripped of that citizenship next year, by the only miscreants miseducated enough to understand my second sentence, so maybe I'll have to get used to it.
The syntax is fine? Allows very easy functional paradigms, and comment on hating PHP is also dumb. Have you ever used F# before? Swift is similar. Everything is very clear.
People who are using these cheap phones probably cant afford whatever product you are selling to them on your website. So there is no reason to spend so much time and effort into designing something for someone who cannot buy it anyways.
I can relate to the main thread.
As a developer, I feel like I've been living under a rock after watching this video.. So much to learn!
I thought I was the only one thinking like this. lol So much to learn. x2
Don't feel bad! This is "bleeding edge" (at least for the web). No developer should feel bad if they are not using OMT yet. Do look into it tho and give it a try.
as a begnner i feel amazed by google ...google is the new trend
well when they shut down this Rock thats on top of you for illegal business dealings and being a .... MSFT from the 90's .... you won't feel so little they won't have the power to continue however the AI they have developed will most likely eliminate them and us before even that happens and I am a HIGH Security and Love Technology person...but Google doesn't know how to accept the return of an API call properly so no they won't do it correctly.
The main thread is over worked and underpaid - Maybe we should start a new library named Unionize to help fix these issues...
TL;DW: Use main thread for UI only, separate high-cost business logic inside the worker.
Not just high-cost business logic. All business logic :)
... to keep the UI responsive, not to speed up the actual computation itself.
Kudos to the production team behind filming and editing these lectures, it's spot on.
Never block the UI thread. This was extensively put in practice by OS/2 2.0 in the early 90s, and just recently MS Office has managed that _most_ of the time.
Thank u so much GCD Team for this talk about Web workers I was in a messed up situation of making a highly responsive PWA that offers realtime Maps with shared pointers and data synchronization using Firebase firestore and the experience was pretty choppy. Using web workers to move computational work out of UI thread made my app 20 times responsive and snappy. Now the app feels almost like a native app when added to the homescreen.
I know you commented a while ago, but can you tell me more about that project? Which parts did you move to workers, very curious to know!
never get enough with surma 🤞
0:44 I like to think that the earth spinning backwards on that slide is a metaphor for how the JS ecosystem defies common sense
Really great video Surma! The lack of easy multi-threading is a severe disadvantage of JS in the coming future, and needs to be fixed. Modern CPUs are getting more cores and threads, with minuscule improvements to clock speed and IPC (for the most part).
I am a random dev desperately waiting for a transparent worker framework to born.
If the rendering system of React or Angular automatically make use of multiple workers without forcing code changes a new era is promised.
React already has designed a scheduler and made use of MessageChannel API of the browsers.
@@ManishJangir That change still largely single threaded, and likely happens in the UI thread. Concurrent mode is a promising candidate for real multi-threaded rendering to happen. So yeah, the far far future is bright.
Workers are well documented man, check MDN. All these worker API's have been around for over 5 years. Balance network io with worker threads, idb, and XMLHttpRequest. Scales very well and you dont need external libraries.
I realized I'm the main thread at my job.
You do all the work and people keep giving you more until you're committing 90% of the new code. I need a different job.
ask for a raise if not quit
Google Chrome Devs speaker using iPhone on benchmark results instead of Pixel reminded me of that MS guy using Edge to download Chrome during an Azure presentation haha
It's nice to see the "not invented here" syndrome dying
@@LostieTrekieTechie It is indeed! :)
I can only say this:
If you want almost instant pages on mobile, then don't use images, don't use ads.
yeah, sure, a pure text website is going to be fast and reactive but this guy isn't talinkg about text websites, he's talking about web apps. he's even using a videogame as a benchmark
Checks eBay for Nokia 2 and orders a stress ball instead. Good talk Surma!
As always, super informative, well delivered talk! I really like the point about inclusivity as well! Thank you!
I see Surma, I click!
Good talk. Though I doubt web apps are bound by CPU work that can be moved to a worker. Non-DOM /Non-Event CPU work is pretty rare.
True, the bottlenecks we see in the wild are predominantly from bad layouts and expensive paints. But as I said in the talk: OMT is *not* about making your app faster, it's about resilience. About making your app _remain_ performant (provided it is already), when run on low-end devices.
@@dassurma I agree with the reliability bit - makes certain that you're not unknowingly performing heavy CPU ops on the UI thread.
But this implies that reliability today is affected by such CPU ops - which might be true for apps like Prox - but will make little difference in make current web app more reliable.
I've been building around workers for over a year. Network IO, parsing json data, and transactions to IDB with these are a different ball game. First obj, iterator, context and string.replace to transform the json to html with attributes. Can avoid nested loops by separating the processing. Bind in second iterator on main thread.
Pardon my lack of knowledge, but why would a 120Hz screen make 60 updates/sec look bad or sluggish or undesirable? You'd still show 60 updates/sec in a screen that could accommodate 120, but how is that worse than showing it on a 60Hz screen?
Good question! It wouldn't. However, there's (currently) no way for web apps to opt-in to a lower frame rate than what the screen runs at. So on a 120Hz screen rAF and CSS Transitions/Animations will tick 120 times per second. Unless you *block* the main thread the *exact* amount of time to "downgrade" from 120fps to 60fps manually, you will end up with an unsteady frame rate, which is the worst possible outcome in terms of UX. A steady 30fps feels better to the user than an app that has an unsteady frame rate.
@@dassurma Thanks for replying!
So, basically this means code running on the UI/main thread gets an update request / invocation once every ~8ms and if it doesn't finish, it stutters. Is that correct?
Because your app wouldn't match the framerate of other things on the system and it would be noticeably slower. You can see the difference between 60 and 120. Not that a 60fps app is that bad to use, but the goal here is to make it feel as close to native as possible.
Seeing this two years later and I still ask myself why frameworks don't incorporate this pattern.
chrome on a mac hardly uses the hyperthreads at all, only the main cores...in windows, all cores and threads are used equally
So there's now a performance reason for MVC? Or at least Model/View separation?
Are camera angles and takes in this event automated?
pssst, hey kid, chrome dev tools has performance throtling of up to 6x and slow 2g speeds which simulate nokia 3310
Emulation is a good start! But real data from real phones is preferable in my opinion. DevTools won't emulate the low-power GPU or the constrained memory. The 6x CPU slowdown is also not slow enough to match hyper-constrained devices.
@@dassurma what do you mean hyper-constrained devices. For years people have been developing as if everybody had the latest model of a desktop PC. Nearly all websites that I frequent do not load at all when I'm on an "H" mobile network (which is about 7mbit/s iirc) while 10 years ago google maps and even youtube (low res) worked on an "H" network on my old G1 phone with 70MB of ram and who knows how slow the CPU was). Facebook and most websites that connect to it load MBs upon MBs of code before I'm even greeted with the logon form.
This is just ridiculous. People also tend to forget what the web is mostly used for. 3 frameworks and several MB of CSS might be able to create beautiful animations, even 3D, what who cares? I just want to look up some information, or look up the address of a restaurant and not download 100MB of high res pictures and the code that displays those pictures in a fancy way.
Speaking of "H" network, I'm on H+ right now which is 14mb/s(?) And can't even post this comment, which is not even a kb of payload data. Who knows how much data the RUclips app actually tries to send and what the server responds with, when a simple "http status 200 ok" would be sufficient
@@borstenpinsel Its almost as if the tech world will slowly start to transition back to C like languages again XD
@@kristupasantanavicius9093 "Hey guys, cobol here, back with another video of how to set fire to your old-style compiler again"
@@dassurma For maximum compatibility, instead of using CPU I prefer to order a bag of potatoes. One potato or lack of potato represents an individual bit in a register. By manually shuffling potatoes with my hands in a Turing Complete way I was able to slow down performance enough to ensure performance backwards compatibility up to 10,000 BC, which is the first agricultural revolution. Match that, Chrome devs!
I’ll remember to give the main thread some paid vacation
Love it as always! This displays a good summary of all Surma and Jake's videos in regards to this subject. We use a lot of Web Workers for our projects the manual way bundled with Web Pack. Thought we never found the API to be that bad to have to use a library such as Comlink; will look into it more though.
If I understand you correctly, the goal is just to make sure the browser gets a chance at least once every 60th of a second to render a frame, respond to user input, and run lightweight events. You are accomplishing this by moving preemptable tasks to a separate thread so the os can preempt that browser thread in order to run the main browser thread. I believe you can accomplish the same thing in the style of cooperative multitasking within the main thread with async and await:
jsfiddle.net/evc8y2uk/
It does run slower with the yeilds, but you could write a more intelligent yeild function to only yeild once every 60th of a second no matter how many times it was called. Then you could just pepper your code with calls to yield. Since you are still in the main thread you can still access everything (dom included) and can share variables (almost) without worrying about mutexes since it is very easy to tell when another piece of code will have the opportunity to interrupt you and change something (it can only happen where you explicitly yeild).
I believe that this style of safe asynchronous programing is javascript's greatest strength. Admittedly doing things as you suggest makes it harder to accidentally not yeild.
I forgot to say: I agree that asynchronous programming is a strength of JavaScript. But the async code paradigm is not mutually exclusive with real threading. Quite the opposite: By using async programming _with_ threads, you can saturate your device more easily and arguably reach higher performance with less mental overhead.
Surma and Jake are my mentor, web development guru.
like a rock song without a crushing guitar... scorpion!
God damn it, this made so much freaking sense and I just finished Java basics.
Man this is such a good talk, now where can I learn more about worker threads and how to effectively use them?
MDN
@@russellabraham9208 MDN is reference material. I could've opened a reference manual to learn git or sql but there are better ways
@@damianrivas True, I found there material on inline workers and queriable workers, to be pretty good.
Does elixir/phoenix already implement this UI/logic separation?
Great work!
Can somebody tell me what RAIL meant here?
developers.google.com/web/fundamentals/performance/rail
@@hansmeyer2 Thanks
Why does proxx.app still use a table and DOM nodes despite not being rendered? wouldn't it be better to only use a canvas and handle the events based on x / y positions? Thereby not having the bloat of lots of extra elements, or do some phones not support touch apis? Or is it only on flagship devices where it adds these nodes?
It's a matter of accessibility! You can play PROXX with a Screenreader. Also the feature phones have no touch screen but only a DPad, which works by focusing interactive elements. We would have to ship more code without the table, so it's actually the opposite of bloat. I'd recommend Mariko's I/O19 talk where she explains all of this.
@@dassurma so the trade off of HTML code vs JS code is in favor for HTML code, because of the inherit accessibility it gives you. It is only when you try to update all of these elements at the same time that it causes an issue with low performance devices. Therefore it is better to store the visual state of the changing elements from the app to a canvas underneath the elements. Although I could imagine that it's not that simple in all cases and should be tested thoroughly for every project.
HTML canvas is dead by design.
Recreating Human touch is impossible for cookies😂
Thank you Surma ..
This is an interesting strategy to know about but I suspect for most use cases staying on the main thread might be best for simplicity and speed, especially if most of your users are on powerful phones or desktop.
That was the whole point of my talk. I was trying to show that: a) using workers doesn’t have a notable negative impact on complexity, b) the argument for speed is highly flawed and c) “most users” is often a synonym for wealth and is excluding a _significant_ portion of people even in the most economically successful countries like America.
Very interesting talk, I should think of creating my 12000 records table in a worker...
probably yes, depends though as indexeddb runs on a separate thread by default so i'd make sense if the data generated is quite big and isn't needed by the ui immediately
Firefox gang
That's probably why proxx.app does not work on my nokia 8110. Because comlink support for firefox starts with version 52. ( 8110 is firefox 48)
PROXX works on the Nokia 8110. We tested on that phone during development.
wow, great talk .thank you.
You demonstrated the impact of screen refresh rate improvements with the impression of performance in ms from the feature phones - which, is probably not important, but just incase you didn't notice it.
It is more likely that someone with a high refresh rate screen is going to have a more powerful device, but not to take away from the important underlying message that performance is important and we have emerging markets
I merely said that both of these developments reduce the time we can use freely on the main thread.
Your point definitely still remains (slow accessible hardware, or, increased refresh rates on high end hardware reduce the time available on the main thread before users experience jank), it was just when you said "We barely make it through our calculating styles here" that I thought I should mention something - you would barely make it through calculating styles on a feature phone powering a 120hz screen if we were following the infographic. I'm guna take myself outside and see to myself appropriately xD thanks so much for the talk!
Thank you.
Great talk
Amazing...
Spent the entire talk lissening while playing the game :D Its amazing for some1 who loves minesweeper
We have a river named "Surma" in my country (Bangladesh), MR. Surma
I'm really looking forward to see a new client side language to take the place of JavaScript.
Good one
Where is Angular?
Shhh... We don't talk about it
Rafael Perelló Polymer is the new Google framework, now.
@@dupersuper1000 NEW??? Man, it's 4 years old
Surma as I commented on your corner booth video that you responded to. NO I WILL NOT develop for a fox and I will not do it with a proxx I will not develop for poor or stale. I will only develop for chrome 5ghz anywhere. But in all reality the only real answer in a world where speed is not increasing but thread count is JS (ahem V8) will have to abandon the single thread mantra and full wrap it's arms around multi-threaded mindset.
How could redux/flux work with web workers? Redux users object comparison for its change tracking so deserialized object will create a complete rerender. I can see this working with reactive/mvvm patterns maybe mobx state tree but I am curious about redux?
Instead of completely copying the state object between worker and main thread every time, you can instead send patches (ImmerJS is a library that can generate patches). That way equality pertains between unchanged substates.
@@dassurma O so keep two stats in sync with jsonPatch. You either need to copy your state before action calls or keep a full copy for reads. That sounds like a nightmare if you want more than one background thread active, and sort of ignores single source of truth. Do you have any examples of this?
nice talk
I feel like a critical piece of the story is missing here. Those minesweeper updates being sent to the UI mean breaking the minesweeper logic into processing chunks, correct? Otherwise, you still have to wait till all the processing is done (even if on another thread/worker). What does that logic look like? How much more complexity are we adding to an application to provide the perception of speed?
No, that's the benefit of the worker. You now have 2 completely isolated, separate event loops. You can call `postMessage()` at any point to to queue up a `message` event in the _other_ event loop immediately, without changing your logic at all. No change in complexity. If anything, by moving the code to a worker and not having to chunk any more, the code got simpler overall.
@@dassurma Can you explain why the worker appears to be sending updates to the UI in batches? It appears to be processing chunks of UI updates, sending, then processing the next batch. Whereas the non-worker version seems to simply compute once. I've seen this technique used for not tying up the event loop.
@@johnrobie9694 We collect 10 fields that need to be revealed and send that as a single UI update. It's just a number we figured out via trial and error that looked good visually across most devices.
@@dassurma So you're sending 10 at a time? So is that really a fair comparison then? To make it fair, it seems like you'd need to pit the event loop trick against workers, since they'd both be batching their logic.
I see someone's asking for arrays
KaiOS😊
I year ago this is will be a 30min gibberish..
But here am i nodding my head an concurring to a representation on rails, web workers and threads..
And am even getting some of the subtle awful jokes..😭😭
And you still have to wait forever when you get to the belt.
One of those videos which do not dislikes !
There are also devices with 30 fps, I think I want to target those first :D
Wow
Watch the Actor Model video
In ASP.NET Core work is marshalled to Thread Pool threads, so everything is not running in one thread ;)
It seems like you are trying to be snarky, but that’s exactly what I said in the talk: Other languages and platforms have been doing this for a long time.
@@dassurma sorry for seeming that way. I can imagine that a lot of frameworks have solved that issue yeah
I made Task.js to make working with workers a little easier ( github.com/icodeforlove/task.js ). Also supports node.js, and worker_threads.
Ok
People even at Google don't consider angular as a framework 18:14, then what's the point
Probably trying to just avoid people complaining about bias. But didn't anticipate people would even complain about it's exclusion.
Too bad this low-end device user have no money for apps and microtransactions , to in the end nothing will chance.
For large corporations these emerging markets are usually a large source of growth. Google and Facebook and all large tech companies want to secure a large market share in Africa and India. An example of Google already pandering to low end markets would be the 305 byte logo, which replaced the former Serif font logo that used 6 KB.
They have personal data
@@conoroflanagan2908 their personal data isn't worth much if they can't buy anything.
@@Masterrunescapeer they can buy things, those phones aren't subsidized, and they will eventually be able to buy as much as us.
@@nicholasmaniccia1005 note that eventually time frame. If it takes 10/20 years that personal data is worthless. Most data is worthless a lot faster than that, humans are not static.
Dev for the Devil. Google Chrome is the Devil.
Yeah, and my computer is like 100 GB of memory on google chrome!!
"The main thread is overworked & underpaid". Like Google employees.
I hate when these talks just advertise some library...
As a developer just jump to 9:15.🤷♂️🤷♂️🤷♂️
Use of "western world" is a misnomer. "Developed world" would be more apt.
who watches this at 2x speed?
well, if they get phone subsidized, do they have actually the money to buy something from you?? 😂😂😂 maybe we're solving wrong problem here, just maybe...😂
Triggered by your use of fake news tactics at 08:26.
Thy conflate high refresh rates with low cpu performance, to fabricate a malapropos tabule justifying thine 0.007s celeritate terminum minimum JavaScript code.
You're either going to get a low end phone with a low refresh rate, or a high end phone that's fast enough to run your productive* JavaScript code within 7ms. You won't get a low end phone with a refresh rate requiring over 144fps. Graphs attempting to purport otherwise are misleading at best, Trumpian levels of deceitful at worst.
Or maybe I'm just triggered by the obsession with 0.016s, where as a citizen of the EU, I'm used to the perfectly acceptable 0.02s standard from PAL. I'll be involuntarily stripped of that citizenship next year, by the only miscreants miseducated enough to understand my second sentence, so maybe I'll have to get used to it.
I finally saw what Swift looks like and I'm disgusted. Did a toddler design the syntax? :(
@Frieder Hannenheim I had the misfortune of working almost exclusively with php for around 6 or 7 years, I'd still choose php's syntax anytime
The syntax is fine? Allows very easy functional paradigms, and comment on hating PHP is also dumb. Have you ever used F# before? Swift is similar. Everything is very clear.
People who are using these cheap phones probably cant afford whatever product you are selling to them on your website. So there is no reason to spend so much time and effort into designing something for someone who cannot buy it anyways.
remove CORS from the browser. remove cookie politics. for better Web.