Design & Développement web - Le topic des canards qui mangent des cookies

[Getz]

Ceux qui utilisent VueJS, vous utilisez quoi pour faire des appels à un web service ?

Perso j'ai utilisé vue-resource sur un petit projet, ça a l'air de faire le taf.

[Dynames]

Dites les gens,


J'ai un futur projet perso, que je vais bientôt commencer. Site pour une asso sportive avec un accueil sur les news du clubs, un menu des équipes (et leurs résultats), infos pratiques, planning des entrainements...


pour mon back, je vais partir du du c#(langage que je maitrise mieux) pour mes api.

Quelles bases sont a conseillés pour une facilité d'utilisation pour mon back? Pg, mysql, une autre? Je n'ai pas encore eu l'occasion dans mes projets pro, de faire ces choix (arrivée sur des projets en cours le plus souvent), donc pas forcément simple pour moi d'isolé ce qui serait le mieux. Je connais bien la partie controller et model, mais moins la partie connectivité à la BDD malheuresement.


Pour mon front, je commence a pas mal connaitre angular donc je pensais l'utilisé, mais ça commence à pas mal parler de vuejs (même ici sur les derniers posts), donc je tenterais bien le coup. Est ce que je serais perdu en allant sur du vuejs après 8 mois de angular? Sachant qu'a côté de ça, je n'ai pas non plus des masses d’expériences en web, j'ai surtout de l'xp en client lourd.

Et ça permettrait, si ce n'est pas totalement différent, d'avoir une nouvelle techno sur mon cv.

[acdctabs]

Pour ton back faut surtout voir ce que propose l'hébergeur, à moins de payer cher tu es souvent limité.

[Dross]

Dites les gens,
pour mon back, je vais partir du du c#(langage que je maitrise mieux) pour mes api.

Quelles bases sont a conseillés pour une facilité d'utilisation pour mon back? Pg, mysql, une autre? Je n'ai pas encore eu l'occasion dans mes projets pro, de faire ces choix (arrivée sur des projets en cours le plus souvent), donc pas forcément simple pour moi d'isolé ce qui serait le mieux. Je connais bien la partie controller et model, mais moins la partie connectivité à la BDD malheuresement.

