Discussion :

[sevyc64]

Pour Google, je ne partage pas vraiment cet avis, Android est quand même plus ouvert que les autres plateformes

Il ne s'agit pas d'un problème d'ouverture du système.

Androïd, tout comme son homologue de chez Apple, est un système propriétaire sous le contrôle total et exclusif de son propriétaire, Google.
Sous couvert de soi-disant ouverture ou transparence, ce sont en réalité des systèmes totalement fermé et opaque, notamment pour les Stores. Tout passe par les serveurs que le propriétaire veut bien mettre en place et contrôle.

De plus Google est effectivement très réputé pour sa politique de respect de la vie privée. Il vient encore de nous le prouver avec son changement de règles en début de mois.
Qui est capable de dire aujourd'hui comment les Stores Androïd, Apple,etc et leurs autres produits fonctionneront dans 6 mois, 2 ans, 10 ans ? Qui est capable de dire que Google, Apple et autres ne prendront pas de façon unilatérale des décisions extrêmes comme nous l'annonce actuellement Microsoft concernant la plateforme .Net à mot couvert.


PS : On peut mettre aussi dans le panier RIM/Blackberry qui impose que tout ce qui rentre et sort de ses téléphones en matière de data, passe obligatoirement par ses propres serveurs. Pour en faire quoi ?

[Uther]

Androïd, tout comme son homologue de chez Apple, est un système propriétaire sous le contrôle total et exclusif de son propriétaire, Google.
Sous couvert de soi-disant ouverture ou transparence, ce sont en réalité des systèmes totalement fermé et opaque, notamment pour les Stores. Tout passe par les serveurs que le propriétaire veut bien mettre en place et contrôle.

Je suis d'accord sur le fait que les stores sont opaque (celui d'Android l'étant quand même moins que celui d'apple) tout comme les services en ligne.

Mais le système lui même est sans aucun doute libre et bien libre. Le nombre de distribution personnalisées en est la meilleure preuve.

[Traroth2]

Il ne s'agit pas d'un problème d'ouverture du système.

Androïd, tout comme son homologue de chez Apple, est un système propriétaire sous le contrôle total et exclusif de son propriétaire, Google.
Sous couvert de soi-disant ouverture ou transparence, ce sont en réalité des systèmes totalement fermé et opaque, notamment pour les Stores. Tout passe par les serveurs que le propriétaire veut bien mettre en place et contrôle.

De plus Google est effectivement très réputé pour sa politique de respect de la vie privée. Il vient encore de nous le prouver avec son changement de règles en début de mois.
Qui est capable de dire aujourd'hui comment les Stores Androïd, Apple,etc et leurs autres produits fonctionneront dans 6 mois, 2 ans, 10 ans ? Qui est capable de dire que Google, Apple et autres ne prendront pas de façon unilatérale des décisions extrêmes comme nous l'annonce actuellement Microsoft concernant la plateforme .Net à mot couvert.


PS : On peut mettre aussi dans le panier RIM/Blackberry qui impose que tout ce qui rentre et sort de ses téléphones en matière de data, passe obligatoirement par ses propres serveurs. Pour en faire quoi ?

La situation n'est pas du tout la même pour Android que pour iOS. Il n'est pas nécessaire de créer un compte Google pour utiliser un terminal Android. On peut se passer de Google Play. L'OS lui-même est open-source, et il existe des versions alternatives pour presque tous les terminaux.

[MiaowZedong]

Personnellement, je ne pense pas que .Net soit en danger bien au contraire, la stratégie est d’orienter les développements sur ce genre de technologies « managé » dans tout les sens du terme.
En revanche, on constate la volonté de vouloir toujours plus verrouiller l’os à des techs plus bas niveau (win32 n’est officiellement plus supporté) … jusqu'à quand des Framework comme QT seront supporté ? Que se passera t il quand on ne pourra plus développer ou distribuer une app sans passer par l’intermédiaire de Microsoft …

Je partage, aussi, cette inquietude.

J'ai l'impression que derrière le remplacement des ordinateurs multifonctions (PC) par des appareils plus spécialisés (tablettes, smartphones, consoles de jeu, ultrabooks) il y a aussi une volonté de verouiller les sytèmes, et de renforcer le contrôle du vendeur au détriment de l'utilisateur.

[BertonF]

