Handlebars.js is the worst templating language in existence, but, if you have to use it, and need some sort of "global" value in your templates, e.g., a csrf_token, then you can use this:
You can now create HTML and CSS fragments in Kitten.
This introduces two new file extensions (.fragment.html and .fragment.css) and you can import these fragments into your pages and into other components and fragments as if they were JavaScript modules*.
[Screenshot of terminal window showing hx (Helix Editor) with two panes. Left pane, selected, shows source of Markup.fragment.html: I’m some HTML from Markup.fragment.html.
${SLOT} I’m some other HTML Markup.fragment.html.
${SLOT.other} I’m yet more HTML Markup.fragment.html.
Been using Volta for a long time now to manage my #nodejs setup, but been slowly feeling like it's being made redundant with Corepack becoming more mature.
I switched to Mise for a few weeks and found a few interesting things 😀
Especially the part where you can just publish your TypeScript package without transpilation, and they handle #NodeJS /NPM compatibility is pretty big for IMO.
My team at Wolt is looking for a staff+ engineer proficient in either #Python or #Nodejs.
The position is fully remote as long as you live in or willing to relocate to Stockholm, Berlin, or Helsinki. If you know someone who might be a great fit, I’d love to have a chat.
I'm working on a JS script that lets you manage packages on Linux (and maybe also Windows) from #NodeJS, as part of Zentrox. I'll see how it goes. If it works fine, I'll try to make it a small library.
I have been trying to get the Lume static site generator to run inside a #Dropserver sandbox, but I have been running into all kinds of issues: some modules written for #NodeJS assume they have read permissions for the entire disk, and error out when you run them with restrictive permissions. Any project that uses #PostCSS + #autoprefixer (ie most build systems) will hit this.
La dualità del fixare #bug (o, in generale, far funzionare il #software?):
Perdi almeno 1 ora buona appresso ad un #glitch oscurissimo (spoiler: la codifica del testo centra sempre in tutti questi bug, in realtà estremamente stupidi), facendo svariati test e tentando varie opzioni prima sensate, e poi senza senso perché altrimenti non sai nemmeno come continuare. 🤥️
Nel frattempo si è fatto #tardi in culo, ti prepari per andare a #dormire e nel frattempo pensi, ma niente… a metà spegni ormai il PC, finisci di prepararti, e continui a #pensare, e solo a quel punto un’idea ovvia viene in testa. Troppo tardi ormai. 💀️
E poi ancora, perché le #incoerenze non sono mai abbastanza:
Giustamente nel letto ti irrequieti e non prendi #sonno, perché il cervello non prende pace senza vedere il #problema finalmente risolto dopo tutta la #pazzia passata, anche scommettendo che l’#idea appena venuta è giusta al 100%. 🥴
Però prima o poi il sonno lo prendi, e dopo ore arriva la #mattina dopo, in cui la sveglia suona e… pensi “zzzzzzz voglio stare nel lettino ancora, tanto la #rogna in mente l’ho risolta, chi me lo fa fare di ammazzarmi a prima mattina [prima mattina: le 9:30, ndr.]”. 🥹
Insomma, è una #condanna. Non se ne esce. Comunque si, il mio #errore era #stupido: stavo cercando di caricare #file nella galleria cloud di #WordPress tramite la #API REST, ma ricevevo sempre un rest_upload_sideload_error… controllo gli header, tutti giusti; cerco in giro, poca roba che non mi aiuta; provo #minuzie come mettere gli header lowercase, ancora niente; tento di settare a mano content-type parziali o estensioni file arbitrarie, e ovviamente non risolvo. 🤯️
Però, noto che un caricamento da curl, anziché dal mio #codice JS, va a buon fine. Allora, provo a caricare verso un server netcat in entrambi i modi, così da poter vedere al volo i dati della trasmissione #HTTP, e noto una differenza stronzetta: il corpo generato dal mio #server è molto più grosso del peso normale del file… quindi qualcosa lo sta corrompendo E qui, però, mi sono ribloccata. 🤔️
Solo poi, quando ormai avevo chiuso tutto come ho detto, ci ho pensato: ma io, nella parte del #programma che legge i #dati trasmessi dal client, vado a castare tutto ad una stringa; sarà questa la causa? …E, ricordandomi di altri #incidenti simili capitati in #NodeJS, capisco subito che è così. Detto in breve: la #codifica del testo centra sempre e rovina ogni cosa. Se esistesse solo l’ASCII, ecco che castare dati binari a stringhe non causerebbe alcun danno. E invece abbiamo deciso che i #computer devono supportare nella loro codifica migliaia di #caratteri discutibili, come tutti quelli emoji. E io, dopo aver apportato questo #fix, devo ora continuare a programmare. Non. Se. Ne. Esce. 😭️
Looks like there is going to be a Node.js documentary soon! Apparently there is even a honorary mention of yours truly. Although I don't know if it there is going to be more than my avatar in the documentary 🤣 Will have to see once it is released!
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. ☠️