Discussion :

[DonQuiche]

Est-ce que les applications seront mieux ou plus efficaces que ce qu'on fait aujourd'hui ? non, probablement pas, mais qui s'en préoccupe ?

Le client ?
Parce que si la concurrence fait deux fois mieux en deux fois moins de temps et pour deux fois moins cher...

Compare un produit touchant 70% du marché à un autre touchant 100%. Le premier est performant, rapide et peu coûteux à développer tandis que l'autre est une horreur pour le développeur et ramouille sévèrement sur les mobiles. En tant que client comme en tant qu'investisseur, sur laquelle vas-tu miser ?

Enfin, ta prédiction s'appuie sur des outils qui ne seraient pas le vieux js+html mais d'autres, pas encore disponibles. Tu ne crois pas que, pendant ce temps, il se passe aussi des choses en C++, java et dotnet ? Sans parler du fait que ce que tu nous décris implique des langages lents tournant sur des interpréteurs eux-mêmes écrits dans des langages lents afin d'assurer l'interopérabilité ! A une heure où la puissance disponible a fait un bond de dix ou quinze ans en arrière avec les plateformes mobiles. Tu parles d'une tour de Babel !

[jeroy]

Ce genre de news fracassante, c'est juste l'expression de la loi de Wirth / Gates :

"The speed of software halves every 18 months."

On rajoute des couches (des VM, des interpréteurs) tous les ans, dans le but de toujours simplifier/accélérer le dévelopement. Au final on ne fait qu'occuper le temps de proc disponible. La nature ayant horreur du vide, on occupe la puissance dispo, au lieu de l'utiliser mieux. Et le développement n'est pas plus simple - mais il nécessite plus de monde, plus de spécialités différentes.

En 10 ans, la puissance des procs a évolué d'une manière énorme, mais Office tourne pas plus vite. On occupe cette puissance à faire tourner des couches additionnelles. Sans vraiment de raison derrière.

Après on y peut rien, le progrès dans le secteur des langages et plate-formes, ça consiste à rajouter des couches au lasagne. Parce que chaque couche permet de filer du boulot à des développeurs (y compris les plus médiocres dans le cas de cette news), parce que chaque couche permet de vendre des formations, de la documentation, des prestations en plus, des outils de développement. C'est naturel, c'est un business, il faut bien manger.

Espérons que ce phénomène est cyclique, et qu'après cette période qui s'annonce coûteuse en mise à jour hardware pour l'utilisateur final et le client, on voit le retour vers une plus grande simplicité et desp late-formes plus raisonnables. L'industrie du mobile redorera peut-être le blason d'un développement plus léger, l'arrivée des procs ARM aussi.

[regisportalez]

En 10 ans, la puissance des procs a évolué d'une manière énorme, mais Office tourne pas plus vite. On occupe cette puissance à faire tourner des couches additionnelles. Sans vraiment de raison derrière.

Rien ne t'oblige à ne pas faire de l'assembleur...

Personnellement je développe des applis Web en html5/WebGL et je trouve bien pratique de ne pas avoir à apprendre le flash, ni le java, ni les activeX...
D'autant que c'est plus rapide, plus léger, et standardisé par le W3C, ce qui m'assure qu'à part IE, tout le monde sera compatible.
C'est mieux qu'une appli java parce que ça tourne chez le client et du coup mon serveur peut rester petit même si j'ai beaucoup de visites...

Enfin bref je vois pas ce qu'on peut trouver à redire à ce genre d'évolution.

A part peut être que les gens ont leurs habitudes et devront ptet les changer.

[camus3]

Rien ne t'oblige à ne pas faire de l'assembleur...

Personnellement je développe des applis Web en html5/WebGL et je trouve bien pratique de ne pas avoir à apprendre le flash, ni le java, ni les activeX...
D'autant que c'est plus rapide, plus léger, et standardisé par le W3C, ce qui m'assure qu'à part IE, tout le monde sera compatible.
C'est mieux qu'une appli java parce que ça tourne chez le client et du coup mon serveur peut rester petit même si j'ai beaucoup de visites...

Enfin bref je vois pas ce qu'on peut trouver à redire à ce genre d'évolution.

A part peut être que les gens ont leurs habitudes et devront ptet les changer.

