Computer music is as old as computers, live coding is pretty old too. (I posted this in the strudel discussion too: https://toplap.org/wiki/HistoricalPerformances) Maybe everyone doing live streams during the pandemic helped get visibility for live coding? It's interesting to see it kind of becoming popular now.
Ha, yeah I think it's my vim muscle memory that made it feel so weird. `j` going left instead of down and `k` going right instead of up. `h` and 'l` probably would have made me feel right at home though. (And in fairness, changing the keys is trivial in this case!) :-p
Those are Vim bindings. The J key rests right under your index finger (and it’s easy to find it thanks to the nudge on your key), which enables you to spend little to no energy to “scroll down”; the K key is for scrolling up.
I was under pretty much all the false impressions mentioned in the article, it was a nice introduction for me. The name comes up, but I never connected the dots.
I hope this becomes common knowledge! There was a period somewhere between when the web platform didn't have good tools to make web applications (plus DOM manipulation was slow) and the mainstream adoption of es2015 in browsers when it made sense to do things like create a virtual DOM to allow for unavailable features at the expense of performance. It did have its place, but we don't need it anymore.
Remove a layer. In 2025 ES6 is ready for prime time, indeed.
The modern web platform is capable and not bad at all to work with directly. I love seeing projects like HTMX and the recent hyperflask etc showing the way, but you don't need to buy into a project to follow this path, just use the web platform.
Edit: for a more practical example, you don't need to go down the web components rabbithole just for native reactive components, MutationObserver can watch for your template fragments entering and exiting the DOM and run your init/destruct routines on them. Now you can just push HTML back from the server with fetch or xmlhttprequest or whatever, and as soon as your component's HTML enters the DOM it will be "hydrated" by your init routine via MutationObserver. Honestly, add some event signaling and XHR and you're further along to a smooth SPA-like experience than you might think.
Web components, copy/paste CSS that does crazy stuff, all of these Web APIs [0]. However, Vue is my go-to. It's just reactivity with files that don't break "separation of concerns". Plus a community if I get stuck. However however, making something super slim bare bones is the most rewarding.
I've had the same (US) bank for 20 years, it's a small one, they have a nice web interface (and I can deposit checks through it on my laptop) but I've never run into a situation where I needed to have some smartphone app to do my banking. (I also don't have a smartphone.) Is this common with major banks? Do they not have web interfaces anymore?
A lot of major banks worldwide have apps, and they usually require un-rooted phones.
People here seem to think this is some sort of Orwellian attempt to control them, but the reasons are more mundane and technical - many of them (mine included, from two countries) use security facilities on the phone to secure your accounts.
For example, my HSBC UK app has replaced the little calculator thing they used to ship, and uses iOS face recognition to secure the generation of log-on codes which you need in order to use the web interface, as well as for secure access to the banking app directly.
With a rooted phone they don't have the guarantees that these aren't being exfiltrated, or the app being subverted in novel ways, so they don't want to support it.
You may not consider this a good enough reason, and I have heard it said on HN that 'the banks shouldn't get to control what I do on my computing device!', and that attitude is absolutely fine, but then you'll most likely end up with either less secure banking (meaning more fraud, higher fees etc) or going back to having to have a dedicated security device.
> I can deposit checks through it on my laptop
American-like banking detected... who uses checks in 2025?!
:)
> People here seem to think this is some sort of Orwellian attempt to control them, but the reasons are more mundane and technical - many of them (mine included, from two countries) use security facilities on the phone to secure your accounts.
My GrapheneOS phone fully supports such facilities. I trust your app works on it?
I can see how that reads like I'm an app developer! I'm not though, I just meant the apps from my bank that I use.
That looks like an interesting and useful capability.
I don't believe this will satisfy the crowd who want complete control over their systems though, as AFAICT graphene is not rooted by default and will likely fail these attestation checks if you root it. This will also not please the "Passkeys and hardware attestation are evil/non-FOSS by nature" crowd.
Definitely provides more freedom wrt. third-party app stores though.
> American-like banking detected... who uses checks in 2025?! :)
Yeah, fair. :-) I live in a small town, the only check I write is my rent check, which I literally walk across the street to deposit. But I still on rare occasions receive checks as well.
Ha. Fair enough. That sort of thing is almost exclusively done using bank transfers here in Aus.
I did receive one check this year, a refund from a company who had screwed up billing on a medical scan. For some reason they couldn't just refund it to my debit card. It was really annoying to have to get to a bank during opening hours to deposit it, but my bank here doesn't offer mobile check scanning. Some do, my old UK bank did ... oh well.
> going back to having to have a dedicated security device.
... and ...?
There are ways to implement security without tying it to one of two app stores. Companies might even get creative and figure out hardware standards for secure verification that are portable, open, and give the user control. They figured out sim cards, and are worried about GAI they created taking over the entire world, they could figure this out.
Personally I prefer the device convergence rather than having to have another thing to keep track of. Plus the added factor of biometrics over pure hardware 2FA.
But you do you, as they say, the point is there are tradeoffs.
> There are ways to implement security without tying it to one of two app stores.
It's not just about the app store - people want to be able to run these on rooted devices, which is an end run around the security guarantees these apps currently rely on.
> Companies might even get creative and figure out hardware standards for secure verification that are portable, open, and give the user control.
I wish you the best of luck in this endeavour.
I hope that they already aren't relying on client-side security any more than they have to. I'm afraid I'm not familiar enough with the APIs around biometrics to know if there's a useful way a server can use the onboard devices to verify a user's identity without relying on client-side security in one way or another though.
It's true on desktop we have stuff like FIDO2 authentication using hardware tokens, which are supported on open systems like firefox on linux. I'm sure it's not insurmountable or unthinkable to do similar on phones. At the least there would need to be a system of remote attestation for the biometric hardware, and a way for it to provide a verifiable response to a remote server. Far from insurmountable, but someone will need to actually do it.
Goes against FOSS still though if there are processors in the system which can't be user-controlled, and biometric chips which perform remote attestation (see the recent discussions on how passkeys are fundamentally OSS-hostile).
At least with my CU, mobile check deposit is the only function I need a mobile phone for; everything else is equally available on the web interface. (I could go to a physical branch, in lieu of mobile, I suppose.)
They do, but some seem to be gradually removing functionality (like check deposit via scan + upload) in favor of using their amazingly convenient (/s) app.
I have a first generation framework 13, I upgraded the mainboard last year to the 12th gen intel i7-1280P mainboard. My original mainboard was from the first batch with the bios battery issues but still works, though I haven't had success getting it to run standalone in the coolmaster case yet.
I'm happy with my framework 13 four years later. I might switch to the stiffer hinge and/or a matte screen in the future. Might try one of the AMD mainboards in a few generations when they're cheaper and put my current mainboard into another case...
Edit: FWIW I bought a macbook air M1 a year after getting the framework 13, and ended up selling it. The battery life on the macbook air was significantly better, but I can still spend an entire workday in the park with the glossy framework 13 without needing to recharge so the extra battery life from the M1 didn't really have a ton of value for me.
reply