Pour ma part ce n'est pas le bruit autour de HTML5/Javascript qui m’inquiète.
Mais c'est plutôt le 'non' bruit sur le retour de C++ avec Xaml le tout en mode compilation statique.
Les périphériques mobile sont lents, le code s’exécutant dans des vm est également lent (même si les PC moderne compense avec leur puissance).
En revanche le code C++ est performant, et largement + que tout le reste.
Donc si je dois construit une stratégie de développement d'application pour mobile et tablette :
je choisi C++/Xaml pour les applications.
Pour les petites 'tuile' je fait du HTML/Javascript connecté à un bon serveur de web service.
Et Dotnet, et ben dotnet je le garde pour les web services et les applications PC.
Bref, moi je refais du C++.

[ash.ice.loky]

En effet, on peut se poser la question du devenir de .NET, mais microsoft en tire pourtant de gros bénéfice (formation, tools, services, produits, ...).

C'est un domaine ou apple et google est absent, je ne pense donc pas qu'ils vont le détruire si vite.
Par contre qu'ils soient obliger de l'adapter aux nouveau besoin, oui!

En fait ce que l'on remarque c'est que microsoft a tenté un pari, proposer une unique solution a tous les problèmes. Code rapide, lourds, léger, web sevices, interface, script/compilé, UI : .NET

La vérité, personne ne veut donner toutes les cartes a microsoft, donc on se rabat sur les technos "libre", même si techniquement elles semblent désavantagées.

A ce petit jeu HTML/CSS/JS pour le web.
C++ pour les client lourds.
C pour l'embarqué.