Et tes navigateurs , ils tournent sous quoi ? un os javascript ? et tes navigateurs ils sont codés en quoi ? javascript ?et le dom ? et les moteurs javascript , ils sont codés en quoi ? javascript ? pour que des personnes comme toi puissent se la jouer HTML5 , d'autres se sont cassé le cul à développer des moteurs qui tournent relativement vite dans des technos que tu dénigres. On appelle cela être ignorant.

[skywaukers]

ce qui m'assure qu'à part IE, tout le monde sera compatible.

donc c'est clair tu es sur que tes applis sont compatibles avec la majorité des utilisateurs, surtout en entreprise.

@++
Dany

[Paul TOTH]

Le client ?
Parce que si la concurrence fait deux fois mieux en deux fois moins de temps et pour deux fois moins cher...

Tu penses réellement que dotNet a apporté quelque chose au client ? tu penses que ça permet de faire 2 fois mieux ?

Compare un produit touchant 70% du marché à un autre touchant 100%. Le premier est performant, rapide et peu coûteux à développer tandis que l'autre est une horreur pour le développeur et ramouille sévèrement sur les mobiles. En tant que client comme en tant qu'investisseur, sur laquelle vas-tu miser ?

Celui de Microsoft ! La qualité d'un produit n'a jamais été le critère principal dans le choix. En tant que développeur Delphi je suis bien placé pour le savoir.

Enfin, ta prédiction s'appuie sur des outils qui ne seraient pas le vieux js+html mais d'autres, pas encore disponibles.

Oui, nous utilisons des solutions de moins en moins pratiques, mais je suis persuadé qu'on finira par retrouver des outils aussi efficaces pour JS/HTML que ce qu'on a depuis 10 ou 20 ans pour les autres langages.

Tu ne crois pas que, pendant ce temps, il se passe aussi des choses en C++, java et dotnet ?

Oui, et Embarcadero vient de sortir un nouveau Delphi, produit dont on dit pourtant qu'il est mort depuis 20 ans. Sauf que Microsoft a décidé que Windows 8 sera HTML et Javascript, pas C++ ou Java.

Sans parler du fait que ce que tu nous décris implique des langages lents tournant sur des interpréteurs eux-mêmes écrits dans des langages lents afin d'assurer l'interopérabilité ! A une heure où la puissance disponible a fait un bond de dix ou quinze ans en arrière avec les plateformes mobiles. Tu parles d'une tour de Babel !

Mais c'est exactement ce qu'il se passe, et ce n'est pas pour rien qu'on a vu une concurrence sévère dans la performance des interpréteurs JavaScript...ça a longtemps été considéré comme un truc optionnel pour le web, c'est devenu le centre d'une compétition pour la plateforme de demain.

En plus je suis persuadé que la puissance des mobiles va grimper en flèche, comme c'est le cas des PC, et que les softs de demains seront encore plus gourmands que ceux d'aujourd'hui.

[Paul TOTH]

Et tes navigateurs , ils tournent sous quoi ? un os javascript ? et tes navigateurs ils sont codés en quoi ? javascript ?et le dom ? et les moteurs javascript , ils sont codés en quoi ? javascript ? pour que des personnes comme toi puissent se la jouer HTML5 , d'autres se sont cassé le cul à développer des moteurs qui tournent relativement vite dans des technos que tu dénigres. On appelle cela être ignorant.

vous ne parlez pas de la même chose, (bien qu'il existe des projets d'OS en JavaScript). la réalisation d'un OS et de l'API machine relèvera toujours d'un développement natif, au moins pour les fonctions de plus bas niveau.

Quand on parle de remplacer les applications natives, il est questions d'application utilisateur, pas de système d'exploitation. Un navigateur reste cependant une application utilisateur, à partir du moment ou Javascript peut utiliser une API graphique et une API réseau, il devient possible de réaliser un navigateur dont les performances ne dépendront que de la qualité du JIT et de la machine hôte.

[Uther]

Je viens de lire le tweet cité en source et il n'est vraiment pas, mais pas du tout, en accord avec le ton de l'article.

"Next year HTML5 will replace native apps" is the new "Next year will be the year of Linux on the desktop"

"l'année de Linux sur le desktop", elle est annoncé tous les ans depuis au moins dix ans, et on l'attend encore. Non pas que Linux ne soit pas un solution viable, mais simplement qu'il n'a jamais pris.
Ca veux bien dire, tout le contraire de ce que sous-entend cet l'article trollogène : le monsieur, n'y crois pas.