Alors déjà, pars sur du ASP.NET Core (et pas l'ancien MVC/API) : tu pourra comme ça l'héberger sur une machine linux (plus présent sur le web et ça commence à 2.5$/mois, tu ne trouvera pas ça en WinServer).

Pour la BDD, ça dépends aussi beaucoup de tes besoins, pour avoir justement pondu une API perso il y a moins de 3 semaines pour des besoins légers (je peux t'indiquer le repo github si jamais ça t'intéresse), je suis parti sur du Azure Table : c'est SaaS et le coût est très bas.
Sinon tu peux installer une BDD sur ton linux, mais à toi de gérer le tout (config, uptime, procédure de backup etc).

Pour mon front, je commence a pas mal connaitre angular donc je pensais l'utilisé, mais ça commence à pas mal parler de vuejs (même ici sur les derniers posts), donc je tenterais bien le coup. Est ce que je serais perdu en allant sur du vuejs après 8 mois de angular? Sachant qu'a côté de ça, je n'ai pas non plus des masses d’expériences en web, j'ai surtout de l'xp en client lourd.

J'ai le même background que toi (.NET Desktop), et je me sens plus à l'aise avec Angular qui reprends certains de nos fondamentaux comme l'injection de dépendance. A ma connaissance c'est le seul qui architecture son code comme ça, alors je serai toi je resterai sur Angular.
Mais bon, apprendre un nouveau truc c'est cool aussi.

[Dynames]

Pour ton back faut surtout voir ce que propose l'hébergeur, à moins de payer cher tu es souvent limité.

Alors déjà, pars sur du ASP.NET Core (et pas l'ancien MVC/API) : tu pourra comme ça l'héberger sur une machine linux (plus présent sur le web et ça commence à 2.5$/mois, tu ne trouvera pas ça en WinServer).

Pour la BDD, ça dépends aussi beaucoup de tes besoins, pour avoir justement pondu une API perso il y a moins de 3 semaines pour des besoins légers (je peux t'indiquer le repo github si jamais ça t'intéresse), je suis parti sur du Azure Table : c'est SaaS et le coût est très bas.
Sinon tu peux installer une BDD sur ton linux, mais à toi de gérer le tout (config, uptime, procédure de backup etc).

Je pensais bien partir sur du dot net core oui.

Pour Azure table, je ne connaissais pas, je regarderais, et du coup je pense partir sur du Azure SQL Database.

Ne connaissant pas trop azure, on peut faire tourner ça en local, sans vrai hébergement azure du coup? Sinon, j'irais du du mysql. Oula, c'est passé chez oracle mysql... Je vais peut être aller sur du PG finalement ^^

J'ai le même background que toi (.NET Desktop), et je me sens plus à l'aise avec Angular qui reprends certains de nos fondamentaux comme l'injection de dépendance. A ma connaissance c'est le seul qui architecture son code comme ça, alors je serai toi je resterai sur Angular.
Mais bon, apprendre un nouveau truc c'est cool aussi.

Je prend note.

Oui c'est interessant d'apprendre une nouvelle techno, mais se prendre la t^te sur un projet perso en apprenant quelque chose de nouveau, ça me motive pas tellement ^^

[Dross]

Pour Azure table, je ne connaissais pas, je regarderais, et du coup je pense partir sur du Azure SQL Database.

Ne connaissant pas trop azure, on peut faire tourner ça en local, sans vrai hébergement azure du coup?

La dernière fois que j'ai regardé Azure SQL Database c'était vraiment super cher. Par contre, c'est pratique quand tu a un codebase déjà calé sur MS SQL, la migration n'est pas instantané mais beaucoup plus facile qu'avec autre chose (j'ai déjà eu besoin de revoir des schémas, donc c'est pas du 1 pour 1 non plus).

Azure c'est une offre Cloud, donc non : si tu veux utiliser la ressource faut avoir un compte Azure et payer en conséquence. Par contre tu n'est pas obligé d'héberger ton site sur Azure pour utiliser les ressources : c'est d'ailleurs ce que je fais, je trouve les offres d'hébergements trop chères là bas.

(Bon, tu as bien une offre "Azure on-premise" mais c'est du "entreprise grade" et hors de portée financière d'un particulier)

Pour Angular, tu peut aussi en profiter pour découvrir des nouveaux outils/patterns que tu n'aurai pas encore utilisé, comme ngrx ou autre type de lib. (Y'a un mec qui a sorti une nouvelle lib de state management avec la philosophie Angular (et non plus React comme ngrx) y'a 2-3 mois d'ailleurs, si jamais tu veux tester des nouveaux trucs).

[Orhin]

Y'a un mec qui a sorti une nouvelle lib de state management avec la philosophie Angular (et non plus React comme ngrx) y'a 2-3 mois d'ailleurs, si jamais tu veux tester des nouveaux trucs

Tien, faudra que je teste, je n'ai jamais vraiment été convaincu par Ngrx (ou Redux directement dans Angular) pour pas mal de raisons que cite l'article.
T'as pu tester sur certains de tes projets ?

edit : je viens de regarder vite fait un peu plus en détail et ça a l'air bien sympa en effet.

[Dross]

J'ai failli mais quand j'ai vu la jeunesse du truc je me suis dit que j'allais attendre encore un peu. Si ce n'était pas aussi jeune j'aurai déjà essayé de le mettre sur nos gros projets, c'est clairement plus logique au vu du framework.
Je me laisserai ptet tenter sur un side project, si quelqu'un se lance qu'il oublis pas de nous raconter comment ça s'est passé. ^^

[Thomasorus]

Si vous avez des Drupal ou votre boite en gère, oubliez pas que il y a une faille béante depuis trois mois. Pas mal de sites ne l'ont tjs pas corrigée apparemment. https://arstechnica.com/information-...ers-continues/

[Dynames]

La dernière fois que j'ai regardé Azure SQL Database c'était vraiment super cher. Par contre, c'est pratique quand tu a un codebase déjà calé sur MS SQL, la migration n'est pas instantané mais beaucoup plus facile qu'avec autre chose (j'ai déjà eu besoin de revoir des schémas, donc c'est pas du 1 pour 1 non plus).

Azure c'est une offre Cloud, donc non : si tu veux utiliser la ressource faut avoir un compte Azure et payer en conséquence. Par contre tu n'est pas obligé d'héberger ton site sur Azure pour utiliser les ressources : c'est d'ailleurs ce que je fais, je trouve les offres d'hébergements trop chères là bas.

(Bon, tu as bien une offre "Azure on-premise" mais c'est du "entreprise grade" et hors de portée financière d'un particulier)

Pour Angular, tu peut aussi en profiter pour découvrir des nouveaux outils/patterns que tu n'aurai pas encore utilisé, comme ngrx ou autre type de lib. (Y'a un mec qui a sorti une nouvelle lib de state management avec la philosophie Angular (et non plus React comme ngrx) y'a 2-3 mois d'ailleurs, si jamais tu veux tester des nouveaux trucs).

