143 karma · joined December 31, 2013
I like the potential of this approach as it lets you get smoother results than just CSS transitions yet doesn't require you to use a RAF loop-based animation library.
EDIT: Firefox gets a 1336
If you add contain: strict to the container in the above example you'll see that it then successfully clips the child div.
I had some promising (at the very least interesting) results with react-native-dom which runs all of React's reconciliation & your own business logic in a web worker: https://rndom-movie-demo.now.sh. I'll fully admit there's a lot more exploration/experimentation left to be done in this space though.
I think it works better because the original framework wrestles with the same limitations you mention (though an upcoming rearchitecture doesn't), and while it is by no means perfect, some early results are promising: https://rndom-movie-demo.now.sh
My case was slightly unique though in that we had probably the best comp sci teacher you could expect in high school. He got through the entire A curriculum in half the time and spent the rest exploring more advanced topics/projects we were individually interested in.
I've been experimenting with an architecture where all app logic lives in a web worker, so in order to respond to events, the event gets handled on the main thread and forwarded to the worker, where it then triggers app logic which sends commands back to the main thread.
Problem is, once you cross a thread boundary, you lose all the context which classifies your calls as "in result of a user gesture", so you need to resort to hacky workarounds that force you to keep your app logic on the main thread :(
Anecdotally I find SPAs, while I'm more comfortable developing them, will take longer to build. You need to pay more attention to the quirks the author mentions and you need to spend more time explicitly optimizing your code. I like this paradigm because if there is inconsistent logic, poor performance, or other issues, it's my fault and I have the opportunity to fix it.
As a counter example to the ones mentioned in the above article, around 2 years ago I build a drum machine webapp entirely in JavaScript/React (https://io808.com). This has ~17 JS library dependencies and ~6000 lines of source code but the gzipped bundle size comes out to ~97 KB.
Just because you're building an SPA doesn't mean you need to spend less time optimizing your code, in fact it likely means the opposite.
I still remember the first day I took the medication, it was like somebody finally turned off a white noise machine in my brain and I could finally do all the things I've wanted to do.
I'm not particularly interested in writing entire webapps in Rust but I do see it being useful for smaller self-contained modules inside a larger JS app. Not having a robust binding API makes that difficult.
EDIT: But unrelated criticisms aside, congrats on the progress! I'm excited to see more first class support of WASM from languages other than C/C++.
Considering that most ad blockers work by identifying ads through class names, it would explain why uBlock origin wouldn't work on the mobile site.
As an amateur/bedroom music producer I've always been fascinated with the impact and history of the TR-808. While trying to learn the new Web Audio API I attempted to try and recreate a few of the sounds by referencing the Sound on Sound Synth Secrets series and the block diagrams of the 808 itself. It became addicting and once I had most of the sounds done, I figured recreating the interface/functionality was the next logical step.
This is a completely client-side app made with React, Redux, and the Web Audio API where all the sounds are being synthesized by the browser (look mom, no samples!). If anything this was a really intense exercise in learning all of these web technologies and was more fun than I’m personally willing to admit.
Feel free to ask me any questions, and I hope you enjoy it!