Deno, le moteur d'exécution JavaScript et TypeScript créé par Ryan Dahl (le développeur qui avait déjà lancé Node.js il y a une quinzaine d'années), s'apprête à faire un sacré pas de côté avec sa prochaine version majeure, qui permettra de fabriquer des applications de bureau pour macOS, Windows et Linux à partir du même code, et même depuis une seule et unique machine.

La fonction, baptisée Deno Desktop, a déjà débarqué discrètement dans la version 2.9.0 distribuée en canal canary, c'est-à-dire la branche de test réservée aux plus curieux d'entre vous, mais pas encore sur la version stable.

L'idée est simple : vous prenez un projet web écrit en TypeScript, ou construit avec des outils connus comme Next.js, Astro, Fresh ou Vite, et Deno le compile en un seul fichier exécutable qui embarque votre code, le runtime et le moteur d'affichage, prêt à distribuer tel quel. Un petit serveur web local est même glissé dans le paquet, ce qui veut dire qu'une appli web existante peut migrer vers le bureau sans qu'on réécrive quoi que ce soit.

Pour afficher votre interface, vous avez le choix entre trois approches, et c'est sur le poids final que ça se joue. Par défaut, Deno s'appuie sur la WebView native du système, autrement dit le moteur d'affichage web déjà présent sur votre Mac ou votre PC, ce qui donne une application d'environ 68 Mo sur macOS.

Si vous préférez la régularité d'un Chromium complet d'une plateforme à l'autre, vous pouvez embarquer le CEF (le Chromium Embedded Framework, en gros un navigateur Chrome entier glissé dans l'application), mais le poids monte alors au-delà de 300 Mo. Et pour les plus aventureux d'entre vous, un mode brut, sans moteur web laisse gérer soi-même les fenêtres et le rendu via WebGPU ou Skia.

Trois moteurs, donc. À vous de choisir.

Forcément, on pense tout de suite à Electron, la techno derrière Slack, Discord ou VS Code, réputée pour produire des applications obèses, et à ses rivaux plus légers que sont Tauri, Electrobun ou Dioxus. Deno débarque sur un terrain déjà bien occupé, avec quand même un argument solide : le même outil sert au serveur, au site et maintenant à l'application de bureau.

Sauf que voilà, tout n'est pas encore en place. La fonction n'est pas stable, certains testeurs ont vu le bouton de fermeture des fenêtres refuser de marcher sur macOS, le sélecteur de fichiers et l'accès au presse-papier manquent toujours à l'appel, et le support mobile reste à l'état de promesse. Les menus natifs, les menus contextuels, les boîtes de dialogue système et les notifications répondent déjà présents, eux.

La vraie question, du coup, c'est de savoir si Deno ne se disperse pas. Le projet vit avant tout grâce à son runtime, et certains se demandent si fabriquer un concurrent à Electron ne va pas siphonner l'énergie qu'il faudrait au coeur du moteur.

Bref, recycler un site en appli de bureau sans tout réécrire, et bien pourquoi pas ?

Source : The Register

Ce matin, je cherchais un moyen simple de tester des webhooks en local sans passer par ce bon vieux Ngrok qui est devenu un peu relou avec ses limites en version gratuite. J'ai d'abord pensé à monter mon propre serveur VPN (coucou Tailscale), mais franchement flemme.

Et puis tout à fait par hasard (aaah les joies de la sérendipité) je suis tombé sur cet outil qui devrait vous plaire, surtout si vous développez des applis qui doivent recevoir des notifications HTTP (GitHub, Stripe, Slack...). Ben oui vous connaissez la galère... votre serveur de dev est sur "localhost", donc inaccessible depuis l'extérieur, du coup, impossible de recevoir ces fameux webhooks sans ouvrir votre routeur ou utiliser un tunnel.

C'est là qu'intervient Webhooks Proxy Tunnel !

Grâce à cet outil, au lieu de multiplier les intermédiaires, vous déployez votre propre tunnel... directement sur l'infrastructure de Cloudflare. Et le meilleur c'est que ça tourne généralement très bien sur leur offre gratuite (dans la limite des quotas Workers évidemment, donc attention si vous bourrinez comme un fifou).

L'outil utilise un Cloudflare Worker couplé à un Durable Object (une sorte de mini-serveur d'état). Le Worker reçoit alors les requêtes publiques sur une URL en HTTPS (genre "truc.workers.dev") et les transmet via une WebSocket à un petit client Node.js qui tourne sur votre machine. Et hop, le trafic arrive sur votre port local.

