Trolldi ; quelles sont les différences entre le développement back-end et le développement front-end ?

Trolldi : quelles sont les différences entre le développement back-end et le développement front-end ?
Partagez votre expérience

Dans l’industrie web, il n’est pas rare d’entendre les termes back-end et front-end, qui sont souvent utilisés pour faire la différence entre les développeurs dans ce secteur. Compte tenu du fait que les rôles et les profils des développeurs dans ce segment ont évolué au cours de ces dernières années, il est parfois difficile de comprendre ce que fait concrètement chacun. Aussi, pour mieux cerner leur importance, il est indispensable de connaître la différence entre ces deux métiers complémentaires.

Le développeur front-end :

Lorsque nous parlons de front-end, nous entendons frontal. En clair, il s’agit de tout ce que l’utilisateur voit : il est donc question ici d’éléments du site visibles sur l’écran dont certains peuvent générer des interactions (boutons, liens, listes déroulantes, etc.).

Parmi les langages/technologies utilisées, nous pouvons citer le HTML pour la structure du site, le CSS pour l’agencement et le JavaScript pour le contrôle. Notons que d’autres éléments peuvent constituer cette liste, comme le framework CSS Bootstrap, la bibliothèque JavaScript JQuery ou encore Java EE pour le développement d’applications web.

Il y a parfois plusieurs postes associés à la notion de front-end. Il faut se rappeler que cela peut être subjectif ; tandis que développeur front-end peut signifier X pour l’entreprise A, la notion de front-end peut englober Y pour l’entreprise B.

L’un des titres de poste à pourvoir qui revient souvent du côté du front-end est « web designer » (concepteur de site web). Cette appellation peut désigner quelqu'un qui produit des maquettes graphiques de sites dans un programme comme Photoshop ou Fireworks. Si auparavant ils ne touchaient pas de ligne de code, force est de constater que de plus en plus de web designer ont franchi la barrière et ont des notions de HTML et CSS. Dans certains cas, ils sont aussi capables de produire du JavaScript. Mais web designer peut également faire référence à quelqu’un qui a une grande expérience en HTML, CSS et JavaScript par exemple.

Un développeur front-end peut créer un site web sans qu’un développement back-end ne soit nécessaire. Dans ce cas, il s’agit de sites statiques : comme une vitrine pour un restaurant, un salon de coiffure, qui ne nécessitent pas que des informations soient stockées dans une base de données. Les pages vont donc sensiblement rester les mêmes et ne seront pas modifiées en fonction des interactions avec les visiteurs.

Le développeur front-end peut donc être une personne issue du milieu du web design qui a renforcé ses connaissances en développement, mais peut aussi être un développeur qui a choisi de se spécialiser dans les technologies et langages renvoyant au front-end.

http://www.developpez.com/public/ima...nd-backend.jpg

Le développeur back-end :

Tandis que le développeur front-end se charge de la partie visible de l’iceberg, le développeur back-end travaille sur les éléments invisibles aux utilisateurs depuis le navigateur, mais indispensables au bon fonctionnement du site/application web. C’est ici qu’intervient la notion de site dynamique, qui est en constante évolution et mis à jour en temps réel avec des informations comme le nom de l’utilisateur et son avatar une fois qu’il s'authentifie, l’affichage de messages reçus, etc.

Parmi les éléments invisibles, nous pouvons citer le serveur, une espèce de disque dur accessible en tout temps, sur lequel les pages du site web sont enregistrées. Le code que les développeurs back-end écrivent va établir une communication avec le serveur et indiquer au navigateur ce qu'il faut utiliser/ajouter dans la base de données.

Notons également que le développeur back-end se charge des bases de données, élément vital pour conserver, traiter, modifier, afficher, utiliser des données comme les mots de passe, les noms, la liste des livres consultés, etc.

Ici, le développeur fait appel à des langages comme PHP, Ruby, Python, Java et SQL (ce dernier revient souvent pour les bases de données). Bien entendu, une connaissance de framework ou bibliothèques peut être très utile. Notons par exemple Cake PHP et Symfony qui figurent parmi les frameworks PHP les plus populaires.

Les développeurs back-end s’inquiètent également de la sécurité d’un site web

http://www.developpez.com/public/ima...ont-back-2.jpg

En conclusion