Je vois.

Je vais mater un peu wordpress aussi. Ça suffira peut être.

[MrBeaner]

Hello les canards J'ai un ami qui bosse pour un petit magazine de Genève et ils voudraient faire une carte interactive de la vie culturelle de la ville.

C'est un mandat payé.

C'est par là : https://epic-magazine.ch/epic-recherche/

Si jamais ça vous intéresse

[LaitLucratif]

Hello,

Petite question de gros débutant, je bricole à grand coup de bouts de code chopés à droite à gauche un site pour un projet de diplôme de ma copine, en gros j'utilise du jQuery/JSON/PHP pour récupérer une BDD SQL et la retranscrire sans recharger de page ou quoi que ce soit. J'utilise aussi le framework W3.CSS.

J'utilise Isotope pour mettre en page une grille d'images dynamiquement (elles ont la même largeur mais pas la même hauteur).

En gros pour poster le code simplifié, je boucle mon JSON ainsi pour créer ma grille d'images :

// On prépare le sizer pour Isotope
var content = '<div class="grid-sizer"></div>';


// Boucle pour la grille
for(var i = 0; i < data_json.length; i++){ 
// Le code de la grille
  content += '<div class="grid-item openLogo" name="'+i+'"><img src="images/'+data_json[i].nomimage+'.png" style="width:100%"></div>'; // Le logo
}
// On applique le contenu à la fiche après la boucle
$('#logoGrid').append(content);

Côté HTML j'ai bêtement ça :

<!-- Grille d'images    -->
<div class="w3-row isotopelaunch" id="logoGrid"></div>

Puis je lance pépère Isotope :

// Isotope pour réarranger la grille
	var $grid = $('.isotopelaunch').imagesLoaded( function isotope() {
    $grid.isotope({
    itemSelector: '.grid-item',
    percentPosition: true,
    masonry: {
      columnWidth: '.grid-sizer'
    }
  });
});

Ça marche niquel, c'est responsive, beau et fluide. Il y a d'autres fonctions à côté (quand tu cliques sur une image y'a une fiche qui s'ouvre avec les infos récupérées dans le JSON), mais j'ai enlevé ça du code pour plus de clarté.

Sauf qu'ensuite j'ai voulu appliquer InfiniteScroll histoire d'optimiser la vitesse de chargement de la page pour les connexions plus faiblardes et de moins imposer un énorme pavé d'images en page d'accueil.
Le soucis c'est que j'ai l'impression qu'InfiniteScroll te demande une pagination avec URL existante, même s'il bidouille derrière pour masquer le changement d'URL (y compris dans l'historique).
Il possède une fonction pour être compatible avec Isotope, mais ça demande toujours un "path" en paramètre que je n'ai pas, puisque je n'ai aucun système de pagination.

// get Isotope instance
var iso = $grid.data('isotope');

$grid.infiniteScroll({
  // Infinite Scroll options...
  path: '???',
  history: false,
  append: '.grid-item',
  outlayer: iso,
});

https://infinite-scroll.com/options.html

Il faut absolument un path... On peut s'en passer avec une option que j'aurais pas pigée ?
Vous connaissez un équivalent qui pourrait coller à ma structure ?

Merci d'avance !

[tenshu]

Y'a marqué dans la documentation que c'est required, tu vas devoir trouver autre chose.

[Orhin]

https://medium.com/@timotheejeannin/...t-cd188dfae773

[LaitLucratif]

Y'a marqué dans la documentation que c'est required, tu vas devoir trouver autre chose.

En effet merci ! Du coup j'ai testé d'autres trucs de "lazy load" en js/jquery mais pas encore réussi à les faire tourner avec Isotope et ma boucle json... Je vais y arriver.

[mrFish]

https://medium.com/@timotheejeannin/...t-cd188dfae773

Brillant.

[William Vaurien]

Petite question rapide pour m'aider à choisir une lib js.
J'ai un vieux projet à maintenir: serveur en C et front en html/js old school (tags en majuscule, plein de fonctions js de merde, des ruses pour IE6, des ruses pour faire de l'ajax indirectement via des iframes cachés, etc).

