484 karma · joined January 8, 2011
These types of experiments are extremely valuable in uncovering hard-to-find bugs, assuming you have sufficient logging and confidence around your metrics. They let you know a problem exists and roughly where it is in the product. From there you can drill down and investigate your source code until the discrepancy is found.
I will always use AB testing for uncertain code in the future. I was skeptical when I first started writing AB tests, but they have proven their worth over and over again.
That said I don't expect a massive impact from this change, but removing unused code is going in the right direction.
While it may be nice, for large production apps we'll take the filesize gains where we can find them.
With no scrollbars it's hard to tell if something is zoomed in or not and you might be missing parts of the UI without noticing. Native apps don't zoom and neither should mobile sites pretending to be apps. Build accessibility into the UI.
Best thing you can do as a tourist is know where you are. It's no different than unsafe areas of Mexico and LA? You gonna stay near skid row?
SF weather and wealth is going to attract homeless and drugs, and unless you want to break the law to stop it, adapting is the next best thing.
Actually NVM it's just easier to shit on SF and act like everyone there is an idiot and the solution is simple.
Why people keep staying there instead of the hundreds of other and safer hotel locations? Maybe hotels need better regulated ratings to take into account the surrounding area.
They are quirky and aesthetically distinguishing, especially all the orange and green.
Love my '95 Saab 900 SE turbo and will most likely never part with it if I can avoid it.
I bet DOM access in WASM is totally doable, just gonna be a lot harder than how this project implemented it.
My project is https://diffhtml.org/ and I have started experimenting with middleware to bridge to server and client workers: https://github.com/tbranyen/diffhtml/pull/251. For the server worker, it uses a WebSocket to ferry the VDOM diff patches, custom events, and property access/function calls. A big goal is to allow synchronous "main thread" access from workers, including on the server-side. This would allow you to write your UI code as if you were a client side app. It does this the same way as partytown using a SharedArrayBuffer and Atomics. You can see demo source code here: https://gist.github.com/tbranyen/2f5be81cfb7b3aa1bb443c8ef13....
I've also toyed around with hot reloading components without the need for a pre-processor like Babel, and the results are hugely promising. Stateful live UI updates from saving a component file to seeing in the browser without all the fuss with complex build steps is liberating.
I'm probably a few months out from having a usable beta, but I'm going to follow your project closely. Thanks for sharing!
I've seen plenty of brands in specialty markets that are more expensive than Heinz for that reason.
Cookies get sent with most requests as headers so you're unnecessarily bogging down requests with data unrelated to the session.
The fix from the Netflix side would be to find a suitable alternative to user agent sniffing for h/w accel and swap that in to this code path.