Hi folks,
Here's some #art I got inspired to #draw very recently. At first I had problems coming up with an #idea until I turned on some #music. You may guess what I chose to listen to.
Colpo di #genio estremamente radicale per risolvere un annoso #problema: il creare una data #webapp, che non abbia bisogno di grande interattibilità (vedi un social network, o un CMS), senza dover mantenere 2 #codebase separate e quindi impazzire, facendola funzionare sia con un #server che totalmente senza… ossia, come unire in una sintesi circa accettabile i due maggiori paradigmi del #frontend? 🤔️
Quello antico, delle prime #piattaforme#web, dove il server genera tutto l’HTML e il browser lo visualizza com’è, spesso con (quasi) zero #JavaScript (vedi la Spacc BBS). 📦️
Quello moderno, dove nel #backend si espongono API (spesso JSON REST), e il fronte viene sviluppato a parte come app che gira totalmente lato #client, con il #browser che richiede pezzetti di dati e fa i suoi iperprocessamenti. 💱️
Ormai quello antico non si usa quasi mai per #progetti nuovi, perché gli svantaggi sono pesanti appena si vuole andare un po’ più in là: per tappare i buchi nel progetto medio si finirebbe a dover scrivere talmente tanto #codice#ClientSide, che a questo punto era meglio fare tutto nel secondo modo, senza menzionare i modelli e le #API da esporre nel server che altrimenti non si sarebbero implementati. Però, le webapp antiche girano bene anche sul computer tascabile meno performante (average Ximi), sui browser vecchi, e spesso sono le uniche che vanno quando tutto il resto ti lascia a piedi. D’altro canto però, anche se in teoria quella #app potrebbe funzionare #offline, magari mostrando dati cachabili, se è sviluppata in modo attaccato al server ecco allora che non si può fare nulla: muore il server, muore tutto. 💣️
Quindi la mia #idea paxxerella, dato che devo fare banalmente una #applicazione come frontend per un altro servizio già esistente, ma voglio i vantaggi appena millantati: sviluppare con i paradigmi #ServerSide in un framework JS adatto, che giri sia in Node che nel browser. A quanto pare, qualcuno ci ha pensato prima, e qualcosa di già fatto ho trovato (Express+FrontExpress, Koa+Koa-Client, Rill)… ma è tutta roba ormai abbandonata, che o non funziona (ho provato) o ha altre #rogne. Te pareva che trovavo mai qualcosa di buono già pronto… Però, in un quarto d’ora ho tirato su uno #script scheletrino, giusto per poter partire per questa via. ☠️
Here is a free #idea for whoever wants to take it:
Knowing that LLMs are basically very good at predicting the next word, it is just rational to have a tiny #LLM locally on the phone to assist #keyboard. The data be offline and it collect data from user's typing and get better. It is also essential to have a large button to suppress recording of keyboard for when user inserts private info like passwords, bank details and etc.
@BrokenFlows
I haven't had iPhone for years,but the last time I used it it was "ducking" bad.
And on Android the issue is still there, although gboard is much better that Apple's.
I just think we need to have a fully transparent and opensource keyboard with very very good word prediction. The technology is there, we just need someone with enough knowledge to stitch them together.
stupid idea: bluetooth #sneakernet without internet connections. clients reside on the phone or computer of participants, and peer automatically with one another when close by (or maybe with a public access point), exchanging messages and propagating messages further with every contact. private and public messages can be read via a simple app
which actually sounds like something someone somewhere might already have created.
January is over, so I've got the first page of my calendar for next year, and now I'm starting to look for inspiration for February. The challenge continues!
👉 #Calendar2025