Perso, je trouve ça brillant car même si le trafic passe techniquement par Cloudflare (puisque c'est leur infra), vous gardez la main sur le code qui s'exécute et vous évitez d'envoyer vos données à un service tiers supplémentaire dont vous ignorez tout.

Pour l'installer, ne plus c'est hyper fastoche. Il vous faut juste un compte Cloudflare et Node.js. J'ai testé l'install en moins de 5 minutes, vous clonez le dépôt, vous installez les dépendances et vous lancez le déploiement (qui vous demandera de vous authentifier) :

git clone https://github.com/peter-leonov/webhooks-proxy-tunnel.git
cd webhooks-proxy-tunnel/worker
npm install
npm run deploy

Et si on pouvait coder un serveur web sans écrire une seule ligne de JavaScript, de TypeScript ou tout autre langage de programmation ? Juste des instructions en anglais (ou en français) tout ce qu’il y a de plus classique dans de simples fichiers texte ?

Ça paraît dingue mais c’est exactement ce qu’a réussi à faire un développeur un peu fou avec Node.js et OpenAI !

Son projet baptisé Node-in-English est donc composé de fichiers sources qui sont des .txt contenant des commandes détaillées en anglais dans le texte. Un script de build Node.js se charge alors de « compiler » ces fichiers pour générer automatiquement le code du serveur et le déployer. Cette technologie repose ainsi sur l’utilisation du langage naturel pour définir les actions et comportements d’un serveur web et le script utilise l’API d’OpenAI pour interpréter ces instructions textuelles et générer le code nécessaire pour créer les endpoints du serveur. Chaque build consomme ainsi environ 4000 tokens chez OpenAI.

Évidemment, on ne peut pas juste demander « build me a server »… Les instructions doivent être suffisamment précises pour guider le modèle de langage vers le résultat attendu. Cela implique une certaine compréhension des librairies et frameworks sous-jacents, et l’auteur admet d’ailleurs que l’expérience de coder en langage naturel est plus frustrante comparée à un vrai langage de programmation car la quantité de texte et le nombre d’essais nécessaire pour obtenir un résultat précis est bien plus important.

Mais l’idée c’était plutôt de montrer ce qu’il est possible de faire à des gens qui ne peuvent pas, ne veulent pas ou n’osent pas se lancer dans le développement classique. Un genre de porte d’entrée vers le développement en douceur, en quelque sorte. L’auteur voulait surtout voir s’il était possible de construire un serveur sans écrire de code et comprendre dans quelle mesure des compétences techniques étaient nécessaires pour créer un serveur web fonctionnel.

Le serveur généré, accessible sur https://nie.avoguard.com/, propose plusieurs endpoints basiques :

• / : une page d’accueil HTML listant les différentes routes
• /list : retourne la liste des endpoints au format JSON (ou parfois un tableau JSON, selon son humeur du jour)
• /quote : affiche une citation aléatoire à partir d’une liste générée lors du build
• /ping : répond « pong », ce qui est toujours rassurant
• /about : retourne une courte description du serveur, ou une erreur 404
• /contact : retourne des informations de contact, ou une erreur 404

Des endpoints DELETE et POST font aussi parfois leur apparition de manière aléatoire selon les compilations.

C’est là tout le charme (et le côté flippant) de la chose… On a beau fournir les mêmes instructions en entrée, on n’est jamais certain de ce qu’on va obtenir à l’arrivée.

Maintenant, d’un point de vue technique, les fichiers .txt du dossier text-src sont combinés dans l’ordre défini dans le script /index.js, qui représente l’unique morceau de code écrit par un humain. L’auteur compte améliorer son système pour permettre de définir des routes plus complexes et plus fiables et y’a même une petite doc pour ceux qui veulent essayer de compiler ça eux-même.

Alors, est-ce que coder en français ou en anglais est l’avenir du développement web ? Peut-être un jour mais pour le moment, on reste quand même sur un projet bien expérimental, avec un Proof of Concept à la fois amusant mais surtout instructif au niveau de ses prompts.

Alors qui sait, peut-être que dans quelques années le métier de développeur consistera à remplir des fichiers .txt plutôt qu’à pisser des lignes de code obscures. Une sorte de no-code nouvelle génération en somme…

Source