Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 290 sur 296 PremièrePremière ... 190240280282283284285286287288289290291292293294295296 DernièreDernière
Affichage des résultats 8 671 à 8 700 sur 8872
  1. #8671
    Je me dis juste que si c'est un tech qui, dans le process de sélection, review ton profil, alors il pourrait tiquer sur ça. "Rholala j'ai vu un profil, sa page web elle consomme tout mon CPU alors qu'elle fait rien, il sait pas coder", dira t-il à ses collègues.
    J'ai déjà vu des profils refusés parce qu'ils avaient marqué AngularJS au lieu de Angular.
    Même s'ils ne sont qu'un maillon de la chaine, et même si tu ne bosseras pas avec eux (donc ne pas juger toute la boite sur ça), les reviewers sont là et ce sont parfois des cons.

  2. #8672
    Wow, j'ai un pc plutôt puissant donc je n'avais pas remarqué, et je suis curieux de comprendre d'où ça vient.
    Je jetterai un oeil au code source à l'occaz (bon ça se trouve tu trouveras le prob en 2 min)
    Sans rien savoir pour moi ça à l'air d'être un problème genre moteur graphique des navigateurs internet? 'Fin je suis pas un expert
    Vous avez un GPU dédié les canards qui ont le problème? Vous avez activé l'accélération graphique?

    Mais ouais sinon objectivement, ça a l'air de consommer bien trop vis à vis du visuel/puissance de calcul requise, c'est p'têt un problème dû à l'implém faites par les navigateurs, parce que pour sûr si tu remplaces ton background avec genre une vidéo compressé, y'aurait 0 impact cpu/gpu.

    À vrai dire vu que je l'avais déjà fait à l'époque, je suis sûr et certain à 1000% qu'un shader WebGL ferait le même résultat visuel avec 0 impact CPU/GPU

    Bref, approche scientifique:

    Firefox Idle, aucun tab ouvert



    Gradient Css qui a l'air standard, trouvé ici: https://www.gradient-animator.com/



    Le site web d'Awake:



    Ca a l'air relativement similaire, faut voir le code source, ça ressemble tout de même plus à un problème d'implém côté navigateur, donc à mon avis faut utiliser de la vidéo compressée ou un shader pour avoir le même rendu sans impact niveau conso et bypass leur engine graphique pourrave

  3. #8673
    Si je supprime l'animation (gradient + text blur) btw, donc bon a priori c'est juste que css est implémenté à la pisse par les navigateurs



    Si je supprime que le gradient mais garde l'animation du texte



    Donc bref, après avoir fait joujou un peu, c'est 3 lignes de css à elle toute seule qui explique toute la conso, plus un problème au niveau des navigateurs je pense, faudra qu'ils optimisent ça

    Ah y'a moyen que le script qui modifie le DOM (splash.ts) joue un poil aussi, m'enfin
    Dernière modification par Kamikaze ; 05/02/2023 à 00h12.

  4. #8674
    Citation Envoyé par Awake Voir le message
    Ça a l'air de beaucoup te préoccuper
    Il s'agit surtout savoir ce que fait un PC sans action particulière de l'utilisateur, et si une consommation anormale de ressources est légitime ou pas.

    Là, on comprend surtout pourquoi il faut des machines de plus en plus puissantes pour bêtement naviguer sur des pages web "statiques".
    « Sans puissance, la maîtrise n'est rien »

  5. #8675
    Bon j'ai rien dit, même avec WebGL la conso est trop élevée. C'est bizarre j'aurais juré avoir fait un gradient qui consomme moins y'a quelques années en WebGL

    Gradient animation - Shader WebGL



    À mon avis faut passer par de la vidéo compressée, c'est ce que font tous les sites web pros avec des vidéos en background

    Gradient animation - Vidéo compressée .webm


  6. #8676
    J'avais déjà remarqué ça, les animations permanentes bouffe beaucoup de ressources. Surtout avec un taux de rafraîchissement élevé. Vous avez combien ? 144 Hz ?

  7. #8677
    Ah bonne remarque ça, je suis à 300hz, et c'est vrai que l'animation du texte parait particulièrement lisse, je me demande si ça rentre en jeu

  8. #8678
    Pour mon premier signalement, c'était sur un laptop avec écran 120Hz.

    A 60Hz, sur un desktop Core i7-11700F avec une RTX 3070 :



    Je précise que dans les deux cas, l'extension uBlock Origin est désactivée.

    D'ailleurs, quand on utilise cette dernière pour uniquement désactiver l'exécution du Javascript sur la page, comme attendu cela coupe l'animation sur le texte, mais pas le dégradé de couleur en background (qui continue donc à bouffer du GPU).

    Par comparaison, l'interface web de gestion de mon NAS Synology ouverte dans la même instance de Firefox ne consomme quasiment rien (<1% CPU <4% GPU). On ne me fera pas croire que le code du DSM est moins compliqué.
    « Sans puissance, la maîtrise n'est rien »

  9. #8679
    Lol en vrai c'est l'opportunité de faire un nouveau navigateur qui supporte mieux css, devenez millionaires les gars!!!

  10. #8680
    C'est le nombre d'anim par lettre simultanées qu'il a l'air de pas trop aimer, je tape à un thread complet sur les phrases les plus longues. Pouvez faire joujou avec la tab "performance" des devtools de Chrome, d'ailleurs mon PC a aussi du mal à suivre 240Hz et drop quelques frames

    C'est assez drôle mais bon, pas exactement le cas d'usage que j'optimiserais si je bossais sur un navigateur.

  11. #8681
    Ola,

    J'ai une petite question (sans doute idiote, pour pas changer ^^), j'utilise pas mal NodeJS en ce moment et je dois faire plusieurs commandes dont :

    - Compilation du TypeScript
    - Conversion Sass vers CSS
    - Compiler TailwindCSS
    - Me faire em***** par un truc poilu, sur 4 pattes et qui aime dormir toute la journée sur mon clavier... (Non rien de degeu)
    - Etc

    Pour ce faire, j'utilise le fichier NodeJS package.json, plus précisement dans une section "scripts" ou je défini les commandes a faire, par exemple :

    Code:
    "scripts": {
       "build:ts": "tsc",
       "build:scss": "sass input.scss output.css",
       "build:tailwindcss": "tailwindcss -i ouput.css -o styles.css",
       ...
       "build": "yarn build:ts && yarn build::scss && yarn build:tailwindcss"
    }
    Et pour automatiser le tout (afin d'eviter de taper toujours tout les commandes dans le terminal) je rajoute le script "build" qui lance toute les commandes a la suite.

    Cela marche, mais je suis pas sur que la méthode en soi est propre, c'est plus du bricolage, ca marche sous windows en powershell, mais je suis pas sur sur d'autre système ou avec d'autre invite de commande. Ma question, y a t'il un moyen de simplifier cette ligne dans un format plutot officiel ?

    Merci.

  12. #8682
    Ça me parait propre au contraire.

    Tu pourrais utiliser Gulp, qui permet de chaîner des commandes, ou d'attendre que des commandes soient terminées pour en lancer d'autres. Mais en soi, franchement, passer par les scripts c'est OK et ça fonctionnera partout.

  13. #8683
    Je vois rien de choquant non plus.

    Ça fonctionnera sur n'importe quel système avec la bonne version de node et yarn d'installé.
    Niveau cross-plateforme c'est au contraire assez bon.
    C'est la faute à Arteis

  14. #8684
    Citation Envoyé par Fastela Voir le message
    Ça me parait propre au contraire.

    Tu pourrais utiliser Gulp, qui permet de chaîner des commandes, ou d'attendre que des commandes soient terminées pour en lancer d'autres. Mais en soi, franchement, passer par les scripts c'est OK et ça fonctionnera partout.

    Citation Envoyé par Orhin Voir le message
    Je vois rien de choquant non plus.

    Ça fonctionnera sur n'importe quel système avec la bonne version de node et yarn d'installé.
    Niveau cross-plateforme c'est au contraire assez bon.
    Ok merci pour vos réponses, je vais me renseigner pour gulp (je connais de nom mais jamais utiliser) et le scripts, j'avoue que cela un peu bricolage (et rien vu d'officiel si y une commande existante pour ce type de tache). Bon je vais sans doute garder le système de scripts pour le moment, je suis au moins rassurer que c'est compatible a peu pres partout

    Merci en tout cas

    Edit: Gulp a l'air plutot interessant.
    Dernière modification par Whiskey ; 06/02/2023 à 20h23.

  15. #8685
    Passer par le package.json comme point d'entré c'est la norme en effet, après tu peux toujours caler le pipeline que tu veux derrière.

  16. #8686
    T'inquiètes pas trop si ça fait bricolage, les systèmes de build c'est *le* truc où si tu veux te moquer de l'ecosystème JS tu peux y aller
    J'ai eu une discussion avec un pote il y a peu qui a pris ça comme exemple du bordel ambient, dans l'étude que j'ai sorti un peu plus haut tu vois que même webpack qui est le plus universel des trucs commence à diminuer en usage. J'ai beau lui expliquer que l'écosystème web pour dev des apps riches n'a jamais été aussi stable et unifier, il peut toujours lol là dessus.

    Y'a de la logique derrière quand même, l'écosystème web c'est beaucoup de composants différents et chacun qui fait sa sauce et choisi ce qui lui convient en composant des briques. Avec des briques plus haut niveau (e.g. des méta-langages entiers genre TS ou SCSS) que dans d'autres environnements de dev. Ca paraît normal que t'aies un peu de bricolage à faire et pas de super outil qui fait tout tout seul. Je trouve même ça plutôt sain, finalement.

    Les points négatifs à ça c'est mon pote SRE qui se plaint d'avoir douze pipelines à maintenir ou la barrière à l'entrée pour les noobs. Par exemple create-react-app a react-scripts pour abstraire tout ça et donner une base qui fait tout toute seule par défaut (de laquelle tu peux t'éjecter si t'as besoin de modifier tes trucs), ça permet à ceux qui se lancent dans l'écosystème de pas avoir à apprendre 39 outils avant de générer un noeud d'HTML.

  17. #8687
    Perso je trouve ça ridicule simplement en terme de computing power vs. ligne de code et features vs. ligne de code.

    Actuellement je bosse sur un produit où j'ai facilement délivré 90% de la valeur du truc dans un langage compilé standard, genre 1000 lignes de code. Ensuite il nous fallait une UI, on a fait ça avec du web.

    Le package.lock.json je sais pas quoi, fait 30k lignes. Et quand je fais des codes reviews de dev web sur une techno que je connais, c'est jamais très bon.

    Donc ça me donne une impression excessivement mauvaise. Enormément de code pour des features simples, des temps de build hallucinants, des performances bofs.

    La plus grande valeur ajoutée pour moi et ce pour quoi j'ai beaucoup de respect c'est l'aspect design, ainsi que la connaissance des trucs sécurisés (paiements sécurisés etc.)

    Je comprends que y'a la contrainte du navigateur, mais ça n'explique pas la pauvreté de ce que je vois

    - - - Mise à jour - - -

    (d'ailleurs si quelqu'un a une bonne ressource sur les bonnes pratiques concernant les paiements sécurisés je prends)

  18. #8688
    Merci Kamikaze d'importer ton précieux savoir à nous autres, misérables devs web. Depuis tout le temps, je ne m'étais pas rendu compte, c'est l'avis de quelqu'un qui n'y connait rien en web qu'il me fallait pour me faire comprendre que mon domaine était de la merde. Et t'es venu le dire sur notre topic en plus, sympa.

  19. #8689
    ça me donne une impression
    i.e. j'y connais rien donc je regarde des métriques qui me parlent (lignes de code, perf). Si y'a une justification pour la taille du fichier package.truc et le reste de ce que je vois je suis preneur

    Je vais pas commencer à dire que c'est incroyable alors que je vois un résultat moyen pour des efforts qui me paraissent démesurés. C'est p'têt qu'un truc m'échappe hein, j'ai pas dit le contraire.

    - - - Mise à jour - - -

    D'ailleurs Jonathan Blow critique le web de manière très aggressive, donc bon s'pas pour l'argument d'autorité, mais je me dis que y'a pas de fumée sans feu aussi

  20. #8690
    package.lock.json c'est les references et les versions de toutes les dépendances du projet.

    Je sais même pas pourquoi je ressens le besoin de t'expliquer la différence entre un script cpp/rust de 1000 lignes et une app faite avec un framework, c'est évident que t'es venu troller...

  21. #8691
    Très constructif merci. À vrai dire ta réponse m'a tout de même aidé car j'ai l'impression que c'est vraiment le choc des cultures.

    En gros après avoir jeté un oeil au projet que t'as partagé plus haut je vois un truc comme ça:

    https://www.npmjs.com/package/@jridg...iveTab=explore

    Dans tes dépendances (6500 lignes de dépendance, un fichier qui fait la taille d'un jeu NES, la moindre des choses c'est de se poser la question si c'est nécessaire). Ce genre de truc dans la plupart des langages, ça ferait partie de la lib standard. Donc en gros (plutôt que de me cracher à la gueule)

    La réponse ça aurait pu être "y'a pas de lib standard, donc on est obligé d'importer beaucoup de dépendances, chose qui est d'habitude 'masqué' par la lib standard existante tout aussi volumineuse"

    Faut arrête les délires de troll/pas troll. J'ai p'têt formulé ça de manière abrasive mais on va pas commencer à prendre des pincettes pour tout, je trouve ça mauvais d'un point de vue extérieur (lignes de code, perfs), je me doute que y'a des explications, j'essaye juste de comprendre

  22. #8692
    Honnêtement tes métriques ne sont pas importantes.

    Du moins elles ne le sont pas pour moi. Ce qui est important pour moi c'est le time to market et l'effort pour le faire, et faut bien avouer que là dessus le web ça défonce tout (et j'ai les pieds des deux cotés de la barrière) : tu peux faire des UI crossplateforme/crossfactor avec un rendu moderne et efficace (pour l'end-user, pas en comparant des benchmarks avec du code compilé) dans des temps records et relativement peu d'effort.

    Et même les problèmes d'avant comme le coté artisanal et l'hétérogénéité des pratiques web a été globalement réglé avec les framework modernes. Tu embauche un dev Angular tu peux le mettre dans le jus à la même vitesse qu'un dev .NET ou Java, il ne sera pas dépaysé.

    Il y a des raisons pour lesquelles Electron s'est imposé aussi rapidement partout. C'est que les outils qui ont utilisé Electron sont sorti avant tout les autres qui étaient encore dans les starting-blocks.

    On avait aussi le même débat avec les langages intermédiaires et les compilés, bah au final c'est pareil, si aujourd'hui .NET est partout et qu'on ne fait plus d'applications avec du C c'est qu'il y a des raisons. Que derrière le binaire fasse 300Mo, qu'il soit nécessaire d'avoir des fichiers de 30k de lignes de code qu'on ne regarde jamais, que le tooling nécessite 150Go de place, j'en ai rien, mais alors absolument rien à faire : c'est pas ça qui fera peur à mes 64Go de RAM et mes 4To de SSD. Par contre, mon temps, et celui de nos développeurs, là c'est pas la même chose : une journée gagnée en temps de développement c'est plusieurs centaines de dollars de gain / dév.

  23. #8693
    Kamikaze,

    le package.lock.json, tu peux avoir la même chose en Java avec Maven ou Gradle (et même Python !), il y a des plugins pour générer un truc similaire, à savoir geler tout l'arbre de dépendances. L'intérêt est d'essayer de se rapprocher d'un build reproductible, alors que des dépendances peuvent déclarer d'autres dépendances avec des intervalles de versions.
    La différence entre Java et Node, c'est peut-être qu'il y a davantage de petites librairies JS (et oui, comme tu l'as vu, une lib std assez pauvre), ou plus de grosses lib Java, question de point de vue, d'où cette impression d'avoir un arbre de dépendances JS aussi grand que l'Amazonie. Mais une fois le paquetage final créé et minifié, ça redevient raisonnable.
    On dirait la même chose de Java si à la place des JAR (qui ne sont rien d'autre que des ZIP avec plein de .class, et un peu de sucre autours) ou avait des dossiers pleins de fichiers class. Extraie tous les .class un projet Spring Boot par ex, ce n'est pas beau à voir.
    Et du coup, je n'ai pas compris si tu l'avais insinué, mais non, le package.lock.json, ça ne se review pas . Le package.json, lui, oui.

    Les mauvaises perfs de compilation JS/TS, cela vient en grande partie des outils. Ceux que tu as vu étaient probablement anciens, sinon mal utilisés. Je ne dis pas que compiler un projet Node c'est devenu super rapide, mais avec les bons outils ça s'est bien amélioré.
    Avoir un compilateur en code natif aiderait encore plus (ou que ça compile en natif à la volée), mais à quel point, cela reste à voir.
    D'autant que les perfs de compilation, ça va surtout impacter la CI (et là osef, tu mets un gros CPU et un ramdisk). Toi, sur ton poste de dev, tu compiles une fois le matin (voir une fois le lundi pour toute la semaine) et ensuite tu recharges ton appli à chaud. Recompiler pour tester, c'est so 2000's.
    Si j'étais mauvaise langue, je dirais que côté C ils en sont encore à.... Enfin bref, la guerre backend vs frontend fait toujours rage alors que nous sommes sensés bosser ensemble. C'est trop facile de critiquer l'autre camp quand on le connait mal, et je connais très, mais alors très peu de devs vraiment bons dans les deux.
    Dernière modification par gros_bidule ; 07/02/2023 à 03h24.

  24. #8694
    C'est beaucoup de gens qui parlent pas de la même chose et qui se comprennent pas. Charmant à vivre quand tu manages des équipes transverses.
    Y'a un tradeoff classique: plus ou moins d'abstraction pour plus ou moins de contrôle et d'efficacité. C'est le sens du vent depuis à peu près le début de l'informatique, ça n'invalide pas les autres façons de faire mais ça me paraît évident que ça a son utilité. C'est la même baston entre Java et les langages qui l'ont précédé. Java a gagné sur les terrains où c'était mieux d'être abstrait, les barbus se moquent encore des AbstractFactoryInterface.

    John Blow c'est un bon exemple, je l'aime bien et il pas con, je crois pas qu'il ait beaucoup fait de web mais si tu prends sa position sur ce qu'il connait le mieux il fait aussi caca sur les gens qui utilisent Unity - parce que tout coder soit-même voire développer son propre langage de programmation comme il le fait c'est bien plus cool.
    Alors d'un côté il a raison, le fait d'avoir des outils très puissants et abstraits ça a ses penchants négatifs, e.g. bride l'innovation en standardisant, les gens qui les utilisent peuvent le faire sans avoir conscience de ce qui se passent en dessous, ça sera toujours moins optimisé que si t'avais tout fait de A à Z pour que ça corresponde à tes besoins exacts).
    En même temps sans Unity y'aurait un paquet de jeux qu'on aurait jamais vu ou de gens qui seraient jamais devenus game designers. Et pendant ce temps là t'as des gus comme Lucas Pope qui en sont pas exactement à leur premier jeu et qui font exactement ce qu'ils veulent avec Unity.
    Sur le web il déteste aussi spécifiquement l'overengineering des grosses boîtes GAFA et affiliés, et là dessus j'ai pas trop de doute non plus que ça existe, toute bureaucratie demande sa bureaucratie. Mais c'est une critique à mon sens bien plus localisée que ce qu'il croit faire.

    Quand tu vois un truc de loin et que ça te semble abhérrant, ça me paraît être une meilleure approche de se dire de façon charitable qu'ils doivent optimiser sur d'autres axes que ceux qui comptent pour toi que du partir du principe qu'ils sont incompétents. Y'avait un peu du #2 dans ton ouverture Kamikaze même si tu rajoutes le "je veux comprendre"
    Mes deux camarades précédents ont bien parlé de ça mais typiquement les dépendances de dépendances de dépendances ou les temps de build, sachant que tu hot reload exactement la partie de ton appli sur laquelle tu bosses en 0.1s quand tu dev (souvent sans perdre l'état de ton appli), et que de toute façon ce qui attérit chez le client est ultra optimisé si tu fais bien ton boulot (voire sans rien faire avec l'outillage qu'on a maintenant), c'est pas tant un problème pour ce qu'on optimise en web. Ca l'est si es un control freak qui veut être plus proche du métal et tout gérer complètement, mais encore une fois, tradeoff..

    Le truc qui confusionne beaucoup de gens aussi, c'est que parce que y'a 10x plus de gens qui font du web que du C ou du rust, et 100x que de gens qui font des compilateurs, on va dire que c'est bien plus facile d'en trouver des incompétents. La median en termes de capacité de conceptualisation/d'ingénierie est sûrement plus basse aussi. Mais un peu pareil, c'est des revers de médaille. C'est une conséquence du fait que le web est très fort pour ce qu'il sait faire et donc très gros, que la porte d'entrée est basse et que c'est facile d'y débuter, qu'on est sympa avec les autodidactes, et d'autres trucs du genre que j'aurais du mal à qualifier négativement. "quand je fais des codes reviews de dev web sur une techno que je connais, c'est jamais très bon", bah tu m'étonnes, c'est un marché où t'as littérallement des maçons qui font des bootcamps de 6 semaines et qui finissent dev web et font le boulot qu'on leur demande, en produisant de la valeur.
    Sauf que.. ça veut pas dire que y'a pas des devs/architectes très compétents dans l'écosystème web. Quand y'a un truc abhérrant qui compte ça se répare bien vite, en général pas par un mason bootcampé. C'est pas pour rien que y'avait 29 frameworks par an pendant un bon moment avant que ça se calme et qu'on change de tooling tous les trimestre, c'est la marche forcé vers l'optimisation de ce qui compte. Je t'assure que si ça changeait quelque chose au schmilblick web d'avoir un fichier de la taille d'un jeu NES il serait plus là. D'ailleurs me semble que le package-lock.json est une feature inspiré de yarn qui a splité de npm et avait cette résolution de l'arbre de dépendance en dur dès le début, parce que ça permet d'avoir une façon de s'assurer que tous les monde (devs & prod) ont la même résolution.

    Enfin, à un moment donné je pense que c'est une question irréconciliable de ce qui te plait et ce qui t'intéresse, et de ce qui parle à ta personnalité. Faut de toute pour faire un monde, quand tu gères une équipe t'es parfois content d'avoir un mec qui va passer 3 mois à réfléchir à l'architecture de données ou 5 semaines à économiser 10mo de RAM, et t'es aussi content d'avoir le gars qui code avec le cul mais va sortir un truc qui fait 80% du taf en 2 jours histoire de voir si ça vaut vraiment le coup d'y passer plus de temps et de le faire sérieusement. Tu te rends aussi vite compte que ça ne marche pas quand l'un ou l'autre tente de faire le boulot de l'autre ou l'un, même si souvent l'un se croit supérieur.
    Les gens vont vers les domaines où leur façon de voir les choses correspond le mieux, l'outillage s'adapte au domaine.. Je crois qu'on échappera jamais à une bonne grosse dose de communautés qui se regardent avec un peu d'incompréhension et du mépris plus ou moins exprimé.

    Petite cassedédi aussi à la boucle classique de pas mal d'équipes mixtes de boîtes dont le web n'est pas l'activité principale: "nan mais le web c'est de la merde j'en fais pas, mets l'alternant et le stagiaire en paire sur la partie webapp" => noob qui bosse sur la partie webapp => webapp faite n'importe comment et contre tout l'état de l'art => "nan mais tu vois je te l'avais dit le web c'est de la merde"

  25. #8695
    Citation Envoyé par Kamikaze Voir le message
    Actuellement je bosse sur un produit où j'ai facilement délivré 90% de la valeur du truc dans un langage compilé standard, genre 1000 lignes de code. Ensuite il nous fallait une UI, on a fait ça avec du web.
    Salut, tu es en train de commencer par comparer le résultat entre une application compilée et du js qui est interprété. Ça commence assez mal.

    Surtout que le js moderne qui est utilisé dans une application est ensuite transpilé dans un package js qui est interprétable par un maximum de browser sur de multiples plateformes.

    Évidemment que le tooling autour il va être un peu énervé.


    Le package.lock.json je sais pas quoi, fait 30k lignes. Et quand je fais des codes reviews de dev web sur une techno que je connais, c'est jamais très bon.
    Si tu dis ça par ce que a la vu de la taille tu pressens que ça implique beaucoup (trop) de dépendances, peu être bien.

    Par contre en soit ces fichiers lock sont hyper verbeux, c'est le but ça décrit absolument toutes les dépendances. En php ça donne même les URL pour donner des sous aux développeurs.
    Tu compares la taille du fichier à une rom nes alors que c'est pas du code qui est exécuté, encore une fois rien à voir.


    Donc ça me donne une impression excessivement mauvaise. Enormément de code pour des features simples, des temps de build hallucinants, des performances bofs.
    Ha bah du coup comme je le disais plus haut tu as tout le tooling nécessaire pour compiler/transpiler, tu as aussi toutes les dépendances qui vont avec les framework/librairies qu'on utilise par ce que comme l'a dit Dross le plus important c'est plus souvent le Time to market donc on a besoin d'industrialisation.

    C'est un constat généralisé sur tout le web, tous les langages se sont professionalisé notamment en s'industrialisant.


  26. #8696
    Ouais ouais mon premier post était clairement trop rentre dedans, Charmide a bien résumé la situation. Je pige mieux maintenant. En fait j'imaginais pas du tout l'ecosystème web comme ça je m'attendais à un truc genre Go ou Rust où toute cette partie rendue explicite par le .lock est complètement masquée.

    Genre quand tu compiles en C généralement par défaut c'est link avec glibc (ou autre runtime lib), qui fait plusieurs MB, sauf que c'est pas "dans" le projet. Du coup ça explique la différence.

    Je suis aussi surpris par le manque de standardisation mais finalement c'est un peu du même niveau que les divers langages dispos (Go, Rust, C, C++, Carbon, etc. etc.)

    Du coup c'est un peu ce que disait Charmide, tu demandes à faire un truc à des devs web, chacun va le faire un peu à sa manière. Mais c'est pareil en C++ quelque part (entre ceux qui utilisent CMake ou autre) c'est pas unifié.

    Du coup je serais curieux de voir la tech stack des canards qui font du web, genre au pif quand je cherche webpack sur internet, je vois plusieurs projets qui prétendent faire 10x mieux

    Genre pour montrer le choc des cultures aussi: on est d'accord que le projet d'Awake (site web), tu pourrais le coder de manière entièrement statique, je dis absolument pas que c'est la bonne manière hein.
    Mais du coup dans ma tête en ouvrant le repo, je m'attendais à voir, le html, le .css, et le javascript qui s'occupe de la logique du site (change de langue). Je m'attendais pas à voir autant "d'autres" trucs qui me parlent absolument pas (bon à la limite le html templaté, et effectivement y'a l'air d'avoir beaucoup de framework qui font ça).
    package.lock, npx webpack, tsconfig.json, tsconfig.browser.json, etc.

    C'est un manque de culture web, je suis toujours surpris/choqué quand je découvre plusieurs trucs distincts fait dans le même langage. Il m'a fallu beaucoup de temps pour "comprendre" Node (et je suis pas sûr d'avoir compris ), avec un collègue je lui disais "mais pourquoi Node c'est en javascript, ça run pas dans le browser, mais pourquoi t'utilises pas un serveur dans un langage plus adapté, mais pourquoi ton truc de 'build' il est aussi en javascript"

    Chui un peu parti au quart de tour, car sur mon projet actuel et le précédent dans ma boite d'avant le temps de "build" (je sais pas exactement tout ce qui s'y passe) du projet web est systématiquement plus lent que ma pipeline CI dans un autre langage. Et quand j'essaye de mettre les mains dans un projet web je suis toujours très déçu des possibilités de refactoring et d'évolution. Donc time to market élevé alors que l'argument habituel c'est de dire que le time to market est plus rapide (langage interprété etc.). Mais c'est p'têt que je tombe avec des mecs qui n'ont pas forcément les bonnes pratiques, etc. etc.

    Bref en tout cas c'est plus clair, merci les canards, et venez poster votre tech stack!!! J'ai envie de faire des petits trucs simples en web et je suis curieux de voir ce que vous recommandez.
    Le trucs qui m'intéresse le plus c'est la partie sécurité (genre form avec password, maintien d'une session une fois loggé, les trucs comme SAML, paiements en ligne)

  27. #8697
    D'un point de vue "Maker" comme moi, votre débat est fascinant ^^

    De mon point de vue, la stack, le nombre de ligne de code etc, c'est vraiment très très bas en priorité par rapport à
    1) La solution apportée au client et combien de temps ça me prend à mettre en place
    2) La facilité de développement que j'ai (Par exemple, je suis passé à Svelte récemment par rapport à React, niveau DX, je trouve ça bien mieux).

    Pour ta dernière question, pareil je pense que ça va dépendre de ton envie d'avoir une boite noire, mais qui se met en place en 2sec, ou de voir la matrice.

    L'année dernière je suis parti d'une idée vague à un produit en ligne avec système de login et paiement en 48h même pas. Par contre je me suis pas fait chier à réinventer la roue. J'ai utilisé Supabase pour le système de DB, et d'authentification/authorization, et Stripe pour le paiement en ligne (Super API, et ultra facile d'utilisation, tu mets en place 2-3 hooks et c'est fini).

    En autre lib de paiement en ligne tu as également Paddle, ou même Gumroad/Lemonsqueezy.

    Pöur l'auth/login, à l'ancienne tu as le venerable Passport.js aussi

  28. #8698
    Bon en tout cas je suis en train de regarder pour gulp qui a l'air plutot sympa et qui pourrait simplifier la procédure d'automatisation des taches, mais en attendant d'etre sur et a l'aise dessus je vais garder le système scripts dans package.json. Merci pour votre aide

  29. #8699
    Aujourd'hui mon client me demande de communiquer avec une API pour laquelle je n'ai absolument aucune documentation.

    Je viens de me rendre compte que c'est du SOAP.

    Comme envie de me petit suicider.

  30. #8700
    Lol une de mes plus belle histoire c'est quand j'ai découvert soap, on me parle de "gSoap", je me dis "ah Google Soap" (pas du tout), ça doit être un truc bien du coup!

    Et puis j'ai découvert l'enfer hahaha, pire daube que j'ai jamais vu

Page 290 sur 296 PremièrePremière ... 190240280282283284285286287288289290291292293294295296 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •