Que faire après HTML/CSS?

Salutations!

Le titre résume assez bien le sujet :

Je pense me diriger vers Javascript côté frontend, notamment Ajax et JQuerry. J’ai entendu qu’il s’agit d’outils puissants, notamment pour les applications web, qui m’intéressent fortement. Connaissez-vous de bonnes ressources à ce sujet? Y-a-t-il des langages frontend plus intéressant pour les applications web?

Côté backend, je pensais à Django. Quid de php et MySQL?

Il y a tellement de possibilités que je me sens un peu perdu.

Je suis particulièrement intéressé par :

• Créer de magnifiques sites-web
• Créer des applications web
• Bidouiller côté serveur/base de donnée, mettre en pratique quelques concepts farfelus qui traînent dans mon esprit
• Bref, plonger dans les méandres du développement web (ouai je sais, c’est pas très précis à ce stade des choses ).

Explorer l’aspect frontend me semble être un bon début. Bien évidemment, je ne me disperse point, je me fixe un objectif et je l’atteint avant de partir sur autre chose.

Merci pour vos réponses!

Je pense me diriger vers Javascript côté frontend, notamment Ajax et JQuerry. J’ai entendu qu’il s’agit d’outils puissants, notamment pour les applications web, qui m’intéressent fortement. Connaissez-vous de bonnes ressources à ce sujet? Y-a-t-il des langages frontend plus intéressant pour les applications web?

Les tendances d’aujourd’hui voudraient que tu continues vers VueJS ou ReactJS au lieu de jQuery & l’Ajax

Créer de magnifiques sites-web

Tu gagnerais du temps avec des blocs préconçus via Material.io ou Vuetify. Grâces à ces frameworks, tu peux intégrer facilement des toolbars, menu, etc… en material design sans avoir à t’embêter avec le CSS.

Côté front ce qui m’a réconcilié d’en faire c’était le React. Sinon apparemment il y a aussi Vue.js qui est pas mal.

Après si tu veux vraiment toucher aux bdd je ne pense pas que django t’aide beaucoup, il s’utilise principalement avec un ORM.

En python pour commencer (avant de passer directement à django) tu peux peut-être passer par du Bottle ou Flask.

Je crois que faire du js, ajax et du Php te permettrons de bien comprendre les choses avant de tomber dans des frameworks.

Tu apprendras plus.

Je suis d’accord avec ça, mais ça dépend des objectifs du PO.

S’il est question d’être rapidement opérationnel, je pense qu’il a mieux fait de ne pas s’attarder sur des outils un peu dinosaures / bas niveau par rapport à ce qui est en vogue actuellement.

Autrement, c’est toujours intéressant de creuser la question.

C’est quand même bien plus pratique une ORM et propre qu’une série de requête SQL en vrac … Aujourd’hui, ça me semble être la base.

Ça dépend. Ce sont deux paradigmes différents. Coder avec React ou Vue.js t’apporte beaucoup sur la notion de composants et les bonnes pratiques pour maintenir ton application (polyfills, cycle de vie, paramètres de compilation etc).

Alors remettons les choses dans le contexte : Ajax est une API pour exécuter des requêtes, Jquery une bibliothèque JS qui te permet de manipuler pleinement le DOM ( = les éléments de la page). Les alternatives à Ajax, il en existe : Axios et Fetch. Pour jQuery on a Umbrella.js, ChibiJs et d’autres.

Tu peux effectivement partir sur n’importe quel back-end et le coupler avec n’importe quel front-end. Tout dépend le langage que tu affectionnes. Il faut toutefois garder en tête que certaines associations sont plus communes que d’autres (en raison du routage) :

• PHP / Django + HTML/CSS + Jquery
• Serveur Node + React/Vue.js/Angular + SCSS

Pour les bases de données, on utilise massivement dans le web MySQL (MariaDb) & MongoDB.

Sur le frontend, je pense que React, Vue.js ou Angular t’apportera beaucoup plus. Sur le backend, difficile à dire, PHP représente une bonne part de marché avec les frameworks Symfony et Laravel puis des CMS comme Prestashop, Magento, Wordpress etc. Mais Django et J2E me semble tout autant populaire.

Je reste toutefois réservé sur l’implémentation des frameworks JS sur n’importe quel back-end, ils font eux même la partie routage que le back-end doit être le seul à réaliser ; je conseillerai pour ça de l’associer avec un serveur Node et réfléchir à une implémentation Server Side Rendering pour le référencement. Après c’est une stack comme une autre, elle doit s’adapter aux besoins du moment. Je sais que certains font du Symfony + React ; j’ai un peu plus de mal à voir l’intérêt de Symfony en l’occurrence, toutefois c’est possible …

D’une manière générale, se lancer dans un framework sans connaitre les bases du langage (quelles que soient le langage et le framework), c’est aller dans le mur. Dans le meilleur des cas, tu sauras utiliser un framework précis, ce qui sera pratique… jusqu’à la nouvelle version du framework qui change pas mal de comportements, ou jusqu’à l’arrivée d’un concurrent.

