Flutter still doesn't support liquid glass on iOS so it doesn't seem like a serious contender to me at this point. And due to the nature of how Flutter is implemented, it's going to continuously be an uphill battle. Maybe it's fine if you intend on having a completely custom UI and don't care about platform look and feel.
The new direction isn’t Liquid Glass, but a more unified branding across Android and iOS. WhatsApp, Google Maps, Instagram, Netflix, Prime Video, and many others don’t look dated, because they don’t make heavy use of the older iOS design language at all.
In general, the "render UI as if it were a video game" route feels like a bit of a dead end on mobile to me. On desktop it's more workable but still isn't without issues.
There are a couple issues with that definition:
- quality is not always correlated with "cheaply made en-masse"
- actual slop, assuming you are talking about the food, is more about preventing food waste although it happens to also be cheap.
I'm being pedantic AF because most people refer to AI slop as "low-quality or careless work". And AI is just a tool so it's possible to spend a lot of time making something of high quality with it. I get the outrage with respect to copyright and artist rights, but it certainly doesn't look like slop to me.
Eeeeh your definition is as good as mine. To me, slop is used to convey the fact that whatever it is applied to was made with quantity/efficiency in mind rather than quality/purpose, like what is fed to pigs. Indeed, ultimately slop could be good by that definition. Lots of people like McDonald's, but I think most people also realize it is slop.
I'm dealing with a severe health ailment with my cat right now and ChatGPT has been pretty invaluable in helping us understand what's going on. We've been keeping our own detailed medical log that I paste in with the lab and radiology results and it gives pretty good responses on everything so far. Of course I'm treating the results skeptically but so far it has been helpful and kept us more informed on what's going on. We've found it works best if you give it the raw facts and lab results.
The main issue is that medicine and diseases come with so many "it depends" and caveats. Like right now my cat won't eat anything, is it because of nausea from the underlying disease, from the recent stress she's been through, from the bad reaction to the medicine she really doesn't like, from her low potassium levels, something else, all of the above? It's hard to say since all of those things mention "may cause nausea and loss of appetite". But to be fair, even the human vets are making their own educated guesses.
Yep, localization is a huge size bloat for enterprisey apps that support many locales. There is no Apple provided way to dynamically download select localization packs based on the device locale. Meta came up with their own solution: https://engineering.fb.com/2022/05/09/android/language-packs...
The small filesize issue is something we commonly see in games, was surprised to see it for Gmail.
I agree, latency is very important and 300 pops is great, but seems more for marketing and would see diminishing returns for the majority of applications.
Good luck getting 100+ devs to all use the same logical commit style. And if tests fail in CI you get the inevitable "fix tests" commit in the branch, which now spams your main branch more than the meaningful changes. You could rebase the history by hand, but what's the point? You'd have to force push anyway. Squashing is the only practical method of clean history for large orgs.
Also rebasing is just so fraught with potential errors - every month or two, the devs who were rebasing would screw up some feature branch that they had work on they needed and would look to me to fix it for some reason. Such a time sink for so little benefit.
I eventually banned rebasing, force pushes, and mandated squash merges to main - and we magically stopped having any of these problems.
We squash, but still rebase. For us, this works quite well. As you said, rebasing needs to be done carefully... But the main history does look nice this way.
The treemap screenshot doesn't look correct. Nearly all charting libs (like Apache Echarts) will group nodes with a heading name, so not sure why they claim it would be hard to notice the "drivers" node. I guess in that screenshot, sure, but that looks like just a bad implementation of a treemap. Maybe this was the case back in 2017?
Flame graphs I have a love/hate relationship with. The hierarchy is very useful, but the name and coloring can be very confusing and misleading. Most people I show them to think red == something bad, but the color is actually just for aesthetics.
At an old startup attempt we once created a nested hierarchy metrics visualization chart that I later ended up calling Bookshelf Charts, as some of the boxes filled with with smaller boxes looked like a bookshelf (if you tilted your head 90 degrees). Something between FlameGraphs and Treemaps. We also picked “random” colors for aesthetics, but it was interactive enough so you could choose a heat map color for the plotted boxes (where red == bad).
The source code got lost ages ago, but here are some screenshots of bookshelf graphs applied to SQL plan node level execution metrics:
Very neat. And if anyone from Plotly should happen to be reading this, a compact format like this might be an interesting option for Icicle Charts, akin to how the compact, indented version of Excel pivot tables saves horizontal space over the "classic" format pivot table.
Yes, pretty much all treemap disk space tools I've used will perform color gradient grouping on boxes, with directories fitting in larger boxes. The box may not be drawn, but the inner boxes will align, visually making a larger box. Also, mouse hovers go a long way.
Like, one just has to look at the qdirstat screenshot at https://github.com/shundhammer/qdirstat. On the bottom-right corner, there are visually distinct boxes of sub-boxes that guide the eye towards a logical set of files.
reply