Et je ne suis pas vraiment d'accord avec lui. Si Linux n'a pas pris, c'est qu'il faut, l'installer et apprendre a l'utiliser pour avoir éventuellement des applications manquantes. Même si c'est beaucoup plus simple aujourd'hui tout le monde n'y voit légitimement que des risque d'incompatibilité, de la complexité et aucun gain.
Alors qu'un navigateur Web, s'il y a bien une chose que tout le monde a déjà sur son ordinateur et sait utiliser, c'est ça. Pour moi, les application web sont justement l’extrême opposé de Linux sur Desktop : tout le monde peut l'utiliser directement sans aucune installation.

[camus3]

Quand on parle de remplacer les applications natives, il est questions d'application utilisateur, pas de système d'exploitation.

Je répondais uniquement à l’intéressé ci dessus.

[DonQuiche]

Tu penses réellement que dotNet a apporté quelque chose au client ? tu penses que ça permet de faire 2 fois mieux ?

Par rapport à une solution js/html ? Sans aucun doute, d'abord parce que nous travaillerons deux fois plus vite, ensuite parce que nous ne rencontrerons pas un plafond de performances qui nous obligera à faire des pieds et des mains pour le dépasser avec des résultats mitigés, enfin parce que notre produit, lui, ne videra pas la batterie de l'utilisateur en huit minutes.

Oui, nous utilisons des solutions de moins en moins pratiques, mais je suis persuadé qu'on finira par retrouver des outils aussi efficaces pour JS/HTML que ce qu'on a depuis 10 ou 20 ans pour les autres langages.

Pouquoi ne sont-ils pas déjà là alors que Js/html est ancienne ? Cette plateforme ne peut qu'évoluer lentement, au rythme des standardisations et de l'adoption hétérogène d'extras par les navigateurs et de l'adoption de ces nouveaux navigateurs par les utilisateurs. Dévélopper en html5 aujourd'hui, c'est encore développer pour un faible public.

Or, pendant que Js/html peine à s'adapter aux besoins actuels, les plateformes traditionnelles travaillent déjà sur les nouveaux besoins.

Sauf que Microsoft a décidé que Windows 8 sera HTML et Javascript, pas C++ ou Java.

Faux. Applis metro en dotnet ou js+html, applis natives en dotnet ou c++.

Mais c'est exactement ce qu'il se passe, et ce n'est pas pour rien qu'on a vu une concurrence sévère dans la performance des interpréteurs JavaScript...ça a longtemps été considéré comme un truc optionnel pour le web, c'est devenu le centre d'une compétition pour la plateforme de demain.

Et malgré tous ces efforts, ça reste lent. Et ça le restera car c'est une limite intrinsèque et infranchissable pour les langages souples.

En plus je suis persuadé que la puissance des mobiles va grimper en flèche, comme c'est le cas des PC, et que les softs de demains seront encore plus gourmands que ceux d'aujourd'hui.

La puissance des mobiles est soumise aux lois de la physiques et celles-ci ne sont pas commodes. Nous verrons les réponses qu'apporte l'innovation.

[Paul TOTH]

Par rapport à une solution js/html ? Sans aucun doute, d'abord parce que nous travaillerons deux fois plus vite, ensuite parce que nous ne rencontrerons pas un plafond de performances qui nous obligera à faire des pieds et des mains pour le dépasser avec des résultats mitigés, enfin parce que notre produit, lui, ne videra pas la batterie de l'utilisateur en huit minutes.

Non, je comparais .Net à l'avant .Net, l'époque ou on n'utilisait pas un Framework de plusieurs Mo et que le code était optimisé.

Pouquoi ne sont-ils pas déjà là alors que Js/html est ancienne ? Cette plateforme ne peut qu'évoluer lentement, au rythme des standardisations et de l'adoption hétérogène d'extras par les navigateurs et de l'adoption de ces nouveaux navigateurs par les utilisateurs. Dévélopper en html5 aujourd'hui, c'est encore développer pour un faible public.

Je l'ai déjà dit, parce que l’intérêt pour Javascript a évolué.

Or, pendant que Js/html peine à s'adapter aux besoins actuels, les plateformes traditionnelles travaillent déjà sur les nouveaux besoins.

Faux. Applis metro en dotnet ou js+html, applis natives en dotnet ou c++.


Et malgré tous ces efforts, ça reste lent. Et ça le restera car c'est une limite intrinsèque et infranchissable pour les langages souples.