@Yarflam je ne comprends pas où tu veux en venir avec ceci :

Je reste toutefois réservé sur l’implémentation des frameworks JS sur n’importe quel back-end, ils font eux même la partie routage que le back-end doit être le seul à réaliser ; je conseillerai pour ça de l’associer avec un serveur Node et réfléchir à une implémentation Server Side Rendering pour le référencement

J’ai le sentiment que c’est valable pour beaucoup de choses en informatique au-delà des frameworks et autres joyeusetés quand même.

C’est là qu’il convient de se demander si s’adapter aux frameworks à la mode est une bonne chose. De ce point de vue je ferais davantage confiance à un outil qui fait ses preuves depuis 10 ans et qui est encore utilisable aujourd’hui (il convient de préciser ce dernier point qui a toute son importance selon moi).

Si un langage n’évolue pas trop / ne comporte pas de changements rétro-incompatibles, ça peut être plus intéressant de l’apprendre.

On a parlé de Django. Comment ça se passe au niveau des versions ? Y a-t-il beaucoup de changements significatifs d’une version majeure à une autre ? Les connaissances acquises grâce à ce framework deviennent-elles rapidement caduques ?

Pour pouvoir associer un back-end PHP avec un framework JS, y’a trois méthodes possibles :

• Utiliser comme API : le back-end échange les données avec le front-end via un échange de requête. Le risque est de dupliquer la partie métier et de perdre l’intérêt des routes du back-end. Tout comme une partie du référencement.
• Modifier le DOM : le front-end va modifier un élément de la page pour afficher un rendu spécifique. On est pas sur de l’affichage intégral, ça reste raisonnable dans la mesure où le contenu est déjà chargé par le back-end. On est obligé de recharger le bundle à chaque changement de page, ce qui n’est pas pratique pour une maintenir une connexion (par exemple avec un Socket) - même chose d’ailleurs avec la solution via API interposé.
• Un bundle intégral : dans ce cas-là on se dit que le back-end est réservé au back-office (l’administration) et le front-end JS au front-office. Le mieux dans ce cas est d’externaliser le rendu pour utiliser les routes de React et appliquer le Server Side Rendering ; ça nécessite un second back-end en Node ou un dépôt avec des snapshots pour le référencement (le contenu est figé).

Après toutes les stacks apportent leurs lots de solutions mais à mon avis … cette construction n’est pas idéal. Apprendre un langage, le Javascript, pour le back-end et le front-end me semble plus rationnel.

J’ai le sentiment que c’est valable pour beaucoup de choses en informatique au-delà des frameworks et autres joyeusetés quand même.

Oui, oui et encore oui !

C’est là qu’il convient de se demander si s’adapter aux frameworks à la mode est une bonne chose. De ce point de vue je ferais davantage confiance à un outil qui fait ses preuves depuis 10 ans et qui est encore utilisable aujourd’hui (il convient de préciser ce dernier point qui a toute son importance selon moi).

Si un langage n’évolue pas trop / ne comporte pas de changements rétro-incompatibles, ça peut être plus intéressant de l’apprendre.

De nos jours c’est un réel problème. Les langages évoluent un peu trop vite. Python, Rust, JavaScript, C++, Java, Go. Tous ces langages évoluent rapidement.

On a maintenant des langages qui évoluent plus vite que leurs frameworks. La création d’un live standard HTML démontre bien ce que je veux dire. On perd en universalité pour gagner en fonctionnalités.

Ça force à se tenir à jour sur de vaste sujet, c’est un problème pour moi.

@OP: De nos jours, le back-end, c’est Python / NodeJS / Java. Je retrouve parfois du Go et du Ruby sur des projets issues de l’autre boue du monde.

Prend une de ces technos, celle qui te convient.

@Ge0 : tout dépend de ton usage et de la durée de vie de ce que tu veux produire. Les frameworks modernes (back ou front) te simplifient massivement la vie et te permettent de te concentrer sur le code métier, donc celui qui a réellement de la valeur pour toi.

En choisissant ton framework, tu dois t’assurer :

• Qu’il te simplifie vraiment la vie
• Qu’il est assez maintenu et à à jour pour voir ses failles corrigées et les dernières technologies prises en charge (derniers navigateurs web pour du front, dernières JVM pour un framework d’un langage à JVM…)
• Que l’effort de mises à jour du framework est raisonnable (pas de nouvelle version trop souvent, montée de version documentée)

Tu vas probablement avoir besoin d’un système plus stable et moins évolutif pour du back, qui peut rester longtemps en place, que pour du front, où les technologies et habitudes changent souvent – la capacité à changer rapidement peut devenir un atout.

Choisir un langage ou un framework pour un projet, ça peut donc être quelque chose de non trivial.

Je suis sincèrement désolé, @Yarflam, mais ça fait plus de dix ans que je fait du développement « web » professionnel, et pourtant je ne comprends rien à ce que tu racontes. Je pense que c’est en partie un problème de vocabulaire, tu utilises des termes que je connais mais qui ne font pas sens pour moi dans ton message.