mais il y aura toujours des société pour proposer quelques chose de différents (pour se faire de l'argent), ce n'est qu'une question de temps.

Par contre aujourd'hui, investir sur les plateformes sûres (C++, JS, HTML) c'est ce donner une sécurité, car ils seront toujours là dans 5 ans.

C'est un peu le combat DX vs OGL, l'un paraît mieux mais instable dans le temps lorsque l'autre semble en retard mais fonctionne toujours.

Par contre je rejoints totalement l'amalgame qui est fait entre W8 métro et .NET.
Tout n'a pas vocation à se retrouver dans une tuile :/, heureusement.

[DonQuiche]

@ash.ice.loky
La grille de lecture libre/proprio me semble totalement fausse.
* C/C++ connaissent un regain du fait des besoins en performances.
* Html/Js/Css étendent leurs usages d'une part du fait des besoins en performances et stabilité (abandon des plugins, une seule plateforme - oui, parler de perfs à propos de Js est bizarre mais c'est bien la raison invoquée contre Flash & co et c'est finalement le navigateur qui assure souvent les services autrefois fournis par Flash) et d'autre part et surtout parce que beaucoup de développeurs connaissent cette plateforme (pas de barrière d'entrée) et qu'un nombre non-négligeable ne connaissent finalement que ça.
* OGl vs Dx ? Mais pendant plusieurs années aucun jeu n'était développé en OGl justement parce que ce standard était à la ramasse, et je n'ai pas entendu dire que cela avait changé. C'est différent dans le domaine applicatif mais soit on parle de besoins peu exigeants, soit de solutions clé en mains avec matériel spécifique et proprio.

@BertonF
Je suis convaincu que les développeurs dotnet n'auront absolument pas besoin de migrer vers le C++ pour les applis PC et que l'API de WinRT a été conçue pour être utilisée en C# comme un objet dotnet natif et en JS comme un objet JS natif. A vérifier mais le contraire m'étonnerait beaucoup. Je présume que c'est plutôt le dév C++ qui risque de bouffer du COM à longueur de journée.
EDIT: Confirmé. Pov C# / Pov C++
Totale transparence en C#, extensions du langage en C++ avec génération auto de wrappers. La programmation WinRT en C++ ressemble fortement à du C++/CLI.

[Cheick.Amed]

Microsoft commencerait il à virer vers l'utilisation de HTML5/JavaScript/CSS ? personnellement je n'ai rien contre et j'apprecie au contraire et suis d'avis!

[zulad]

Je pense que MS veut virer de technologies pour de question de restrictions dues à une mauvaise conception de langages C# et VB beaucoup moins puissants qu'un Javascript ou un Dart structurellement mieux faits et qui permettent de faire plus de chose avec moins de framework. En somme, ils voudraient rebondir et reconsolider leurs bases. Leurs développement à toujours été incrémental chez microsoft... rarement du développement de scratch. Dommage, moi aussi j'aimais le .NET mais j'ai toujours senti ses limites : La nécessité d'un framework assez lourd.

Mais ça m'étonne pour silverlight et wpf... Ils n'arriveront pas à nous imposer du HTML5. Le Xaml est beaucoup mieux fait... :lil:

De plus, microsoft perd des clients dans l'applicatif de gestion.

[Bluedeep]

Je pense que MS veut virer de technologies pour de question de restrictions dues à une mauvaise conception de langages C# et VB beaucoup moins puissants qu'un Javascript ou un Dart structurellement mieux faits .

Tu peux ajouter un semblant de démonstration à ce délire hallucinatoire ?

[zulad]

Tu peux ajouter un semblant de démonstration à ce délire hallucinatoire ?

Oui , mais ma diatribe ne portera pas sur mes connaissances en .NET.
Voilà ... rHum, rhum... Vous savez tous que JScript de MS a échoué. Et bien pour ne pas faire double emploi, ils veulent un langage apte à faire du multimédia avec peu de code. Metro étant orienté front end, le C# et le VB ne sont pas à la hauteur à ce niveau là. J'entends que structurellement on aura beaucoup de peine à faire un "jQuery" like avec ces langages. Du moins, cela me ferait rigoler.

Le C# c'est du C like, je dirais à ce niveau qu'ils sont passé à coté de leur objectif : Le langage de .Net c'est pas C# mais VB... et c'est beaucoup trop verbeux à mon goût.

Seul un langage comme le JS permet de faire des appli réactives et des librairies lisibles à la volée de manière performante. Voilà

[tomlev]

Metro étant orienté front end, le C# et le VB ne sont pas à la hauteur à ce niveau là.

Si tu le dis
Je pense pas que tu aies fait beaucoup de C# ou de VB pour dire un truc comme ça...

J'entends que structurellement on aura beaucoup de peine à faire un "jQuery" like avec ces langages. Du moins, cela me ferait rigoler.

Je vois pas pourquoi on pourrait pas, mais de toutes façons ça ne servirait à rien : jQuery n'est utile si tu fais du HTML ; en XAML on n'a pas besoin d'un truc comme ça, il y a d'autres méthodes plus adaptées pour arriver au même résultat.

Le langage de .Net c'est pas C# mais VB...

Première nouvelle
Les 2 langages sont quasiment isofonctionnels, tout ce que tu peux faire avec l'un, tu peux aussi le faire avec l'autre. Et s'il n'y en avait qu'un, le langage de .NET serait plutôt C#, qui a été spécialement conçu pour ça (alors que VB.NET n'est qu'une adaptation de VB6 pour .NET)

Seul un langage comme le JS permet de faire des appli réactives et des librairies lisibles à la volée de manière performante. Voilà

Encore un avis super objectif et argumenté

[sevyc64]

Le C# c'est du C like, je dirais à ce niveau qu'ils sont passé à coté de leur objectif

Là tu te plante complètement.
C# ne rivalise pas avec C, ce n'est un C like. Il n'a pas grand chose à voir avec le C, si ce n'est la syntaxe de base du langage.

Il a été développé, sur une inspiration de Java qu'il cible (tout au moins au départ) comme principal concurrent. Le C# est un peu le Java de Microsoft (après que le projet J++ est fait un gros bide)

Le langage de .Net c'est pas C# mais VB... et c'est beaucoup trop verbeux à mon goût.

Non, pas du tout. Le .Net est un framework, d'autres, sous d'autres langages, appellent ça machine virtuelle. C'est, en gros, un ensemble d'api qui peuvent être utilisées par n'importe quel langage, pour peu qu'il y soit adapté.
VB et C# sont les 2 principaux et les fers de lance, mais il en existe d'autre. Un temps on pouvait faire du .Net avec Delphi, je sais pas si c'est toujours possible. Il me semble aussi que Windev sait interfacer .Net.

VB n'est pas .Net. L'idée de Microsoft en 2000 quand .Net a été conçu, était de faire disparaitre VB à terme. Le C# avait pour un des but d'amener les vbistes sur cette nouvelle programmation (puisque globalement ils étaient réfractaire au C++). Sauf que ce qui s'est passé, et que Microsoft n'avait pas prévu, c'est que les C#piens au départ ont été essentiellement des anciens de C et de C++.
Désormais, depuis 2008, VB et C# on un avenir commun sur .Net, enfin tant que .Net existera.

[Nathanael Marchand]

Le C# c'est du C like, je dirais à ce niveau qu'ils sont passé à coté de leur objectif : Le langage de .Net c'est pas C# mais VB... et c'est beaucoup trop verbeux à mon goût.

Oh ben oui, c'est bien pour ca que toutes les nouvelles fonctionnalités sortent sur VB.Net avant de sortir sur C#.

Seul un langage comme le JS permet de faire des appli réactives et des librairies lisibles à la volée de manière performante. Voilà

Oh pinaise, j'en ai encore une crampe à ma machoire

Pour être allé au DevCamp Windows8 chez Microsoft, je peux vous dire que le message est de ne surtout pas abandonner .Net (ni C# d'ailleurs)!
Ceux qui ont fait du HTML5 pour des applis Metro c'était soit:
-Pour s'essayer à l'HTML5 et voir ce que ca donne;
-Parceque c'est une migration d'application existance en HTML5;
-Parceque c'est pour un client et qu'après le client à des ressources en HTML5 dans ses équipes et pas en XAML.

Par ailleurs, si si, il est possible de faire du JS propre, découpé, modulable, avec des patterns comme le MVC, etc.
Perso, non je ne suis pas fan du html5 sauce metro: tous les controles sont des div, je trouve qu'on s'y perd completement à la lisibilité. En xaml, un textbox c'est un textbox, un bouton est un button. En HTML5 tout est div

D'ailleurs il est à souligner que les seuls languages ou il est possible de faire des libraires de controles sont le C# et le C++. Impossible en Javascript.

[sevyc64]

Je pense que MS veut virer de technologies pour de question de restrictions dues à une mauvaise conception de langages C# et VB beaucoup moins puissants qu'un Javascript ou un Dart structurellement mieux faits et qui permettent de faire plus de chose avec moins de framework. .... La nécessité d'un framework assez lourd.

Là, ça mérite que tu détaille tes arguments quand même, parce que parler de mauvaise conception pour .Net, on en le fait pas sans argumentation solide.

Mais ça m'étonne pour silverlight et wpf... Ils n'arriveront pas à nous imposer du HTML5. Le Xaml est beaucoup mieux fait... :lil:

Au contraire, ça semble plus logique, Silverlight et WPF n'ont jamais pris à la hauteur de ce qu'attendait Microsoft. Technologies prometteuses mais qui n'ont pas séduit.

De plus, microsoft perd des clients dans l'applicatif de gestion.

Perso, j'aurais dit le contraire.
Aux vues des articles de presse, offres d'emploi, etc, SQLServer semble gagner tous les jours plus de parts de marché, la gamme Dynamics semble ne pas trop mal se porter (je n'entend d'ailleurs plus parler du possible abandon de la CRM, au contraire, il y aurait une forte orientation cloud dans les prochaines versions), Sharepoint est en train de s'imposer comme un acteur majeur, Office se porte toujours bien, ....

Certes, ça fait quelques années que l'on a perdu Money déjà, à mon grand regret

[zulad]

Là, ça mérite que tu détaille tes arguments quand même, parce que parler de mauvaise conception pour .Net, on en le fait pas sans argumentation solide.

C'est simple pourtant. A la base les langages microsoft, à moins qu'ils aient des langages propriétaires tenus secrets, ... ne sont pas extensible via le code source. Des librairies sont à développer pour l'étendre : cf la machinerie .Net.

Je prends pour exemple un langage objet plus ancien le Lisp qui lui permet de le faire.

Je passe de là à JQuery pour exemple qui constitue une avancée significative en terme de développement. La couche est logicielle, on ne parle pas de librairies ou d'add on. Tout est portable et natif ici.

J'entends par là que C# ET VB.NET sont malheureusement voués à disparaître.

La spécificétés du .Net c'est l'informatique de Gestion
Le C++ : L'ingéniérie
Le JS, et dart, ... des langages mieux "conçu" pour le Multimédia, et comme le multimédia est l'huile dans le développement, c'est normal qu'il relègue le C# et VB.net à la postérité.

Attention que je ne parle pas des librairies .Net qui elles migreront vers un plus noble langage.

[MiaowZedong]

C'est simple pourtant. A la base les langages microsoft, à moins qu'ils aient des langages propriétaires tenus secrets, ... ne sont pas extensible via le code source. Des librairies sont à développer pour l'étendre : cf la machinerie .Net.

Je prends pour exemple un langage objet plus ancien le Lisp qui lui permet de le faire.

Vraiment, tu plaisantes j'éspère?

Pour ta gouverne, le LISP est un language fonctionnel à la base. Pour programmer objet en LISP il faut utiliser une extension du language, la plus établie est je pense le CLOS (Common LISP Object System); mais le CLOS ou d'autres extensions objet ne sont pas disponibles dans de nombreux dialectes de LISP, comme Scheme ou Clojure.

De plus tu ne sembles pas bien saisir ce qu'est une librairie ou un framework, car ce sont justement des extensions du language, comparables au CLOS de LISP. Étendre monj interpréteur LISP ou rajouter des librairies pour mon environnement .Net, c'est du pareil au même. D'ailleurs, il est possible d'écrire du code LISP .Net (avec e.g. Clojure).

.Net c'est avant tout un framework d'API accessible à partir du CLR. En ce sens, je dirais que le .Net est plus important que le language utilisé, car c'est le .Net qui t'apporte tes fonctionnalités prêtes à l'emploi qui peuvent être appellées avec n'importe quel language, du moment que as un compilateur qui puisse en faire du CIL. Cependant, le C# qui est un Java-like (mieux structuré, dixit les devs C#) demeure le language de référence pour programmer pour le .Net.

Je passe de là à JQuery pour exemple qui constitue une avancée significative en terme de développement. La couche est logicielle, on ne parle pas de librairies ou d'add on. Tout est portable et natif ici.

Le JQuery est une librairie
Comme tout code JavaScript, jQuery est interpreté

Et niveau portabilité le JavaScript n'est pas une référence, à cause de la multiplicité des moteurs JavaScript (contrairement à Java ou .Net où tu connais la machine virtuelle qui va executer ton code).

[DonQuiche]

@Zulad
Je reprends d'abord quelques assertions en vrac:

• Le C# ne pourrait pas être étendu faute d'accès au code source. JS non plus puisque tu dois te conformer au standard. Certes les code source de certains navigateurs est dispo, tout comme celui de Mono pour dotnet.
• VB serait le langage de prédilection. Pas du tout, c'est C# : le plus utilisé et celui que MS bichonne le plus.
• C# serait trop proche du C et trop bas-niveau. Voici qui révèle une totale méconnaissance de ce langage. C# possède notamment à peu près tout ce qui existe dans JS et davantage (typage statique par défaut et support intégré des types dynamiques, closures, lambdas, événements en standard p/invoke, énumérables, méthodes d'extension, etc). C'est un des langages les plus riches qui soit en fonctionnalités de haut niveau.
• Par "faire du multimédia" tu désignes improprement la création d'interfaces riches.
• Il faudrait rajouter des tonnes de framework en dotnet. C'est une blague ? Aucun dév JS ne travaille plus sans JQuery (un framework) et beaucoup utilisent en plus des ExtJS & co (d'autres frameworks) puisque html n'offre pas de briques UI de base dignes de ce nom.

Maintenant, il serait impossible de faire du JQuery en C# ? Exemples de code, certains possibles en JS, d'autres non, certains dispos en standard, d'autres réclamant 5 lignes de code en amont. A l'exception du premier exemple qui n'est valable que sur des noeuds XML, le reste s'applique à n'importe quel ensemble d'objets : ils n'ont pas à définir de méthodes "First", "Where", "Recursive", "OrderBy", etc (c'est ce qu'on appelle des méthodes d'extension). En revanche une DB pourrait aussi "surcharger" ces méthodes pour offrir un code optimisé. Pour la comparaison, seul le premier exemple serait aussi aisé à écrire en JS mais ce dernier n'a pas de syntaxe assez souple pour les suivants ni de support pour les méthodes d'extension (il faudrait une indirection de plus, comme le $() de JQuery). Je précise enfin que tout ce qui suit utilise exclusivement le typage statique, preuve qu'il n'est pas aussi limitatif que tu sembles le penser et avec tous les avantages que cela implique (vérifications par le compilateur, performances, intellisense, découvrabilité des API - bref, productivité).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
// Sélectionner le premier élément <a> ayant la classe "truc" dans un doc html.
var result = root.SelectNodes("//a[@class='truc'"]).First();
// Prendre les 5 premiers éléments sélectionnés dans la hiérarchie UI descendante et les trier par leurs noms. Puis changer leur couleur de fond.
var result = node.DescendantsAndSelf().Where(x => x.IsSelected).Take(5).OrderBy(x => x.Name);
foreach(var selected in result) selected.Background = Brushes.Red;
// Sélectionner le premier enfant de type ForLoop dans le DOM d'un langage.
var result = node.Descendants().FirstAs<ForLoop>();
// Afficher le chemin "a>b>c>d" dans une hiérarchie ascendante sur un système de fichiers.
var result = node.Recursive(x= > x.Folder).Reverse().Implode(x => x.Name, ">");
// Obtenir le premier élément correspondant dans une liste, ou null sinon
var result = list.FirstOrDefault(x => x.IsSelected);

Les seuls cas où un langage dynamique comme JS est plus adapté pour l'UI sont :

• Le prototypage ou les logiciels de petite taille.
• L'inclusion de morceaux de codes très courts (typiquement une seule ligne) au sein d'un langage déclaratif pour l'UI, par exemple pour définir des bindings avec conversions de données. En html malheureusement tu ne peux inclure que des déclarations de handlers en JS. Regarde plutôt ce qui se fait du côté de Qt Quick où JS y est utilisé intelligemment mais uniquement pour une petite part de l'appli, le reste relevant du C++.

Dynamique != plus puissant != plus adapté à l'UI.

[ptah35]

@zulad,

corrigez-moi si je me trompe, mais il me semble que derrière votre discours à propos des défauts des "languages microsoft" et de la supériorité de l'ECMAScript ou de dart se cache en fait simplement l'expression de votre préférence pour les langages à typage dynamique.

Or rien dans la machine virtuelle de .NET n'empêche l'utilisation d'un langage dynamique, et il n'a pas été nécessaire de modifier ou d'étendre le MSIL pour compiler ces langage pour elle. L'ajout de la DLR a seulement permis de simplifier l'implémentation de ces compilateurs.

Cela n'a d'ailleurs rien d'étonnant, le premier compilateur LISP a été implémenté pour un IBM 704 -- un ordinateur électronique à tube et à mémoire torique -- dont le jeux d'instruction n'avait sans doute pas grand-chose à voir avec celui des x86, pourtant on retrouve LISP sur nos machines à base d'Intel. MSIL ou Bytecode sont les jeux d'instructions de machines virtuelles, mais ces machines virtuelles ne sont pas plus différente d'un microprocesseur x86 que ce dernier l'est du processeur de l'IBM 704. On retrouve d'ailleurs des compilateur LISP pour ces deux jeux d'instructions.

Ensuite, si par "machinerie de .NET" vous entendez la bibliothèque de classes, elle est essentiellement écrite en C#; en ce sens .NET permet donc d'étendre .NET.

De façon très subjective, j'ai une préférence pour les langage fortement typé mais j'apprécie la souplesse et la puissance de langage dynamique (comme beaucoup, j'ai appris la programmation avec Scheme), de là à dire que les uns sont plus "nobles" que les autres, c'est une chose que je ne ferais pas. En outre, c'est une chance C#permet d'avoir en quelque sort le meilleur des deux mondes.

[DonQuiche]

Je pense que MS veut virer de technologies pour de question de restrictions dues à une mauvaise conception de langages C# et VB beaucoup moins puissants qu'un Javascript ou un Dart structurellement mieux faits

Merci pour ce poisson d'avril qui m'aura bien fait rire.
Cela étant dit, rappelons que dotnet n'est absolument pas abandonné et que JS ne vise en aucun cas à le remplacer (seul un suicidaire irait utiliser JS pour une appli de bureau complète) mais simplement à attirer les développeurs web vers les plateformes windows.

Ils n'arriveront pas à nous imposer du HTML5. Le Xaml est beaucoup mieux fait... :lil:

J'aurais plutôt dit "un peu moins mal fait". C'est quand même le gros point faible des solutions WPF/SL/WinRT, partir sur du XML était une fichtrement mauvaise idée. Syntaxes à la noix (espaces de noms en XAML vs C#), verbosité, etc... Quand on compare avec Qt Quick par exemple...

Au contraire, ça semble plus logique, Silverlight et WPF n'ont jamais pris à la hauteur de ce qu'attendait Microsoft. Technologies prometteuses mais qui n'ont pas séduit.

Pour WPF je pense que c'est une question de temps: les applis WPF sont insupportables sur XP mais très satisfaisantes sur de bonnes machines sous Seven. Quant aux vices de conception, ils ont été à peu près palliés par les System.Windows.Interactivity et une évolution des pratiques (abandon des convertisseurs, etc). Je vois mal des solutions purement JS ou JS/C++ (avec grosse plomberie sous le plancher) s'imposer. Ce qui se fait aujourd'hui en WPF se fera demain en WinRT + dotnet, voilà tout.