Tech person
Kraków, Poland
Joined February 2016
- Tweets9.7K
- Following508
- Followers336
- Likes8.3K
I'm not holding my breath since I know how easy it is to miss Canny requests but this would be so nice to have
expo.canny.io/feature-reques…
PSA: If you're using @Dropbox, the latest version is overriding the Mac OS floating thumbnail in the bottom right corner with their own version that doesn't support drag & drop.
After you disable it, press ⌘+shift+5, go to Options and re-enable "Show Floating Thumbnail".
On one hand, this is quite impressive.
On the other, if this is the future of programming then I may just as well start looking for a new job because the process sounds absolutely horrible.
Ok, going to vibe code again tonight.
This time, I'll try to build a zombie survival first-person shooter in blocky style with Cursor + Sonnet 3.7 + @superwhisper.
Maybe too ambitious, but we'll see.
Follow along in this thread 🧵
Michał Matyas retweeted
Web performance engineer here!
Browsers don’t actually render stuff outside of the screen! At least in the narrow sense of “painting what’s off-screen”.
Browsers, however, have other “rendering”-ish work that still they have to do for off-screen elements. This work is computing 1) styles, and 2) layout (sizes/positions) of elements on the page, and it’s this work that content-visibility: auto disables.
Why can’t browsers skip this work by default? Well, for one, if they don’t compute sizes for off-screen elements, how would they know how tall the page is? If they don’t know that, they can’t even render the scroll bar correctly.
This is why `content-visibility: auto` by itself is actually not sufficient enough. You need to also add `content-intrinsic-height: XXXpx` on each element with `content-visibility`. If you don’t, then off-screen elements will render as 0px tall, and when you scroll, you’ll see your scrollbar jump worse than a toddler
Really, Docker? THIS is what you paywall? :|
docs.docker.com/reference/cl…
I dug out my Meta Quest 3 recently and it's fascinating how the company that renamed for the sake of VR world, came up with such an amazing piece of technology etc. also invented probably the worst possible hands-free user experience possible.
The pinch-to-click is so bad.
One of the major problems when working in web development is that backenders often think of the clientside UI as a weird version of a server and assume certain guarantees.
And then they get annoyed or outright angry that the UI/front-end is a very different realm.
Michał Matyas retweeted
> how many r's are there in strawberry?
> whole foods organic strawberries, now just $3.99!
Sent a proposal to GraphQL Ruby for making this available in the ActionCableLink.
I'm still not sold on this being the best possible option but it seems to work for our case (in our code all subscriptions are paired with an API call with subscribeToMore)
github.com/rmosolgo/graphql-…
All right, so there's an undocumented (poorly documented?) option to do this 💀
github.com/rails/rails/pull/…
Does anyone have a good solution to websocket connection dying when tab goes to background considering ActionCable doesn't have message replay support?
Or do you just accept that the app may randomly become broken and require a full refresh?
Since I'm integrating it with graphql-ruby my plan is to monkey-patch ConnectionMonitor from rails/actioncable JS package to add an event on reconnect and then trigger Apollo's reFetchObservableQueries() but I'm surprised I couldn't find anyone else mentioning doing it.
All right, so there's an undocumented (poorly documented?) option to do this 💀
github.com/rails/rails/pull/…
The more I learn how ActionCable and websockets work, the more I'm wondering why anyone would want to use Hotwire in a production level app
