2 ms·
I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though
by sktrdie 8y ago
I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though
- mpweiher 8y agoOr maybe not even in the browser but in the OS? It is interesting how we build a new layer on top, and then notice that we need to reproduce all the functionality of the lower levels. Maybe Open Implementation wasn't such a bad idea?
- pmdarrow 8y agoThe Chrome dev team is working to create a scheduling API in the browser: https://github.com/spanicker/main-thread-scheduling https://github.com/spanicker/main-thread-scheduling
- danabramov 8y agoYep, and React is actively collaborating with them.
- quickthrower2 8y agoWe’ll end up with threads in JS one day.
- danabramov 8y agoRelevant: https://github.com/facebook/react/issues/7942#issuecomment-254984862 https://github.com/facebook/react/issues/7942#issuecomment-2...
- amelius 8y agoHopefully without a "Global Interpreter Lock".
- dana321 8y agoI would prefer that they implement it in the same way go has with channels.
- kalmi10 8y agoRelevant: https://developers.google.com/web/updates/2018/10/wasm-threads https://developers.google.com/web/updates/2018/10/wasm-threa...
- amelius 8y agoYes it's highly unsatisfactory that frameworks are implementing "threads" (i.e., fibers) now, while the OS already provides native threads. Perhaps it would not have been so bad if they just kept the interface the same ...