Je ne sais pas vous, mais j'ai l'impression de revivre le même scénario qu'il y a 20 ans
Il est fréquent que des techniques parfois délaissées un temps réapparaissent sous une autre forme plus tard, et ça n'a rien de problématique dans l'absolu ; c'est juste que tu te focalises sur les ressemblances (parce que c'est attirant, que tu as envie de prédire le futur de manière simple) en oubliant les différences. Par exemple avec Rust et Go, on reprend goût à faire applications web avec des langages compilés en natif et ce n'est pas pour ça qu'on va retomber dans les travers des CGI en C.
En l’occurrence Java était fait par une seule entreprise dans son coin, alors que là on à affaire à un standard conçu par les acteurs du Web ; alors évidemment les erreurs de design sont possibles, mais les gens qu'il y à derrière sont sûrement les plus qualifiés pour faire le taff. Et puis il y a des erreurs de design même dans unix/posix (même si elles ont mis longtemps à être découvertes), mais bon la seule façon de ne pas faire d'erreur c'est de ne rien faire.
Les développeurs d'application (pas tous) s'en fichent un peu du web, de faire du contenu
Les développeurs qui ne veulent pas faire de web peuvent continuer à ne pas faire de web, je ne vois pas où est le problème. Si l'idée c'est d'arrêter d'améliorer les technologies web pour que les autres technologies restent dans la course, ça me parait être une mauvaise façon de raisonner.
Pourquoi en arrive t-on là ? A mon sens en grande partie à cause des logiciels privateurs
Je ne pense pas, vu comment les langages de script (Sh, Python, Ruby...) sont populaires, même en se focalisant dans les logiciels libres n'ayant pour vocation que de tourner sur les unix libres.
La diversité me semble faire toujours du bien sur le long terme
Il va y avoir plusieurs implémentation de la VM WebAssembly (tout comme on a plusieurs VM JavaScript), et sûrement des tas de langages qui vont générer du WebAssembly (tout comme des tas de langages génèrent déjà du JS; sauf que ça devrait être bien mois crade). Donc de la diversité il va y en avoir ne t'inquiète pas ! :)
[^] # Re: WebAssembly
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Firefox 45 ESR et autres actualités mozilliennes. Évalué à 10.
Il est fréquent que des techniques parfois délaissées un temps réapparaissent sous une autre forme plus tard, et ça n'a rien de problématique dans l'absolu ; c'est juste que tu te focalises sur les ressemblances (parce que c'est attirant, que tu as envie de prédire le futur de manière simple) en oubliant les différences. Par exemple avec Rust et Go, on reprend goût à faire applications web avec des langages compilés en natif et ce n'est pas pour ça qu'on va retomber dans les travers des CGI en C.
En l’occurrence Java était fait par une seule entreprise dans son coin, alors que là on à affaire à un standard conçu par les acteurs du Web ; alors évidemment les erreurs de design sont possibles, mais les gens qu'il y à derrière sont sûrement les plus qualifiés pour faire le taff. Et puis il y a des erreurs de design même dans unix/posix (même si elles ont mis longtemps à être découvertes), mais bon la seule façon de ne pas faire d'erreur c'est de ne rien faire.
Les développeurs qui ne veulent pas faire de web peuvent continuer à ne pas faire de web, je ne vois pas où est le problème. Si l'idée c'est d'arrêter d'améliorer les technologies web pour que les autres technologies restent dans la course, ça me parait être une mauvaise façon de raisonner.
Je ne pense pas, vu comment les langages de script (Sh, Python, Ruby...) sont populaires, même en se focalisant dans les logiciels libres n'ayant pour vocation que de tourner sur les unix libres.
Il va y avoir plusieurs implémentation de la VM WebAssembly (tout comme on a plusieurs VM JavaScript), et sûrement des tas de langages qui vont générer du WebAssembly (tout comme des tas de langages génèrent déjà du JS; sauf que ça devrait être bien mois crade). Donc de la diversité il va y en avoir ne t'inquiète pas ! :)