Je dois remplacer un bout de l'appli par un appel vers un webservice en REST et je voudrais pour cela introduire une petite lib pour gérer les appels ajax, lire le JSON et incorporer des données dans une page.

Le but est d'amorcer une maintenance à plus long terme pour virer le plus possible du code de 'plomberie' datant de 2003 et d'avoir un outil simple pour gérer ce genre de besoin.

Je ne suis plus trop à jour au niveau frontend et je me demande ce qui serait le plus adapté entre:
- utiliser le bon vieux JQuery que je connais un peu, qui m'est donc familier, qui a une doc lisible et profusion d'exemples pour mes collègues (ils sont "concomitant" du code et n'ont jamais vraiment cherché à suivre les évolutions ni en back ni en front).
- utiliser un truc plus récent et moins fourre tout que jquery, comme umbrellajs. Ce dernier est 10x plus petit, propose seulement ce dont j'ai besoin (DOM/events/ajax) et plus "moderne"/concis.
Mais avec moins de doc et d'exemple pour mes collègues. Ou un autre du même genre, mais lequel ?

Perso jQuery me va, mais j'ail l'impression qu'il est un peu "has-been".

Vous feriez quoi ?

[Orhin]

Crame tout.
De rien.

Plus sérieusement, la page dans laquelle tu veux incorporer les données existe déjà ou ça fait partie des réalisation à faire ?
Si elle n'existe pas, je conseillerais de partir sur du Vue.js ou React.js pour créer la nouvelle partie de ton site encapsulée dans un coin sans toucher à tout le bordel autour.
Si elle existe, soit tu la refait complètement (et part sur la solution du dessus) soit tu pars sur une solution à la Umbrella.js (mais ce n'est clairement pas la solution la plus maintenable).

[tenshu]

Faut vraiment voir quel est l'état de l'application et ce qu'il faut en faire sur le moyen long terme.
Si y'a pas d'objectif d'y investir du temps alors je me ferais le moins chier possible.

Si on parle de migrer le services progressivement sur la base d'une api rest + frontend en js, alors là ouai il faut sortir le framework et bien réfléchir.
L'idéal c'est de coller un router qui va distribuer soit les anciennes pages soit les nouvelles, puis de réécrire les pages une par une."
Tout en prenant soin de gérer tout ce qui va avec et qui est bien relou comme le partage de session etc.

Bon courage, essaye juste de ne pas rajouter une couche de caca sur un mille feuille de caca.

[Dross]

Si jQuery te va et te posera le moins de soucis avec ton équipe, ça reste une bonne solution.

Après, ça dépends vraiment de la vision à long terme, est-ce que tu rajoute une fonctionnalité et c'est fini, ou vous allez encore bosser dessus pendant 5 ans ? Pour du court terme, t'emmerde pas. Pour un truc plus long, c'est à vous de voir. Soit migration vers un gros framework (mais je déconseillerai : c'est beaucoup de taf), soit commencer à préparer le terrain, tu prends un truc pas trop intrusif (umbrella, knockout, etc) et tu assainie ton codebase (séparation de la logique des vues, etc). Comme ça si tu veux aller de l'avant après, le gros du travail sera fait et tu aura moins de surprises. Et entre temps tu aura déjà un truc plus propre et viable.

[William Vaurien]

Pour préciser le framework actuel c'est 'Panther'. Leur slogan c'est :

You know of Panthers' capabilities in the 90s, but do you know what if can do today

(lien facebook., je peux pas mettre un lien vers leur image de merde depuis mon poste)
Je vous laisse imaginer la merde que c'est...

En gros c'est un RAD des années 90 qui permet de faire des écrans de mainframe via un designer. Puis des écrans *nix et windows, et ils ont enfin migré leur bordel au forceps pour faire du web.
Les écrans du designer sont transformés en html via une moulinette et sont ensuite incorporée dans des templates (format propriétaire) sur lesquels nous avons la main.
Le code javascript est injecté à ce moment là. Il est dégueu comme l'était toute base de code js d'avant la standardisation des browsers et l'utilisation systématique de jQuery et consort.
Du coup j'ai pas spécialement envie de passer sur du vue.js ou autre, je veux simplement nettoyer un peu la merde qui dépasse trop, et là c'est sous couvert de corriger un bug.

Si y'a pas d'objectif d'y investir du temps alors je me ferais le moins chier possible.

Le but n'est pas de tout ré-écrire: une nouvelle version html5 prend le relais au fur et à mesure, mais comme il y en a pour 10 ans au rythme ou ça va, je veux pouvoir maintenir dans de meilleurs conditions les trucs trop dégueu au fil de l'eau.

Bon courage, essaye juste de ne pas rajouter une couche de caca sur un mille feuille de caca.

Je crois que quelques crottes de biques passeront inaperçues sur une telle bouse d'éléphant !

En gros je me demande si Jquery ( = confort zone pour moi et l'équipe) peut être avantageusement remplacé par un truc qui serait à la fois simple et pérenne aujourd'hui et si ça vaut vraiment le coup.
Je suis tombé par hasard sur Umbrellajs, ça à l'air cool et beaucoup moins verbeux pour les appels ajax que jquery, mais est-ce que ce sera maintenu dans le temps ?

[Dross]

Brule tout.
PC compris.

[William Vaurien]

Brule tout.
PC compris.

C'est une mine d'or ce truc: du travail jusqu'à la retraite... Et en plus Java à l'air tellement moderne quand je retourne en faire

[Orhin]

Il est dégueu comme l'était toute base de code js d'avant la standardisation des browsers et l'utilisation systématique de jQuery et consort.

Non mais la période jQuery systématique est dégueu aussi hein.
Et la standardisation des browser, dans les faits c'est très récent (et même pas complètement terminé vu que IE11 refuse toujours de mourir dans certains milieux ).

C'est une mine d'or ce truc: du travail jusqu'à la retraite... Et en plus Java à l'air tellement moderne quand je retourne en faire

Brûle tout.

Et va faire du Kotlin.

[Fastela]

Ou du Scala.

[GrandFather]

Et la standardisation des browser, dans les faits c'est très récent (et même pas complètement terminé vu que IE11 refuse toujours de mourir dans certains milieux ).

IE11, c'est ce que je me coltine au boulot. Et encore, c'était la liesse quand il est arrivé il y a trois ans, car avant c'était IE8...

Je dois remplacer un bout de l'appli par un appel vers un webservice en REST et je voudrais pour cela introduire une petite lib pour gérer les appels ajax, lire le JSON et incorporer des données dans une page.
Le but est d'amorcer une maintenance à plus long terme pour virer le plus possible du code de 'plomberie' datant de 2003 et d'avoir un outil simple pour gérer ce genre de besoin.

Si tu es pressé par le temps, jQuery est une option. Mais pour du long terme, je partirais sur du Vue.js + Axios. Vue a une assez faible courbe d'apprentissage, ne nécessite pas d'outils de build pour une utilisation simple et s'intègre parfaitement à du code existant. Et Axios pour la partie Ajax, puisque Vue ne gère que la partie IHM.

Je suis en train d'écrire une bibliothèque de composants Vue (boutons, grid, menus, datepicker, etc.) pour remplacer une bibliothèque de plugins jQuery, et franchement c'est du bonheur. Le passage de « l'impératif » au « déclaratif » change complètement la donne, le code est nettement plus concis et lisible, et plus facilement maintenable et évolutif. Il me serait difficile de revenir en arrière, même si je considère toujours jQuery comme une excellente librairie.

[Teocali]

Non mais la période jQuery systématique est dégueu aussi hein.
Et la standardisation des browser, dans les faits c'est très récent (et même pas complètement terminé vu que IE11 refuse toujours de mourir dans certains milieux ).


Brûle tout.

Et va faire du Kotlin.

Oui

Ou du Scala.

Non :mdt:

[gros_bidule]

Rigolez, mais à mon bureau le client (l'état) exige que l'on supporte l'avant-dernière ESR de Firefox

[Orhin]

Rigolez, mais à mon bureau le client (l'état) exige que l'on supporte l'avant-dernière ESR de Firefox

Bah depuis peu la dernière ESR de Firefox c'est la version 60.
Donc l'avant dernière c'est la 52.
Autant dire que y'a pas trop de soucis de compatibilité, tu peux même faire du ES6 sans transpilation (y'a que 2-3 méthodes très peu utilisées qui ne sont pas supportées sur cette version).

[gros_bidule]

Quand tu fais de l'Ember (j'en fais des cauchemards) et des trucs tricky en JS ou CSS, il y a des trucs qui ne passent pas très bien
Pas grand chose hein, mais c'est démoralisant.