je pourrais dire exactement le même chose de .Net

La puissance des mobiles est soumise aux lois de la physiques et celles-ci ne sont pas commodes. Nous verrons les réponses qu'apporte l'innovation.

Nos téléphones sont déjà des merveilles de technologie et ce n'est qu'un début.

Maintenant, soyons clair, je ne trouve pas que cette évolution soit un bien - je suis des plus rétrograde en matière de développement - je dis simplement que c'est le sens de l'histoire.

[DonQuiche]

@PaulToth
Par rapport au C++, oui, dotnet nous a fait gagner en productivité et permet d'écrire un code plus clair et plus maintenable selon moi, et plus stable. Y a t-il un coût en performances ? Bien sûr de l'ordre de 30%, ce qui est acceptable pour la plupart des applications.

La situation est-elle alors comparable avec js+html ? Non :
* Le coût en performances n'est pas de 30% avec js+html, il est beaucoup plus élevé, sans doute 500% à 1000%. Le moindre accès à une variable impose de consulter un dictionnaire.
* Cette perte de performances se faisait dans le cadre de machines dont la puissance doublait tous les 18 mois. Ici la puissance vient d'être divisée par 20.
* Dotnet permettait d'accroître la productivité. Js+html la diminue.

Enfin, le sens de l'histoire jusqu'à présent, c'était d'accroître la productivité au détriment des performances. Rien de tel avec js+html. Le seul intérêt de js+html c'est de prétendre à être un esperanto, ce qui est relativement faux (support restreint de html5 sur les postes windows existants et sans doute anciens iphones) et à relativiser par l'existence d'alternatives viables. Accessoirement, et c'est surtout là la raison de cet engouement, il offre d'autres débouchés à une pléthore d'équipes web js+html moins coûteuses.

[michelzam]

C'est mon humble avis, basé sur l'expérience vécue depuis 4-5 ans.

Si vous faites encore du client lourd pour des applis de gestion ou orientées données (avec grilles modifiables, maîtres-détail, formulaires, onglets, quelques charts) c'est que l'existant (legacy) vous pèse et ça se comprend.

Pour les nouveaux projets de ce type, le web riche a atteint depuis plus de 4 ans environ un niveau de maturité fournissant une ergonomie et des performances équivalentes. Lorsque je l'ai réalisé, j'ai abandonné définitivement tout développement client lourd et je me porte très bien. Le web mobile y est également arrivé, stockage local compris. A titre d'exemple, voir l'appli FinancialTimes sur ios5 et android à la fois. Elle n'y est plus sur les *Store et *Market, car full html !

Maintenant, si vous écrivez du HTML à la main (5 ou moins), vous n'êtes pas sortis de l'auberge en termes de productivité et de qualité.
Mais si vous utilisez déjà un framework web riche (style ExtJs, mon préféré, mais il y en a plein d'autres), vous faites peut-être déjà du HTML5 sans le savoir ... et les aspérités entre navigateurs vous ne les percevez même plus, car absorbées par cette couche d'abstraction de grande qualité (au sens génie logiciel).

Côté langage client, le JavaScript s'est imposé paradoxalement non pas seulement comme langage industriel, mais aussi académique : de nombreux outils et mécanismes sont développés pour apporter qualité, productivité, abstraction, sécurité, évolutivité, etc. J'ai bien aimé l'expression "binaire" lue plus haut. Les puristes (comme je l'ai été et je le reste) ont intérêt à se documenter pour ne rester que du bon côté de JavaScript (voir livre Douglas Crockford). Côté serveur, Sun avait intégré Rhino depuis Java 6, sorti en 2006 pour ne pas perdre le train (ou la vague) du scripting serveur.

Bref, pour ce type d'appli (CRUD à 80% selon Dave Thomas) les prétextes d'une non adoption du web riche tombent un à un. Et le HTML5 y est incorporé sans qu'on s'en aperçoive ... (ex extjs4). /* Je laisse un peu de côté Flex, qui est un cas à part et qui n'est pas le sujet */

N'oubliez pas que le standard n'est qu'une conséquence de mises en oeuvre réussies et ne précède jamais l'expérimentation. Seulement, il en facilite la généralisation par l'organisation de l'offre sur un marché concurrent, donc moins captif.