• Quelle différence tu fais entre tes points 1 et 2, ou 1 et 3 ?
• Qu-est-ce que tu appelles « un bundle » ?
• Pourquoi « les routes du back-end » semblent importantes pour l’utilisateur final pour toi ?
• Tu as l’air de considérer que l’on ne sait pas référencer des SPA, alors que si

PS :

De nos jours, le back-end, c’est Python / NodeJS / Java. Je retrouve parfois du Go et du Ruby sur des projets issues de l’autre boue du monde.

Le choix du langage back-end dépend aussi beaucoup du type de projet et assez curieusement du pays. On trouve de plus en plus de Go dans les architectures microservices. Java est historiquement lié à de gros monolithes mais a maintenant un très bon écosystème microservices. Ruby est beaucoup plus présent en Amérique qu’en Europe, etc.

Pour différencier les points dans les détails, je te conseille de regarder cette vidéo : https://afup.org/talks/2187-comment-marier-symfony-et-reactjs.

La 1ère implémentation consiste à définir une API avec le back-end PHP et à l’utiliser avec un bundle JS (routes PHP et contenus asynchrone en JS) alors que la 2ème ne s’intéresse qu’à une fonctionnalité (rendu PHP intégral, modification parcellaire en JS). Par exemple un chat dans un coin de la page. La 3ème solution est plus radicale puis-ce qu’elle écarte pour la partie front-office (ou back-office au choix, l’un ou l’autre) l’utilisation du rendu PHP pour la remplacer par un rendu intégral en JS (routes et rendus en JS).

Un bundle au sens d’un script JS compilé avec Webpack. La forme finale de la mise en production d’un framework JS. Je n’ai pas une définition différente.

Concernant les routes, je ne dis pas que celles du back-end prévaut sur celles du front-end. Seulement qu’il faut faire un choix. Dans la 1ère et 2ème implémentation, on se réfère clairement aux routes du back-end, ce qui empêche la continuité des cycles de vies des composants front-end ( -> chaque changement de page, nécessite de relancer le bundle, donc de perdre potentiellement des connexions Web Socket ou un état des composants que l’on aimerait conserver).

Les SPA sont effectivement référencés par Google mais ce n’est pas le cas des autres crawlers. Le rendu étant bien plus lisible lors-ce que la page contient déjà du contenu HTML, ça fait partie des bonnes pratiques. Si tu regardes les sites qui utilisent des bundles JS, ils passent tous par des pré-rendus HTML.

Côté backend, je pensais à Django. Quid de php et MySQL?

Django c’est un framework en Python. PHP un langage. Il te faudra un certain bagage en Python avant d’apprendre Django. Comme il te faut bien connaître le PHP avant d’apprendre un framework en PHP.

Il y a tellement de possibilités que je me sens un peu perdu.

Au contraire je trouve que le développement d’applications web est largement dominé par une infime poignée de langages et technologies. Mais ce n’est que mon avis.

En effet c’est pas précis. Si t’as un projet, on pourra te donner les avantages et inconvénients d’un framework, un SGBD, par rapport à un autre.

S’il s’agit d’apprendre pour le plaisir, personne ne peut choisir à ta place !

Je suis mitigé par rapport à ça.

Je pense qu’il d’autant plus comprendre comment le web et le protocole HTTP fonctionnent si l’on veut utiliser un framework pour construire un site web dynamique avec du traitement de données en arrière plan.

Les pré-requis en Python ne me paraissent pas énormes pour savoir utiliser Django. En revanche, comprendre ce qu’est une requête HTTP, son traitement par Django, ce qu’est une réponse etc. C’est essentiel.

En tout cas je recommande à quiconque voulant faire un site avec Django de ne pas attendre de savoir faire du Python. C’est en résolvant des problèmes d’ordre réel (à savoir, « faire mon site sous Django pour permettre à des gens de s’inscrire et poster des commentaires » par exemple) que vous apprendrez à utiliser les outils qui permettre de résoudre ces problèmes.

Apprendre un langage pour apprendre un langage a aussi son intérêt… Mais je persiste et signe : c’est beaucoup plus stimulant quand on a un objectif concret.

En plus, en ce qui concerne Python, le problème qu’il résout parmi tous les langages, c’est qu’il est peu verbeux et assez facile à prendre en main. Donc pour le certain bagage je suis vraiment mitigé.

Je suis d’accord, c’était peut être trop appuyé comme expression "un bagage" mais il faut quand même un minimum de connaissances en programmation orientée objet et python. Pour un débutant et autodidacte, c’est tout bête, mais la plupart des cours et bouquins que j’ai lus sur Django attaquent sur le framework et considèrent les bases du langage python comme acquis. Je pense que c’est nécessaire de connaître a minima python ou un autre langage de programmation avant, pour éviter des erreurs à la con de syntaxe ou problèmes de type qui vont faire perdre du temps dans le développement et qui n’ont rien à voir avec Django.

Carrément d’accord.

Après il m’est arrivé de "jouer" à programmer sans but précis. Pour se faire la main, y’a les cours avec exercices sur ce site. En cas de pénurie d’idée, y’a Codingame.