Nous n’avons pas pu énumérer toutes les différences entre les développeurs front-end et back-end, même si elles peuvent varier étant donné qu’il n’existe pas de norme industrielle sur ce que ces deux notions représentent exactement. Notons qu’il y a de plus en plus de développeurs qui font à la fois du front-end et du back-end, ces développeurs sont souvent appelés « full stack ».

Et vous ?

:fleche: Quelles différences pouvez-vous relever entre le développement front-end et le développement back-end ?
:fleche: Êtes-vous plutôt front-end ou back-end ?
:fleche: Quel est le plus valorisant entre les deux ?
:fleche: Lequel des deux devrait prendre les décisions globales sur le projet ?
:fleche: Est-il préférable d'avoir une équipe de full stack ou une équipe de front-end et une équipe de back-end ?
:fleche: Pouvez-vous partager vos anecdotes sur des conflits d'intérêts entre front-end et back-end ?

Ou dit plus simplement, le front-end est le code s'exécutant côté client et le back-end le code s'exécutant côté serveur.

Quelques remarques:

Citation:

---

Un développeur front-end peut créer un site web sans qu’un développement back-end ne soit nécessaire. Dans ce cas, il s’agit de sites statiques

---

Pas forcément, on peut également concevoir des services dynamiques sans back-end qui utilisent des technologies de stockage local (Service workers, IndexedDB...), de la communication peer-to-peer (WebRTC) et des services externes dédiés à la persistance de données. On parle d'architecture "serverless". Plus d'infos : https://github.com/anaibol/awesome-serverless.

Citation:

---

Les développeurs back-end s’inquiètent également de la sécurité d’un site web

---

Les développeurs front-end doivent aussi s'en inquiéter. Une faille XSS peut faire beaucoup de dégâts.

Citation:

---

Quel est le plus valorisant entre les deux ?
Lequel des deux devrait prendre les décisions globales sur le projet ?
Pouvez-vous partager vos anecdotes sur des conflits d'intérêt entre front-end et back-end ?

---

Je flaire l'appât à troll :mrgreen: Du moment qu'un contrat d'interface clair est établi et approuvé par les deux parties (REST, HATEOAS ou GraphQL sont généralement très appréciés), et que le front n'essaie pas de faire du back et réciproquement, tout se déroule très bien et il n'y a pas de conflits d'intérêt ou d'autorité à avoir l'un sur l'autre.

1. art du design de l'information et art des procédures de l'information
2. back-end (art des procédures de l'information) avec GCC et front-end/back-end avec C++ Builder, par exemple.
3. front-end, infographiste et autres métiers lié à l'apparence et donc première approche pour l'utilisateur final. Cela dit, un front-end peut ne pas être graphique, mais aussi textuel ou tactile ou sonore ou olfactif.
4. front-end, les threads y sont très nombreuses et les remontés d'informations vis-à-vis des procédures beaucoup moins nombreuse mais toutefois informatives.
5. une équipe de front-end et une équipe de back-end.
6. x.org qui bogue suite à un changement de résolution (Linux comme Windows 98)... ou blue screen windows sans mode sans échec (Windows NT).

La question est un peu trop sérieuse pour du troll :aie:

1) Quelles différences pouvez-vous relever entre le développement front-end et le développement back-end ?

Tout ce qui se voit brille. le reste est obscure.

2) Êtes-vous plutôt front-end ou back-end ?

Je préfère le cotés obscure de la force :mrgreen:

3) Quel est le plus valorisant entre les deux ?

ça dépend du client et de ses connaissances en informatique.

4) Lequel des deux devrait prendre les décisions globales sur le projet ?

Tout dépend du projet :
- Si l'aspect interface est primordiale, alors ce sera l'équipe front-end.
- Si c'est les données et les règles métiers associées, alors ce sera l'équipe back-end.

5) Est-il préférable d'avoir une équipe de full stack ou une équipe de front-end et une équipe de back-end ?

Partons du principe qui faut savoir tout faire. Bon, deux trois spécialistes dans chaque domaine, c'est un minimum :aie:.

6) Pouvez-vous partager vos anecdotes sur des conflits d'intérêts entre front-end et back-end ?

Expliquer à un front-end que sa modélisation de la base de données y peut s'en faire de bigoudi, parce qu'elle est nulle et qu'avec ce qu'on va lui mettre dans le buffet (la base :mrgreen:, pas le front-end :aie:), ça va pas tenir.

