I assume this is about the Android gallery app? You may want to try an alternative, like Fossify Gallery. I switched for the exact reasons you say and the paid/locked filters that I don't use anyway.
That's not it. The core issue is AAA sites vs apps. Let me explain.
Public sites need to load quickly and use progressive enhancement, work without JavaScript even. Next.js is driving this with server side rendering and hybrid approaches. They've done a great job so far.
Then there are applications that have a browser UI. These typically use a JSON-based API (REST, RPC, or GraphQL doesn't matter). These apps don't require server side rendering and their API backend can be anything.
In the latter model, you just host a bunch of static assets and point them to your API. No need for compute, everything is done client side (except API operations of course).
In the first model, you need to pay for rendering and it guides you into doing the API the same way. Closer to older PHP/ASP sites but on steroids.
This move caters to Next.js. IMO, as a lot of recent developments do.
The issue really rears its head when we consider that most are in the second category but "modern" frameworks like Next.JS don't really cater to that market.
I used React for a long time to build frontends for my REST APIs. When I started, CRA was the standard to get started with. CRA got deprecated and I wanted to shift to Next.JS since that seems to be a little more full-stack and I wanted built-in routing instead of relying on react-router. Once I got going on Next.JS everything turned out to be connected to Vercel. Even the tutorial at one stage expects you to sign up for a Vercel account. This really turned me off of React because there doesn't appear to be a single framework for people who want to build the latter category of web apps without either a) tying together multiple disparate modules/libs or b) signing up with 1 framework with 1 vendor. Either option doesn't appeal to me.
I shifted over to Angular (despite everything) because it seems to have finally stabilized and has a pretty good feature set for what I'm looking for. Plus build times on Amplify have really come down. Build times for similar sized apps take around 4 minutes(!) for React applications and routinely under and about 1 minute for Angular applications. I honestly just want a frontend framework where I can build a foundation fairly quickly and just get on with building features instead of worrying about if dependencies have suddenly been sunset or if the author made some breaking change to some key library I don't even interact with directly and right now this is Angular.
> want a frontend framework where I can build a foundation fairly quickly
Vue with Quasar has been that for me. And previously Vuex-orm, now Pinia-orm. With a RESTful backend.
However lately I've been using React because of a graphql backend (I hate graphql) and it's a relay type graphql and the frontend relay library only works with React.
React itself is pretty easy to pick up. But Relay is a pain in the ass.
Fragments, @arguments, @argumentsdefinitions, the naming is a super pain in the ass.
And it's even more of a pain with Typescript and doesn't work with Javascript.
Reusing queries is not possible because of the naming requirements.
You can't just have a PostFragment, no you need to have a MainPagePostsFragment and a ProfilePagePostFragment and a PostDetailPagePostFragment etc.
But I digress.
React has been surprisingly cute so far. But I've also just been with it for 1 version only, 18.
I could imagine switching to it because of the ecosystem and because most frontend jobs are React jobs. You can easily embed it into for instance static HTML files, unlike Angular or Vue, keyword easily.
Angular syntax is beautiful, but the framework is too time consuming.
I have recreated a real-time forum, which took about 3 years to build with Angular in 2 weeks with Vue.
Bottom line, Vue, for me, is the most productive framework. Angular, Vue and React are all very similar.
Svelte is a bit alien, because of its state management and kit being the nextjs equivalent, but apparently the fastest because of the compiler.
I use Arch almost exclusively on the desktop but I gave up on running it on servers that I don't want to actively maintain (think of small, non-critical web servers). Ubuntu works fine there.
I found this a few days ago when I was researching SVG in Flutter. After the initial "why not SVG?" reaction, this is not that bad! As the README says, It is a format for efficient presentation, not an authoring format. You're supposed to author in SVG etc and then export to IVG.
However, SVG Native [1] seems to be very similar, and it's also a subset of SVG, and non-binary.
SVG in Flutter still leaves a lot to be desired. We've ended up building a subset of SVG that can be composed using const code that fills some of the missing gaps in packages like flutter_svg.
That looked interesting until I got to this quote:
"SVG Native is a standalone file type, expected to be rendered with a dedicated-purpose renderer. Therefore, SVG Native content must not be present as part of a larger XML (or HTML) document. If it is present as part of a larger XML (or HTML) document, the content should be interpreted as SVG proper."
reply