Restent les outils. Il y a les classiques (Eclipse, NetBeans, VS, ...) avec des plugins qui progressent tous les jours. Mais je citerais à titre d'exemple et de provoc' 2 outils qui tournent directement dans le navigateur (en HTML5 déjà, ou presque) :
- Cloud9IDE/ACE : une sorte d'Eclipse dans le cloud, absolument bluffant, dédié aux développeurs javascript, ruby, php, ... et prochainement java. Il y a syntaxe en couleurs, code completion, refactoring et debuggage https://c9.io/
- MyDraft : un autre ovni, un L5G, qui permet d'assembler directement dans le cloud et en quelques minutes - sans coder ou presque - des applis riches, avec refactoring lourd, génération de diagrammes, tests unitaires pour le peu de code serveur, historisation et time machine intégrés. Je le connais très bien, pour y avoir oeuvré depuis un moment

Mais au delà du cas forcément subjectif de mon expérience avec MyDraft, il faut juste voir ce qu'il est possible de faire en quelques minutes pour déployer une appli riche, accessible depuis tout terminal connecté, fixe ou mobile. Puis, allez comparer les coûts et l'agilité des alternatives natives, qui seraient forcément à décliner (donc investissement à multiplier) par plateforme cible.

Donc, à moins d'avoir des besoins très spécifiques, HTML5 passera partout, vraisemblablement de façon souterraine. Ce n'est qu'une question de temps, de maturité de l'outillage et de reconversion des développeurs ...

A bientôt dans le cloud

mz - @karmiczam

[seb012007]

Jamais tu verras un Photoshop réalisé en HTML.

http://pixlr.com
http://www.photoshop.com/tools/overview
etc.. (y en a des tonnes)

Jamais tu verras un jeu PS3 réalisé en HTML.

PS3 c'est sûr vu que c'est une console... Par contre pour les jeux en 3d :
http://code.google.com/p/quake2-gwt-port/

Jamais tu verras un Visual Studio réalisé en HTML.

http://www.wiode.com/

Evidemment ça n'est que quelques exemples, mais clairement l'avenir est là.

mais juste qu'il faudrait être con pour utiliser une technologie qui n'est pas faite pour.

C'est justement ça qu'on appelle... l'innovation.

Bref.

[BenoitM]

Non, je comparais .Net à l'avant .Net, l'époque ou on n'utilisait pas un Framework de plusieurs Mo et que le code était optimisé.

Je pense qu'il y a beaucoup plus de chance que le code soit optimisé dans un Framework de plusieurs Mo que quand un développeur essaye de réinventer la roue (et avec moins de bug en prime)

Maintenant c'est vrai que pour d'autres parties, on construit des usines à gaz mais qui facilitent le développement (le binding par exemple)
Quoique je suis pas sur que si tu voudrais faire la même chose que le binding tu ne construirais pas non plus une usine à gaz mais encore moins performante

[zeyr2mejetrem]

PS3 c'est sûr vu que c'est une console... Par contre pour les jeux en 3d :
http://code.google.com/p/quake2-gwt-port/

Désolé, mais GWT c'est du Java qui ensuite crache du Javascript/HTML pour la partie cliente et du Java Web/JEE pour la partie serveur.
HTML5 n'a rien à voir la dedans (ou si peu ...)

http://www.wiode.com/

L'ide en question est en PHP ...

Evidemment ça n'est que quelques exemples, mais clairement l'avenir est là.

... Dans les technos serveurs existantes saupoudrées de HTML5
Pas dans les applis full HTML5 (côté client) comme les marketeux voudraient le faire croire.

C'est justement ça qu'on appelle... l'innovation.

... mouais... c'est surtout ce qu'on appelle le buzz

[seb012007]

Désolé, mais GWT c'est du Java qui ensuite crache du Javascript/HTML pour la partie cliente et du Java Web/JEE pour la partie serveur.
HTML5 n'a rien à voir la dedans (ou si peu ...)

Oui non mais là alors si tu te met à croire qu'on va faire des applis complexe et des jeux en 3d avec juste un langage de balisage...

L'ide en question est en PHP ...

Ben oui c'est du client/serveur avec la partie client en html + js.

... Dans les technos serveurs existantes saupoudrées de HTML5
Pas dans les applis full HTML5 (côté client) comme les marketeux voudraient le faire croire.

On en revient au fait que html c'est du balisage. Pas de la logique de code.
[edit]Pardon j'avais mal lu. D'un autre côté de plus en plus la partie serveur ne sert plus qu'à stocker des données en base. De là a stocker les données dans le navigateur à la place il n'y a qu'un pas.

