Ne fais pas l'erreur de penser qu'il existe une structure universelle qui convient à tout. Même en entreprise, l'approche change selon qu'on construise une app monolithique, un système de microservices ou une librairie. Ce que tu peux faire, c'est apprendre les principes communs et ensuite les adapter à ton projet spécifique, au lieu de courir après la dernière mode des tutoriels.
La base qui fonctionne presque toujours, c'est de diviser le code par responsabilité : composants/logique UI séparés de la business logic, les appels API isolés dans des services dédiés, les utilitaires dans des dossiers à part, les tests à côté du code qu'ils testent. Si tu utilises un framework comme React ou Vue, exploite sa structure naturelle et ajoute dessus une organisation pour les fichiers de configuration, les constantes, les helpers. Si c'est du JavaScript vanilla, tu pourrais penser à une architecture en couches (présentation, logique, accès aux données) ou à des modules autonomes avec des objectifs spécifiques.
Ce qui compte vraiment, c'est que ton équipe (ou toi-même dans six mois) arrive à naviguer dans le projet sans devenir fou. Si tu ouvres un dossier et tu comprends tout de suite ce qu'il y a dedans, si le nom des fichiers te dit ce qu'ils font, si tu peux trouver où modifier une feature sans fouiller partout, alors la structure fonctionne. Commence simple, développe au fur et à mesure que le projet grandit, et n'aie pas peur de faire du refactoring des dossiers si tu vois que ça devient confus.