I wonder, if there were an open platform to exist that people use increasingly, maybe that would be incentive enough for at least one bank/financial app to permit that platform just to get a competitive advantage.
In the meantime probably the best that can be done is having a regular phone and a banking phone.
Maybe the answer is to put whatever the banks etc need on something like a smartwatch. Smartwatch + phone is better than two phones IMHO and they're so tedious to use/install anything on that it reduces the attack surface for hackers etc. Tap to pay or digital signatures or identity, passkeys etc via a smartwatch interaction seems like a good use case. Sort of a souped up yubikey. I don't know how good biometrics is on watches nowadays but my Pixel phone has some sort of camera behind the screen to read fingerprints so I can't imagine its impossible. Even adding a capacitive pad on a band seems plausible. Who knows, I don't feel like biometrics have been a real focus of design in the smartwatches I've used.
Personally, I have found smartwatches fairly useless (I do enjoy the activity tracking and notifications but that's not much really) so freeing my phone from bullshit by moving some functions to a watch could increase the value/utility of a some sort of smartwatch. Ultimately, it doesn't need to be that "smart" even.
Still, the problem is that if you go this way, you'd have to put almost all useful functionality of a modern phone on a smartwatch, at which point you could just ditch the phone.
It's not just one tiny use case that's pushing us down the road of increasingly locked down devices. It's most use cases - because no matter the service, it's more profitable for the provider to control what you can and cannot do.
I don't think that's actually true? That's like insisting all useful functionality would have to be moved to a smartcard/yubikey/bitcoin hardware wallet/TPM etc. The main reason this is an issue is to prevent emulated hardware tokens. If you can disable secure boot, you can emulate secure elements and then things that others (i.e. your bank, government, etc) believe are carefully controlled secrets are not.
Doubtful - the costs of supporting it far outweighs any gain they'd have. In case of banks, the costs of supporting aren't just about developing software for an additional platform, but also insurance premiums and managing fallout of hacks (which always eventually happen) - both of which would go way up, as the company would be voluntarily supporting endpoint decides that are less secure than "industry standard" minimum.
Both convex and Instant let you build apps quickly without worrying about the backend. Where Instant differs, is that queries and transactions can run on the client: you get optimistic updates and offline mode by default. On the other hand, convex lets you define queries as functions that can run on the edge. I haven't used convex deeply, but this is my understanding.
Thank you so much!
I’m a first time builder of a bigger CRUD app. While I’m happy to build it with traditional methods the first time (REST API, SSE, auth etc.) I would love to use offers like Instant or Convex in my next projects.
Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks? From what I know it has more fine grained reactivity than for example React or Vue and should therefore just run more efficient? Or has the approach of Svelte also drawbacks that I am not aware of?
> Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks?
I personally would say no. I like Svelte's dev experience but I don't like the output code and while it has smaller invalidation subsections than a full component there's not a 1 to 1 mapping between a piece of data changed and the exact piece of DOM getting updated.
> Or has the approach of Svelte also drawbacks that I am not aware of?
Svelte is superb for producing NYT infographics and other relatively lightweight experiences. I work on interface builders and when you're scaling up the number of components on a page and the complexity then having the reactivity code repeated in the components instead of shared in a library becomes a drawback. What pushed me off of of Svelte was a ~500 loc component that had ~40 reactions and resulted in a 4.1k LoC js file output. I looked through the output and didn't see any particularly egregious mis-compilations, just that the Svelte's approach resulted in verbose outputs. I don't think most people will have components this complex so I don't think Svelte is a bad choice and I do like the DX but that caused me to move on.
Of the current options, I recommend Solid. It has fine grained reactivity all the way down, better perf, similar bundle size, and the community is generally performance obsessed. They're currently experimenting with islands/partial hydration/mixed server+client rendering and preliminary results are halving the delivered JS. As an example, their movies demo [1] is ~15k.
For example, angular, react, vue, etc. You can follow these tools as their popularity comes and go, but at the end of the day they exist on top of HTML/CSS/JS. So while these 3 basic blocks are there to stay forever, the tools on top are a game of musical chairs.
I'm not saying that they are bad. I've been using them at works for years. I'm saying that some people chose to focus on "old" tech and produce web pages and webapps without much tools. The advantage of this approach is that your environment is stable so you can actually learn and master the tools. You can even find crazy tricks and "abuse" some of the features as you become really good at those.
It can be liberating to stop changing tools every year, but instead learn the intricacies of the basic tools that will never change.
In the meantime probably the best that can be done is having a regular phone and a banking phone.