... mouais... c'est surtout ce qu'on appelle le buzz

Ben non justement : ce genre de technos prend de plus en plus d'ampleur depuis quelques années, on est loin du buzz. Regarde du côté de Google Document et consorts.

[Paul TOTH]

Je pense qu'il y a beaucoup plus de chance que le code soit optimisé dans un Framework de plusieurs Mo que quand un développeur essaye de réinventer la roue (et avec moins de bug en prime)

Maintenant c'est vrai que pour d'autres parties, on construit des usines à gaz mais qui facilitent le développement (le binding par exemple)
Quoique je suis pas sur que si tu voudrais faire la même chose que le binding tu ne construirais pas non plus une usine à gaz mais encore moins performante

ah ah j'aime beaucoup cet argument "le framework .Net est bien écrit et il s'occupe de tout donc mes programmes sont plus stables..." sauf que dotNet recèle son lot de pièges et de memory leaks de part sa conception même !

d'autre part, ce n'est pas parce qu'on ne fait pas du .Net qu'on code tout soit même. la notion de composant est bien antérieure à .Net, et avant cela on avait les library, faut arrêter de penser qu'avant .Net il n'y avait rien.

et dans le monde Javascript (pour revenir au sujet) on en trouve aussi des library qui masquent les différences de navigateur, qui déchargent le développeur des tâches répétitives et qui proposent d'éviter les usines à gaz...libre à toi de penser que ce sont eux même des usines à gaz, après tout c'est ce que je pense de .Net ^^

[zeyr2mejetrem]

Oui non mais là alors si tu te met à croire qu'on va faire des applis complexe et des jeux en 3d avec juste un langage de balisage...

Ce n'est pas moi qui le dit, c'est le propos du topic: "Les applications natives seront-elles remplacées par les applications HTML 5 ?"
HTML 5 est un langage de balisage. Ce n'est pas parce qu'on va lui rajouter une couche de Javascript qu'on va en faire une vrai appli

Ben oui c'est du client/serveur avec la partie client en html + js.

Oui. Donc rien de nouveau sous le soleil ...

De là a stocker les données dans le navigateur à la place il n'y a qu'un pas.

Euh, pour des petites applis, pourquoi pas.
Pour les applis professionnelles je suis carrément dubitatif.

Ben non justement : ce genre de technos prend de plus en plus d'ampleur depuis quelques années, on est loin du buzz. Regarde du côté de Google Document et consorts.

Attention. Quand je parle de buzz, je parle du fait qu'on essaie de faire croire que HTML5 fait le café alors que ce n'est qu'une norme (non encore stabilisée) qui n'apporte pas grand chose par rapport aux technos actuelles qui ont déjà pris la place le temps que le W3C se bouge ...

Je suis complètement d'accord que l'on peut faire de très bonnes applis avec la combo (XHTML/Js)<--Ajax-->Langage Serveur.

Cependant pour certaines applis professionnelles (progiciels) le web n'est, a mon humble avis pas approprié car on est dans une autre échelle qu'un logiciel de bureautique comme Google Docs et on a aucun intérêt ou presque à faire trainer des infos sur inter/intranet.

Je pense que de nombreux acteurs du forum confirmeront que par rapport à certaines applis "industrielles" (de gestion de process, de flux financiers, de gestion immobilière, etc ...) Google apps et autre c'est de la roupie de sansonnet (et je suis pourtant un gros utilisateur de Google Apps !!).

[BenoitM]

ah ah j'aime beaucoup cet argument "le framework .Net est bien écrit et il s'occupe de tout donc mes programmes sont plus stables..." sauf que dotNet recèle son lot de pièges et de memory leaks de part sa conception même !

d'autre part, ce n'est pas parce qu'on ne fait pas du .Net qu'on code tout soit même. la notion de composant est bien antérieure à .Net, et avant cela on avait les library, faut arrêter de penser qu'avant .Net il n'y avait rien.

C'est toi qui a déclaré qu'avant le Framework .Net on utilisait pas de Framework et que le code était optimisé pas moi

Perso j'ai plus confiance en la classe DateTime du FrameWork de .Net/Java ou autre qu'un mec qui s'amuse a programmer sa propre classe DateTime
Mais bon c'est un avis personnel

De plus dans ton article c'est un problème d'architecture et non un problème du framework en lui même...