https://octospacc.altervista.org/wp-content/uploads/2024/03/image-6-960x960.pngI side #projects non finiscono mai: ogni volta vengono quelle #idee che devono per forza essere stuzzicate… e puntualmente ciò che doveva essere un progettino di 1 giorno o 2 si protrae sempre più a lungo (e se non è tecnicamente già successo, sta nell’aria), e da #progetto collaterale diventa un nuovo progetto principale. E i #progetti precedenti? Beh… diventano a loro volta secondari! 😬️Praticamente, qualche settimana fa pensavo che avere una roba simile alla #fotocamera DSi (si, ormai quello è un chiodo fisso nel mio cervello, anche se mezzo arrugginito, e l’articolo non è ancora finito) ma open-source e per dispositivi #mobile moderni sarebbe figo, si può sviluppare qualcosa di versatile e potente… però non avevo personalmente iniziato nulla. Da però qualche giorno ho pensato di voler creare una piccola #webapp semplificata per fare questi memini con le scritte, e magari pure varie decorazioni (per il momento sto usando GIMP, che è molto tedioso). Stamattina ho pensato… “Perché non unire tutte e due le cose? Una versione molto basica riesco a farla in qualche giornata scarsa…”… si si 🤣️
Beh, non iniziamo al meglio, perché la prima metà giornata l’ho spesa a pensare “hm ok voglio qualcosa di multipiattaforma”, ma “il mio amore #web vanilla non va bene perché su telefoni più scrausi con camere marce non girerebbe bene, e quindi “vabbé quasi quasi provo #React Native”, solo che “ah mi sa che per avere un canvas di disegno su tutti i target di build devo usare questa libreria particolare”, peccato che “aiuto è un casino tra documentazione e dipendenze dell’ambiente non so cosa è più mentale”, e quindi “aspetta ma se usassi Godot?”, per poi scoprire che “mannaggia solo la versione iOS di Godot supporta le fotocamere (non ci godo[t])”, e allora “vabbé, Unity funzionerá”, e quindi via con la pazienza di installare un SDK LTS vecchio che supporta ancora Android KitKat (è stato lentissimo sulla mia VM cloud), peccato che poi “aiutoooo Unity è complicatissimo è impossibile fare qualsiasi cosa senza soffrire”, e anche se “magari ci sono altri engine #multipiattaforma che fanno al caso mio?”, purtroppo “no, non esiste un bel niente”. 😶🌫️️
E comunque alla fine mi sono convinta che in qualche modo questa cosa l’avrei fatta funzionare per forza su #ReactNative, che di tutte le probabili #soluzioni mi sembra ancora quella meno malata; per fortuna, #giochicchiando fino all’ora precedente (con non poca confusione), ho tirato su una base che mi dimostra all’atto pratico che ciò che mi serve è facilmente implementabile. Quindi, essendo la domanda del perché sempre esaurita da un “perché no?”, e risolto il dubbio del come, ora l’unica cosa che mi chiedo è il quanto… quanto #tempo e sudore prima di pubblicare la prima grezza build online? 💀️ (Ammesso che vada tutto liscio, perché sulla carta ora dovrebbe, ma nella pratica non ho ancora testato il funzionamento su Android, solo quello via browser…)
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. ☠️