Je suis sur le point de commencer à créer un site Web de projet musical pour un ami. Cela devrait être assez simple pour le moment: pas de contenu dynamique (dates de tournée, etc.), et rien de plus que quelques exemples de chansons ou liens SoundCloud intégrés. Je ne m'attends pas à utiliser autre chose que JavaScript et Bootstrap ou Foundation vanilla pour une grille réactive.
Est-ce suffisant cependant? Puis-je simplement télécharger des fichiers HTML, CSS et JS sur un hôte et en finir, ou dois-je prendre le temps de programmer un serveur dorsal en nœud ou en PHP?
Réponses:
Si vous ne savez pas si vous avez besoin d'un code côté serveur, vous n'avez probablement pas *
* Avertissement : le code côté serveur est essentiel pour la sécurité lorsque vous souhaitez contrôler en interne l'accès au contenu, aux données ou aux fonctionnalités. (Il n'est pas nécessaire que ce soit votre serveur, voir le dernier paragraphe.)
Demandez-vous quel problème utiliserait les technologies côté serveur. Si vous ne pouvez en penser à aucune (et dans votre cas, je ne peux pas non plus), vous n'en avez pas besoin.
Sachez qu’il est beaucoup plus possible que vous ne le pensez possible d’utiliser un code côté client. Les infrastructures JavaScript telles qu'AngularJS ou ReactJS peuvent vous permettre d'intégrer du contenu dynamique tiers via des API utilisant Ajax. (Cela inclut la connexion à une API capable de gérer sa propre sécurité.)
la source
Server-side code is essential for security
De nombreux développeurs n'accordent pas beaucoup d'importance à la sécurité. Pas avant d'avoir jeté leur visage dans leur ... bordel. Ma ligne est que si vous avez besoin d'authentification, vous avez besoin d'un back office. Si vous avez besoin de stocker des données, vous avez besoin d'un backoffice où les données seront vérifiées une deuxième fois après avoir été vérifiées par le client.Lisez à propos des générateurs de sites statiques. Celles-ci vous permettent de créer un site de manière programmatique (à l'aide de modèles, de données, etc.) et non de manière manuelle. Le résultat est un ensemble de HTML et de CSS statiques ne nécessitant aucun back-end.
https://www.staticgen.com/ répertorie et classe un certain nombre de ces générateurs à source ouverte; des offres fermées existent probablement aussi.
la source
Can I simply upload HTML, CSS, and JS files to a host and be done with it, or should I take the time to program a backend server in Node or PHP?
cela appelle à souligner qu'il existe une 3ème option intéressante, dans le cas de OP, àVous pouvez et devez utiliser uniquement un site statique si cela est suffisant, ou utilisez un générateur de site statique . Pourquoi? Maintenabilité. Le code a des bugs. Toutes les quelques semaines, un autre trou de sécurité WordPress est trouvé. Si vous utilisez un CMS commun, vous devrez le corriger constamment. Sinon, le site Web de vos amis contiendra bientôt une publicité pour des drogues illicites, la propagande ISIS, des logiciels malveillants installés sur les ordinateurs des visiteurs ou pire. Même si vous le corrigez régulièrement, il se peut que vous soyez trop en retard, vous devez donc rechercher en permanence des piratages. Il existe des moyens de sécuriser ce CMS. Installez des "plug-ins de sécurité", configurez un pare-feu pour une application Web tel que mod_security, etc. Ils doivent également être tenus à jour. Parfois, vos règles mod_security vont casser un plugin pour WordPress, vous devez l’analyser et le corriger. Plus de travail.
Vous pourriez penser que personne ne voudra pirater ce site. Mais en ce qui concerne les failles de sécurité communes aux systèmes de CMS communs, il existe bientôt des robots automatiques qui explorent / recherchent sur le Web et piratent TOUS les sites utilisant ce CMS. Ils veulent juste diffuser leurs liens / malware / propagande.
Avec un site statique (créé manuellement ou avec un générateur), vous n'avez pas ce problème.
Si vous implémentez votre propre back-end, il comportera également des failles de sécurité (personne n’est parfait), mais il est fort probable que personne ne les exploitera pour ce petit site Web. Mais que voulez-vous mettre en œuvre? Si vous souhaitez créer un éditeur où votre ami peut modifier lui-même les dates de la tournée, pensez au temps qu'il faudra jusqu'à ce qu'il soit assez facile pour lui de l'utiliser sans votre aide. Combien de fois pouvez-vous simplement changer rapidement les dates pour lui avec ce budget de temps?
À mon avis, beaucoup trop de gens aujourd'hui n'utilisent que les systèmes CMS pour chaque site, car le HTML statique est "ancien". Si vous n'avez besoin de rien qui ne soit pas possible avec HTML5, utilisez le code côté serveur. Mais si vous n'en avez pas besoin, vous gagnez beaucoup de temps sans cela.
la source
Vous n'avez besoin de faire de la programmation backend que lorsque vous en avez besoin.
Cependant, même les fonctionnalités de base telles que les formulaires de messagerie électronique nécessitent généralement une programmation de base. Si c'est juste un site d'affichage, alors oui, c'est bien.
la source
Pas nécessairement, mais vous rencontrerez probablement des problèmes si vous créez l'ensemble du site en HTML.
De nombreux sites ont les mêmes éléments de menu, en-tête et pied de page sur plusieurs pages. Si vous copiez et collez simplement ceux-ci d'une page à une autre, cela peut devenir fastidieux et sujet aux erreurs lorsque le site s'agrandit et que vous devez continuer à apporter des modifications dans ces domaines.
Auparavant, la programmation côté serveur était si courante. Une façon habituelle de résoudre ce problème consistait à utiliser des cadres pour intégrer ces zones à chaque page. Cela est tombé en disgrâce il y a plusieurs années, donc je ne recommande pas de le faire maintenant. Vous pouvez écrire un simple code côté serveur à la place pour afficher ces éléments communs sur chaque page.
Je suis d’accord avec d’autres ici qui ont recommandé l’utilisation d’un CMS standard.
la source