Sommaire
- 1. Objectif
- 2. Quelques commentaires suite à l'annonce de la normalisation
- 3. En attendant que Dart VM arrive dans les navigateurs web (si jamais cela arrive)
- 4. Performances par rapport à JavaScript
- 5. Dart VM par défaut dans Chrome et Android ?
- 6. Idées reçus et trolls baveux
- PS
Le langage Dart de Google va être normalisé par l'ECMA au sein du commité TC52. L'annonce a eu lieu le 12 décembre 2013.
Dart a été présenté la première fois en octobre 2011. La version 1.0 est sortie le 13 novembre 2013.
Dart est multiplateforme et disponible sous licence BSD et sa syntaxe est très proche de celle de Java et C#.
1. Objectif
Le but de Dart à long terme est de remplacer JavaScript, jugé impropre à la création d'applications web complexes :
"Javascript has fundamental flaws that cannot be fixed merely by evolving the language"
"The “clean break” option is extremely high risk--it will be a huge challenge to convince other browser vendors to rally around a new language--but is the only way to escape the historic problems with Javascript. Thus, its high risk is matched by the potential for a very high reward--a classic leapfrog strategy."
"When the leapfrog attempt succeeds (that is, it is an open standard and browsers covering a majority of market share implement it), web programmers will have a viable and superior alternative to JavaScript."
"Developers focusing on all browsers will have to wait multiple years for direct Harmony support, due to the relatively slow pace of the standardization process."
Le (l'un ?) métier de Google est de créer des applications web complexes, ils ne peuvent plus se contenter des limitations de JavaScript.
2. Quelques commentaires suite à l'annonce de la normalisation
Hacker News (https://news.ycombinator.com/item?id=6897701 et https://news.ycombinator.com/item?id=6902520)
"I like Dart after trying it. The tools are great and the libraries are starting to come into their own."
"I've used it for a few projects now and have been really impressed with how quickly it's matured and how much fun it is to develop in."
"Google has gone about the introduction of Dart in a scrupulously open way. They publicized the language early on it's design and implementation, they open sourced their implementation immediately on announcement and continued development in the open with input and contributions from all comers. […] Now they've begun a standardization process.
[…] Mozilla couldn't ask for a more open […] Regardless of Google's overall impact on the world, the Dart project is very much in line with Mozilla's mission. […] I expect Mozilla will oppose Dart, but they'll have to twist themselves into rhetorical contortions in the process. NIH is alive and well."
Ars Technica
"Microsoft, Google, and
Apple[ndlr : Jeremy Ashkenas] each independently realized that designing large projects in Javascript is a nightmare, so they designed something to replace it. That's why we have Typescript, Dart, and Coffeescript."
Slashdot
"Google is gaining way too much power over […] the internet."
"I want to say I like Dart. I have translated some of my javascript stuff over to see how it compares. In many ways it is a big improvement. However, it still does things I hate about javascript."
"As a web developer, I'm quite excited for Google Dart and am interested in seeing where it leads; I'm not sure what's with all the bashing about it, except out of pure ignorance. Javascript is a very useful and neat, but rather strange language, riddled with tricks, "gotchas", and downright strange behavior."
3. En attendant que Dart VM arrive dans les navigateurs web (si jamais cela arrive)
Actuellement beaucoup de développeurs utilisent des pré-processeurs pour compenser les défauts de JavaScript, notamment CoffeeScript et TypeScript de Microsoft.
Il y a deux problèmes avec ces (pseudo ?) langages :
- Ils ne sont pas standardisés
- Ils demandent une étape supplémentaire lors du développement en "compilant" le code vers JavaScript
- Ils héritent de certains défauts de JavaScript
Comparativement, les avantages de Dart sont :
- Le langage est en cours de normalisation (pérennité supérieur)
- Une version de Chromium embarque la VM Dart et permet donc d'éviter l'étape de compilation vers JavaScript ce qui réduit les temps de développement
Un outil (dart2js) est fournit pour compiler vers JavaScript en production tout comme CoffeeScript et TypeScript.
4. Performances par rapport à JavaScript
Les benchmarks de Google montrent que Dart VM est grosso-modo 2x plus rapide et que dart2js est légèrement au dessus que le code JavaScript équivalent écrit à la main : https://www.dartlang.org/performance/
D'autres benchmarks montrent que ce n'est pas encore toujours le cas : http://benchmarksgame.alioth.debian.org/
A noter que le développeur principal de Dart est Lars Bak qui a écrit la VM JavaScript (V8) de Chrome qui est très performante.
D'après lui et son équipe, les gains attendus dans le futur sont bien supérieurs alors que les VMs JavaScript ont commencées à atteindre leurs maximums.
Dans certains cas, Dart VM va plus vite que la JVM : http://www.infoq.com/news/2013/05/Dart-Java-DeltaBlue
De manière générale, les auteurs de Dart ont fait de la performance l'un des objectifs premiers : http://www.youtube.com/watch?v=huawCRlo9H4
5. Dart VM par défaut dans Chrome et Android ?
Actuellement une version experimentale de Chromium embarque la VM Dart
Dixit le très bon article de CNET, la VM Dart devrait arriver dans Chrome d'ici 1 an.
Pour Android, aucune annonce n'a été faite mais il est déjà possible de compiler et lancer Dart VM sous cet OS.
6. Idées reçus et trolls baveux
Ca va être le nouveau ActiveX/Flash/Silverlight/…
- Techniquement c'est difficilement comparable
- Les objectifs sont différents
- Contrairement à ActiveX/Flash/Silverlight/… les spécifications de Dart sont ouvertes depuis le début. L'implémentation est libre (licence BSD), le langage est en cours de normalisation et tout le monde peut participer. Comme indiqué dans un commentaire sur HackerNews: "Google has gone about the introduction of Dart in a scrupulously open way"
Dart est contrôlé par Google contrairement à JavaScript
Pour le moment oui : Dart est contrôlé par Google (initiateur du projet) ; tout comme JavaScript était contrôlé par Netscape dans les années 90.
C'est la raison pour laquelle Google a lancé le processus de normalisation Ecma : pour inviter tout le monde à participer.
Il y a déjà des contributeurs externes mais la proportion est certainement très faible actuellement.
Dart va segmenter le web
Pour le moment non puisque les développeurs utilisent dart2js (même principe que CoffeeScript et TypeScript).
Le risque est effectivement que Chrome embarque la VM Dart ET que Chrome (et non pas WebKit/Blink) possède 95% de part de marché (tout comme IE 6 à son époque). Alors certains développeurs seraient tentés de ne pas utiliser dart2js.
Dart VM ne sera jamais intégrée à Firefox ni à Internet Explorer
Peut-être. C'est ce qu'a annoncé par exemple Brendan Eich, le CTO de Mozilla et créateur de JavaScript, en août 2011 : "I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM". En attendant il y a dart2js.
asm.js c'est mieux !
Rien à voir, asm.js est un sous-ensemble de JavaScript, une sorte de bytecode ou langage assembleur. Cela permet de convertir du C/C++ vers du JavaScript.
Google a trop de pouvoir sur le web
C'est vrai :/
PS
Je n'utilise pas Dart (mais compte le faire plutôt que d'utiliser CoffeeScript ou TypeScript), je ne suis pas employé par Google et je n'ai jamais possédé d'actions de cette entreprise.
Il y a beaucoup de dénigrements autour de Dart qui a mon avis ne sont pas justifiés.
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 5.
Peut être que wtfjs, t'aidera à voir ce que certains n'apprécient pas dans le langage ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10. Dernière modification le 23 décembre 2013 à 22:01.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Sébastien Douche . Évalué à -2.
Les développeurs de Dart
Leurs nombres et leurs importances ne sont pas les mêmes. Un point révélateur est le fait qu'on a inventé 2 surcouches pour améliorer le langage (jquery puis CoffeeScript).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 23 décembre 2013 à 22:46.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 7.
Non, c'est un langage a part entiere qui compile vers JavaScript.
A la difference de TypeScript [1], du code JavaScript n'est pas du code conforme CoffeeScript.
Il y a bien sur la possibilite d'embarquer du code JavaScript dans du CoffeeScript : le code sera simplement ignore par le compilateur CoffeeScript et rendu tel quel.
[1] ce qui AMHA en fait une bien meilleur approche, d'autant plus que beaucoup de fonctionnalites de TypeScript sont identiques a celle du futur EcmaScript 6.
Ou que l'on a actuellement pas le choix tout simplement !
C'est le point de vue de Eich et de Microsoft via TypeScript.
C'est une position qui se defend, qui vivra verra.
Je n'ai egalement pas trouve de reponse claire a cette question pourtant fondamentale.
En vrac : le support dans les IDE, le scope des variables, this, l'API DOM, NaN, null, ===, Number…
Certains de ces problemes peuvent etre resolus partiellement ou totalement en faisant evoluer JavaScript.
Mais le point le plus important semble les performances.
D'apres Lars Bak, le createur de V8, la complexite et les performances de la VM JS ont atteint un sommet alors que Dart VM permet d'aller beaucoup plus loin.
C'est tres important notamment a cause des smartphones qui n'ont pas les memes resources qu'un PC - et meme si c'etait le cas, il y a le probleme de la batterie.
Il a fallu 5 ans (premiere version de Chrome : 2008) pour obtenir les performances actuelles de V8 et seulement 2 ans pour que la VM Dart soit 2x plus performante que V8.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 6.
Dans cette interview Lars Bak donne 2 raisons : la maintenabilite et la recherche de la performance.
Il repond aussi a la question pourquoi pas une VM a multi-langage ? (avec bytecode donc comme la JVM ou la VM .NET)
Et la suite de l'interview ici : http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-lars-bak-and-kasper-lund-bonus-content/
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Ouais enfin en pratique, Dart est 5x plus lent que les .NET/JVM tout en bouffant globalement plus de mémoire.
http://benchmarksgame.alioth.debian.org/u64q/dart.php
Vu que le langage n'a à peut prêt rien d'original ou d'excitant comparé aux dernières moutures de C# ou Java, on cherche encore l'intérêt de Dart, si ce n'est pour Google une façon de s'accaparer le futur du Web à coup de technos spécifiques, implémentées bien entendu en priorité dans Chrome.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Faut arrêter avec ça : C# est spécifié, normalisé, dans le même organisme que Dart, c'est pas pour autant qu'il remplace JavaScript. On parle ici de techno Web, pour moi c'est pas l'ECMA qu'il faut prendre en compte, c'est le W3C.
Je répète ma question : que va apporter Dart par rapport à d'autres langages ? Au pif C# ?
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par claudex . Évalué à 4.
Je pense que c'est justement plus cohérent de standardisé ça l'ECMA où est standardisé le JavaScript, plutôt qu'au W3C qui n'a jamais standardisé de langage de programmation.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Cela aurait été justement plus cohérent que le W3C reprenne la main sur une techno si critique pour le web.
Même le HTML5, qui a été initié en dehors du W3C avant d'y retourner, réunissait dans son groupe de travail des acteurs du Web multiples et pas uniquement un acteur unique comme le fait Google avec Dart.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 3. Dernière modification le 28 décembre 2013 à 03:08.
Tu te trompes lourdement.
Ca fonctionne toujours ainsi : une personne ou une entreprise a un besoin, elle le code dans son coin. Une fois que le resultat est jugé acceptable, l'entreprise ou l'individu rend publique cette techno puis ensuite vient l'etape de la normalisation/travail avec des acteurs externes pour ameliorer la techno.
Tim Berners-Lee a invente HTML debut des annees 90. Le W3C n'a ete cree qu'en 1994.
Plus précisément HTML vient de SGML qui a la base provient de chez… IBM… avant d'etre normalise par l'ISO.
Pareil pour JavaScript : c'est Netscape qui a cree dans son coin le langage en 95, puis soumission a l'Ecma en 96.
Ruby (norme ISO en 2012) : Matz (95) ; Python : van Rossum (91) ; Perl : Larry Wall (87)
Pareil pour C# (2001 - Ecma en 2002) ect…
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 8. Dernière modification le 26 décembre 2013 à 17:56.
Precision : jusqu'a C# 2.0 il y a 7 ans - une eternite (2006). Depuis il y a eu C# 3, 4 et 5 qui eux n'ont pas ete norme.
De plus l'implementation C#/.NET de Microsoft n'est pas multi-plateforme, n'est pas libre tout comme ses librairies.
Ce n'est que recemment que ca a change pour quelques librairies C#. Le framework web ASP.NET MVC a ete mis sous license Apache par Microsoft.
Pas vraiment le choix pour Microsoft quand on voit que tous les frameworks web modernes sont des projets libres : Rails, Django, Scala, PHP, Symfony, Drupal, Spring, Play!, J2EE, GWT…
Et tous les outils autour restent proprietaires : IIS, SQL Server, Visual Studio…
La communaute elle aussi reste neanmoins tres loin de l'ouverture d'autres communautes.
(PS : j'ai fait beaucoup de ASP.NET MVC en plus de Rails et c'est un tres bon framework)
Et franchement je la ramerais pas sachant l'apport de C# en 2001 par rapport a Java/C++.
Evidemment, c'est d'ailleurs le W3C qui normalise JavaScript…
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 0.
On s'en fou non ? Y'a d'autres implémentations qui le sont, pourquoi en prendre une qui ne l'est pas ? Les specs sont libres, ils existent des implémentations libres, et rien n'empêchait Google d'en faire une libre.
Mono propose un interpréteur C# qui en fait un langage de script à part entière.
Bah C# était à l'époque innovant sur plusieurs points :
- des améliorations clair dans le langage par rapport à Java (event, metadatas, P/Invoke, (un)Boxing)
- Un modèle de VM multi-language by design
- Un modèle de compilation en code natif sans aucune interprétation (contrairement à la VM Java).
Donc oui, à l'époque C# apportait de réelles innovations par rapport à Java.
Justement, je pense que c'est une erreur. Un vrai signe de standardisation pour une techno web, c'est d'être considérée par tous les acteurs du web, et ce qui représente tous les acteurs du web aujourd'hui, c'est pas l'ECMA, c'est le W3C.
Mais à la limite que les gens n'aime pas le C#, trop MS toussa, pourquoi pas, mon propos n'est pas de dire "fallait utiliser C#" - même si effectivement je penses que c'était un bon candidat modulo quelques adaptation - mais je trouve clairement dommage que Google reparte "from scratch" sans même tenir compte de l'existant en matière de VM. C'est d'autant plus surprenant qu'ils ont était beaucoup plus pragmatique sur Android : ils ont repris et adapté la JVM à leur besoin en créant Dalvik.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par claudex . Évalué à 6.
Pas du tout, Dalvik ne dérive pas de la JVM, c'est un projet à part (ce n'est ni la même licence, ni la même architecture).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par flan (site web personnel) . Évalué à 0.
C'est ce qu'il dit, non ?
Ils ont créé une nouvelle machine virtuelle Java avec Dalvik, en reprenant et adaptant le concept de JVM. En tout cas, je le comprends ainsi.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par claudex . Évalué à 6.
Je ne sais pas quel concept de la JVM ils ont reprit mais il me semble qu'il y a autant en commun entre la JVM et Dalvik qu'entre la VM C# et Dalvik. Si ce n'est qu'il y a un outil officiel pour convertir les .class en dex.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 3.
Dalvik n'est pas une machine virtuelle java. Dalvik :
Il existe juste un compilateur class vers dex. Donc si dalvik est une machine virtuelle java JS est une machine virtuelle C++ (puisqu'il existe un compilateur C++ vers JS).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à -1.
C'est plus ou moins une JVM puisque capable d'exécuter du bytecode Java à travers une pré-compilation, mais ca reste effectivement un nouveau type de VM. De toute façon mon propos n'était pas là : je voulais juste indiqué que Google avait repris un langage "éprouvé" (Java), en proposant une techno dérivée adaptée à leur besoin.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 4.
Non elle exécute du code dex. Si tu considère la compilation class vers dex comme cette précompilation, alors ça n'a pas vraiment de sens la OpenJDK, dalvik, la vm .Net, parrot, cpython, pypy, ton processeur x86, ton shell et spidermonkey (entre autre) sont des JVM puisqu'ils sont tous turing complet.
Ils n'ont repris que le langage rien de plus (ensuite ils ont trouvé plus simple de faire une compilation bytecode java vers bytecode dex (probablement pour le code fermé), mais c'est un détail d'implémentation).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 8. Dernière modification le 28 décembre 2013 à 02:31.
Donc ta proposition c'est quoi ? Que a la place de Dart, Google reprenne C#, un langage controlle a 95% par Microsoft, qui a une culture ferme et mono-plateforme, qui n'est plus normalise depuis 7 ans, qui n'est pas un langage interprete a la base et de le soumettre au W3C qui n'a jamais normalise un langage de programmation ?
Heureusement que C#/.NET apportait des ameliorations par rapport a Java : 6 ans d'ecart entre ces technos. Mais au final il y avait moins de differences qu'entre Python 2 et 3.
Pourquoi ne pas avoir ameliore Java et la JVM, en quoi c'etait impossible ?
Le choix de Microsoft avec .NET et C# etait clairement politique et pas technique, le detournement de Java avec J++ le prouve bien.
A l'epoque ils etaient les rois du petrole et pouvaient imposer leurs technos mono-plateforme et leur modele ferme et ils l'ont fait.
C'est vraiment pas un argument a avancer. Tous les meilleurs bindings/langages utilisent la JVM : JRuby, Scala, Jython…
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 3.
Ça j'y mettrais pas ma main à couper.
Le JCP met bien plus longtemps à se mettre d'accord (cf. : les lambdas).
Il y a surtout un bon paquet de langage .Net qui sont soit mort-nés soit moribonds.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Pas spécialement C#, mais qu'ils repartent d'un existant : un langage existant ou bien la JVM ou la VM.NET ou Parrot ou je ne sais quoi, mais qu'ils ne réinventent pas intégralement la roue quand il n'y a aucun apport et aucune justification technique.
Leur argument c'est de dire "les VM multi-langages ca marche pas, ca oblige à choisir des dénominateurs communs, c'est donc trop lent". En pratique leur langage n'apporte rien de nouveau, leur VM est 5x plus lent que la JVM et bouffe plus de mémoire.
Parcque MS voulait apporter des nouveautés impossibles avec la JVM. C'est également politique on est d'accord.
Ils sont peut être plus utilisés mais pas meilleurs que les IronRuby, IronPython, Boo, etc.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 7.
Donc pour Google c'est nul qu'ils n'aient pas repris l'existant malgre les explications donnees.
Par contre pour Microsoft et C#/.NET, aucun probleme c'etait parfaitement justifie.
2 poids, 2 mesures ? un jugement sans connaitre ? de la mauvaise foi ?
"en quoi c'etait impossible ?", reponse : "apporter des nouveautes impossibles" => Wow ! c'est convaincant comme argumentation !
Tellement impossible que d'apres toi-meme "C# […] fourni la roadmap du langage Java avec 2 ou 3 ans de retard"
Personne n'utilise IronRuby alors que JRuby est tres utilise et toutes les grosses gems (sauf rares exceptions) sont testees sous JRuby.
IronRuby n'est plus maintenu depuis plus d'un an cf https://github.com/IronLanguages/main/tree/master/Languages/Ruby et http://ironruby.codeplex.com/releases
Si les langages CLR étaient meilleurs, ils seraient plus utilisés que leurs equivalents JVM, non ?
Quant au terme employé : "Ils sont peut être plus utilisés"…
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à -1.
Leurs explications sont tout simplement contredites par les faits : Dart est beaucoup plus lent et bouffe plus de mémoire que Java. Et le contexte est différent, ce que j'essai d'expliquer : la concurrence a parfois du bon (Java vs .NET a créé une saine émulation), mais dans le contexte du web, il me semble plus important d'atteindre une forme de consensus et d'interopérabilité, merci le W3C.
Ok, tu veux des exemples :
- modèle de VM multi-langages, notamment pour pouvoir faire le langage C++/CLI.
- amélioration des performances : nouveau modèle de bytecode pour faire de l'AOT et non du JIT, notion de pointeur, boxing/unboxing, types générics à l'exécution
- P/Invoke : pouvoir faire des wrappers de code natif de manière portable (vs JNI).
J'ai une autre analyse : C# est un très bon langage multi-paradigme (procédural, objet, fonctionnel, dynamique, etc.) et les gens ne voient pas autant d'intérêt à le remplacer, à l'inverse de Java ;)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Les améliorations que tu cites ne sont pas impossibles avec la JVM. Certaines sont d'ailleurs déjà là: il y a depuis longtemps plusieurs langages, les perfs se sont bien améliorées, JNA est équivalent à P/Invoke…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 0.
De manière non normalisée, le niveau de compatibilité entre les briques développées dans des langages différents est aléatoires. Tu peux difficilement faire l'équivalent du C++/CLI avec la JVM.
En théorie oui, en pratique c'est beaucoup plus limité : absence de notion de pointeur en Java (pointeur mémoire ou fonction), obligeant à faire des contorsions ou du marshaling, ce qui est lent et couteux en mémoire.
Mais je pense qu'on est d'accord sur le fond : MS voulait "sa" techno et a choisi de concurrencer Java, avec des arguments techniques mais pas uniquement. Ca s'est traduit par une saine émulation technologique entre les 2 plateformes. Je cherche l'émulation et l'intérêt d'une concurrence pour une techno web.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 4.
Tu viens quand même de changer d'argumentation. Mais pourquoi tu te focalise sur leW3C qui n'a jamais normalisé de langage coté client ? S'ils avaient était intéressé par ça ils auraient inclu JS dans les techno HTML5 ?
groovy/scala/clojure sont là pour remplacé Java, les portages de langages existants sur la JVM sont là pour faire un mélange différent (réutiliser à la fois du code JVM et du code du langage en question).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Mon propos dès le début est d'indiquer que leur argument, purement technique, n'est pas valide en pratique. Comme s'ils essayaient en fait de justifier un choix qui pour moi est politique.
C'est un peu la pierre manquante des technos web au W3C, et comme toi, je me demande pourquoi le W3C n'a jamais normalisé de langage côté client. L'effort de Google ne semble pas aller dans le sens du consensus, j'ai vu aucun groupe de travaille façon HTML5 pour tenter de réunir les acteurs du web. On sort tout juste de l'enfer IE/ActiveX/Flash/Silverlight, je trouverai ca vraiment dommage que Google nous y conduise à nouveau.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 4.
Parce que ça ne les intéressent pas ?
Parce que c'est déjà fait ailleurs et qu'ils veulent pas entrer en concurrence avec ce qui a était fait ?
Parce que pointé sur une norme hors W3C ils aiment pas trop ou ils craignent que si ça évoluent, ils n'évoluent pas aussi vite ?
Je ne suis pas un spécialiste de l'ECMA, mais je présume qu'ils ont un processus pour créer un groupe de travail (actuellement il y a 3 personnes dont 2 de chez Google). Faut pas se focaliser sur le W3C, il y en a pleins des organismes de normalisation (ISO, IETF, ECMA, OASIS, ANSI, LSB, Freedesktop, etc). Le fait que quelque chose soit standard ou pas n'indique rien, c'est la crédibilité de l'organisme qui a de l'importance (est-ce que leur normes sont de qualité ? sont respectées (voir obligatoire) ? comment fonctionne leur processus de normalisation ? Est-ce que les contributeurs à cette norme sont crédibles ?…). Si on considère que l'ECMA est crédible pour js pourquoi ne le serait-il pas pour dart ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 1.
En gros tu proposes que le W3C arrête de s'occuper de son rôle de standardisation des technos web, c'est plus simple de laisser un acteur tout seul sur une techno, ca permet d'évoluer toujours plus vite et surtout ne pas essayer de rentrer en concurrence avec lui.
La question n'est pas de savoir si l'ECMA est crédible ou non, mais de savoir si le groupe de travail l'est : 3 personnes dont 2 de chez Google, pour une techno aussi critique pour l'interopérabilité du web, c'est pas crédible.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 7.
Je propose rien j'émets des hypothèses pour expliquer des faits.
Tu fantasme détend-toi. Je présume que personne n'a vu d'intérêt à créer un groupe de travail là dessus dans le W3C. Je crois que n'importe qui peut faire ce genre de demande, donc demande par exemple à Mozilla pourquoi il ne l'ont pas fait.
C'est quoi se centrisme sur le W3C ? Tu peut m'expliquer en quoi le processus du W3C est meilleur que celui de l'ECMA ?
Ils viennent de créer le groupe et en même temps ils ont lancé les inscriptions donc c'est normal qu'ils soient 3. C'est à mon avis le nombre minimal de personnes qu'il faut pour créer un groupe. Maintenant ils reçoivent des demande d'inscription (regarde le formulaire). C'est même la seule chose qu'a fait ce groupe en fait.
Faudrait vraiment arrêter de spéculer quand tu ne sais pas de quoi tu parle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Peut-être parcqu'ils ne veulent pas d'un truc nouveau pour remplacer Javascript ? Idem pour MS et Apple ? Bref, s'il n'y a pas de consensus parmis les principaux acteurs, comment peut-on espérer que Dart devienne autre chose qu'une techno Chrome-Only ou en tout cas contrôlée par Google ?
Parcqu'on parle de techno clé pour l'interopérabilité du web ?
Je spécule pas, je constate : Excepté Google, les mastodontes du web ne font pas parti du processus. Même si le processus ECMA est très bien pour un langage de programmation, pour moi il n'est pas suffisant pour une techno web.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 5.
Ça ne dis pas en quoi le W3C est meilleur que l'ECMA. C'est si compliqué à comprendre comme question ?
On verra ça à la cloture des inscription tu ne crois pas ? C'est un commité qui a à peine quelques semaines et même (surtout ?) le W3C prend énormément de temps pour faire une spec.
À part toi qui pose ta vérité tu as quoi à redire de leur méthode ? Surtout que ce qui « n'est pas suffisant pour une techno web » a quand même relativement bien marché pour l'existant avec javascript.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 2.
N'importe quelle société peut faire standardiser un langage à l'ECMA : l'ECMA ne juge pas de la pertinence au regard de l'existant et ne raisonne pas en terme d'interopérabilité au sens Web. Un exemple : tu peux très bien déposer à l'ECMA un standard auquel est associé une palanquée de brevets, que tu pourras exploiter (dans des conditions RAND). Ce n'est, à mon sens, absolument pas suffisant pour une techno web. On est d'accord, la stratégie de Google ne semble pas être la monétisation de brevets, mais cela montre clairement les limites de l'ECMA.
A l'inverse, le W3C fait des choix (pas 36 standards pour un même besoin) et a une action de lobbying en incitant ses membres - qui sont suffisamment représentatifs pour justifier la crédibilité du W3C - à utiliser les technos qu'elle promeut.
Le principal défaut du W3C, c'est sa lourdeur/lenteur, de part le nombre d'acteurs qui y participe. Une initiative "externe" peut donc être pertinente, mais il faut qu'elle représente des acteurs suffisamment représentatifs et avec des objectifs similaire : trouver un consensus et réintégrer par la suite le W3C. C'est ce qui s'est passé avec le HTML5. Attendons comme tu dis la clôture des inscriptions, mais l'avis émis par Mozilla semble plutôt montrer qu'il va au moins manquer cet acteur, voir d'autres tout aussi important.
La stratégie de Google semble être : ne cherchons pas à trouver un consensus qui garantisse l'interopérabilité mais sortons vite notre techno, de manière ouverte (l'ECMA est très bien pour ça), afin que les développeurs/utilisateurs s'en empare. Cela deviendra un standard de fait : les concurrents seront pointés du doigt pour ne pas intégrer une techno ouverte et nous aurons de toute façon une longueur d'avance.
Où comment créer une fragmentation du web.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 2.
Je ne comprends pas comment tu peux faire autant de reproches a la demarche de Google et en meme temps etre fanboy de Microsoft/C#. Autant d'incoherences, pour moi ca releve de l'arnaque intellectuelle :/
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Si j'aime le C#, c'est uniquement pour des raisons techniques. Mais c'est même pas le sujet : d'ailleurs le message auquel tu me réponds n'en parle pas.
Mais bon je sais très bien qu'en discutant ici, on va forcement se retrouver avec ce genre de conclusion, où il est pourtant "évident" que Google c'est bien et MS c'est mal (TM), et vu que j'aime une techno MS, je suis forcement un arnaqueur intellectuel. Ca évite d'argumenter.
Il y a des choses bonnes et mauvaises chez tous ces acteurs, et là en l'occurrence on ne devrait même pas parler de Microsoft : juste réfléchir de la stratégie de Google avec son nouveau langage.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 3.
Ouai enfin t'es pas moins manichéen que ceux que tu dénoncent.
Dommage que tu l'ai fait :)
Tu commence en disant que C# t'aime bien pour des raisons techniques même s'ils ont une stratégie de conquête du monde derrière et tu fini en disant que Google il faut regarder juste leur stratégie et pas se pencher sur la partie technique. :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 2.
A aucun moment je dis "MS c'est génial" et à ok moment je dis "tout ce que fait Google c'est pourri".
J'ai pris soin de prendre 2 exemples, C# et Java, pour éviter de tomber dans le troll MS.
T'es quand même un brin malhonnête. Si tu lisais mon premier commentaire, tu verrais que je critiques essentiellement l'argumentation technologique de Google (l'impossibilité d'obtenir des performances intéressantes avec une VM multi-langage comme .NET ou Java). Et oui, à défaut d'argument technologique, j'en conclu que Dart est avant tout stratégique. Déjà en soit ca me dérange (j'ai la techno, je suis déçu). Qu'en plus ce soit développé par un seul acteur majeur du web, pour une techno web, ca me dérange encore plus.
Ce qui serait cool si ca te dérange pas, c'est qu'on arrête ce meta-troll sans intérêt. Soit on en revient au sujet, à défaut je te laisse continuer tout seul.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 0.
Source ?
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 3.
J'ai pas inventé l'eau tiède, hein. L'un des premiers liens du journal :
http://www.ecma-international.org/memento/TC52.htm
(donc le site officiel sur la page dédiée à la standardisation de Dart)
Quand on regarde ce que tout ce beau monde a fait sur la page activité, on voit que pour le moment ils ont enregistrés un groupe de travail et rien de plus. Ça ne me paraît pas choquant que pour le moment il n'y ai rien on est hyper tôt dans le processus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 0. Dernière modification le 30 décembre 2013 à 23:33.
Le preuve que non :) (Ah oui quand j'ai demande la source, c'etait un piege hein…)
http://www.ecma-international.org/memento/TC39.htm (ECMAScript)
http://www.ecma-international.org/memento/TC49.htm (C#)
Je pense qu'il n'y a pas besoin d'epiloguer sur le fait que t'as sorti une grosse connerie :)
Bien sur TImaniac c'est empresse de conclure que le groupe de travail pour Google n'est pas credible : 3 personnes dont 2 de chez Google.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 1. Dernière modification le 30 décembre 2013 à 23:45.
Oui mais non. Le commité existe à peine. Regarde l'activité du groupe, pas la moindre réunion, rien d'autres que l'ouverture des inscriptions. Probable qu'il y ai déjà d'autres personnes d'inscrites, mais pour le moment sans la liste des membres ou le compte rendu d'un évènements qui listerais des membres supplémentaires tu ne peut pas dire autre chose que ce que j'en ai dis. Pour le moment ce n'est presque rien. Il n'y a pas de groupe de travail, il n'y a pas eu d'évènement.
Dis autrement lors de l'étape inscription/désinscription, mes seuls personnes que l'on sait membre du commité sont les 3 listées. Tout le reste n'est pas publique et n'a donc pas d'importance quant à la crédibilité du commité. Mais encore une fois c'est normal.
C'est surtout que je n'aurais pas du parler de groupe de travail mais de comité vu qu'ils n'en ont pas créé.
Par contre je trouve le site de l'ECMA particulièrement mal foutue c'est pas simple de connaître les participants.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 0. Dernière modification le 31 décembre 2013 à 00:00.
Pour TOUS les groupes de travail il y a un president, un vice-president et un secretaire (ba ouai c'est logique hein). En conclure qu'il y a seulement 3 personnes dans le groupe de travail de Dart est faux.
Et donc tu ne peux pas tirer de conclusions.
Et oui on imagine bien que comme le groupe de travail vient d'etre cree, il y a probablement peu de personnes. Peut-etre qu'il y a meme reellement que 3 personnes.
Dans tous les cas ton raisonnement est simplement faux, point barre.
Admettre que t'as lu un peu trop vite la page de l'Ecma, ca va pas te trouer le cul hein…
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 2.
Je me fous qu'il y ai les plus grands créateurs de langages qui n'aient jamais existaient :
J'ai parlé par erreur de groupe de travail alors qu'il aurait fallu parler de comité. Pour le reste j'ai dis que pour le moment (ce qui est acté, ce qui est officiel, ce qui est publique, de ce que l'on peut voir dis-le comme tu le souhaite) on voit 3 personnes simplement parce qu'il n'y a rien de fait pour venir me dire que je mens, ou que je dis des conneries il va falloir me montrer une liste plus exhaustive.
Bien sûr que ce sont les 3 membres nécessaires à la création d'un comité (comme pour une asso française), mais affirmer qu'il y a d'autres membres (encore une fois actuellement) c'est de la conjecture. Je présume que lors de l'étape suivante on verra les membres officiels du comité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à -1.
J'ai pas tout compris a ton dernier commentaire. Je pense qu'il y a incomprehension mutuelle.
Les 3 personnes de base pour chaque comite/groupe de travail/peuimportelenom de l'Ecma ne presage pas du nombre de personnes qui vont y travailler (on ne connait pas ce nombre et vu le peu d'info que donne l'Ecma de maniere generale, peu de chances qu'on le connaisse un jour).
Faisons confiance a l'Ecma et Google, il y a peu de raisons que ca finisse en fiasco comme pour le format Open XML de Microsoft cf http://fr.wikipedia.org/wiki/Office_Open_XML#Un_projet_de_norme_contest.C3.A9
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 1.
C'est ce que je dis depuis le premier message.
Non. Comme je l'ai dis plus haut, je ne sais combien de fois ce qui donne de la valeur à une norme c'est la confiance que l'on a envers l'organisme et les procédures qu'il utilise. C'est ce qui fait la différence entre une spécification et une norme. Si l'ECMA cherche à rester opaque je ne vois pas pourquoi je lui ferrais confiance.
Ensuite si Dart devient un standard de fait tant mieux ou tant pis, mais ça ne me ferra pas faire plus confiance en l'organisme.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Antoine . Évalué à 4.
Une interprétation efficace à la volée ? Du source C# embarqué dans une page Web, quel délai d'attente avant de pouvoir l'exécuter ?
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par YBoy360 (site web personnel) . Évalué à -1.
Vous devriez tester dart avant d'en parler. Le lien benchmark par des packagers de debian pour faire crédible, pitié. Foutez la paix a l'humanité en faisant autre chose de vos journée (genre tester les pointeurs null reto
urné par malloc)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 8.
La JVM existe depuis 18 ans (1995), .NET VM depuis 12 ans (2001) et Dart VM depuis 2 ans (2011).
Les developpeurs de Dart pendant ces 2 ans ont cree un IDE base sur eclipse, une VM, l'integration dans Chromium, dart2js, toutes les libs autour, les specs maintenant la normalisation…
Ils ont deja montre que Dart pouvait etre 2x plus rapide que JavaScript et dans certains cas depasser la JVM.
Laissons leur un minimum de temps pour prouver leurs dires.
De plus .NET et Java demandent une etape supplementaire de "compilation", Dart au contraire est un langage de script comme Python, Ruby ou JavaScript et ne demande pas d'etape supplementaire.
C'est voulu pour séduire le plus de personnes possibles. Si ils avaient fait dans l'originalité, ca leur aurait ete reproche aussi.
Tout comme JavaScript est apparu d'abord dans Netscape.
Tout comme asm.js et Firefox.
Il faut bien commencer par quelques chose, tu serais a leur place, ca serait quoi ta solution ?
C'est possible, on peut voir le mal partout. La mise a disposition des specs, la licence BSD, l'ouverture du projet, la normalisation en cours tend a montrer le contraire.
Que peuvent-ils faire de plus ?
"Google has gone about the introduction of Dart in a scrupulously open way. They publicized the language early on it's design and implementation, they open sourced their implementation immediately on announcement and continued development in the open with input and contributions from all comers. […] Now they've begun a standardization process.
[…] Mozilla couldn't ask for a more open […] Regardless of Google's overall impact on the world, the Dart project is very much in line with Mozilla's mission. […] I expect Mozilla will oppose Dart, but they'll have to twist themselves into rhetorical contortions in the process. NIH is alive and well." https://news.ycombinator.com/item?id=6903420
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à -1.
La question n'est pas de savoir s'ils vont arriver à faire pareil en matière de perf que C# ou Java, la question est : que va-t-il apporter de différent/mieux par rapport à ces langages ?
Au moins un consensus au W3C. Je pensais que c'était fini l'époque façon Netscape/IE où chacun y allait de sa techno proprio et les standards de fait qui ont pourris le web pendant tant d'année.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Dr BG . Évalué à 5.
bah déjà, il est directement interpreté. Je pense que ça aurait été mal vu de proposer une VM pour le web côté client lisant des binaires.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à -1.
Non il est directement compilé :) (en code natif).
Bof, quand tu "décompiles" le bytecode JVM ou .NET, tu sors quasiment intacte le code source. Le binaire est juste une forme optimisée pour être compilé en code natif plus rapidement, tout en prenant moins de place.
Quand tu vois le nombre de code Javascript qui sortent d'un pre-compilo, c'est pas franchement plus clair que du bytecode décompilé.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 1.
Voici une presentation (2014/01/02) d'un ingenieur Google qui travaille sur V8 et la VM Dart et qui a auparavant travaille sur une VM Java.
(Pour info Lars Bak a aussi travaille sur une VM Java en plus de Smalltalk : HotSpot quand il etait chez Sun).
Il compare le fonctionnement de la VM V8 et de la VM de Dart : Building an Optimising Compiler for Dart
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Maclag . Évalué à 9.
En pratique, je vois bien des choses écrites en Javascript, y compris de nouveaux projets. C'est que quelque part, le remplaçant "idéal" de JS n'existe pas encore. Si JS atteint ses limites, il faut un remplaçant à JS.
Sinon à ce petit jeu on peut sortir les benchs de tous les langages et tout le monde devrait programmer en C.
Je me méfie aussi de Google, mais là je vois difficilement comment ils auraient pu laisser la porte plus grande ouverte aux implémentations concurrentes.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par reno . Évalué à 1.
Sérieux, tu mets sur un pied d'égalité en tant que langage C# et Java??
OK, C# a commencé comme étant un clone de Java, mais il a bien surpassé Java depuis..
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Dr BG . Évalué à 3.
Je ne pense pas me tromper en disant que la personne à qui tu réponds le pense aussi…
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Bien sûr que non :) Je mets C# loin devant, mais j'ai voulu rester neutre histoire qu'on ne rentre pas dans un débat anti-MS de base, ce qui n'est pas le sujet.
C# est un bon exemple de langage qui a percé par rapport à Java (pas suplanté, mais en tout cas qui a trouvé sa place) : il apportait vraiment du neuf, que ce soit en terme de performance, de syntaxe, etc. Dart n'apporte pour moi rien d'excitant.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . Évalué à 5.
C'est quoi au juste la contribution de c# au monde serveur?
Nan parce que ce que j'en voit de mon cote, bossant dans une boite .net centrique c'est que je peux pas nommer une seule techno/librairie qui ne soit pas venue du monde java ou ruby d'abord.
Et sorti de stackoverflow/microsoft.com, je peux pas te nommer un seul site a traffic decent base sur du .net.
Je vois aussi des gens avec une mentalite datant de debut 2000, ou des trucs aussi basiques que la gestion des dependences a la maven (nuget) ou l'IoC/DI a la spring sont loin d'etre acquis.
Et je passe sur ces noms de frameworks a la cons impossible a googler.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Désolé, je connais plutôt le côté client :) Mais j'ai tendance à dire qu'effectivement pas grand chose côté serveur. ASP.NET a été une vraie bouse.
C'est facile : le langage C# a à lui seul fourni la roadmap du langage Java avec 2 ou 3 ans de retard :)
Pour ce qui est des bibliothèques tierces, on est d'accord.
Myspace
Walmart
Barnes and Noble
Dell
Newegg
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ils n'ont pas du viser les bons items de la roadmap, car Java est utilisé par la majorité des développeurs dans tous les domaines et tous les types de machines alors que C# est resté confiné aux microsoft fanboys pour du web / gui / jeux presque uniquement sur les OS de la marque.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 2.
Aucun rapport, ça n'en fait pas un bon langage pour autant.
Il suffit de voir combien de temps il a fallut pour avoir nombre de fonctionnalités de bases. Juste un exemple au pif, le fait par exemple de ne pas avoir de
isEmptysur lesString.Et franchement sans les libs apache (mouai) ou guava (mieux) java serait assez peu utilisable.
Dans beaucoup de cas Java est choisi sans prendre en compte les qualités (nope) et défauts du langage mais en regardant l'écosystème, les libs et parce que c'est bien corporate de faire du java donc say bien.
Par contre, C# est pour moi un bien meilleur langage et oui il est en avance sur Java depuis un bon moment…
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 7.
L'écosystème est hyper important pour un langage. Bien des langages n'ont jamais décollés malgrès leur qualité intrinsèque à cause de ça. Pour ce qui est de l'écosystème .Net/Java, j'ai l'impression qu'il y a un foisonnement du coté Java alors que .Net a plus une et une seule solution à chaque problématique (probablement mieux intégrées entre elles du coup). C'est ce qui pousse la création de trucs comme jython/groovy/clojure/scala, être compatible et utiliser l'écosystème java avec un langage différent.
Je pense que le commentaire initial parlait surtout de l'outillage autour de Java qui n'est as mauvais (avec les builders type maven/gradle/sbt).
Mais ce qui plombe sacrément .Net AMHA c'est le centrage sur Windows (pour les serveurs).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Le isEmpty date de la 1.6 sorti en 2006. Beaucoup de développeurs ont été traumatisé par la merditude des débuts de Java, mais c'était il y a 7 ans quand même…
http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty%28%29
Mais il n'est pas (plus) mauvais non plus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 2.
Cool, c'est pour ça que j'ai encore vu tourner du code en 1.5 il y a quelques mois.
Mais c'était juste un exemple de la lenteur avec laquelle Java évolue. Alors oui à partir de java 1.8 on commence à avoir des trucs intéressants, mais franchement comparé à d'autres langages c'est pathétique.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par reno . Évalué à 3.
Il y a un juste milieu: je n'aimerai pas avoir à maintenir une grosse application en Ruby vu la vitesse à laquelle ils
cassentchangent tout, mais oui Java c'est l’extrême opposé, beurk.[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 3.
Extrême, je ne pense pas C++ (post C++14) et C sont bien plus long. Pour les choses simples C++ est bien fait, mais pendant pas mal de temps et jusqu'à l'arrivé de C++11 faire du C++ sans boost c'était pas si agréable que ça. Faire du multitâche en C++ n'est pas standard (ou l'est depuis C++11). L'API C pour gérer les bibliothèques est piégeuse (suffisamment pour qu'une partie soit bannie dans certaines normes de codage), mais elle reste pour compatibilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Lesquels? Je suis toujours à la recherche d'une bonne plateforme de développement pour remplacer mon trio Java/C++/Python!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 2.
Ça dépend toujours de ce que tu veux faire. Le langage ne fait pas tout, l'intérêt de java étant bien évidemment les libs compatibles avec la jvm (en même temps vu que sans tu ne peux rien faire…)
Maintenant côté langage intéressant il y en a plein. Certains vont te sortir elixir par exemple, ou ruby. En ce moment par exemple je fais du clojure au taff, et c'est quand même plutôt bien, vraiment pas envie de retourner sur du java.
Et je fais aussi toujours beaucoup de js parce que j'aime bien.
Et je regarde de temps en temps Ada (entre autre parce que ma boite en fait) et c'est vraiment intéressant. Par exemple la gestion de la concurrence est vraiment pas mal, (très) loin devant java.
Dans tous les cas ce qui est mieux c'est surtout l'expressivité, java en manque cruellement. N'importe quel langage plus expressif sera plus intéressant.
Par exemple passe sur un autre langage que java tout en gardant la jvm, groovy/jruby si tu aimes le style, clojure parce que c'est bien et cool pour gérer des ensembles de données.
Ben voilà, remplace Java/C++/Python par Clojure/Ada/Ruby :-)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tout!
L'un des gros projets que j'ai en tête est un jeu en ligne avec des clients desktop, web et mobiles. Je me vois mal maintenir une base de code avec plusieurs langages…
Ça fait peur!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 2.
Qu'est-ce qui fait peur dedans ? Vraiment hein.
Et pourtant, c'est probablement la meilleure chose à faire.
Java sur le desktop ? Niveau intégration multiplateforme c'est en général assez nul. Sur le mobile ? Heu, java sur iOS ça doit être assez marrant :-)
Sur le web à moins de faire du vaadin (ou équivalent, et encore) tu vas devoir prendre autre chose que du java (au moins partiellement)
Pourtant, tu pourrais très bien faire ton serveur en java (guice, jaxrs, etc) et avoir des clients différents. Et oui des langages différents. Mais c'est utiliser des langages (et sdk) différents qui va te permettre d'avoir des choses intégrées et adaptées à la cible.
M'enfin pour le serveur en fait je trouve clojure avec liberator (par exemple) plutôt bien foutu et agréable. korma si tu as besoin d'une bdd.
C'est rapide à coder, c'est expressif, say bien.
Ha oui, ou sinon jseverywhere ! un serveur en node.js, clients js partout et hop. Et à la rigueur une compile js -> asm.js pour gagner un peu en perf.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pour le jeu, il y a playn et libgdx, une seule base de code pour tous les clients. Au boulot, on fait juste des IHM web et des applis mobiles qui embarquent un navigateur :-)
Vu les délais (entre 3 mois et "il faut que ce soit fini avant de perdre la motivation") et la taille des équipes auxquelles j'ai accès (de 1 à 4 personnes), ce n'est pas réaliste.
Déjà que Java c'est pas génial… Il faut aussi que les devs ne partent pas tous en dépression!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 2.
C'est pour ça que j'adore répondre à une question sans connaître les contraintes, c'est toujours très marrant.
« j'ai peu de ressources, peu de temps, je connais déjà X tu proposes quoi d'autres ? »
Rien, tu as déjà fait ton choix.
Et sinon, fait du playn avec jruby par exemple ou n'importe quel autre langage jvm un peu plus évolué que java.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 28 décembre 2013 à 11:16.
J'ai fait le choix il y a 5 ans, mais je reste ouvert! Par contre, il faut que la solution proposée soit au moins aussi bien.
Depuis quand Ruby est plus évolué que Java? :-) Je lorgne de temps en temps sur Scala, mais j'ai l'impression qu'il sert surtout de bac à sable pour expérimenter les nouveautés à intégrer dans Java N+1.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 3.
hum…
Le choix c'est aussi d'apprendre autre chose. Peut-être ai-je mal compris cette phrase mais je le lis un peu comme "il faut pas que ça prenne du temps à apprendre"
Hors c'est bien l'une des principales raisons qui fait que tout le monde reste sur du java ou php : tout le monde connait (plus ou moins, souvent moins) donc coût d'apprentissage quasi nul donc pourquoi partir pour autre chose de plus productif qui aurait un coût initial (formation) plus important ?
Depuis toujours ?
Côté langage, syntaxe, etc il n'y a pas photo du tout.
De manière générale aujourd'hui je privilégierais de toute façon un langage avec des functions first-class citizens donc des trucs genre ruby ou js sont ok. En fait coder en fonctionnel a changé ma façon de voir les choses (en bien). Et bon, java pour ça c'est juste merdique.
Le peu que j'en ai vu ne m'a jamais intéressé (peut-être à tort)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Non, je parlais du fait d'utiliser une techno par plateforme. Même en enlevant le temps de formation initial, ça veut dire beaucoup de travail en plus.
Un exemple bête: si tu dois valider des numéros de téléphone, il faut le faire au niveau du client et au niveau du serveur.
Avec un langage par plateforme, tu peux te retrouver à implémenter cette validation:
Le développement est fait 6 fois et je ne parle même pas du temps de déploiement/maintenance/gestion de configuration qui s'ajoutent avec tous ces langages…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par fredix . Évalué à 4.
Moi je fais du Qt coté serveur, coté desktops, je peux maintenant en faire aussi sur iOS et Android. Et si je dois faire un site web il y a un framework MVC
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 2.
Pour les trois derniers en gardant Obj-C/C#/C++ : tu peux pas avoir une lib commune ?
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Tu peux aussi faire une seule lib en C# qui tourne sur toutes ces plateformes ;)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
On a compris que tu aimes C#, mais il faudrait que Microsoft soit plus ouvert: on est encore dans la situation avec un offre au top dans l'univers Microsoft, au rabais ailleurs.
Sun/Oracle faisait la même chose avec Java, mais aujourd'hui on ne voit plus la différence entre Oracle Java et l'openjdk (sauf applis pourries qui utilise com.sun.internal.jesuisungrosdebilededevquiutiliseça.*).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 1.
MS est officiellement partenaire de Xamarin, offre très complète pour faire du C# sur iOS et Android.
Unity 3D est probablement l'environnement le plus populaire pour réaliser des jeux cross-plateformes, là encore de grande qualité.
Je vois pas ce qui est au "rabais" là dedans, surtout si on compare par exemple à ce qui est possible de faire en Java sur les autres plateformes mobiles : iOS, Windows Phone, etc.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Comme exemple d'ouverture, tu cites Xamarin et Unity qui sont pwivateurs. Si tu veux troller gras, va sur windowsfr.org :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 0.
Tu comparais à "une offre au top" sur Windows, je compare donc du privateur sous Windows (Visual Studio & Co) avec des technos privatrices ailleurs :) On est d'accord c'est toujours des outils fermés, mais ca reste technologiquement ouvert à d'autres plateformes.
Un troll est quand même nettement plus fun quand tu vas à l'encontre de quelque chose :)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par sifu . Évalué à 4.
Tu dis plus haut que Xamarin est partenaire avec MS. Mais à part une intégration à Visual Studio plus poussée, j'ai le sentiment que cela ne vas pas apporter grand chose. Il y aura sans doute moins d'énergie consacrée à la version reposant sur MonoDevelop.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Je veux faire une appli avec côté serveur quelque chose de très performant pour donner des stats en temps réel (il faut imaginer une plateforme boursière à laquelle on accède via le web), mais je ne veux ni d'usine à gaz J2EE ni de ASP.NET dépendant de serveurs Windows.
Que proposes-tu ?
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 2.
y'a plein d'autres choses que JEE dans le monde java hein
maintenant y'a pas vraiment moyen de répondre à ta question (c'est quoi très performant ? comment tu scale ? horizontale ou verticale ? etc)
mais tu peux imaginer faire du elixir du clojure, du smalltalk, de l'Ada, de la jvm (je te laisse le choix du langage) avec des trucs beaucoup plus simple que jee, etc
D'ailleurs Ada c'est pas trop mal si tu veux vraiment faire du temps réel
mais tout dépend ce que tu veux / privilégie. par exemple la perf pure ou tu es capable de perdre 10% de perf si tu gagnes 10% de productivité (et tu scale autrement) ?
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Zarmakuizz (site web personnel) . Évalué à 1.
Pour l'instant, je me renseigne sur un projet que je développerai l'année prochaine, une fois mes études terminées.
Ce sera hébergé sur un seul serveur, donc pour le scaling ce sera plutôt vertical dans un premier temps.
Perdre 10% de perf pour gagner 10% de productivité ne m'intéresse pas.
J'avais déjà Erlang en mémoire, suite à une news du Site du Zéro qui le présentait comme un langage qui tient la montée en charge. Je vais me pencher sur Erlang vs Elixir.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par CrEv (site web personnel) . Évalué à 4. Dernière modification le 28 décembre 2013 à 12:52.
hum… tu parles de bourses et ensuite d'un projet sur un seul serveur ? vertical ça veut dire que tu va faire tourner sur un truc très puissant (horizontal voudrait dire que tu rajoutes de noeuds)
Elixir c'est juste une autre syntaxe qui s'exécute sur la VM Erlang
C ? C++ ? Ada ? Obj-C ?
Le truc c'est qu'on peut quasiment tout faire avec quasiment n'importe quel langage. Après il faut juste savoir placer les curseurs, par exemple perf, lisibilité, maintenabilité, parallelisme, productivité, etc
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 8.
Ca me semble de la grosse pignole. Défini déjà précisement ton projet et son domaine fonctionnel précis. Designes en conséquence, la perf du langage ou du middleware est assez secondaire et sera évidente une fois que tu sais ou tu vas. 10% de perf, d'une part t'es encore dans l'erreur statistique de l'autre ca ne veut absolument rien dire.
Ce que tu dis est très très flou; mais pour ce dont tu parlais au début c'est le design du système et du dataflow qui fait que ca marche ou pas. Après tu choisis l'outil qui te semble adapté. Tu veux publier des valeurs de marché avec un jitter minimal ? Alors tu peux vouloir faire une archi type lmax couplé à un pub/sub adhoc. Ou peut être que tu veux faire un truc un poil différent sans de contraintes très forte sur la latence et un modèle à acteur sera la bonne abstraction. Où peut être qu'en fait c'est des algo de streaming couplé à une in-memory grid qui rendront ton business possible.
Une fois ces briques posée tu peux comencer à vouloir réfléchir aux outils à utiliser et comment les utiliser (entre du Java idiomatique et du Java HFT y'a pas grand chose en commun).
Autrement si tu n'as pas une spec précise, tu as juste le problème commun de > 90% des sites webs. Utilise ce que tu veux de toute facon tu n'as aucune idée d'où tu vas et tu vas tout réarchitecturer au fur et à mesure que ca se cassera la gueule. Faut juste compartimenter proprement pour pouvoir faire évoluer les briques indépendaments. Viser la perf au début c'est de la connerie et syndrome classique de la startup "Je veux utiliser la même stack que XXXX par ce que ca va vite"
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Narmer . Évalué à 0.
J'ai nommé … drum roll … Go ! Go remplace les 3 mon capitaine !
Développé par des "petits" gars de chez … je vous le donne en mille … Google.
Pourquoi ? parce que
compact • épuré
expressif • productif
rapide • concurrent
orienté "composition"
Et qui sont les créateurs de Go (que du lourd ):
Ken Thomson (oui c est bien lui), Rob Pike, Robert Griesemer, Russ Cox, etc
la compilation va tellement vite que c'est presque de l'interprété.
la syntaxe est juste génial.
les concepteurs ont voulu effacé toutes les merdes qu'ils rencontraient avec c/c++.
Et surtout les librairies disponibles de bases couvrent tous les besoins de bases d'une application moderne.
La communauté est super dynamique …
vala my 2 cents
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 5.
Genre l'IHM ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Narmer . Évalué à 0.
N'ayant pas précisé effectivment.
L'IHM via web il n'y a pas de souci. via le package http standard.
L'IHM via ligne de commande non plus. il existe des lib pour ça
L'IHM via avec des bindings : webkit, gtk, x11, qt/qml etc , Go2D, etc etc
L'IHM via des moteurs de jeux il en existe déja
il est rare qu'un langage inclus directement des fonctionnalité d'IHM, on passe plus par les bindings généralement.
bon après je ne sais pas exactement ce que tu mettais derrière IHM, avec ça on peut commencer
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ce langage plus lent que Java, sans generic/tempplate et sans IDE digne de ce nom?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . Évalué à 6.
Myspace? Vraiment, tu vas me citer myspace? Un truc mort et enterre depuis 7 ou 8 ans, dont tous les talents ont fuit vers d'autres horizons, essentiellement des java shops? Je le sais, j'ai bosse avec nombre d'anciens myspace ces 5 dernieres annees.
Barnes and nobles est mort est enterre (merci amazon).
Il te reste donc dell (effectivement), walmart, surtout connu pour ses magasins physiques, et newegg.
Maintenant, poussons le raisonnement un chtouille plus loin. Combien de ces boites sont connus pour repousser les limites, que ce soit d'un point de vue architectural, techno pure ou philosophie?
C'est ca qui m'a frappe quand j'ai decouvert le monde .net, c'est que la creme de la creme de cette communaute se resume a rattraper son retard sur le reste de la planete, et le milieu du panier fait franchement peur.
Regardes du cote java/ruby/python maintenant. Strictement aucune des technos "vrais hommes avec des couilles et de la scale serieuse" n'ont emerge du monde .net: tout le monde nosql, la montee du soa (a l'epoque ou ms poussait soap et du rpc bien rigide), la philosophie devops vient essentiellement de java shops, style netflix ou amazon, ou un mix ruby/java, l'emergence de serveurs "simples et legers" a la mode.js, toute la montee "data science", le big data, l'analytics/business intelligence, que sais je encore, j'ai la flemme de chercher.
Alors ok, c# a des features fancy (encore que linq est une non feature a mon avis, mais ca engage que moi), ms pousse des horreurs du style "serialization json en pascal case par defaut, et le fleuron de ms pour faire des api rest, c'est un truc nomme MVC, ce qui est assez rigolo sachant qu'une API rest est 100% modele. Forcemment, si t'as pas de vue, ton controlleur il sert pas a grand chose.
Pendant ce temps, java, qui est apparement un sous langage a t'ecouter, pousse l'ensentiel des avancees du milieu. J'avais tendance a te croire, ainsi que pbpg, et penser que les fanboy linuxiens en rajoutaient aveuglement, depuis que j'ai vu a quoi ressemble un .net shop, je me rends compte que les fanboys linuxiens sont pas si loin de la realite que ca.
Alors, ok, ms a probablement fait un bon boulot sur le clr, j'imagine qu'ils ont evite certaines des erreurs de java (les generics et autres conneries du style), mais sorti de ca (i.e., sorti des core teams microsoft qui sont probablement tres competentes), ya pas grand chose a se mettre sous la dent. Et le pompom c'est qu'ils ont reussi a se faire piquer leur principale avancee, un vm multi langage, par la jvm avec des trucs comme scala ou jruby.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 2.
Tu pourrais leur laisser l'honneur de Rx quand même !
Cela dit la JVM et le multilangage c'est très loin d'être tout rose. Suffit de suivre les JVM Language submit pour rigoler un peu.
Maintenant on se retrouve avec une VM construite initialement pour un langage "à neuneu" qui à profité de milliers d'années de boulot. Le langage a été patché dans tout les sens mais ses tares resteront à jamais pour raison de compat. Et les nouveaux langages choisissent la JVM pour éviter d'avoir à réinventer une VM et pour chopper la traction des devs Java. Sauf que souvent ca veut dire compat avec Java et exposer toutes ses tares dans les nouveaux langages.
Ca reste le moins pire choix, mais le futur est pas super brillant non plus.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Le langage à neuneu, c'est un avantage pour travailler en équipe.
Que celui qui n'a jamais eu à corriger un code C++ avec des templates de barbus ou du python si dynamique qu'il est impossible de faire le moindre refactoring sans tout péter jette la première bière!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 1.
Tu fais un gros mélange entre le langage et la VM. Bien sur que l'un a était écris pour l'autre, mais ça reste 2 choses bien distinctes qui évoluent différemment (comme les CPU et les langages compilés tel que C ou C++). La JVM évolue pour prendre en compte les langages dynamiques, mais je n'ai jamais vu de reproche fait au design de la VM (sauf au sujet du gc).
Tu aurais quelque chose d'un peu plus concret que « Java c'est de la merde donc la JVM c'est de la merde » ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 3.
Ou pas. Peut être que je fais parfaitement la différence entre la Java Language Specification et la Java Virtual Machine Spécification. Voir même j'ai une petite idée des trous qu'il y a entre les deux même si je suis très très loin d'être un dev OpenJDK ou ex Harmony.
J'ai juste suffisament tordu le truc dans tout les sens ces dix dernières années pour avoir quelques notions relativement solides…
Java n'est pas de la merde. Ses choix initiaux se font par contre de plus en plus payer de jour en jour. On est de deux axiomes: compatibilité reine et moins on t'en donne mieux tu te portes. Dans l'idée ca se tient, sauf qu'en pratique les deux ont conflictés et conflicteront toujours de manière de plus en plus violente. Le sous ensemble fourni était mauvais (et l'est toujours) donc on a passé les dix dernières années à le patcher comme on pouvait. Sauf que la compatibilité à forcée à faire des implémentations complexes de leaky abstraction bourrées de corner cases: Les generics fuient dans tout les sens, l'autoboxing est une horreur tant pour le footprint, que pour les perfs que pour la sureté, les lambdas sont une demi réponse au manque d'objets de premier ordre ca ne couvre pas 50% des besoins et la tête du bytecode à générer est rigolote, l'ajout des default methods est un gros patch qui encore une fois ne règle pas le vrai problème de la composition etc.
Plus ca va, plus les problèmes d'impedance entre Java et ce vers quoi on veut aller augmente. Et c'est encore renforcé par le JDK qui soufre exactement des mêmes symptomes.
Je n'ai jamais dit "beurk caca", la JVM est ses langages sont mon outil de travail depuis des années et c'est actuellement un excellent choix pour beaucoup de chose notamment grace à son ecosysteme, outillage et sa facilité de déployment pour des perfs honnorables.
Par contre dire que l'interop des langages sur la JVM c'est chaud bouillant ca me parait objectif. Si les gens utilisent la JVM c'est rarement pour le côté technique mais pour choper la traction de son ecosysteme afin de pouvoir percer. Et la ca demande d'avoir un langage sur la JVM et qui peut parler à du Java. Et c'est la que les ennuis commencent. Si tu es intéressé les Talks du Java Language Submit sont en ligne depuis des années. On peut aussi dire que Java est de plus en plus en boulet d'une complexité de plus en plus grande pour de faibles de gain en perf ou en sureté (pas du simple sucre syntaxique qui génére le boilerplate pour toi). De même que le JDK reste aussi pauvre conceptuellement d'année en année par rapport à d'autre plateformes.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 1.
C'est peut être pas très clair dans mon propos, mais je me fous de tes connaissances, tu pourrais être James Gosling ça ne changerait pas mon propos, ton message avait l'air de mélanger le langage et sa JVM. Ça n'indique strictement rien sur tes compétences (que je ne cherchais pas à mettre en doute).
Dis autrement tu peut être un grand cador et dans un message laisser paraître une erreur, une imprécision ou utiliser un raccourcis un peu trop rapide. La bataille du « moi je… » ne me semble pas très intéressante dans ce genre de débat.
Je le souligne parce que c'est à mon avis important sur internet de distinguer « ce que tu dis est idiot » de « t'es idiot ».
Par contre la seconde partie de ton message est très intéressante. Je pense que je vais apprendre des choses :) Merci.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pourtant la JVM défonce à peu près tout le monde niveau perfs (sauf C++), le langage s'améliore à chaque version et on a jamais eu autant de libs (le JDK on s'en fout, tout se fait via Maven). Le langage s'applique à pratiquement tous les domaines, sur toutes les plateformes et pas comme un toy language.
On peut regretter le poids de l'historique et la bloat attitude, mais quelle plateforme de dev peut aujourd'hui prétendre à ce niveau?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 5.
Je ne te parle pas de la JVM.
Si tu regardes les évolutions du langage la majorité écrivent juste le boilerplate, que tu n'aurais jamais du avoir à écrire, pour toi. Les concepts restes les mêmes on les masque juste et c'est javac qui pisse du bytecode pour toi.
Bref c'est cool on arrête d'avoir à écrire des stupidités, ca va réduire le nombre de lignes de code inutile mais des vrais progrès tu en as très peu que ce soit en expressivité, en perf ou en fiabilité. Le langage a beau être simple il est piégeur dans la vraie vie.
Maintenant la complexité d'implémentation le dev ne la voit pas. Mais si tu t'interesse un poil au travail dans OpenJDK tu verras que ca devient de plus en plus difficile pour rajouter quelque chose dans le langage. Et ca ne présage rien de bon pour l'avenir.
Pour les perfs de la JVM, c'est un excellent compromis si tu n'as pas besoin du SIMD ni d'auto-vectorisation. C'est actuellement l'un de ses plus gros points faibles par rapport à du C/C++. Tout le monde n'en a pas besoin mais quand tu tombes dessus ca fait mal. Après selon tes besoins tu vas coder en Java idiomatique ou en C-like si tu as besoin d'aller vite où d'avoir de faible latence (finance, db, big data).
Non on ne s'en fou pas. Il y a des choses qui doivent être au coeur du langage sinon elles perdent leur intêret. Si part hasard elles finissent par trouver leur chemin dans le JDK alors tu traines ce clash pendant des années.
Prenons Optional de Java 8. Java est une pourriture concernant la null-safety depuis le début.
Guava a rajouté l'Optional comme sucre syntaxique. C'est cool on peut commencer à l'utiliser, c'est toujours pas null-safe (un Optional peut être null) mais au moins c'est expressif. Si je veux l'utiliser je dois ajouter une dépendence vers Guava. Maintenant ca fait sont chemin vers le JDK. Maintenant j'ai deux implémentations concurrentes et incompatible. Si je bascule sur le JDK je pète la compat de mon projet. Si je reste sur Guava alors je vais imposer de plus en plus de conflit à mes utilisateurs. Ooops. C'est un problème très courant quand des libs font le job de ce qui devrait être dans le JDK. Et ca fini toujours en bordel crado.
Maintenant on a rajouté Optional mais comme on va pas changer l'API du JDK bin j'ai 50% des méthodes du JDK qui peuvent toujours retourner null. Donc je fini aussi avec un truc ultra-batard
C'est un exemple parmis des dizaines d'autres. De même avoir un langage expressif à la base permet d'avoir du code cohérent et fiable. Regarde les milliers de pauvres dev Java se débattre avec la composition de future et tu pleures. Ce genre de trou fait très très mal et c'est en parti un problème du langage et du JDK.
Aucune. Ne lis pas ce que je dis comme une critique bête et méchante de Java ce n'est pas le cas. Je signalais que tout n'est pas rose ainsi que les problèmes qui arrivent.
Ca fait quelques années que pas mal de gens cherchent à avancer et construire un nouveau langage sur la JVM et c'est chaud à cause de l'interop Java (autrement l'interet de la JVM diminue fortement). Pendant ce temps là on continue d'écrire les core-lib en Java comme on écrirait du C, des bindings Scala/Groovy/Whatever et on prend son mal en patience en ayant l'impression d'être toujours aussi mal chaussé et le cul entre deux chaises depuis 10-15 ans même si c'est clairement la meilleure plateforme pour beaucoup de trucs.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je ne comprends pas trop, tu me parles de complexité d'implémentation de Java en la comparant avec C++ :-)
C'est valable pour toutes les plateformes de dev… Quel est le problème spécifique à Java là dedans?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 2. Dernière modification le 27 décembre 2013 à 20:25.
Je n'ai jamais parlé de C++.
Il combine:
1- Un langage à neuneu avec 3/4 features rajoutées de manière bancale (bonjour le boxing de type primitif avec overhead mémoire de 200 à 400%, bonjour le type erasure)
2- Un JDK incomplet pour les besoins courant qui vieilli, et qui prend la flotte de partout.
Enfin si tu vois pas le problème tu vois pas le problème et comment il empire petit à petit soit heureux. Contrairement à tout les autres qui passent leur temps à s'amuser entre Java/Scala/Clojure/Groovy pour mettre un pied après les années 80.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . Évalué à 1.
Bon apres, ca depend ce que tu fais aussi.
Pour du backend de consumer web de base, le langage est certe veillot, mais c'est pas la fin du monde, et les perfs sont plutot tres bonnes.
L'ecosysteme autour aide enormement, j'ai monte une api rest sur notre backend en 15 jours recemment. Spring/jersey/jackson et j'ai un combo redoutable. Je me tape du mapping json dans tous les sens, ca va vite, c'est fiable, j'automatise le bousin avec chef tres facilement. Au final, je me retrouve avec moitie moins de VMs que ce que l'ancienne equipe .net avait, et avec de meilleurs temps de reponse et un nombre d'incidents reduits.
Les mecs qui voulaient pousser ruby sont incapables de me garantir que le format json public ne va pas changer suite a un changement innoncent de code, et l'equipe .net a toujours pas compris pourquoi du json en pascal case, ca emmerde le monde en plus de nous faire passer pour des amateurs.
Et on arrive au point ou le ruby commencerait a montrer ses probleme de perfs, et me lance pas sur son manque en multithreading (oui, je peux deployer sur des petites vm a un core, mais ca devient vite lourd).
Apres, oui, le langage a ses lourdeurs. Qu'un for(String string : list) te pete une npe a la gueule, c'est lourd. Idem avec int a = b + c, merci l'autoboxing a la con, et l'amour immodere de sun pour la philosophie "oh mon dieu! Un pointeur null! C'est la fin du monde!!".
J'ai brieffe un de mes dev objc sur cette api recemment, c'etait fun de lui dire toutes les 3 lignes "ouais, ca peut te peter une npe ca, fait gaffe". Apres, objc est le seul langage que je connaisse a etre aussi complaisant avec nil, merci le message send. Fin de la digression.
Apres, force est de constater que si tu veux faire du backend a grande echelle, ya beaucoup de chances pour qu'une evaluation objective des besoins te fasse dire "on va mettre pas mal de java la dedans".
Oui, tes data scientists vont mettre du scala, clairement tes front ends vont gueuler comme des putois (et a raison) si tu leur demande de faire du java.
Oui, java.util.Date est une blague de tres mauvais gout. Merci joda time.
Mais pour tes services, ton event bus et un paquet d'autres choses plutot critiques pour ton business, java marche bien, tres bien meme.
Ya juste trop d'historique et de boulot qui a ete accomplit en java, que ce soit dans la jvm ou l'ecosysteme pour refaire ca, et les gains seraient potentiellement limites.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je te cite:
Sinon les défauts que tu cites sont réels, mais je le répète le langage à neuneu est un avantage en entreprise et le JDK incomplet n'a aucune importance puisqu'il y a une tétrachié de libs.
?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 2.
Là c'est toi qui confond tout… Qu'HotSpot soit incapable de vectoriser du code n'a aucun rapport avec le langage ou sa complexité d'implémentation. Le mot JVM était un indice, c'est juste une limitation de toutes les JVM actuelles.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Tu pointes un certain nombre de défauts de la plateforme en faisant comme si c'était catastrophique.
Je me dis que pas vraiment, puisque Java a connu un grand succès alors qu'il était beaucoup moins bien et qu'il continue de s'améliorer tout en maintenant la compatibilité avec l'existant.
Les autres ne peuvent pas en dire autant…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par barmic . Évalué à 1.
javac fait assez peu de choses face à g++ :)
Il y a des langages où c'est pire comme le C++ avec
std::stringet lesQString(et celle de gtk etc). Le C est pas mal non plus dans le genre. python tente de ce protéger de ce genre de choses en partie par le duck typing et en partie parce qu'il essaie d'être batery included.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . Évalué à 1.
Mouais, ca se discute ca. Java pour de l'ui c'est un choix douteux quand meme, entre le gc qui va tout freezer regulierement, et donc tuer ton framerate, l'absence de blocks pour tes callbacks (les class anonymes ca va 5 minutes), l'absence d'integration au systeme et la lourdeur du langage en general, c'est tres loin d'etre mon langage de predilection.
Ah, et l'overhead en ram de java sur des telephones est loin d'etre appreciable.
C'est pas pour rien que google a forke la jvm, et meme avec le monstre de travail accompli, ca reste tres lourd et plutot pas terrible niveau perfs, meme sur les monstres que sont les telephones android. D'ailleurs, ya une raison pour laquelle l'iphone s'en sort tres bien avec la moitie de la ram des telephones android equivalent…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'utilise Java pour les jeux et il faut vraiment s'y prendre comme un manche pour avoir des freezes à cause du gc. La seule fois où j'en ai eu, c'était un bug d'openjdk 6…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Oui, ce sont des sites "out", mais ils ont eu leur moment de gloire et ont géré beaucoup de trafic utilisateur, ce qui était ta question. On parle techno, pas "mode" non ?
Quand tu regardes le "top" des technos utilisés par les sites à forte audience, tu tombes sur… PHP. No comment.
En attendant Ruby et Python sont quasiment invisible sur les sites à fort trafic, et d'après le tableau de stat que je t'ai donné en lien ci-dessous ASP.NET est devant Java dans le TOP 10000 des sites.
Non c'est ASP.NET Web API. Et franchement je vois pas ce que tu reproches à cet API, il est clean.
Ton analyse est "historique" : si le gros des évolutions architecturales ont avant tout émergées du monde Java, c'est parcque Java a un très lourd passif côté serveur web. C'est largement en train de changer. Pas au profit de .NET, au profit d'autres technos. Bref, c'est indépendant de la techno.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 3.
En meme temps ca veut pas dire grand chose par ce que dès que tu sors du petit site web, ton truc est en fait une grosse composition d'une multitude de services, souvent chacun fait dans une technos completement différente. Tu as aussi des grosses boucles d'interactions. Typiquement du front & back qui pissent du log, qui vont passer par l'analytics qui va le repasser dans une db qui va être consommée par X autres services. Chacun de ces modules à sa propre techno.
Ce qui est visible de la partie front est en général assez petit niveau fonctionnel et les contraintes de perfs sont pas lourdes (lire ca scale horizontalement linéairement et la plupart du temps est passé à attendre les autres services). Et cette partie se fait de plus en plus vampiriser par l'évolution des clients qui bouffent de l'API qui elle même n'est le fruit que d'une composition.
Bref c'est un choix technos parmis des dizaines d'autres qui se combinent et ne sont pas exclusif. Bien souvent tu vas même avoir plusieurs technos front en même temps, la tendence étant de laisser chaque équipe produit la plus indépendante possible.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 0.
Y'a rien de "rigolo". ASP.NET MVC (a ne pas confondre avec ASP.NET qui est une bouse - oui le nom a ete mal choisi), est l'equivalent Microsoft de Ruby on Rails (une copie conforme pour C#).
Pour faire une API REST, tu n'as plus la vue cote serveur, mais tu as toujours des controlleurs cote serveur ; que ca soit en Rails ou en ASP.NET MVC.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par tanguy_k (site web personnel) . Évalué à 1. Dernière modification le 28 décembre 2013 à 03:23.
(Pour info le co-createur de Stack Overflow est Joel Spolsky qui etait deja connu pour le blog Joel on Software et qui est un ancien de Microsoft.)
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Un site qui donne un aperçu des 10000 plus gros sites (me demande pas comment ils font leur stats) :
http://trends.builtwith.com/framework
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
L'API DOM ne fait pas partie de Javascript. C'est une API standardisée de manipulation de contenu XML/HTML, implémenté/implémentable dans n'importe quel langage.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Sébastien Douche . Évalué à -1.
Rappelles moi le but premier du Javascript ? Ah voila, gérer le DOM.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par dave_null (site web personnel) . Évalué à 2.
Les utilisations de JavaScript ont légèrement évolués en 15 ans. Maintenant tu peux même faire une application web toute en JavaScript sans jamais toucher à l'API DOM.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
euh… non.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par flan (site web personnel) . Évalué à 6.
Je ne suis pas du tout d'accord. On ne trouve pas ça dans tous les langages, en tout cas pas à ce niveau.
Sur wtfjs ou wtfphp, on parle de syntaxes qui ne font pas ce à quoi on pourrait logiquement s'attendre, ou qu'on ne peut pas prédire à la seule vue du code avant d'être déjà tombé sur ce cas pathologique.
Au contraire, les trucs cités sur Python sont soit liés à la transition Python 2 -> Python 3 (dont le but est justement d'éliminer les bêtises de Python 2, donc, oui, il y a des incompatibilités), soit des trucs et astuces pour améliorer un code fonctionnel ; autrement dit, le code écrit fait bien ce qui est attendu, mais on peut faire plus efficace.
Exemple de ce que tu cites sur stackoverflow :
Les deux sont facilement compréhensibles, et font bien ce qui est attendu. Rien à voir avec ce qu'on trouve avec JS, où [,,,] est compris comme [,,],
isFinite('42'); // true
isFinite('hi'); // false
…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par flan (site web personnel) . Évalué à 8.
C'est pourtant un élément de réponse. Avoir un langage qui pousse à l'erreur, qui ne permet pas beaucoup de vérifications statiques, qui n'a pas de systèmes de classes simples (et quand je suis tombé sur des explications sur le prototypage, c'était pour expliquer comment retrouver un truc utilisable en émulant un système de classes…), ça ne facilite pas la création de codes conséquents et maintenables.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . Évalué à 7.
Mouais, ca veut un peu rien dire ca. Toutes les applis sont "inherentement" dynamiques, c'est un peu la definition d'un programme d'etre dynamique, ca veut pas dire qu'on fout du dynamique partout.
Moi aussi je fais des choses super dynamiques toute la journee, et je les exprime de facon "statique" en objc (si tant est "qu'exprimer de facon statique" veuille dire quelque chose).
Mouais, si je voulais faire comme en java/c++, je ferais du java/c++, tout simplement, tu fais justement un argument contre le javascript la.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . Évalué à 6. Dernière modification le 24 décembre 2013 à 00:06.
http://highscalability.com/blog/2013/3/20/dart-is-it-the-future-of-the-web.html
https://gist.github.com/paulmillr/1208618
(je me fiche de Dart mais ca me semble etre plus ce que tu attends)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . Évalué à 9.
La version courte: parce que js a atteint son pic de performance, et que les ameliorations a venir sont essentiellement hardware, ou alors une rupture forte avec le langage (asm.js, dart et autres). Parce que les ameliorations hard donnent assez peu d'espoir que ca s'ameliore beaucoup sous peu.
Parce que l'avenir est dans les devices mobiles, ou js performe comme une merde, et parce que la consommation d'energie (et donc les perfs indirectement) est plus importante que le confort du developeur et la resistance au changement de certains.
La version longue est la
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 24 décembre 2013 à 13:45.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Ça dépend du programmeur… Je suis 42 fois plus productif en C++ qu'en javascript pourtant le premier est aussi dynamique qu'un bloc de béton.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Narmer . Évalué à 0.
Ah, Je comprends maintenant pourquoi tu es aussi résistant !
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . Évalué à 8.
Mon point sur le hardware visait surtout a dire qu'en l'etat de la spec, les gains de perf vont venir essentiellement du matos, pas du soft.
Le langage est a son pic de perf, et c'est pas joyeux joyeux dans le monde mobile, js performe aussi bien sur un 4s (pas degueux niveau hard tout de meme) que sur ie8/x86. Avec assez peu d'espoir de gains de performance (je serais surpris que meme l'a7 qui poutre tout change grand chose a ce niveau la). En clair: js a fait un bond de geant en 2008-2010 parce que les implementations etaient tres naives, mais maintenant c'est "about as good as it gets".
Ensuite, sur l'evolution du langage, c'est pas aussi simple que ca.
Le cote prototype est un gros probleme de perfs. eval de meme. Le modele memoire est totalement non specifie, il faudrait faire le menage la dedans, mais ca va pas plaire a tout le monde, forcemment.
Au final, tu te retrouves avec une hydre a 3 tetes (quelqu'un a dit c++?) qui est un enfer a maintenir pour les developeurs de vm, et ou des trucs tout con et parfaitement, valides, genre importer une autre classe, vont ruiner tes perfs parce que les optimisaitons ne sont plus possible.
Ou alors tu fais une v2 qui pete la compatibilite, mais a ce compte la, est ce toujours javascript et pourquoi ne pas repartir sur de bases saines d'emblee?
Tu te retrouves dans un situation a la con, ou t'as pas de bonne solution, tu perds sur tous les tableaux. Partant de la, et sachant que js a un certain nombre de tares que beaucoup aimerait corriger, l'argument du "on remet tout a plat et on recommence" se tient. C'est un boulot titanesque, certes, mais ca tombe bien, c'est des titans qui s'en occupent.
Bon apres, a ta decharge, c'est google, et ca les arrangerais bien de pouvoir tirer le web vers eux, donc c'est parfaitement possible qu'ils poussent ca pour emmerder la concurrence.
Perso j'ai tendance a penser que la solution a ce probleme est de pas faire d'applis webs super riches (etonnant venant d'un developeur natif, hein?)
Si les perfs sont une contrainte, fait du natif, et distribue le via les stores de la plateforme. L'auto update que quasi tous proposent amenuise les problemes de distibution, ca performe bien, tu peux t'integret proprement a la plateforme et ca evite la valse bi annuelle des frameworks javascript.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Yakulu . Évalué à 2.
Au sujet de la performance : la réponse de Sencha (même chose en vidéo), que l'on sait fortement impliqué dans les technologies JavaScript/HTML, essaie d'argumenter le contraire.
En résumé, selon eux :
À propos du pic de performance pour JavaScript seul, Are We Fast Yet, de Mozilla, qui est lui aussi un acteur très impliqué, semble montrer que sur l'année dernière, tant leur moteur que v8 de Google continuent de s'améliorer (de l'ordre de 30% en un an selon le test et le moteur, ce qui n'est pas négligeable).
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Sébastien Douche . Évalué à -8.
Plonk.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le typage statique?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par Dr BG . Évalué à 3.
En fait, Dart n'est pas typé statiquement, le typage est optionnel. Ces donc un langage dynamique, mais les auteurs pensent qu'il est pratique de mettre des types (pour les humains et les machines) :
https://www.dartlang.org/articles/optional-types/
https://www.dartlang.org/articles/why-dart-types/
# Ne pas être implémenté ailleurs
Posté par barmic . Évalué à 10.
Si le processus de normalisation se concrétise et que Mozilla refuse d'y passer ce sera pour moi une grosse déception de la part de Mozilla. Quand on lis un peu plus loin dans son post :
Alors que asm.js présente les même problématiques (du code optimisé très finement pour un moteur *monkey ne l'est pas forcément pour les autres ou pas dans les même proportions), ça montre pour moi que Mozilla¹ veut se lancer dans une nouvelle guerre sur le web asm.js vs dart vs … Ça ne me semble pas être bénéfique à l'internaute.
[1] on voit d'ailleurs que Tristan Nitot alimente le FUD sur dart dans son dernier billet de blog, En vrac du mardi, spécial parano.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne pas être implémenté ailleurs
Posté par etenil . Évalué à 10.
Asm.js n'a pas grand chose à voir avec Dart. Comme tu l'a dit, il s'agit d'un effort d'optimisation alors que Dart est un langage à part entière.
Je pense que Mozilla est satisfait de javascript au contraire des autres et qu'ils ne voient pas d'intérêt à changer de langage.
Mes deux sous.
[^] # Re: Ne pas être implémenté ailleurs
Posté par barmic . Évalué à 5.
C'est un js-like. Utiliser asm.js sur autre chose qu'un moteur monkey¹ c'est aussi intéressant que d'utiliser dart via dart2js, c'est une dégradation de l'application pour essayer de faire de la compatibilité. D'un coté on dira que le site est optimisé pour firefox et de l'autre on dira que le site est optimisé pour v8².
Qu'on appel cela comme on veut je m'en fou, le problème est le même.
C'est de la langue de bois quand on explique que pour faire des choses évoluées il faut utiliser du C++ et le compiler vers du js via emscripten. Sincèrement asm.js est un gros hack de js qui essaie tant bien que mal d'ajouter ce que js n'a pas de base : la sémantique suffisante pour faire de js quelque chose de performant.
[1] : je n'ai pas regardé la spéc d'ASM.js (ni comment fonctionne le monkey actuel et v8) pour savoir si celle-ci n'est pas trop liée au fonctionnement interne de monkey et resterait difficilement portable sur un autre interpréteur.
[2] : d'ailleurs c'est assez marrant si Mozilla fait quelque chose seule ça sera supporté par Firefox et Thunderbird. Alors que si Google ajoute quelque chose dans v8 ce sera réutilisable partout. C'est tout de même pas mal de penser les briques logiciels comme des bibliothèques réutilisables.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne pas être implémenté ailleurs
Posté par flan (site web personnel) . Évalué à 9.
Si Google ajoute quelque chose dans v8… ça sera utilisable dans les projets utilisant v8.
Si Mozilla ajoute quelque chose dans *Monkey… ça sera utilisable dans les projets utilisant *Monkey.
Je ne vois pas tellement la différence, à vrai dire.
[^] # Re: Ne pas être implémenté ailleurs
Posté par barmic . Évalué à 7. Dernière modification le 23 décembre 2013 à 22:27.
C'est à dire dans les logiciels Mozilla et les ex-logiciels Mozilla.
Monkey n'est pas utilisable ailleurs que dans les projets Mozilla. Il n'est pas pensé comme un produit n'a pas une API stable (comme gecko hein). Ils ont essayé à une époque de rendre ça utilisable (à l'époque où XUL était censé devenir une technologie à part entière), mais ça n'a pas duré et tous les projets qui utilisaient gecko/monkey (sauf Seymonkey) sont passé à webkit/v8 parce qu'ils n'ont pas à avoir 2 versions de retard à cause de l'API qui à changée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ne pas être implémenté ailleurs
Posté par programLyrique . Évalué à 5.
Le jeu 0ad utilise Spidermonkey, par exemple.
[^] # Re: Ne pas être implémenté ailleurs
Posté par etenil . Évalué à 3.
Ça c'est intéressant. Je croyais pourtant qu'il n'était pas possible de dissocier le moteur javascript du reste de l'environnement mozilla. Il faudra que je zieute.
# Quelques commentaires
Posté par Sébastien Douche . Évalué à 10. Dernière modification le 23 décembre 2013 à 18:46.
L'équipe de Blink a évolué le temps passer dans v8 lors de la navigation de sites web. En général, cela va de 0 à 20%. Sur des sites Google, c'est plutôt de 20 à 40%. Google est un gros utilisateur de Javascript (directement ou indirectement avec GWT), et c'est pour l'équipe Dart un très bon panel d'applications.
Il a aussi dit que la complexité du moteur v8 commence à poser soucis car il dépasse le 1/2 millions de SLOC et qu'ils galèrent pas mal pour gagner de nouvelle perf.
Un langage bien plus adapté, c'est une nouvelle sémantique, pas juste une surcouche.
Il faut d'abord comprendre le business-model de Google pour comprendre la création de Dart. Contrairement à Facebook, Ms ou Apple qui se foutent royalement du Net du moment que vous utilisez leurs produits et services, Google doit s'appuyer sur un Net rapide et fonctionnel. C'est la raison des financements des projets OSS, des CDN, des apifonts, de NaCI, de http2 / SPDY, etc. Google gagne de l'argent quand le Net fonctionne car 90% de leur CA vient de la pub.
Une fois compris cela, c'est facile de voir que c'est dans l'intérêt de Google d'unifier le Web autour d'un langage puissant et qui permet d'aller bien plus vite.
Le créateur de la plus grosse bouse (marrant d'ailleurs qui soit devenu CTO). Si chrome n'avait pas torché Firefox à sa sortie, ce dernier se contenterai de la vitesse qu'il avait. C'est Google qui a lancé la course à la vitesse et qui permet maintenant d'avoir des sites aussi riches (v8 va 600x plus vite que Chrome 1.0). Bref Mozilla me souvent sourire. Des grandes déclarations mais j'ai du mal a voir les améliorations qu'ils apportent de décisif (et me dites pas un browser Libre, un autre aurait pris sa place. Y'en avait une dizaine début 2000).
Je n'aime pas plus Google que toi, mais leurs contributions sont de loin bien supérieures aux autres et je ne crache pas dessus. Pour le reste, je les mets dans le mec sac que MS, Facebook et autres.
[^] # Re: Quelques commentaires
Posté par tanguy_k (site web personnel) . Évalué à 10.
Je suis d'accord sur tout le reste de ton post en revanche je ne pense pas que l'on puisse reprocher a Brendan Eich la creation de JavaScript : il faut se remettre dans le contexte de l'epoque. Le langage a ete cree en quelques jours seulement.
D'autres personnes supposément plus competentes n'auraient probablement pas fait mieux vue les contraintes et les connaissances de l'epoque. Personne n'aurait imagine en 1995 que JavaScript allait prendre une telle ampleur 10 ans plus tard.
[^] # Re: Quelques commentaires
Posté par Antoine . Évalué à -4.
Quelqu'un avec un minimum d'éthique professionnelle aurait pu refuser en disant "désolé, on ne crée pas un langage de programmation en quelques jours". D'autant que le besoin, justement, n'était pas criant à l'époque (il me semble). M'enfin bon…
[^] # Re: Quelques commentaires
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Dans la vraie vie, il y a la théorie et la pratique. refuser en disant "désolé, on ne créé pas un langage de programmation en quelques jours" ça serait typique du puriste qui dit "non, je ne veux pas utiliser un ordinateur si on n'a pas 100% de logiciel libre"… Heureusement que certains sont plus enclins au compromis (même s'il est import qu'il y ait des puristes).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Quelques commentaires
Posté par barmic . Évalué à 5.
C'est tout de même le boulot du développeur d'expliquer clairement qu'on est entrain de faire de la merde. Et continuer de s'y attacher 20 ans après ça donne surtout l'impression qu'ils ont tellement investi dedans qu'ils résistent au changement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques commentaires
Posté par claudex . Évalué à 7.
Tu dis que c'est de la résistance au changement mais il ne s'agit pas que de changement. JavaScript ne va pas disparaitre du jour au lendemain, ça veut donc dire deux machines virtuelles différentes à maintenir, ce qui est un cout énorme, et je ne pense pas que Mozilla peut se le permettre. Surtout que c'est un cout risqué. Si Microsoft et Apple ne suivent pas, ça veut dire que le développement de la VM Dart n'aura servit à rien.
Quand tout le monde utilisera Dart sauf Mozilla, on pourra dire qu'ils font de la résistance au changement, en attendant, même Google ne le propose pas dans son navigateur.
asm.js est est un hack, mais au moins, il fonctionne avec l'existant, ne demande pas de doubler les cout de maintenance et est inclus par défaut dans Firefox.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques commentaires
Posté par barmic . Évalué à 4.
Ce qu'ils disent, c'est « nous ne le supporteront jamais ». Je dis si c'est un standard et qu'ils ne le supportent pas c'est que ce sont des arrogants incapables de vraiment se remettre en cause.
Le coût on s'en tamponne il est tout à fait possible de faire comme V8 et d'utiliser un moteur réutilisable entre les différents navigateurs et les frameworks comme Qt et GTK.
Pour le moment il est pas fini d'être spécifier, mais non il fonctionne avec spidermonkey et spidermonkey est développé avec asm.js en tête. Donc d'une part si son coût est faible il n'en est pas moins nul, d'autre part… serieux quand c'est qu'on va arrêter de faire des gros hack bien moche en informatique parce que l'inertie est trop grande, parce que les gens sont habitués ou parce qu'on a pas envie de se bouger les fesses ? On en a pleins et on passe notre temps à expliquer que l'avantage du libre c'est qu'on essaie de faire les choses bien, plutôt que d'être hyper-pragmatique en regardant tout par l'aspect purement économique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques commentaires
Posté par claudex . Évalué à 3.
Ce n'est pas du tout un cout nul. Déjà, il y a une couche d'adaptation à faire, mais c'est vrai que c'est peu élevé. Mais le gros cout (qui ne concerne quasiment aucun des navigateurs reprenant V8, c'est la sécurité. Si on trouve une faille dans la version de V8 qu'un soft utilisé par très peu de monde, ce n'est pas grave. Si ça arrive avec Firefox, ils doivent réagir très vite, soit en patchant la version qu'ils utilisent et ça demande du monde qui connait la VM soit en mettant à jour peut-être en milieu de cycle. Et, ça, c'est le scénario où la faille est déjà patchée en amont, s'ils doivent corriger eux-même, ça demande encore plus de ressource.
Quand faire autre chose que le hack résoudra vraiment le problème plutôt d'ajouter d'autre problème sans résoudre le problème initial. Sans compter que la plus grosse partie (voire tout) d'asm.js pourrait tout à fait être implémenter proprement dans une future norme de JavaScript.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques commentaires
Posté par barmic . Évalué à 6.
En vrai dans la vrai vie. V8 est largement plus utilisé que spidermonkey et je présume qu'il a bien plus de contributeur.
C'est quoi le problème exactement ?
ou
Ce qu'on voit c'est qu'après 5 ans on arrive à un palier et tout le monde fait des pieds et des main pour arriver à contourner ce palier parce qu'on ne pourra pas faire autrement (vu l'investissement mis sur l'accélération du JS s'il n'a pas était trouvé c'est que ça n'est pas possible dans l'état actuel de nos connaissance).
Donc il faut réécrire les applications actuellement en JS dans un autre langage (actuellement le C++) pour les compiler de nouveau vers JS, non on est pas entrain de marcher sur la tête, mais alors pas du tout.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques commentaires
Posté par claudex . Évalué à 4.
Et ?
Tu simplifie beaucoup trop le problème, évidemment si les ressources le permettaient, ça dérangerait beaucoup moins de monde d'avoir plusieurs VM dans les navigateurs. Seulement, en vrai, dans la vraie vie, les ressources sont limitées et il faut tenir compte de l'existant.
La solution, ce sont les types, c'est tout à fait possible avec une évolution du langage, c'est ce que montre asm.js qui est bien plus rapide dans Firefox et Chrome (qui utilise les types d'asm.js dans V8 pour tenir compte des optimisations possibles).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques commentaires
Posté par zebra3 . Évalué à 2.
Ben tu dis au dessus en substance que si on trouve une faille dans la dernière version de V8 c'est pas grave, mais dans Firefox c'est grave, ce qui n'est plus vrai du tout si Michel a raison.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Quelques commentaires
Posté par claudex . Évalué à 4.
Ce n'est pas du tout ce que j'ai dit. J'ai dit que si on trouve une faille dans V8, un petit projet (pas Chrome) qui l'utilise n'a pas vraiment besoin de mettre à jour dans les jours qui viennent. Par contre, Firefox, vu le nombre d'utilisateur, a intérêt à réagir très vite. Et il y a deux choix, soit il y a patch upstream pour la faille, soit il y en a pas (parce qu'elle n'impacte pas Chrome, parce qu'elle corrigée dans la 3.13 mais Firefox utilise la 3.11…). S'il n'y en a pas, Mozilla a intérêt à avoir des équipes prêtes qui connaissent V8 pour pouvoir la corriger dans la version actuellement utilisée. Donc l'intégration d'un moteur externe n'est pas du tout à cout nul.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques commentaires
Posté par barmic . Évalué à 1.
Ça réduit fortement le coût parce que tu as moins de R&D à faire dessus et parce que tu as potentiellement largement plus de contributeurs. Regarde comme opera baisse ses coûts en passant à Webkit/Blink.
Au passage ça permet de contribuer à la sacro sainte expansion du web dont Mozilla se targue tant en permettant à tout un chacun de facilement utiliser ces technos.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques commentaires
Posté par flagos . Évalué à 2.
Oui enfin asm.JS a toujours été présenté comme un moyen de réutiliser les codes existants en c++ en mode webapp (avec portabilité du bousin). Notamment pour les jeux vidéos où on ne réécrit tout chaque matin parce que l'envie nous pète.
Et la bonne surprise, c'est que les performances sont au rendez vous.
Ca n'a rien a voir avec Dart qui s'adresse aux applis légères ayant vocation à être écrites from scratch.
[^] # Re: Quelques commentaires
Posté par Maclag . Évalué à 7.
Avec le même raisonnement, il faut arrêter Wayland de suite, et toute modification un tant soit peu révolutionnaire, parce que la transition est toujours douloureuse.
[^] # Re: Quelques commentaires
Posté par claudex . Évalué à 3.
Alors là, je ne vois pas bien le rapprochement. Wayland vient avec XWayland qui permet justement une transition en douceur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelques commentaires
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques commentaires
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
C'est son boulot de dire qu'on fait de la merde. Le fait est que ce n'est probablement "pas tant de la merde que ça" vu comme ça a été accueilli et comme c'est désormais utilisé. Dans les très bons langages, il y a Eiffel. Excellent langage… mais pas du tout utilisé.
L'argument de la durée n'a pas de sens :
- le C++, par exemple, certains le vantent encore et à juste titre
- si la nouvelle techno n'apporte qu'un peu d'amélioration (par rapport à "recoder" 20 ans de dév), c'est pertinent de résister au changement.
Maintenant, là, j'en sais rien si Dart c'est la super techno révolutionnaire par rapport à JS. Mais si tu mises sur une techno donnée (c'est le cas de Mozilla, notamment avec ses téléphones mobiles), c'est cohérent de la défendre (pertinent, c'est une autre histoire).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Quelques commentaires
Posté par Antoine . Évalué à 5. Dernière modification le 24 décembre 2013 à 11:40.
Accueilli ? Je ne me souviens pas que Javascript ait été accueilli avec des cris d'enthousiasme. En plus, à l'époque ça ne servait à rien à part afficher quelques effets kikoolol.
Après, les utilisateurs font avec ce qu'ils ont : si le seul langage pour coder côté client est Javascript, ils vont utiliser Javascript…
[^] # Re: Quelques commentaires
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 6.
Beaucoup de gens étaient content de faire des effets kikoolol.
Pour faire des appli web dynamiques, il y avait Javascript, il y avait Flash, il y avait les applets Java et Java web start, il y avait Silverlight ; il se trouve que la techno la plus facile à mettre en oeuvre et à déployer / utiliser était Javascript. C'est comme ça.
Si tu avais une meilleure idée, il ne fallait pas hésiter à la développer et la mettre en oeuvre . Reste qu'après 20 ans, si Javascript est LA techno qui a su s'imposer, c'est parce qu'elle convenait le mieux (peut-être pas "bien", mais "mieux" que les autres) aux besoins des utilisateurs.
Je précise que je n'aime pas spécialement Javascript, mais faut arrêter de croire qu'on détient la vérité et que nos prédécesseurs sont des ânes.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Quelques commentaires
Posté par barmic . Évalué à 4.
Ça tombe bien, la dépêche parle justement de personnes qui sont entrain de le faire et d'en discuter.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques commentaires
Posté par Antoine . Évalué à 4.
En 1996 ? On n'a pas dû aller sur les mêmes sites Web.
Quel est le rapport avec la qualité de Javascript en tant que langage ?
[^] # Re: Quelques commentaires
Posté par Dr BG . Évalué à 2.
Surtout qu'ActionScript (Flash), c'est comme JavaScript, mais en mieux.
[^] # Re: Quelques commentaires
Posté par CrEv (site web personnel) . Évalué à 2.
surtout que les deux sont simplement des implémentations de différentes versions d'ecmascript
[^] # Re: Quelques commentaires
Posté par barmic . Évalué à 3.
Faire un langage en quelques jours c'est faire de la merde. Il a était bien accueilli parce qu'il est le seul a répondre à un besoin. Je n'ai pas dis qu'il était dénué de qualité, juste que quand on fait un truc à l'arrache on fait de la merde.
L'argument ce n'est pas qu'il est vieux, mais que c'est un truc fait à l'arrache et qu'on refuse de le mettre en concurrence avec quelque chose d'un peu repensé.
Pour moi c'est clair. On est à l'aube d'une nouvelle guerre sur le web au sujet de l'évolution du langage web client. Je suis pas certains que ce soit très bénéfique pour les développeurs et les utilisateurs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quelques commentaires
Posté par reno . Évalué à 2.
Covariance vs contra-variance? Désolé, je n'ai pas pu résister ;-)
Sinon note qu'à ses débuts, les compilateurs Eiffel mettaient à genoux les PC de l'époque, ça n'aide pas pour l'adoption et les étiquettes durent plus longtemps que le matériel..
[^] # Re: Quelques commentaires
Posté par Antoine . Évalué à 3.
Un compromis qui est garanti d'aboutir à de la merde en boîte ? Drôle d'éthique professionnelle. Et c'est parce que des développeurs sont trop lâches pour refuser que le paysage de l'informatique professionnelle est si sinistré…
(mais bien sûr « c'est-la-faute-aux-marketeux », disent-ils ; car c'est toujours la faute des autres et jamais de soi-même)
[^] # Re: Quelques commentaires
Posté par rewind (Mastodon) . Évalué à 6.
Zenitram, sors de ce corps !
[^] # Re: Quelques commentaires
Posté par Antoine . Évalué à 6.
Pas mal, hein ? :)
[^] # Re: Quelques commentaires
Posté par claudex . Évalué à 10.
Tu n'as jamais créé un truc vite fait parce que c'est censé être qu'un détail pas primordial pour te rendre compte que c'est beaucoup plus utilisé que prévu (parce que les usages changent, parce que tu avais mal compris, parce qu'on t'avait dit l'inverse…) ? Et le besoin était quand même là, on voulait un truc qui permettent de facilement ajouter un peu de dynamique côté client sans avoir à tout écrire dans un applet Java.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quelques commentaires
Posté par fmaz fmaz . Évalué à 2.
Sauf erreur, javascript a fortement été influencé par self.
[^] # Re: Quelques commentaires
Posté par Dinosaure (site web personnel) . Évalué à 1.
Pour peu que tu baignes dans le milieu de la compilation et ayant connaissance des outils qui te génèrent du code d'analyse lexicale et syntaxique, faire un langage se compte en jour. Bien entendu, cela se limitera sûrement à un interpréteur, à ce qu'il n'y est pas d'optimisations et, à ce que les problématiques de sémantique qu'on retrouve dans le JavaScript soient rognés de manière empirique.
Vu le langage et vu le personnage, c'est tout à fait plausible que JavaScript ait été fait en 2-3 jours.
[^] # Re: Quelques commentaires
Posté par Maclag . Évalué à 6.
Tu dois changer souvent de boulot, parce que dans la plupart des boites "non, on ne fait pas ça", ça se termine par "je demanderai à quelqu'un d'autre".
Si tu assumes jusqu'au bout, il ne te reste qu'à plier bagages. C'est ça aussi la vie.
Ça ne veut pas dire que je soutiens la position de Mozilla dessus face à Dart.
[^] # Re: Quelques commentaires
Posté par Antoine . Évalué à 3.
Ben oui, c'est ça la vie. On essaie d'être fidèle à des principes ou on s'assoit dessus.
Mais c'est vrai que l'informaticien travaillant dans la Silicon Valley est un des grands défavorisés de l'ère moderne, il doit sans cesse se ravaler et s'avilir pour se hisser au-dessus de la pauvreté la plus noire… si en plus on se permet de critiquer ses choix éthiques !
[^] # Re: Quelques commentaires
Posté par Sébastien Douche . Évalué à 8.
On ne créé pas un langage en quelques jours. On se moque sufisamment des SSII et des gros éditeurs qui sortent des trucs non testés pour ne pas me gêner pour rappeler à Mozilla (beaucoup sont des anciens de Netscape, et pas les moins bien placés) qu'ils ont développés cette daube. Et au lieu de saluer toute initiative d'amélioration, sa réaction est de dire "on ne le fera jamais" comme un gamin capricieux.
Depuis 7 ans, Google améliore le Web. Et en plus, tout est normalisé W3C (Shadow Dom, Mutation Observers, http2…) ou en cours de l'être comme Dart. Tous les projets sont Libres. On peut les attaquer sur beaucoup de points (vie privée, monopole sur la pub, fonctionnement du moteur de recehrche…) mais pas celui de se bouger le cul pour faire avancer les choses.
[^] # Re: Quelques commentaires
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 24 décembre 2013 à 08:33.
C'est exactement ce qu'a fait Brendan Eich… avec des moyens probablement plus modestes que ceux dont disposent les équipes R&D de Google…
Note au passage que tous les projets Google ne sont pas libres ; qu'ils tentent de fermer régulièrement des choses - leur API Caldav, par exemple, même si au final ils ont renoncé face aux protestations.
Enfin, pour ce qui est de se bouger le cul pour faire avancer le web, cela me semble assez logique qu'une boîte dont le crédo est de gagner un maximum d'argent améliore ses outils de génération de revenu ; il se trouve que le web en est le principal vecteur et que libérer des technologies est un des moyens stratégiques les plus efficaces pour assurer son adoption avec un moindre effort.
Pour caricaturer, c'est un peu comme si tu comparais l'amélioration des outils de gestion locative mis en œuvre par Foncia ou par l'office HLM. Buts différents = moyens différents.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Bien mais pas top?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Dart est très intéressant, mais il manque clairement des fritures orientées perf:
En tout cas l'approche est beaucoup propre que asm.js.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bien mais pas top?
Posté par etenil . Évalué à 1.
Personnellement j'attends de voir arriver des compilos de langages sympa vers asm.js. Ça pourra devenir le bytecode du web et contenter les déçus de javascript.
[^] # Re: Bien mais pas top?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est bien le problème: bytecode illisible versus vrai langage.
Bizarrement Mozilla ne pousse pas la solution la plus ouverte.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bien mais pas top?
Posté par flagos . Évalué à 10. Dernière modification le 23 décembre 2013 à 22:32.
Oui enfin une fois que ton JavaScript est minifie, je vois pas vraiment en quoi il est plus lisible qu'un bytecode.
[^] # Re: Bien mais pas top?
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Tu confonds minification et obfuscation (comment on dit en bon français?), non?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bien mais pas top?
Posté par Antoine . Évalué à 4.
Heu… Tu as déjà vu du Javascript minifié ?
Un indice : http://code.jquery.com/jquery-2.0.3.min.js
Le code original non minifié : http://code.jquery.com/jquery-2.0.3.js
[^] # Re: Bien mais pas top?
Posté par mael . Évalué à 1.
En javascript, minifier, c'est obfusquer.
[^] # Re: Bien mais pas top?
Posté par N4th4 . Évalué à 1.
En minifiant, tu perds les commentaires mais tu peux toujours utiliser un outil de formatage de code pour le rendre à nouveau lisible.
En obfuscant, là, tu perds les noms des variables et des fonctions et ça devient impossible à comprendre.
[^] # Re: Bien mais pas top?
Posté par claudex . Évalué à 6.
Minifier, ça veut aussi dire réduire le nom des variables non globales, ça réduit beaucoup la lisibilité. C'est autant lisible que du C décompilé avec le fichier de header.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bien mais pas top?
Posté par mael . Évalué à 1.
Non. Si tu minifies ton javascript, tu essaies de faire en sorte que la minification soit la plus efficace.
Et minifier efficacement du javascript, ce n'est pas seulement supprimer les commentaire et les espaces inutiles, c'est aussi changer les noms de variables (donc obfusquer). Le gain est tellement énorme que se contenter d'enlever les commentaires et les espaces est tout bonnement idiot.
Quasiment toutes les librairies libres écrites en javascript te proposeront le téléchargement d'une version minifiée, et le code ne sera pas lisible, même si tu le formates. Ils ne le font pas pour s'amuser, mais parce que c'est efficace.
[^] # Re: Bien mais pas top?
Posté par CrEv (site web personnel) . Évalué à 0.
Non.
La différence entre minifier est obfusquer est simpler. Obfusquer c'est volontairement rendre illisible. Minifier c'est volontairement dans un but de performance. Après aujourd'hui quasiment plus personne ne minifie (enfin je crois) mais la plupart du temps c'est de la compilation javascript vers javascript. Et l'un des meilleurs exemple est Google Closure compiler qui permet de faire des trucs vraiment bien genre inline de méthodes, suppression de code mort, etc.
[^] # Re: Bien mais pas top?
Posté par mael . Évalué à 2.
Mouais. L'intention est peut-être différente, mais le résultat est exactement le même.
Et aujourd'hui, on parle de "minifier" le javascript dès lors qu'il s'agit de réduire sa taille que ça soit en supprimant les espaces ou en renommant les variables.
[^] # Re: Bien mais pas top?
Posté par tanguy_k (site web personnel) . Évalué à 0.
L'utilisation de asm.js implique une etape supplementaire : la compilation.
Avec le langage Dart et la Dart VM, il n'y a pas cette etape (au moins durant l'etape de developpement).
C'est aussi l'un des avantages de Dart par rapport a CoffeeScript et TypeScript grace a Dartium.
Cf http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/
Native Client (NaCl) de Google a le meme objectif que asm.js
Conclusion : il faut les deux, un langage fait pour le developpement web "natif" et un systeme qui permet de compiler n'importe quoi vers le web.
[^] # Re: Bien mais pas top?
Posté par barmic . Évalué à 2.
Je ne vois pas pourquoi il faut les 2. L'objectif c'est de pouvoir créer des applications véloces sur navigateur. NaCl/ASM.js posent un gros problème de debugging à cause de cette phase de compilation (bon ensuite le premier pose des problèmes de sécurité, le second est un gros hack).
Je ne suis pas certain de voir l'intérêt de porter du code existant du C/C++ vers le web.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bien mais pas top?
Posté par tanguy_k (site web personnel) . Évalué à 1.
C'est pourtant clair, d'apres Lars Bak :
- "L'utilisation de asm.js implique une etape supplementaire : la compilation" cf le post auquel tu reponds
- une VM generique n'est pas aussi performante qu'une VM specifique
Non c'est faux, il n'y a aucun probleme de debugging. C'est le meme principe que debugguer du C/C++ compilé en binaire. Pareil pour CoffeeScript, TypeScript, dart2js : il y a les source maps pour ca.
idem, ca sera surement un usage bien specifique et non majoritaire.
[^] # Re: Bien mais pas top?
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Et pourtant il y en a. Zenitram< voulait une version en ligne de son bébé car c'est plus simple à utiliser qu'un client natif où il faut avoir l'autorisation de l'admin réseau pour faire l'installation. Sauf que le logiciel existant prendrait trop de temps à réécrire.
Si en plus on peut profiter d'une syntaxe de javascript obscure mais qui permet d'avoir des perfs bien plus proches du C que d'autre chose, c'est tout bénèf. Dommage que emscripten ne soit pas mature.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Bien mais pas top?
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Avoir une version en ligne de son bébé, ça augmente le nombre de couches, ça le rend plus vulnérable aux virus et en plus on l'entend moins crier (avantage ou inconvénient suivant les cas). À mon avis c'était lui l'admin réseau à domicile, donc il n'a pas eu à demander une autorisation pour installer le bébé.
[^] # Re: Bien mais pas top?
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Je ne comprends pas ton commentaire. Notamment le lien entre "Zenitram est son propre admin à domicile" et "il existe des politiques d'administration nazies dans des entreprises qui empêchent d'installer ce qu'on veut", parce que les potentiels clients ne sont pas en train de travailler chez Zenitram.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Bien mais pas top?
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 25 décembre 2013 à 11:24.
Oui, mais je ne suis pas l'admin réseau de la planète entière (lieu de mes utilisateurs). Et Zarmakuizz ne parle pas de moi (moi je sais faire!) mais de mes utilisateurs.
Je déteste cette idée de tout mettre dans un navigateur, d'avoir le droit qu'à JS (j'aimais bien l'idée de Chrome NaCl comme équivalent à ce qu'on peu avoir sur Android et iOS avec un bac à sable, mais ça a l'air de partir aux oubliettes), mais voila, c'st un constat : pour toucher les utilisateurs sur le desktop, aujourd'hui une version JS st très utile. Alors bon, on fait avec (l'idée est de répondre aux besoins des autres, pas suivant mon environnement mais suivant le leurs)
Donne moi une meilleure réelle (non théorique) solution, et je la prend. Ca sert à rien de faire des grandes théorie, ici c'est la réalité qui compte.
[^] # Re: Bien mais pas top?
Posté par Zenitram (site web personnel) . Évalué à 2.
Pas d'amélioration en 1 an? (oui, la honte, le projet est en pause pour le moment)
[^] # Re: Bien mais pas top?
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
dave_null a testé récemment, pour gérer des listes avec la syntaxe C++ plutôt qu'en utilisant une barbouze javascript (je résume très grossièrement). On a pu discuter, et malgré l'ajout d'asm.js et quelques debugs parci parlà, on peut repasser plus tard ! (Ou contribuer, comme dirait Yaka le faucon.)
D'après l'historique des commits, il y a un contributeur principal et quelques coups de mains isolés dans le temps.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Bien mais pas top?
Posté par barmic . Évalué à 1.
Ça n'explique pas le besoin de NaCl/ASM.js. Ça sert à quoi ? En quoi dart ou un autre langage performant coté client ne suffit pas ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bien mais pas top?
Posté par claudex . Évalué à 2.
Tu mélange deux chose, le besoin principal d'asm.js , c'est la performance avec la compatibilité avec l'existant. Tandis que NaCl, c'est la performance pure (pas de GC, quasiment pas de compilation côté client…)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bien mais pas top?
Posté par barmic . Évalué à 4.
Donc on empile des dizaines de langages qui n'ont pas exactement le même objectif (on va en trouver pour la compatibilité avec les langages dynamique et un autre pour la compatibilité avec les langages statiques etc), juste histoire de pourrir le développement web une bonne fois pour toute ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bien mais pas top?
Posté par fredix . Évalué à 9.
Le développement web est déjà pourri par l'idée que l'on doit faire des applications web équivalentes aux applications natives … Tout découle de cela.
Le dev web est une suite de hack sans nom et l'on doit maitriser 3 tonnes de technos pour arriver à un ersatz d'app native que l'on fera simplement en Qt par exemple.
[^] # Re: Bien mais pas top?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 24 décembre 2013 à 19:01.
A faire comme Java Web Start (des applications sandboxées) en moins bien, mais en mieux accepté, car on préfère une grosse bidouille bien pourrie à une solution propre, parce que javasapulol.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bien mais pas top?
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu as un convertisseur performant de C/C++ en Dart?
Si non, un autre langage autonome où il faudrait que je recode tout ne m’intéresse personnellement pas, car j'ai des années de travail en C/C++ que je voudrais mettre en ligne.
C'est le très gros avantage de NaCl et ASM.js (en théorie, en pratique NaCL n'est pas déployé et ASM.js a des perfs pas encore top partout) : réutilisabilité.
[^] # Re: Bien mais pas top?
Posté par tanguy_k (site web personnel) . Évalué à 1.
Le RAII c'est pour le C++ et les exceptions, dans Dart il y a le garbage collector.
Peut-être dans le futur ? : https://code.google.com/p/dart/issues/detail?id=3691
Ceci n'est pas suffisant ?
[^] # Re: Bien mais pas top?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Le garbage collector, c'est bien pour la mémoire classique, mais avec l'ajout de webgl, on doit gérer des ressources bien plus rares comme des textures ou des buffers de vertices. Il faut donc les libérer dès qu'on en a plus besoin. On peut forcer le ramasse miette à se lancer plus souvent, mais ça va ralentir l'application…
Pour le reste, je n'avais pas vu, ça a l'air bien!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# asm.js...
Posté par Larry Cow . Évalué à 5.
… ne sert pas à "convertir du C++ en Javascript". C'est juste une cible potentielle d'Emscripten (ou de son concurrent proprio), qui eux se chargent de ce boulot.
[^] # Re: asm.js...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Je ne comprends pas ce que certains ont contre asm.js, je trouve l'idée excellente: des optimisations que tous les navigateurs peuvent implémenter, sans perdre la compatibilité avec l'existant.
Il est évident que ce n'est pas fait pour coder directement, dart n'est pas comparable (et en suivant de loin ça a l'air intéressant aussi, je n'ai rien contre dart et à mon avis ça ne s'oppose pas du tout à asm.js). Ça n'est pas non plus fait pour coder en C++ pour le web (faudrait être un peu maso), mais ça peut servir pour porter des choses utiles (par exemple sqlite a été porté ainsi, ça peut-être intéressant de l'utiliser en javascript).
Pour moi c'est plus la possibilité d'avoir une machine virtuelle native, et ainsi de coder dans le langage qu'on veut, ça se rapproche plus d'une vm java sans la complication des plugins à installer.
Il y a eu de nouvelles annonces de performances vendredi dernier, c'est tout de même assez impressionnant: https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/ .
Et l'argument de Mozilla de ne pas vouloir maintenir 2 langages me semble tout à fait valable.
Pour ma part je code l'interface web de SàT en Python qui est ensuite compilé en Javascript avec Pyjamas: ça me permet d'utiliser un langage que je préfère, et de factoriser une bonne partie du code (un gain de temps très appréciable). asm.js est dans cet esprit et ça me paraît être une bonne direction.
[^] # Re: asm.js...
Posté par barmic . Évalué à 2.
Qu'est ce qui te dis que tous les navigateurs peuvent l'implémenter ? Qu'ils puissent tous exécuter le code généré c'est une chose, mais ASM.js est surtout fait pour faire des choses très lourdes. Pour le moment temps que ces optimisation n'existent que dans monkey rien n'indiquent qu'elles sont portables.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: asm.js...
Posté par groumly . Évalué à 7.
Le probleme d'asm est qu'il accelere tout, sauf le principal, a savoir le js existant.
C'est cool de pouvoir compiler le moteur de doom 42 vers du js, ca fait de belles demos, on s'eclate a tuer des monstres pendant 5 minutes, et apres on retourne a son gmail qui est plutot pas super rapide (tout est relatif, evidemment), et asm.js ne peut pas y faire grand chose.
Si on garde js en brique de base, c'est un peu bizarre de demander de tout reecrire dans un autre langage, non? A ce compte la, partir sur un langage dedie avec un vrai bytecode me parait plus adapte.
asm.js est au mieux une solution de transition.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: asm.js...
Posté par Philippe F (site web personnel) . Évalué à 3.
J'aime bien la réflexion derrière asm.js et derrière dart en général. D'ailleurs, je m'interroge sur le fait que le choix du sous-ensemble de javascript utilisé par asm.js doit être tout aussi facile à optimiser pour SpiderMonkey que pour V8, non ?
Autre question si qq'un a la réponse : pourquoi un outil comme dart2js ne génère-t-il pas de l'asm.js ? Ca peut être une façon détournée de faire un gain en performance sur Firefox.
[^] # Re: asm.js...
Posté par claudex . Évalué à 3.
Oui, d'ailleurs, ils ont bossé là dessus chez Chrome.
Et sur Chrome qui, pour l'instant, n'intègre pas la VM Dart.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Programmation d'interfaces Dart : Angular.dart
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 6.
Comme je m'intéresse actuellement à Angular.js, et que je suis également intéressé par la programmation via des langages typés, j'ai creusé un peu et il se trouve qu'il existe un portage de Angular.js vers Dart, intitulé angular.dart. Angular.dart est développé par l'équipe Angular
Ca a l'air d'être un projet actif !
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Petite digression sur asm.js
Posté par Kaane . Évalué à 2.
Les incompréhensions sur asm.js ont la vie dure.
asm.js est effectivement un sous ensemble de javascript, mais un sous ensemble qui est facile à compiler en bloc.
De la même façon que llvm est capable de convertir du C ou du C++ en bytecode javascript, il existe la possibilité de convertir le même C ou C++ en asm.js.
Cet code asm.js peut être éxecuté par n'importe quelle VM javascript (il s'agit de bytecode javascript complètement valide), mais si il est exécuté sur une VM qui connait asm.js il va pouvoir être compilé de façon beaucoup plus efficace - notamment parceque les optimisation AOT (ahead of time - c'est à dire la compilation à l'avance de morceaux dont on va forcément avoir besoin, par opposition au JIT (just in time) qui ne compile que quand il y a le besoin ). On a entre 1,4x et 3x la vitesse d’exécution du C++ avec le backend LLVM actuel - qui est loin d'être optimal aux dires des mainteneurs.
Dans ce sens il est complètement sur le même ségment que DART : un nouveau langage web destiné à être beaucoup plus facile et efficace à compiler en JIT (voire en compil classique) - Mais lui il ne casse pas tout l'existant pour ce faire. Cependant il ne faut pas non plus s'attendre à ce qu'il soit aussi performant que DART - du moins dans un premier temps. Cependant le but du jeu étant d'utiliser un maximum d'UI et de graphismes 2D/3D (la majorité du calcul étant fait coté serveur et/ou par la carte graphique pour la 3D) il est possible que l'approche asm.js soit suffisante pour 95% des apps.
Il est difficile d'écrire de l'asm.js directement à la mano sans passer par un pré-compiler, la façon la plus proche est d'utiliser http://mbebenita.github.io/LLJS/ LLJS qui rend les choses compréhensibles (même si une personne habitué au javascript pur va prendre un moment pour retrouver ses marques).
En ce qui concerne DART, les deux derniers projets Open Source de chez Google auxquels j'ai participé (Android et Wave) m'ont laissé un gout beaucoup trop amer pour que je ne le considère sérieusement. Malheureusement je ne suis pas le seul. Je considère l'approche asm.js/LLJS beaucoup plus claire, ouverte et viable.
[^] # Re: Petite digression sur asm.js
Posté par tanguy_k (site web personnel) . Évalué à 3. Dernière modification le 28 décembre 2013 à 03:47.
Il y a autant de similitudes entre asm.js et Dart qu'entre le bytecode de la JVM et le langage Java.
La reponse a deja ete donnee ici :
(Pour info Native Client (NaCl) de Google a le meme objectif que asm.js cf http://asmjs.org/faq.html)
Cf http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/
La question qui vient ensuite a l'esprit est pourquoi ne pas utiliser asm.js en tant que bytecode pour Dart ?
La reponse ici :
Plus d'infos dans la FAQ de Dart :
[^] # Re: Petite digression sur asm.js
Posté par tanguy_k (site web personnel) . Évalué à 3. Dernière modification le 28 décembre 2013 à 04:02.
Ah aussi, pourquoi Google a cree NaCl alors qu'il y a deja asm.js ?
D'apres GitHub, asm.js date de octobre 2012 - premier commit alors que NaCl date de bien avant (activé dans Chrome depuis au moins la version 11 cf http://doom.pdox.net/).
La techno NaCl provient certainement de Chrome OS (2009).
http://www.google.com/trends/explore#q=NaCl%20Google%2C%20asm.js
Le principe de asm.js est particulierement malin, a la facon de RISC vs CISC.
[^] # Re: Petite digression sur asm.js
Posté par Antoine . Évalué à 1.
Pas sûr que l'analogie soit très maligne, vu qu'aujourd'hui CISC (x86) tient la dragée haute à la plupart des RISC.
[^] # Re: Petite digression sur asm.js
Posté par claudex . Évalué à 3.
Sauf que les CISC d'aujourd'hui, ils font du RISC derrière (contrairement au début où il y a avait une vraie différence).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Petite digression sur asm.js
Posté par Antoine . Évalué à 1.
Ben oui, mais c'est bien la preuve que l'opposition CISC / RISC du côté du jeu d'instructions est obsolète :)
[^] # Re: Petite digression sur asm.js
Posté par Kaane . Évalué à 1.
Il y a autant de similitudes entre asm.js et Dart qu'entre le bytecode de la JVM et le langage Java.
Non, asm.js est un langage. Il est quasiment impossible de l'écrire à la main certes, mais il s'agit ni plus ni moins que d'un subset de javascript. Le fait que la traduction se fasse systématiquement en bytecode est liée au fait que l'écriture manuelle de asm.js est pénible (pour rester poli) mais lljs résoud en grande partie ce problème en fournissant un autre langage facile à écrire et qui enlève le coté "magique" de la compilation de C/C++ en bytecode optimisé.
asm.js a pour but de permettre la compilation sous forme de bytecode javascript optimisé, de façon à pouvoir faire de l'AOT. Personne n'écrit de code directement en asm.js (à part les personne qui font asm.js bien sur) mais c'est techniquement faisable.
Après reste le problème de la compilation mentionné dans ton ancien post, mais bon c'est un faux problème - pour un gain de perf d'un facteur de l'ordre de 10 je n'ai rien contre lancer une compilation pour tester.
[^] # Re: Petite digression sur asm.js
Posté par tanguy_k (site web personnel) . Évalué à 1.
C'est pas ce que j'ai ecrit dans le journal ? "asm.js est un sous-ensemble de JavaScript, une sorte de bytecode ou langage assembleur"
Pourquoi alors ecrire "Les incompréhensions sur asm.js ont la vie dure" dans ton premier post ?
C'est l'emploi du mot "bytecode" qui te choque ?
Et si on te propose les 2 : les perfs ET sans compilation ?
[^] # Re: Petite digression sur asm.js
Posté par xcomcmdr . Évalué à 0.
Rêve !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Petite digression sur asm.js
Posté par Kaane . Évalué à 4. Dernière modification le 30 décembre 2013 à 10:23.
C'est l'emploi du mot "bytecode" qui te choque ?
Oui, parceque la partie bytecode de asm.js quand elle est compilée avec les optimisation AOT fait référence à une autre VM (enfin un chemin tellement différent dans la VM que l'on pourrait séparer les deux - si d'ailleurs asm.js a du succès il est probable que c’est ce qui se passera)
Alors que asm.js est lui même 100% compatible javascript.
Et si on te propose les 2 : les perfs ET sans compilation ?
En fait les choix sont plutôt
coté asm.js les bons points : Mozilla + perf + comptabilité avec l'existant + nombreuses preuves de ce qui a été fait (je pense notamment à la démo banana bread optimisée et à la démo Epic citadel). Avec en défaut : langage pénible à écrire (même en passant par LLJS c'est pas top) chaine de compilation compliquée à mettre en place (ca devrait s'arranger très vite si le langage a du succès)
et coté dart les bons points : perf + langage relativement agréable à écrire + pas de chaine de compilation à mettre en place (donc test et debug grandement accéléré); et en mauvais mauvais points : double rupture avec l'existant (Non seulement il faut implémenter Dart dans les nouveaux navigateurs pour en tirer parti, mais en plus toutes les étapes de manipulation DOM et events sont à réapprendre), google (on sait ce qui se passe quand une techno google a le succès escompté, on sait aussi ce qui se passe quand elle ne l'a pas), pas d'exemple "real life" (les exemple donnés sont pour le moins simplistes, pas moyen de trouver de "gros" exemple sur le web).
Les deux ont des avantages et des défauts, masi j'aurais plus tendance à croire en asm.js qu'en dart.
[^] # Re: Petite digression sur asm.js
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est toujours un bon point ça? Après l'abandon de Thunderbird et le succès fulgurant de XUL?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Petite digression sur asm.js
Posté par xcomcmdr . Évalué à 2.
Thunderbird évolue toujours, et franchement j'ai pas trouvé mieux que lui.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Petite digression sur asm.js
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je faisais référence à https://blog.lizardwrangler.com/2012/07/06/thunderbird-stability-and-community-innovation/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Petite digression sur asm.js
Posté par barmic . Évalué à 3.
Il n'est quand même pas génial malheureusement…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Petite digression sur asm.js
Posté par Kaane . Évalué à 2.
C'est toujours un bon point ça? Après l'abandon de Thunderbird et le succès fulgurant de XUL?
C'est au moins une garantie qu'on a accès aux sources et que l'on peut forker (moyennant un changement de nom éventuellement), c'est aussi une garantie de quasi absence d'agenda autre que "rendre le web plus accessible" - et traditionellement ils sont plutôt ouvert aux devs extérieurs.
J'aimerai pouvoir en dire autant de Google…
[^] # Re: Petite digression sur asm.js
Posté par tanguy_k (site web personnel) . Évalué à 1.
Pour obtenir de meilleurs perfs que JavaScript, en effet il faut la Dart VM.
Mais la rupture que tu decris n'existe pas : dart2js permet de convertir du code Dart vers JavaScript (avec des perfs identiques a du JavaScript ecrit a la main).
Exactement de la meme facon que CoffeeScript ou TypeScript.
Quant a reapprendre les APIs (pas bien epaisses) pour manipuler le DOM et les events (click, focus, hover…), c'est simplifie dans Dart et les fonctions s'inspirent de celles de jQuery.
Exemple :
querySelector() va te retourner un seul element contrairement a jQuery qui retourne systematiquement une liste. De plus c'est "built-in" dans le langage, pas besoin de passer par une librairie externe.
Reellement, ca prends 30s chrono pour n'importe qui qui a deja ecrit du code jQuery et les avantages sont immediats.
Cf http://www.parleys.com/play/52a9897ce4b04354fb7e57d0/chapter19/about : Montage, Blossom.io - apparemment bien etabli, GreenTea/Angular.dart
Oui c'est vrai, c'est encore pauvre comme exemples et Dart doit encore convaincre.
Ta remarque "on sait ce qui se passe quand une techno google n'a pas le succès escompté" est parfaitement valide et tout le monde en a conscience. La normalisation du langage, l'integration de Dart VM dans Chrome et l'utilisation grandissante de Dart en interne par Google sont des elements determinants.
Revenons a ams.js.
1- Encore une fois, ca n'a pas le meme but. Les demos que tu donnes en exemples le montrent bien : ce sont des compilations de jeux videos OpenGL C/C++ !
Crois-tu que asm.js va remplacer du code JavaScript/jQuery (ou CoffeeScript, TypeScript…) avec AngularJS ou Backbone.js ?
Pourquoi alors Mozilla travaille encore sur les futurs versions de JavaScript si asm.js va tout changer ? Va t-on ecrire le prochain Facebook avec asm.js ?
2- asm.js n'est pas plus rapide que JavaScript au sens ou tu l'entends.
asm.js est plus rapide que JavaScript quand on compare l'execution d'un code C/C++ compilé vers JavaScript classique VS vers asm.js avec une VM specialisee. Il est aussi possible de comparer le code C/C++ original et la version compilee asm.js.
Mais il n'est pas possible de prendre une appli web existante (JavaScript, jQuery, Backbone.js), de la recompiler avec asm.js et de comparer les perfs : c'est juste completement different.
3- asm.js est une approche intelligente, comparativement peut-etre meilleur (ou pas) que NaCl (je n'ai utilise ni l'un ni l'autre).
Ca vient de sortir, ca a fait le buzz fin 2013, attendons que le buzz soit retombe.
[^] # Re: Petite digression sur asm.js
Posté par barmic . Évalué à 4.
Il y a quoi de différent avec Mozilla ? XUL n'est plus utilisé que chez Mozilla, mais pas non plus partout parce que les perf sont pas géniales. Google a libéré Wave quand ils ont perdu confiance en ce truc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.