Expliquer que la modélisation des données, ça ne correspond pas forcément à ce qui s'affiche à l'écran :mouarf::mouarf::mouarf:.

Expliquer qu'une procédure stockée ira toujours plus vite qu'un bout de code coté client, pour générer un fichier d'export :mouarf:. Et qu'un serveur sera toujours plus performant qu'un poste de travail :mouarf:

Ce Trolldi aurait'il fait un flop ?

On ne parle pas assez du développeur middle-end, celui que ne voit pas l'utilisateur et que ne voient pas non plus les serveurs. Il est en général absent du bureau pendant les heures de travail et n'apparait dans les couloris que le jour de paie :)
Rien à voir avec le développeur all-ends, souvent mal orthographié all-hands, qui sait taper au clavier des deux mains !
Le meilleur restant le développeur hands-up qui développe sans les mains...

il a une partie d'ajax sur la bibliothèque j que ries cela peut bien permettre un développeur front- end sans le connaissance en dynamiques de récupérer et charger certaines données aux serveurs, bref il utile a la conception(uml) et la programmation(html/css)

Front-end: Tout le monde comprend ce que font les dev front-end et tout le monde les plaint car la dernière fois qu'on a essayé d'alligner un truc en CSS ça nous a pris 3h et c'était casser dès qu'on redimensionnait la fenêtre.
Back-end: Personne comprends ce que font les dev back-end mais tout le monde les plaint quand même parce que dès qu'un truc est cassé c'est à eux de se tapper les heures sup' pour réparer.
:pastaper:

Encore une bonne partie de rire pour ce bon vieux dino. Imaginez-vous qu'il y a fort, fort longtemps, le développeur non seulement concevait les écrans de l'application qu'il allait livrer, mais allait jusqu'à INTERROGER l'UTILISATEUR, vous vous rendez compte ? pour apprendre en gros son métier... Ensuite, il s'apercevait assez vite que certaines choses étaient locales au dialogue, en gros tout ce qui bouge sur l'écran, et que d'autres traitaient surtout des données, en réponse aux premières le plus souvent.
Ca donnait une vue synthétique et complète de l'application, si le gars qui s'occupait plus de la partie "arrière" voire "batch" n'était pas là, celui qui s'occupait plus de l'interface prenait la relève et l'utilisateur n'y voyait rien. L'application était gérée par une équipe, avec un responsable de projet, qui était la tête à couper en cas de grosse merde. Mais elle repoussait assez vite...
Je reviens sur l'atomisation des fonctions du développement informatique, qui me semble totalement contre-productif. Elle peut expliquer la quantité de sites mal foutus, mal dessinés, peu intuitifs, ne répondant pas au besoin sans un manuel complet qu'on trouve un peu partout, et singulièrement, pas mal en France. Bien souvent la vue globale manque, et les choix semblent faits plus pour satisfaire les fantaisies d'un tel ou d'un autre voire d'une hiérarchie plutôt que pour satisfaire l'utilisateur, seul et unique client à prendre en considération.
S'il est vrai que le nombre de connexions à un site peut être très grand chez Amazon, Google, Yahoo etc, ce n'est sans doute pas le cas de la plupart des sites existants. Alors pourquoi en faire des usines à gaz ingérables, lourdes, pataudes, moches, alors que les outils permettant de faire quelque chose de pertinent, joli et agile existent ? Je suis avec intérêt Vanilla.js, qui semble aller dans mon sens. Il faut bien sûr rester raisonnable, mais faire un peu de vrai code (et encore, je parle de TypeScript/JS) ne tache pas plus les doigts qu'utiliser des librairies et des frameworks hypertrophiés et ingérables à moins d'une hyper-spécialisation.

Troll, Dinosaures, même combat, unissons-nous !

Il y a vraiment un problème de compréhension de ce qu'est le Frontend. Le Frontend n'est pas forcément visuel*: une API peut être un frontend avec un backend (une base de données, une autre API, une myriade de µ-services). Un frontend ou un backend sont des interfaces à un client, le frontend étant généralement public là ou le backend est au moins protégé.

Par exemple, la GraphAPI de FB est un frontend, qu'on peut utiliser comme un backend.

En somme, c'est plus une question de rôle que de nature.