web-dev-qa-db-fra.com

Webdesign réactif sur le "frontend" vs "backend"?

Apparemment, il existe deux façons de concevoir un site Web réactif. Je ne sais pas comment appeler les deux méthodes, mais disons simplement qu'elles sont frontend et backend:

  • Par frontend Je veux dire, la manière habituelle de redimensionner la mise en page lorsque vous redimensionnez votre navigateur (par exemple, Twitter Bootstrap, Foundation, etc.).

  • Par backend Je veux dire, charger une version mobile ou une version de bureau sur le domaine de premier niveau. Cela revient à avoir m.example.com et example.com sauf que vos scripts chargent la version mobile ou de bureau uniquement à example.com (inutile de m.example.com).

Personnellement, je trouve que la façon dont le front est utilisé est un peu "hack" et cela implique beaucoup de réflexion/tests pour obtenir le résultat souhaité, cela augmente également la taille du fichier par visiteur. Bien que le chemin d'accès apparaisse plus simple et plus simple, la taille de fichier par visiteur est réduite.

Je me penche vers la voie arrière. Mais, il semble que la méthode frontale (Twitter Bootstrap, Foundation, etc.) soit omniprésente. Y a-t-il un problème avec la méthode de base parce que cela semble être un choix moins populaire?

htmlcsswebsite-designresponsive-webdesignlayout
3
IMB

Résumé: optez pour la conception Web réactive (ce que vous appelez l'interface).

Lorsque vous utilisez la version "backend", vous avez les inconvénients suivants:

  1. Vous devez créer deux sites Web: un pour le bureau et un pour le mobile. Ou vous devez créer une solution personnalisée intelligente qui envoie automatiquement le même contenu aux deux sites Web différents. Pas facile.

  2. Vous devez trouver un moyen fiable de savoir si votre visiteur utilise un navigateur mobile ou un navigateur de bureau. C'est dur et hackish et pas fiable (du moins jusqu'à présent).

  3. Vous devez non seulement prendre en charge les ordinateurs de bureau et mobiles, vous avez des tablettes et des tablettes et mobiles plus grands et plus petits, vous devez maintenant créer plusieurs sites Web et non plus uniquement 2. De plus, la liste des tailles d’écrans des appareils s'allonge chaque jour.

Lorsque vous optez pour la conception Web réactive, vous évitez tout ce qui est mentionné ci-dessus. Vous pouvez également travailler sur des infrastructures solides et sur les technologies les plus récentes. Vous trouverez également de nombreux moyens de résoudre les problèmes que vous rencontrez. De plus, les nouvelles versions de navigateur implémentent de nouvelles fonctionnalités qui rendront la conception Web réactive plus facile et plus robuste.

Bonne chance.

À votre santé.

2
Mario Awad

allez pour frontend

Use a responsive framework, like Twitter bootstrap or similars, créez un seul site Web pour tous.

Ensuite, use media queries pour basculer les règles CSS là où vous en avez besoin, que ce soit pour mobile ou non.

Et définitivement switch all you want to show or not in mobile and desktop by server side.

Par exemple, un huge banner on mobile is useless, remplacez l'utilisation de modules HTML et de conditions côté serveur, par exemple:

<?php if(isNotMobile()){ ?>
$this->loadModuleBanner(); //this loads html module
<?php } ?>

Donc, plus vous êtes doué pour créer des modules, plus votre code de site est facile à lire, à conserver, à mettre à l'échelle.

Utiliser 2 sites Web différents vous rendre fou si vous n'avez pas 2 équipes de développeurs 1 pour mobile/pads et 1 pour ordinateur de bureau

2
itsme

Pensez-y de cette façon: quelle que soit la taille de votre écran ou de votre appareil, votre contenu est le même, plus quelques éléments qui ne sont peut-être pas pertinents pour certains types d'appareils.

Cela revient à afficher le contenu sur un écran et à imprimer ce contenu. Vous pouvez utiliser des feuilles de style distinctes pour les supports screen et print. Vous ne créez pas un site Web distinct uniquement pour les vues imprimées.

De même, une taille d'écran différente n'a pas besoin d'un back-end séparé.

Si vous utilisiez l'architecture MVC, toutes vos modifications seraient nécessaires uniquement à la V (view)

1
karancan