Je ne fais pas de pub. Répond sur le fond, cet article c'est du grand n'importe quoi. Les commentaires sont ouverts à tous apparemment, même à ceux qui ont pondu 4 commentairesCitation:
Envoyé par blbird
Version imprimable
Je ne fais pas de pub. Répond sur le fond, cet article c'est du grand n'importe quoi. Les commentaires sont ouverts à tous apparemment, même à ceux qui ont pondu 4 commentairesCitation:
Envoyé par blbird
RTuy sais bien qu'il ne s'agit pas de ça, il s'agit de gens non compétents qui empilent des librairies qu'ils ne maitrisent pas.Citation:
Envoyé par walfrat
Mais peut-être que s'ils ne sont pas compétents c'est tout simplement parce que JavaScript n'est pas un langage qui donne envie d'acquérir de la compétence dessus.
C'est comme les gens qui s'amusent à faire du graphisme sous Paint pour le fun, d'accord avec assez de pratique on peut faire des choses impressionnantes mais les gens normaux préfèrent acquérir de la compétence sous Photoshop ou Illustrator.
Personnellement j'ai fait des tas de trucs en JS Vanilla, des sites one page, des jeux vidéos, des concours à la con, eh bien je confirme que JS ça reste toujours tout autant de la merde quel que soit le niveau d'expérience dessus, donc maintenant qu'il y a de meilleurs outils pour ça je les utilise.
ce serait pas plutôt j'ai essayer de faire.Citation:
Personnellement j'ai fait des tas de trucs en JS Vanilla, des sites one page, des jeux vidéos, des concours à la con, eh bien je confirme que JS ça reste toujours tout autant de la merde quel que soit le niveau d'expérience dessus, donc maintenant qu'il y a de meilleurs outils pour ça je les utilise.
Donc quoi ? Il faut s'être bouffer toutes les specs du JS et avoir 5 ans de pratique avant de faire un projet ?Citation:
Envoyé par rccc_
Il faut aussi s'être manger toute la documentation d'une librairie et avoir au moins 3 ans de pratique avant de commencer ?
Bien que je ne doute pas qu'il y a des gens plus ou moins compétent la réalité est là : l'informatique est encore un domaine qui dans certaines parties manque de maturité et qui n'est pas stable. Le développement d'applications avec IHM en est un très bon exemple. Ceci peu aussi s'expliquer que quand il s'agit de développer des IHM, n'importe qui qui arrivent à empiler quelque copier/coller peuvent faire croire qu'ils pondront quelque chose de sérieux. Ce n'est évidemment pas le cas pour d'autres éléments tel que l'embarqué, le système,...
En outre si on veut aller plus loin on peut ressasser ce que tout le monde a déjà dit et redit :
- la gestion plus ou moins foireuse des projet
- les estimations des développeurs coupé en deux parce qu"on arriver quand même a faire marcher quelque chose"
- Les gens qui n'y connaissent rien qui imposent leur décision
Je fais partie de ces gens qui "empilent" des librairies/framework. Par "empiler" ici dans mon cas, j'aime à croire que quand je rajoute un dépendance c'est que j'en ai vraiment besoin, et je la prends pas parce que c'est le dernier truc à la mode. Et quand j'utilise le framework (surtout le framework, moins les librairies) parfois je le fais bien, parfois non. Ou parfois je commence à bien le faire, puis la demande change, encore et encore, pas la deadline par contre.
Mon point est que quand on voit le résultat d'un site et que c'est pas bon, c'est souvent l'empilement de plus d'un dysfonctionnement ou incompétence.
Avec Angular on a au final très peu besoin de rajouter des dépendances non intégrées à l'écosystème. Ca n'en fait pas un facteur de stabilité parfaite, mais c'est déjà beaucoup mieux qu'un React qui n'est qu'un squelette sur lequel on vient greffer tout et n'importe quoi.
Svelte
Citation:
Svelte is a radical new approach to building user interfaces. Whereas traditional frameworks like React and Vue do the bulk of their work in the browser, Svelte shifts that work into a compile step that happens when you build your app.
Instead of using techniques like virtual DOM diffing, Svelte writes code that surgically updates the DOM when the state of your app changes.
Bonjour,
Je suis obligé de faire du React depuis plus d'un an maintenant et je dois dire que je n'accroche pas du tout mais bon il en faut pour tous les gouts. Pour moi, j'ai clairement l'impression d'être revenu dans les années 90 où il fallait tout faire à la main.
Je ne suis pas du tout en accord avec et c'est d'ailleurs en partie pour cela que j'ai l'impression de revenir dans les années 90... Sans parler que même avec des frameworks tels que Bootstrap par exemple, il faut passer des tests sur tout un panel de navigateurs et versions (en entreprise on n'a pas toujours les dernières versions des navigateurs).Citation:
Envoyé par Sodium
Dans 5 ans ton appli ne sera pas maintenue : elle aura été réécrite (peut être même plusieurs fois) en fonction des frameworks à la mode. Je développe aussi avec Delphi sans problème tout type d'application avec : Web, Mobile, Desktop sans avoir été limité ou bloqué par l'éditeur. C'est justement la force de pouvoir utiliser le créateur d'interface ou non en fonction des besoins. Les ihms sont en vectoriel et il est possible via un mécanisme d'héritage d'adapter au mieux ton interface en fonction de la cible (ce n'est pas la même utilisation sur pc doté d'un 1 ou plusieurs écrans que sur un smartphone 5 pouces ou une montre connectée). C'est à mon avis bien plus responsive et multi devices qu'une application web. En plus on peut s'appuyer sur les thèmes des OS donc l'utilisateur n'est pas perdu.Citation:
Envoyé par Sodium
En plus, le maquettage est facilité et une autre personne qu'un dev peut le faire et cela peut être repris tel quel par le dev ensuite pas besoin d'un outil intermédiaire !
J'utilise et apprécie beaucoup VSCode et Teams par exemple basés sur Electron mais j'ai du mal à voir le bénéfice d'Electron. Il y a à mon sens bien mieux pour faire du natif multi device. Il suffit de lancer VSCode sans plugin sans ouvrir de projet : c'est tout de suite plus de 300 Mo de RAM occupé, Teams 800 Mo... Alors dire que c'est ultra léger...
Mais cela est une tendance générale malheureusement, les développeurs ne cherchent même plus à optimiser un minimum leur application. Si l'appli ralentit, on préfère la scaler différemment, lui ajouter des conteneurs, ajouter du CPU et de la RAM tant pis pour la consommation d'énergie...Citation:
Envoyé par Sodium
C'est normal, React est dans la philosophie JavaScript et reste du bricolage, ça permet juste de bricoler plus vite.Citation:
Envoyé par gbegreg
C'est une question d'expérience, l'application que je développe actuellement est compatible Internet explorer 9 et je n'ai fait aucun effort particulier pour cela. Mais il faut bien connaître la technologie. Le CSS ce n'est pas facile, ça en a l'air mais ça ne l'est absolument pas, ça nécessite de l'expérience et une très bonne connaissance de ses sélecteurs et règles.Citation:
Envoyé par gbegreg
Non, je travaille dans une entreprise dont le chiffre d'affaire se compte en millions, hors de question de redévelopper quelque chose de stable s'il n'y a pas une valeur ajoutée considérable. C'est purement une question idéologique, personne ne met un fusil sur la tempe pour passer au dernier truc sorti, mise à part des décideurs incompétents. On ne peut pas attribuer la responsabilité de mauvais choix de technologie aux technologies en question.Citation:
Envoyé par gbegreg
Une tentative avait été faite (pas par moi) de développer une application en Delphi. Finalement ça s'est révélé impossible et c'est moi qui ai repris le projet... en Angular. Si tu considères que tu peux faire ce que tu veux en Delphi, c'est que tu ne travailles pas avec un graphiste et avec de grandes exigences en design et qualité d'interface utilisateur.Citation:
Envoyé par gbegreg
Ca fait vingt ans que les gens ici travaillent sur du Delphi. Pour une fois on a décidé de faire les choses correctement et d'utiliser les ressources du département graphique pour faire une application de qualité. Eh bien avec Delphi, ça ne fonctionne pas. Mais si tu as de super contre-exemples je veux bien être mise face à mes erreurs.
Non, ça n'existe pas, et c'est pour cela que les développeurs se sont peu à peu tournés vers les technologies web, notamment vu la galère que c'était de maintenir une application juste compatible iOS/Android. Delphi est une technologie d'un autre âge dont on ferait mieux de débrancher de le respirateur. Le problème c'est que le développeur veut avant tout développer vite est a très peu d'exigence en terme de qualité d'Interface utilisateur.Citation:
Envoyé par gbegreg
Ce n'est pas que les développeurs ne cherchent plus à optimiser leurs applications, c'est que les applications ne font plus la même chose qu'il y a dix ans, et nos machines n'ont pas les mêmes ressources qu'il y a dix ans. 300mo ce n'est rien, Chrome me prend la même chose juste pour maintenir mon plugin Hangouts.Citation:
Envoyé par gbegreg
Juste par curiosité, si tu lances un Eclipse, un Visual Studio ou Delphi ça prend combien ?
Tout à fait d'accord, le css n'est pas simple et c'est une question d'expérience. D'ailleurs, c'est valable pour n'importe quel langage.Citation:
Envoyé par Sodium
Moi aussi, je travaille dans une grande entreprise et il s'avère que si on laisse vieillir une application stable qui répond au besoin tôt ou tard cela se transformera en dette technique (la version du framework utilisé est ancienne et les impacts seront importants pour migrer vers la nouvelle version du framework, parce qu'une dépendance n'existe plus etc...).Citation:
Envoyé par Sodium
Si je travaille avec des UX designer...Citation:
Envoyé par Sodium
Justement, ces personnes qui travaillent depuis plus de 20 ans avec Delphi utilisent ils les dernières versions ? Le framework multi plateforme (Firemonkey) ?Citation:
Envoyé par Sodium
Et voici quelques exemples d'applications récentes faites avec Delphi qui disposent d'interfaces stylées :
https://www.youtube.com/watch?v=IJzEuZTSXDI
https://www.youtube.com/watch?time_continue=1&v=5cWQbH3llx8&feature=emb_logo
https://www.youtube.com/watch?v=Tu3O5qvVVHo
https://www.youtube.com/watch?v=RHssUAUZd00&feature=emb_logo
A titre personnel, ma dernière petite démo (ce n'est pas une application complète), mais elle fait environ 500 lignes de code, fonctionne sans pb (et avec le même code) sous Windows, Linux, MacOS, Android et IOS (pour le coup, je ne suis pas graphiste) :
https://www.youtube.com/watch?v=J4u8enI74-k
Si ça existe (cf les exemples ci dessus). Delphi n'est pas une technologie : c'est l'IDE RAD Studio couplé au compilateur Pascal Objet d'Embarcadero. Si on couple RAD Studio avec le compilateur C++ d'Embarcadero, c'est C++ Builder.Citation:
Envoyé par Sodium
Et pour la petite histoire Delphi et Javascript ont le même âge et les deux ont beaucoup évolué depuis leur apparition ;)
Les frameworks Electron et autres (React native...) ne sont là que pour permettre aux développeurs qui n'ont fait que du web de faire à moindre couts (pour eux) des applications natives. Regardez aussi les consommations électriques de ces applications sur des appareils mobiles où l'autonomie est aussi un critère important des clients finaux.
Les applications font toujours les mêmes choses : des IHM, des bases de données, des besoins utilisateurs à combler. Ce qui est certain c'est que les délais pour répondre aux utilisateurs se sont réduits et qu'il faut aller toujours plus vite. Ce qui peut expliquer le manque d'optimisations mais comme tu le disais c'est aussi une question d'expérience.Citation:
Envoyé par Sodium
Pas de pb :Citation:
Envoyé par Sodium
Pièce jointe 574096
NB : Delphi en version 10.4 Sydney, VSCOde en version 1.46, Eclipse en 4.16 (juin 2020). A chaque fois IDE démarré, aucun projet ouvert.
Ca sera vrai sur n'importe quelle technologie. Ne pas migrer vers le nouveau framework à la mode, ce n'est pas la même chose que d'acquérir de la dette technique.Citation:
Envoyé par gbegreg
Pour les nouvelles applications oui, les anciennes sont du Delphi 7 et il a fallu engager des personnes spécialement pour les maintenir...Citation:
Envoyé par gbegreg
La première ce sont des vues très simples et de l'interactivité simple. Ca n'existe a priori pas sur desktop, bien que j'avoue avoir la flemme de vérifier.Citation:
Envoyé par gbegreg
Fl Studio je l'utilise, très franchement niveau UX c'est loin d'une référence, c'est même très en dessous de la concurrence à mon humble avis. Apparemment ils ont galéré énormément à sortir une version MacOS (ce qui est un peu un problème vu que MacOS est bien installé niveau création audio. Est-ce la même base de programmation pour la version mobile ? J'en doute fortement, l'interface n'a rien à voir, elle est d'ailleurs beaucoup plus jolies (l'avantage surtout d'être sorti d'une dette technique...).
L'application de dessin c'est de l'api graphique pour le dessin, je ne vois pas vraiment le rapport, et les menus ressemblent à du Windows 98. Même remarque pour les jeu vidéo, c'est du jeu vidéo, pas de l'application multi-devices.
C'est partiellement vrai, c'est effectivement devenu populaire par question de facilité de dev car maintenir des applications iOS/Android est très vite devenu un casse-tête pour les développeurs lorsqu'Android s'est popularisé.Citation:
Envoyé par gbegreg
Par contre, le fait que le DOM soit devenu aussi populaire n'est qu'une prise de conscience de sa puissance en terme de conception d'interface. Le "je ne peux pas faire ça" dans ce domaine ça n'existe pas.
Par ailleurs, penses-tu honnêtement que les équipes de Microsoft aient développé VSCode en JavaScript par paresse ou par incompétence ? Et penses-tu réellement qu'il serait devenu probablement l'éditeur le plus populaire s'il s'agissait d'un soft de mauvaise qualité
Effectivement, impressionnant, après il faut voir en utilisant réelle, et considérer également que Delphi fait du Delphi tandis que VSCode fait à peu près tous les langages imaginables avec des armées de plugins pour leur prise en charge ainsi que sa customisation. Note que VSCode sans projet ouvert je tombe à 160mo, avec un projet je monte à 230mo et 400 avec deux instances et deux projets ouverts.Citation:
Envoyé par gbegreg
Delphi 7 c'était en 2002, il y a 18 ans (Windows XP venait juste de sortir...). Même si les applications fonctionnaient et étaient stables, le fait de ne pas les avoir maintenues à jour à créer de la dette technique. C'est quand même une belle preuve de longévité qu'elles aient pu passer Vista, Seven, 8 et Windows 10 !Citation:
Envoyé par Sodium
Citation:
Envoyé par Sodium
Les goûts et les couleurs :), on a chacun son avis mais tu ne peux pas dire que l'interface n'a pas été travaillée avec des graphistes. Et si la version mobile (depuis la version 3) est faite aussi avec Delphi.Citation:
Envoyé par Sodium
L'application de dessin avec l'interface du stylet et sa représentation graphique en 3D qui s'incline, s'oriente en fonction du stylet et la pression qui est gérée...Citation:
Envoyé par Sodium
Pour le jeu, l'interface l'interface est travaillée (ce n'est pas encore multi device (utilisation de DirectX) mais c'est dans les tuyaux...).
Je t'ai donné quelques exemples divers et variés car tu parlais de travailler avec un graphiste et que ça n'était pas possible à faire en Delphi. Je serai bien curieux de voir ce qui n'est pas réalisable en Delphi mais qui le soit en Angular...
Du moment que l'on a la main sur le graphisme, on peut faire tout ce que l'on veut. L'avantage de jouer avec le DOM c'est que ça tourne dans une application Web. Ça ne montre en rien sa puissance en terme de conception d'interface.Citation:
Envoyé par Sodium
Non je pense qu'ils l'ont fait pour contrer Atom qui commençait à devenir populaire. Il se sont appuyer sur les mêmes briques pour le concurrencer et le dépasser rapidement.Citation:
Envoyé par Sodium
Pour moi la qualité d'un soft ne dépend pas du langage utilisé. L'utilisateur se fiche pas mal de la techno utilisée : il veut que l'application fasse ce pourquoi elle est prévue de manière fiable et si en plus elle peut être agréable c'est un plus indéniable (mais les goûts et les couleurs je me répète...).Citation:
Envoyé par Sodium
Le principe des logiciels tels que Delphi est de fournir une interface graphique pour créer des applications, de fournir des briques utilisables facilement pour créer des éléments d'interface. C'est pratique, mais ça trouve forcément ses limites, les éléments sont conçus pour être personnalisés et adaptés jusqu'à un certain point. Ca a été le cas avec les éditeurs web tels que Dreamweaver ou plus récemment Adobe Muse mais plus aucun développeur sérieux ne travaille avec ça.
Le DOM et CSS c'est exactement l'inverse, rien n'est rien et tout est tout. Il n'y a, à part les éléments de formulaires qui sont d'ailleurs souvent substitués pour plus de contrôle, rien qui ait un rôle particulier, tout se fait à la main et le développeur doit donc immédiatement apprendre à utiliser le peu qu'il a à sa disposition pour remplir les besoins de plus en plus poussés en termes d'interface. Ca signifie qu'il a plus de boulot. Ca signifie aussi qu'il n'y a pas de limites. Le tout séparé en trois couches distinctes, le DOM, le CSS et JavaScript, parfaitement adaptés à la représentation code d'un rendu graphique.
Alors, peut-être qu'avec assez de maîtrise, quand on génère l'ensemble du code source soi-même plutôt qu'avec l'éditeur Delphi, on peut faire la même chose. Mais alors pour s'infliger de travailler son IDE, se marier avec un éditeur qui peut abandonner complètement le support, l'absence d'une vraie communauté derrière et surtout... travailler en Pascal, brrr.
Oui, l'utilisateur se fout complètement dans quel langage est développé le logiciel qu'il utilise. Sauf que, si VSCode est actuellement l'un des éditeurs préférés des développeurs c'est que... eh bien la technologie utilisée pour le faire est adaptée à cela.
C'est ton opinion, ce n'est pas la seule possible.Citation:
Envoyé par Sodium
Nous utilisons React pour toute nos applications depuis trois mois (après 6 ans d'angularjs) et ce n'est absolument pas du "bricolage". Note aussi que tout est en Typescript.
Merci pour ce moment.Citation:
Envoyé par gbegreg
Va dire ça en entreprise qui tourne Cobol, ou encore des app VB6 avec des composants VB4 qui bloquent la migration Windows 10...
Boucle d'affichage en Angular :
Boucle d'affichage en React :Code:
2
3<select> <option *ngFor="let i of numbers">{{i}}</option> </select>
Je pense que ça se passe de commentaire.Code:
2
3
4
5<select> { numbers.map(el => <option value={el} key={el}> {el} </option>) } </select>
Et ça c'est sans même aborder l'ignoble mélange de scripting et de rendu de vue, séparer la vue de la logique c'est tout de même le point un de toute application lisible.
C'est très pratique et ça couvre facilement 80% des cas les plus fréquents que l'on trouve dans une application. C'est un gain de temps appréciable sur la majorité des applications demandées. On peut alors passer plus de temps sur l'implémentation des règles métiers, les tests...Citation:
Envoyé par Sodium
Les besoins particuliers en interface peuvent être gérés manuellement aussi en Delphi, il n'y a donc pas de limite non plus. Ça demandera alors forcément plus de temps et de tests. Ca signifie plus de boulot mais aussi plus de risque de bug du coup.Citation:
Envoyé par Sodium
Affaire de goût toujours... et il a évolué depuis Delphi 7 !!!Citation:
Envoyé par Sodium
Non c'est plutôt que l'outil est adapté au besoin mais en rien que la technologie utilisée pour le faire est adaptée.Citation:
Envoyé par Sodium
Mais j'attends toujours un exemple d'ihm faisable en Angular et pas avec Delphi :)
Ben justement dans mon entreprise il y a toujours et pour encore un moment du Cobol. Sauf que (même si c'est possible) on ne l'utilise pas pour les IHM, il est côté back sur des serveurs Unix. Or, la conversation était basée sur les ihm.Citation:
Envoyé par frfancha
Ouep, 80% des cas, jusqu'au moment où on te demande un truc et où tu es obligé de répondre je peux pas faiCitation:
Envoyé par gbegreg
Boah je ne sais pas, si je te demande de faire un menu horizontal et que lorsque je clique sur un élément il décolle et se transforme en boule dont le background est un flux Youtube que je puisse m'amuser à faire rebondir contre les bords de l'écran ça te prend combien de temps ?Citation:
Envoyé par gbegreg
Citation:
Envoyé par Sodium
Ben si faisons-en de commentaire, et même deux:
1) Le code React de création des options est beaucoup plus puissant puisqu'il dispose de tout ce que Typescript offre, on n'est pas limité à ce qu'offre Angular dans ngFor
2) Mais surtout, il n'est pas nécessaire d'apprendre un langage spécifique au framework
Pour moi y a pas photo React est loin devant.
Et c'est vraiment marrant ton exemple, parce que tu sembles aimer dans Angular les possibilités spécifiques prédéfinies et limitées, le genre de chose que tu reproches à Delphi d'autre part
Oui merci je sais que cobol est côté back end, et encore certaines grandes banques utilisent encore des écrans "verts" pilotés en cobol.Citation:
Envoyé par gbegreg
Mais oui c'est très rare, à la limite si on voit des écrans verts ce seront plutôt des AS/400 avec du RPG.
Néanmoins mon exemple était sur le conservatisme de l'entreprise en général, cobol n'était qu'un exemple, l'autre étant VB6 avec composant VB4 dont plus personne n'a la source qui bloque le pasage à Windows 10, et là on est bien dans IHM
Le ngFor il peut faire à peu près tout et n'importe quoi. C'est juste qu'entre gens civilisés, on sépare cette logique du template.Citation:
Envoyé par frfancha
Quel langage exactement ?Citation:
Envoyé par frfancha
Oui, en terme de popularité car faire de l'Angular requière de la rigueur et de bonnes pratiques de programmation tandis que React demande... ben de savoir faire du JavaScript quoi :DCitation:
Envoyé par frfancha
Quelles possibilités spécifiques et prédéterminées exactement ? Mon exemple est très simple, passer la balise en positionnement fixe, lui appliquer une classe CSS et mettre une balise Youtube dedans. Bon après faut rajouter un petit moteur physique en JavaScript, mais je l'ai déjà fait et je suis une brèle en math donc ça ne doit pas être si compliqué.Citation:
Envoyé par frfancha
Par ailleurs, je parlais de la technologie DOM-CSS-JavaScript, pas d'Angular spécifiquement.
C'est plutôt la philosophie des informaticiens de manière générale, si ça marche on y touche pas. Si ça marchouille et que ça a dix ans on y touche encore moins car il n'y a plus personne qui sait comment ça marche.Citation:
Envoyé par frfancha
perso, je fais de l'Angular. c'est bien encadré, complet, extrêmement fiable, performant.....
Si on peut toujours faire mais pour les cas particuliers (à la marge je le répète) c'est des adaptations manuelles comme avec le DOM, CSS, HTML. Aucun blocage, aucun "je ne peux pas faire".Citation:
Envoyé par Sodium
C'est un cas d'ihm assez particulier que tu décris et je ne suis pas certain que visionner des vidéos Youtube sur une sphère qui bouge soit la meilleure expérience utilisateur qu'il soit, mais bon. Ton exemple reste aussi sur des animations simples.Citation:
Envoyé par Sodium
Aucun pb, menu horizontal, les animations de toutes sortes aucun pb et en plus sans aucun code. Il y aura du code pour déclencher l'action sur le clic, pour déterminer en dynamique la taille de l'écran et pour intégrer la vidéo en tant que texture sur la sphère. Après par code on pourrait même aller plus loin en intégrant un moteur physique (Box2d est fourni en standard par exemple) pour que la sphère ne fasse pas que rebondir sur les bords de l'écran mais qu'il y ait une gestion de la gravité par exemple, qu'elle se "cogne" aux autres éléments graphiques etc...
Le Cobol évolue toujours aussi (intégration du XML, JSON par exemple) et si on ne le fait pas évoluer on perd le support éditeur et on se retrouve avec une dette technique importante...Citation:
Envoyé par frfancha
Citation:
Envoyé par frfancha
(1) ngfor est complet et dispose de tout le nécessaire. tu connais rien alors tu nous sort de fausses affirmations
(2) avec REACT donc on se retrouve avec du code dégueux dans la vue ---> AH AH AH justement c'est ce qu'il faut éviter ... le comble
par contre, oui, le JSX c'est un langage de merde sur REACT ! je te confirme !
(3) "spécifiques prédéfinies et limitées,"
je crois que c'est tes connaissances qui sont limités.
je suis à mon 4ème gros projets sur Angular, je n'ai jamais été limité.
ça me débecte ce genre de personnage qui la ramène avec de fausses informations, de l'ignorance totale !
React, c'est le bordel.... les gens dev... chacun à sa façon, bonjour la maintenance. React c'est juste une mode de moutons....
Moué, je serais très curieuse de voir la tronche du code derrière (surtout s'il est généré) et le niveau de complexité que ça ajoute dans l'ide pour ensuite développer l'application qui du coup, je suppose, se met à intégrer des effets graphique et n'est plus uniquement déclaratif. En html ça va être un menu normal, une déclaration de style css de quelques ligne (réutilisable) et un add class qui là aussi va tenir en une ligne. Ensuite évidemment le code du moteur physique, ça c'est autre chose mais ça reste uniquement un fichier de code à charger. À mon avis ton application va commencer à intégrer de la complexité avec de la manipulation d'éléments.
Sans faire ce que tu as demandé (car je n'en vois pas l'intérêt, et j'ai déjà des exemples avec des textures animées en 3D mais pas avec des vidéos Youtube), voici un exemple de la "tronche" du code. Exemple d'un bouton qui va se déplacer sur l'axe des abscisses de la position 90 à 300 lorsqu'on clique dessus.Citation:
Envoyé par Sodium
Dans le designer d'interface, j'ai placé un bouton via la souris, j'ai ajouté un composant TFloatanimation via la souris aussi.
Pièce jointe 574172
Dans la vue "Structure", je place l'animation pour qu'elle soit enfant du bouton (tous les composants peuvent contenir d'autres composants) afin que l'animation agisse sur le bouton et ses éventuels composants enfants.
Pièce jointe 574173
Dans la vue "Inspecteur d'objet", je configure l'animation comme je le souhaite. Si ce qui est proposé par défaut (déterminé en fonction du composant parent) ne suffit pas, il est possible d'implémenter sa propre animation dans l'événement OnProgress.
Pièce jointe 574174
Et enfin, dans le code, j'implémente le démarrage de l'animation lors du clic sur le bouton :
Pièce jointe 574175
C'est manifestement un code lourd et illisible...
Je persiste à dire que les besoins usuels sont largement couverts avec ce qui est fourni en standard. Pour les besoins particuliers, c'est à implémenter soi même mais tout est possible.
Bien sur, tout ce qui est fait via la souris, la vue structure et l'inspecteur d'objet peut être fait aussi dynamiquement dans le code.
Pour ajouter des effets graphiques, même chose : de nombreux effets sont fournis en standard sous forme de composant (donc bien évidemment réutilisable, cumulable à souhait). D'ailleurs, la notion de composant réutilisable est l'essence même de Delphi depuis son origine. Cerise sur le gâteau, derrière se sont des shaders exécutés sur le GPU. On peut créer ses propres shaders mais, dans ce cas, il va falloir connaitre le HLSL ou le GLSL.
moralité : éviter de dire oui à des demandes du genre "j'aimerai que mon application métier s'affiche dans le ruban de l'exporateur windows en 1500 x 1200 px tout en flashant le bios à l'ouverture"
Ca ressemble assez bien à ce que j'imaginais et finalement pas mal à du Flash en plus puissant. Premier point qui me choque : Je place un bouton sur la grille qui va se déplacer sur l'axe. En HTML on n'a pas une grille, on a un DOM, et des styles qui s'appliquent à ce DOM. Un élément dépend de son contexte et pas de sa position sur une grille.Citation:
Envoyé par gbegreg
Avoir une vue WISIWYG d'une application non designée pour un viewport un affichage spécifique (et même dans ce cas) est un problème majeur et c'est pourquoi aucun développeur web compétent ne travaille avec un éditeur de ce genre).
Là je vois déjà un cauchemar à maintenir alors que tu as un bouton. Une grille, graphique, une arborescence d'éléments graphiques, des objets d'animations, des éditeurs de propriété avec 300 trucs et configurés dans des sous et sous-sous menu. Alors quand on commence à avoir des couches et des couches et des couches de trucs et de machins, qu'il faut réorganiser le layout pour des dizaines de tailles d'écran différentes, quand c'est un autre développeur qui arrive sur l'application...
La meilleure méthode pour concevoir des interfaces, passée la phase design, c'est du code et uniquement du code. Et c'est pour ça que la technologie web est devenue une référence, car ça permet de concevoir des inerfaces sans utiliser un éditeur graphique tout en restant facilement lisible par un humain car c'est une représentation très simple avec une couche contenu, une couche style, et une couche interactions, tout en ayant accès au code source en cours d'exécution dans le navigateur pour modifier et tester des trucs en directs.
Je pense qu'il faut juste de l'habitude et de l'expérience pour se rendre compte d'une part de la puissance du truc, d'autre part au final de la simplicité et maintenabilité.
Ah, et quand je disais "je me demande la tronche du code", je veux dire quelle est le code du rendu de l'application avec ses composants et ses styles, pas le code qui te sert à appliquer à un élément un truc choisi dans des menus :aie:
Il n'y a pas de grille, c'est juste les coordonnées à l'écran qui reste en 2 dimensions qu'on soit dans une application native ou web. Pour reprendre ton exemple d'un élément qui bouge et qui rebondit aux bords de l'écran (puisque c'est ce que indiquais), j'ai fait vite: je n'ai pas fait de positionnement relatif via des layouts.Citation:
Envoyé par Sodium
Sache que l'interface graphique est dans un fichier .dfm à part qui est un simple fichier texte, consultable et modifiable en mode texte. L'éditeur graphique est un plus bien utile dans la plupart des cas. Le code métier est dans le fichier .pas.Citation:
Envoyé par Sodium
La vue en structure permet de rapidement voir comment est constituer l'ihm.
Méconnaissance encore : les interfaces sont en vectoriel... Par défaut, pas besoin de les adapter en fonction des résolutions et définitions des écrans. Après, en revanche, il est possible par un mécanisme d'héritage, de configurer l'interface spécifiquement pour une plateforme donnée : on n'affiche pas les mêmes infos sur un écran 30 pouces 4k et sur l'écran d'une montre connectée...Citation:
Envoyé par Sodium
Le développeur qui arrive sur le projet s'y retrouve vite, comme tu le dis c'est une question d'habitude.
La technique web est une référence pour le développement d'application web car c'est une bonne méthode pour simuler et tenter de se rapproche du comportement réactif des applis natives dans un navigateur. Les OS, applis natives, jeux n'utilisent pas les technologies web pour concevoir leurs interfaces...Citation:
Envoyé par Sodium
Tout à fait, et manifestement, tu n'as pas l'habitude d'utiliser Delphi pour comparer.Citation:
Envoyé par Sodium
Je t'ai montré ce que le développeur voit en terme de code (et ce qu'il doit maintenir). C'est du compilé en natif, donc le générer sera de l'assembleur et je fais confiance aux personnes qui font les compilateurs pour optimiser bien mieux que je ne pourrai le faire le code généré. Dans le cas d'une application web, il faudrait que tu donnes le code généré + le code du navigateur pour voir comment l'implémentation à été faite jusqu'à l'affichage sur l'écran.Citation:
Envoyé par Sodium
Mais je suis toujours en attente d'un exemple qui serait réalisable en web et pas en natif...
Mais pourquoi des coordonnées ? Le HTML affiche le contenu en fonction du flux. Si je conçois un menu après, ce qui se trouve après se retrouve en dessous. Si je veux positionner un élément de ce menu, il est relatif au menu. Quelle perte de temps que de placer élément par élément à la main.Citation:
Envoyé par gbegreg
Le vectoriel ne résout que le plus petit des problèmes. Rendre une interface responsive, ce n'est pas juste rendre des éléments plus petits ou plus grand, c'est parfois réorganiser complètement le layout. Je suppose qu'en Delphi tu crées des layout différents en te basant sur plusieurs tailles d'écran... comment tu t'y retrouves ? Si tu as un item d'un menu en haut à haut à gauche à 900px de large et en bas à droite en 860px comment tu suis le flux de ton layout.Citation:
Envoyé par gbegreg
Comment veux-tu que j'ai l'habitude d'utiliser Delphi ? La techno est morte de chez morte, je n'ai même pas trouvé de vidéo Youtube d'explication. Mais j'ai déjà bossé avec des conceptions de ce genre et ça ne marche pas.Citation:
Envoyé par gbegreg
Ce que je veux dire c'est que je veux pouvoir avoir un contrôle total du layout directement dans le code, et pouvoir comprendre le layout de l'application juste en regardant ce dernier. Donc à quoi ressemble ce code ?Citation:
Envoyé par gbegreg
Tu as raison, j'aurais probablement plutôt dû dire pas possible de faire ça de manière maintenable. Déjà là avec ce simple exemple c'est limite, tu ajoutes des objets d'animations, des styles via des menus. En HTML l'élément de menu est une balise comme n'importe quelle autre, tu déclares un style de 3-4 lignes qui se trouve proprement rangé dans un fichier de style, même pas besoin de créer une animation il suffit d'indiquer qu'on peut une transition, avec un positionnement on le sort de son flux et peut être manipulé facilement... et à l'inverse il suffit d'inverser l'action. Le tout, hors moteur physique, tient en une ligne de HTML, 10 lignes de CSS, une ligne de JavaScript. Sans perdre du temps à aller cocher des cases dans des menus.Citation:
Envoyé par gbegreg
Parce que tu souhaitais faire rebondir un élément graphique sur les bords de l'écran...Citation:
Envoyé par Sodium
Je me répète, une nouvelle fois car tu ne sembles pas lire mes réponses, tu peux le faire par code aussi : on est libre d'utiliser ou non l'éditeur graphique. Celui ci convient parfaitement dans les cas les plus fréquents. Après via le code, ça revient effectivement à ce qui est fait en web.
Concernant la perte de temps c'est subjectif et ça dépend de l'expérience de chacun. Je fais du développement web aussi et, pour moi, il m'arrive de perdre beaucoup de temps à comprendre certains phénomènes avec CSS car je ne le maitrise pas.
Tu lis les réponses que je te fais ? J'ai dit que l'on pouvait parfaitement réorganiser partiellement/complétement le layout si on le souhaite et ce n'est pas une réécriture à chaque fois, via le mécanisme d'héritage c'est de l'adaptation du parent. Dans mes développements Web j'utilise aussi pas mal Bootstrap et ça convient bien pour une majorité de cas d'usage mais son côté responsive à des limites sur de petits écrans par exemple.Citation:
Envoyé par Sodium
Ce n'est pas mort, ça fonctionne très bien et tu n'as pas du beaucoup chercher... Exemples :Citation:
Envoyé par Sodium
https://www.youtube.com/c/Embarcader...ologies/videos
https://learndelphi.org/
et un exemple en français récent :
https://www.youtube.com/channel/UCSr...4Pfprlw/videos
Dans le concepteur graphique d'ihm Delphi, il suffit de basculer en mode texte/graphique pour voir/modifier le code généré ou passer par la représentation graphique.Citation:
Envoyé par Sodium
Ça ne charge ni l'IDE ni le code métier réellement utile. Avoir la représentation graphique en temps réel dans l'IDE est appréciable également, d'un coup, je vois le rendu sur Desktop (Windows, MacOS, Linux) et Mobile (IOS, Android). Les modifications apportées via l'éditeur graphique sont instantanément visibles dans l'IDE sans avoir à recompiler. Pour ce qui est des animations, oui il faut recompiler et exécuter l'appli.
Dans mon entreprise, des personnes non développeur accèdent au code et visualisent ainsi tout de suite le rendu de l'interface. Pour le maquettage c'est également très pratique. On peut constituer l'interface très rapidement avec le client à nos côtés.
Je n'ai pas rajouté de style via des menus, par défaut c'est le style de l'OS cible qui est utilisé. L'objet animation correspond à ton code HTML, on peut aussi le faire de manière inverse, en boucle, utiliser les méthodes d'interpolation de son choix, c'est exécuté dans un thread à part. Les composants que je rajoute sont réutilisables et modifiables à souhait. Et encore une fois, on n'est pas obligé de passer par l'inspecteur d'objet pour modifier les propriétés (c'est juste un raccourci pour gagner du temps), tout peut se faire par code mais du coup on se retrouve à tout faire à la main comme en web et, du coup, on perd du temps ! Sans parler des risques d'erreur quand on ajoute du code manuellement, des tests qu'il faut faire en plus.Citation:
Envoyé par Sodium
Je ne vois pas ce que tu trouves de limite dans la maintenance car une application Web moderne s'appuie sur un grand nombre de dépendances également ce qui n'est pas facile à gérer dans le temps et qui accélère aussi beaucoup la dette technologique d'une application Web.
Enfin, dans n'importe quel langage on peut produire ou non du code maintenable.
Bonsoir j'arrive peut être après la bataille entre Sodium et Simon ;D
En ce moment je cherche à choisir
J'ai un projet à rendre en septembre pour le CNAM
Le back est en Java Spring.
Je peux choisir entre Angular, view, et react.
Je vois partout des offre Angular + Spring.
Cela m'influence un peu
Car ça me ferai un plus sur le CV
Je sais que FaceBouc à fait des éfforts sur l'accessibilité avec react
Quant à view il me semble plus facile à prendre en main que les deux autres.
Et même si je dois refaire après.
Mon objectif est de présenter le minimum viable
J'ai encore du mal à choisir
Que ce soit pour le projet ou pour après
Car en général je fais du front à minima juste pour collaborer avec ceux qui savent faire, et surtout ce qui peuvent faire avec leurs yeux.
J'interviens surtout sur l'accessibilité numérique quand ça compte pour le projet
Et dans ce cas je dois chercher pourquoi ce n'est pas accessible
Je ne suis pas trop intéressé par un design single page
Mais je vais devoir faire des appels ajax, je vais appeler mes services rest fait acvec Spring
Avoir une bibliothèque de composant serait un plus, ce qui penche pour view
Si vous pouvez me donner d'autres clefs
Justement, pourquoi un élément graphique ? En HTML ça serait une simple balise qui peut sortir du flux tout comme y revenir avec une simple classe CSS.Citation:
Envoyé par gbegreg
Avec quel complexité de code par rapport à du HTML ?Citation:
Envoyé par gbegreg
Concernant la perte de temps c'est subjectif et ça dépend de l'expérience de chacun. Je fais du développement web aussi et, pour moi, il m'arrive de perdre beaucoup de temps à comprendre certains phénomènes avec CSS car je ne le maitrise pas.
Et donc tu perds en clarté du flux de ton application, déjà bien complexifié par le fait d'avoir des calques et des sous-calques, ou quel que soit le terme utilisé pour décrire la hiérarchie des éléments de l'écran.Citation:
Envoyé par gbegreg
Je ne vois pas de quelles limites tu veux parler, mais Bootstrap c'est bien pour faire un back-office sans faire perdre de temps à un graphiste mais que pour ça.Citation:
Envoyé par gbegreg
Le code généré c'est TOUJOURS sale. Ca n'existe pas du code généré propreCitation:
Envoyé par gbegreg
Encore une grosse faiblesse, utiliser des styles liés à l'OS est s'assurer d'avoir des inconsistences entre les navigateurs et devices.Citation:
Envoyé par gbegreg
On perd du temps car ce n'est pas conçu pour ça, tout simplement.Citation:
Envoyé par gbegreg
Citation:
Envoyé par CoderInTheDark
il existe une bibliothèque de widget avec Angular Material https://material.angular.io/components/categories
en effet, il y a de nombreuses offres d'emploi Angular + java. le choix est vite fait !
Angular est un framework complet et niveau temps d'apprentissage est aussi conséquent que si tu fais du vue ou react en lui ajoutant tout le nécessaire pour être complet
Si tu fais une app one page Angular est bien adapté. Il n'est pas fait pour s'inclure dans un workflow qui n'est pas 100% Angular côté front.
Si tu veux faire des pages web renvoyées par le serveur avec des éléments dynamiques, par exemple un tableau qui se régénère avec des issues d'une api qui te renvoie un JSON, VueJS est bien adapté.
Angular est bien adapté pour dev. des petits composants indépendants appelable si on le souhaite via un script javascript
Si ce n'est toi qui fait rebondir l'élément sur les coins de l'écran c'est que tu utilises quelque chose (une lib) qui le fait pour toi (ou qui va le générer pour toi)... Il n'y a pas de magie. Il faudra que tu m'expliques comment faire rebondir un élément graphique dans un conteneur (l'écran, la fenêtre du navigateur...) sans utiliser de coordonnées !Citation:
Envoyé par Sodium
Je te rappelle que l'exemple que tu voulais était :
Donc ton menu décolle (animation), se transforme en boule (3D) et on lui applique en texture une vidéo Youtube (pas de pb avec Delphi, en CSS je ne sais pas) et la boule rebondit sur les bords de l'écran (besoin de manipuler des coordonnées). J'attends de voir cela avec une simple balise HTML et une simple classe CSS (et voir également ce qui est réellement généré et exécuté par le navigateur...).Citation:
Envoyé par Sodium
Un exemple tout simple : création d'un cube en 3D, et je l'affecte à son parent (un viewport dans cet exemple qui lui aussi peut être créer de la même manière par code et le tout positionné au pixel prêt ou en relatif c'est comme on le souhaite) :Citation:
Envoyé par Sodium
C'est l'équivalent de déposer un composant TCube sur la fiche via l'éditeur graphique. Je maintiens que l'avantage de l'éditeur graphique c'est qu'on peut le faire et le montrer à l'utilisateur en temps réel (que ça soit un simple formulaire classique, une scène 3D ou autre peu importe). Une autre personne qu'un dev peut le faire également. Et cela couvre facilement 80% des demandes usuelles. Pour le reste, tout est réalisable par code et cela n'apporte absolument pas plus de complexité qu'en Web.Code:
2
3
L'application n'est pas complexifiée et le fait d'avoir un outil graphique qui te permet justement de bien voir comment est architecturé ton interface est très appréciable. La hiérarchie est ainsi bien comprise au premier coup d'oeil. Chose que je ne vois pas en CSS (par manque de maitrise certainement) dans certains projets Webs (React) que j'ai pu reprendre.Citation:
Envoyé par Sodium
Par exemple, si ton appli tourne sur des écrans de résolution < ou > à ce qui est prévu (extra small < 576px ou extra large ≥1200px). Il y a des cas où tu veux plus de souplesse (écrans très petits ou au contraire très grands)Citation:
Envoyé par Sodium
:ptdr:Citation:
Envoyé par Sodium
Venant d'une personne faisant du web, elle n'est pas mal celle là !!! Angular (je ne connais pas) mais il me semble que c'est Typescript qui est utilisé : une surcouche à Javascript. Lui même interprété par le navigateur qui ensuite a ses propres routines d'affichage qui s'appuient sur l'OS...
De plus, je ne parle même pas des minifiers ou autres que tu utilises certainement.
Encore une fois, tu ne lis pas mes réponses. Avec Delphi, je développe des applications natives : elles n'ont pas besoin de navigateurs pour fonctionner. De plus, relis bien ma phrase, j'ai dit "par défaut c'est le style de l'OS cible qui est utilisé". Sous entendu que bien évidemment on peut appliquer ses propres styles. Mais par défaut c'est le thème de l'OS qui est appliqué justement pour ne pas perturber les utilisateurs habitués à leur OS. A titre personnel, j'ai mon bureau dans un thème sombre et quand je surfe sur un site qui est par défaut en clair (ou comme beaucoup) où on ne peut pas changer le thème je ne trouve pas ça très ux.Citation:
Envoyé par Sodium
Pour rappel, Anders Hejlsberg l'un des principaux créateur de Typescript a conçu Delphi et C#.Citation:
Envoyé par Sodium
Tu ne connais pas Delphi, tu continues à le critiquer et tes remarques à son sujet sont toutes fausses.
Si tu veux vraiment te faire une idée, tu peux télécharger la community édition gratuite et qui permet de compiler pour Windows, Mac OS, IOS, Android (le compilateur Linux n'est pas fourni avec cette édition) : https://www.embarcadero.com/fr/products/delphi/starter
Ah mais le moteur physique c'est autre chose, moi je te parle de flux de contenu. Non c'est le terme "élément graphique" qui me choque. Tu commences à manipuler des éléments graphiques au lieu de faire du simple déclaratif.Citation:
Envoyé par gbegreg
Je te rappelle que l'exemple que tu voulais était :
Pas besoin d'une texture, une simple iframe suffit. Pour le côté html tu aurais un menu classique <nav><div>Lorem ipsum</div></nav>, une déclaration de style CSS (exemple .ball { border-radius: 50%; }) puis en JS addClass('ball'). On a d'un côté un DOM tout à fait classique, une liste de style bien rangés dans un fichier à part et le scripting totalement séparé.Citation:
Envoyé par gbegreg
Oui mais là encore tu rajoutes de la logique de scripting plutôt qu'encore une fois juste déclarer une balise et scripter uniquement de l'interactivité.Citation:
Envoyé par gbegreg
Là tu parles de bootstrap qui fournit une grille avec des tailles préconçues et effectivement généralement pourries. En CSS tu peux target n'importe quelle largeur d'écran en pixels, résolution en dpi ou même appliquer des styles spécifiques pour une impression papier.Citation:
Envoyé par gbegreg
Oui mais on s'en fout de ça, moi je parle de maintenance de l'application, le code qui est lu par des humains. On s'en fout du code qui est généré derrière puisque le but est de ne pas y toucher, tout comme on n'irait pas toucher à du binaire. De plus, le code humain en PHP par exemple (et très certainement sur Delphi aussi) est recalculé par l'interpréteur afin d'être optimisé avant exécution.Citation:
Envoyé par gbegreg
Oui... donc c'est bien pour faire des applications natives pour un usage spécifique, pas pour des applis multi-device / écrans, avant tout orientées affichage de contenu. Et encore, très franchement, si je devais développer de l'application purement native Delphi serait très probablement mon dernier choix vu l'absence total d'avenir de la technologie.Citation:
Envoyé par gbegreg
Donc Delphi est tellement bien que son créateur est parti créer certaines des technologies que tu décries ? :aie:Citation:
Envoyé par gbegreg
Je pourrais l'avoir au boulot mais franchement pourquoi faire ? Je préfère me former sur des technologies d'avenir et quand je vois le bordel que c'est pour maintenir de vieilles applications... Du HTML/CSS On en fait depuis plus de vingt ans, on en fera encore très probablement dans vingt ans. La technologie évolue mais il y a rarement des choses qui arrêtent de fonctionner, à part les hacks spécifiques pour pallier au non respects des normes des anciens navigateurs de Microsoft.Citation:
Envoyé par gbegreg
Citation:
Envoyé par dukoid
Ok merci
Alors je vais rentrer dans le moule
Another brick in the wall
Comme aucun des arguments contre le Delphi ne fonctionne, puisqu'ils sont juste de la méconnaissance, tu en viens à dire que c'est la techno tout entière qui n'est pas "d'avenir". :roll:Citation:
Envoyé par Sodium
Alors que Delphi est presque aussi vieux que le HTML, et à toujours très bien fonctionné, et continuera à le faire certainement tout aussi bien que ton HTML.
C'est fou cette manie de critiquer sans connaître et encore moins comprendre.
Encore une fois, la grande majorité du temps, on passe par l'éditeur d'interface graphique. Il génère le fichier .dfm (fichier texte). Le code métier se trouve dans le fichier .pas. Très souvent, on n'a pas à modifier manuellement le fichier .dfm.Citation:
Envoyé par Sodium
Sûre ? puisque tu souhaitais, mettre la vidéo sur une boule (donc un objet 3D), il y aura forcément utilisation d'une texture.Citation:
Envoyé par Sodium
En Delphi, le menu, la constitution de l'interface seront dans le .dfm, les styles (si on veut en appliquer autres que celui par défaut de l'OS) sont des fichiers autres que le graphiste fourni par exemple, le code métier est dans les fichiers .pas que l'on peut bien sur organiser à sa guise.Citation:
Envoyé par Sodium
C'était dans le cas où je crée les composants de manière dynamique. Je peux organiser mon code comme je le veux : faire un .pas où on ne fait que créer les composants, un autre où l'on gère par code les animations que l'on veut...Citation:
Envoyé par Sodium
Oui je parlais de bootstrap (relis bien ma phrase d'origine je le mentionnais). En CSS tu peux cibler n'importe quelle largeur d'écran. Avec Delphi aussi et en plus, comme c'est du vectoriel, c'est encore plus simple de gérer les différentes résolutions, définitions et tailles d'écran.Citation:
Envoyé par Sodium
C'est bien ce qui me semblait : alors le code que je t'ai montré est le code lu et modifié par les humains ! Il n'y a pas d'autre code généré car il n'y a pas d'interprétation, je le répète c'est du compilé en natif pour la plateforme ciblée à partir du code que je t'ai montré.Citation:
Envoyé par Sodium
Moi je ne trouve pas "qu'on s'en fout" comme tu dis. Je note juste que pour quelqu'un qui pense maitriser tout l'affichage et qui se méfie du code généré, tu passes par beaucoup plus de couches et de génération de code que ce que je fais avec Delphi.
Encore une fois, affirmation complètement fausse. Je te renvoie par exemple à la première vidéo que je t'ai partagée (https://youtu.be/IJzEuZTSXDI): une application mobile qui fonctionne sous Android et IOS (donc multi device), sur des écrans de smartphones ou de tablettes (donc multi écran) qui est justement très orientée affichage de contenu.Citation:
Envoyé par Sodium
Attaque gratuite et sans fondement (comme le reste) typique de la personne à court d'argument (et qui aussi n'a jamais testé le produit critiqué).Citation:
Envoyé par Sodium
Encore une affirmation fausse : il a été débauché (ainsi que d'autres personnes à l'origine de Delphi) par Microsoft car Microsoft a tout de suite vu le potentiel et a un chéquier bien plus garni que celui de Borland à l'époque. De nombreux concepts ont été repris pour C#.Citation:
Envoyé par Sodium
C'est d'ailleurs ce qui a lancé les rumeurs dans les années 2002-2005 de la mort de Delphi. Mais depuis le rachat par Embarcadero et la mise en place du framework multi plateforme Firemonkey (FMX), c'st bien repartie et la solution est fiable, efficace, productive.
De plus, je n'ai pas l'impression de décrier certaines technologies contrairement à toi. Je te montre que tout ce que tu dis à l'encontre de Delphi est complètement faux et émane d'une personne ne connaissant absolument pas le produit.
Pour tester justement et constater les bêtises que tu racontes à son sujet. De plus, c'est toujours bon de voir autre chose, de sortir de sa zone de confort : on apprend beaucoup ainsi.Citation:
Envoyé par Sodium
On en revient à ce que je te disais : tu verras ton appli web dans 5 ans. Avec toutes les dépendances que tu tires, et que les faire monter de version (si elles existent encore à ce moment), ton application sera certainement à réécrire avec ce qui sera à la mode dans 5 ans. D'ailleurs, Angular a déjà connu dans son passé une rupture de compatibilité ascendante... (comme d'autres : Swift, Python...)Citation:
Envoyé par Sodium
Dans ma boite, on termine une migration industrialisée de plusieurs centaines d'applications. On passe ces applis à React pour le front et spring boot pour le back (et plein d'autres lib tierces et variées). Résultat des courses, on met en prod des applis qui utilisent des versions anciennes des frameworks et libs (elles étaient pourtant à jour au moment où le projet a démarré mais les coûts que cela engendre de les faire monter de versions, repasser les tests... et il ne s'est pas écoulé 5 ans).
Il y a quelques années, j'avais développé une appli web. Le code est en Groovy et je ne sais plus quel était le framework graphique utilisé toujours est il que l'on a eu un problème car l'appli ne fonctionnait plus correctement lors du passage à Chrome en version 45 (de mémoire). En fait, Chrome avait modifié sa lib de parsing XML et c'est ce qui posait pb...Citation:
Envoyé par Sodium
