Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ton argument est valable, mais tu es loin de le porter.Envoyé par Grimly
Premièrement, citer une vidéo Youtube est une mauvaise idée. Un court texte résumant ce qu'il y a dedans aurait été beaucoup plus intéressant, d'autant que certains n'ont pas accès à Youtube au boulot.
Ensuite ta dernière phrase est agressive, ce qui décrédibilise tout de suite tes propos. On est ici pour avoir des débats constructifs, pas pour s'insulter et se rabaisser.
Si je me permets de critiquer Javascript, c'est par expérience.
Je préfèrerais un langage où les mauvais côtés sont moins lourds et contraignants.
Un tel langage existe ?
Plus sérieusement, je ne vois pas en quoi JavaScript est lourd et contraignant. Ce que je trouve moi lourd et contraignant c'est de vouloir à tout pris coder un site web dans un langage qui devra toujours être transcodé en JavaScript pour marcher.
Pouvez-vous développer quels sont les mauvais côtés, lourds et contraignants, du JavaScript ?
Pour ma part JavaScript est devenu mon langage préféré, pourtant au départ j’avais un très mauvais apriori sur celui-ci, avant d’être forcé de l’utiliser. Ce ressentiment été dut à une mauvaise expérience, dans le domaine du développement Web, notamment sur la manipulation du DOM et l’utilisation de Framework obscures.
Pour moi son principal avantage est de pouvoir utiliser des objets sans avoir à les modéliser par des métadonnées, ainsi que la simplicité de la réflexivité de ce langage. Grâce à cela j’ai gagné en productivité et flexibilité, en réécrivant, de C# a JavaScript, des applications lourdes.
Je ne connais pas trop CoffeeScript, j’avoue être rebuté par sa syntaxe, mais un gain de 20% sur le nombre de lignes de code est intéressant, surtout si ça ne se traduit pas par une perte de performance. Bref je vais étudier ca d’un peu plus près.
ShaderElement : Bénéficier de l’accélération graphique simplement par une nouvelle balise HTML <shader>
ODE.js : portage JavaScript du célèbre moteur physique 3D Open Dynamics Engine
Pourquoi, dans le milieu du développement Web, vous subissez de telles contraintes ?
Car des technos serveurs permettant d’écrire en JavaScript ils en existent plusieurs
ShaderElement : Bénéficier de l’accélération graphique simplement par une nouvelle balise HTML <shader>
ODE.js : portage JavaScript du célèbre moteur physique 3D Open Dynamics Engine
Comme mon message a mal été compris (en fait je suis d'accord avec toi) je rajoute ceci: JavaScript est la lingua franca du web, alors vouloir passer par une couche supplémentaire pour faire un site web me semble être aberrant. Les outils sont là, et bien documentés en plus, il faut juste savoir les maîtriser (ce qui est notre travail).
Comme certains trouves LESS aberrant, pourtant quand tu utilises LESS une fois tu n'as plus envie de faire du CSS pure. Les développeurs sont fainéant. Toute technologie qui accélère le développement sera toujours plébiscitées. Coffeescript permet de se concentrer sur le code, sans avoir à taper une fois le mot prototype ou le mot fonction , à se demander si il faut ou non utiliser == ou === , ou les points virgules. Coffeescript est javascript sans les bad parts.je rajoute ceci: JavaScript est la lingua franca du web, alors vouloir passer par une couche supplémentaire pour faire un site web me semble être aberrant.
Je ne pense pas que CaffeeScript permette justement d'accélérer le développement dans ce contexte (je trouve son installation est assez lourde, on compile maintenant son code, quid de la maintenance ? quid du debugging ? ...)
Cela est juste une affaire de gout en matière de programmation. Autant reprocher à Java de faire des classes en utilisant le mot 'class' .
Cela veut dire quoi exactement "bad parts" ?
compilation = possible vérification statique du code, ça évite certains crashs à l'exécution.
pour le debugging il faudrait vraiment que vous alliez voir chez les autres langages comment c'est fait, le js est juste à des années lumières en terme d'outils.
je connais pas coffeescript, mais pour js : typage dynamique, gestion de la portée exécrable, déclaration des variables entre autres.
Dans un contexte de script dynamique côté client, on compile (déjà cela me choque) et on génère son code JavaScript. A ce niveau là, autant arrêter de faire du dev web.
Je répondrai de la même manière: il faudrait aussi que tu mettes à jour ton navigateur et que tu regardes bien ce qui est fait en matière de debugging JavaScript (je prends au hasard le debugging dans Chrome).
J'ai fait du J2EE / ASP.net / PHP, et je préfère de loin le debugging dans un navigateur, beaucoup plus souple.
- typage dynamique: c'est un avantage pour moi, je n'en peux plus de la nécessité de caster/transtyper son code
- gestion de la portée exécrable: Ce n'est pas parce que c'est différent que c'est exécrable
- déclaration des variables: et ?
pourquoi ne pourrait-on pas faire du compilé quand on fait du web?
en quoi faire du web oblige à ne faire que des scripts, et ça c'est la vision qui est imposée par js, il n'y a pas de concurrent donc on impose une façon de penser.
hors si on regarde bien la tendance, c'est de faire des applis lourdes en web (ce qui, perso, est d'une connerie sans nom), donc une charge de calcul plus importante et la nécessité de passer par du natif pour accélérer les traitements.
si on arrêtait cette tendance, on reviendrait sur un modèle où le script reprendrait sa place, celle où les tâches sont courtes, peu complexe et où le dév natif serait overkill en coût/temps de dév/maintenance.
autant pour moi, celui de chrome est en effet plus complet que ce qu'il y avait il y a encore peu de temps, heureusement d'ailleurs, ça fait longtemps que c'était la croix et la bannière pour faire du js.
en regardant ce que ça donne pour google, ça donne encore du grain à moudre pour le premier point cité : quand on regarde le js de google.fr, condensé à mort, pourquoi est ce qu'on ne donnerait pas du bytecode à bouffer aux clients, vu la lisibilité ça serait du pareil au même, mais le monopole de js impose ça : du code finalement illisible et lent reçu par le client.
- caster/transtyper son code c'est pas une nécessité, ça participe à la vérification statique du code.
- gestion de portée, dans js ce n'est pas que c'est différent, je dirai qu'il n'y a pas de gestion de portée, si à chaque fois que tu tapes le nom d'une variable tu es obligé de réfléchir aux possibles effets de bord avec d'autres variables de même nom, tu n'as pas fini de t'arracher les cheveux.
et encore avec des langages style c/c++/java, tu as la vérification de typage qui te prévient si dans la même portée tu as 2 variables de types différents.
- déclaration de variable, dans les langages que je cite au dessus tu es obligé de déclarer et voir même d'initialiser les variables, toujours et encore dans le contexte de vérification statique du code. ça aide aussi à la lisibilité du code, tu ne vois pas des variables fleurir comme par enchantement au milieu d'une séquence.
tout ce que tu considères comme des bons points le sont dans le cas d'un script, mais surement pas dans le cadre de développement d'une application.
En fait, tout dépend de tes contraintes. Mais "philosophiquement" pour moi, développer pour le web, c'est connaître les différentes technologies qui gravitent autour du web et les utiliser directement.
Appeler JavaScript un language de script est très réducteur. Ce n'est pas parce qu'il y a 'script' dans le nom que c'est un language utilisable que pour ce besoin. JavaScript a été conçu initialement pour être exécuté côté serveur, après les circonstances en ont décidé autrement.
Je développe actuellement un Designer en JavaScript et si je l'avais fait dans un language autre, cela aurait été plus compliqué. J'en suis à 200 000 lignes de code en JavaScript, et jusqu'ici je n'ai pas eu à me plaindre du choix du language. Il faut juste maîtriser les outils que l'on a en main.
S'il est illisible, c'est parce que le code est minifié non ? Pour ce qui est de la lenteur, ce n'est plus un argument valable de nos jours (même si on n'atteint pas la rapidité du natif, le JavaScript est exécuté très rapidement).
Tout à fait d'accord, mais je ne considère pas cela comme une "bad part" mais comme un avantage.
La notion de scope existe en JavaScript, elle est très poussée et te permet de faire de belles choses. Après il existe des IDE qui permettent de vérifier ton code pour toi (il est fini le temps où il n'y avait pas d'iDE pour JavaScript).
Tu me parles language ou IDE là ?
Il existe en JavaScript l'instruction "use strict;" qui permet de faire ce que tu me décrit.
Le blocage est plus "philosophique" que technique. Passer du compilé à de l'interprété n'est pas facile comme il faut apprendre de nouvelles habitudes et changer un peu la manière dont tu conçois ton architecture. Mais ce n'est pas parce que c'est différent que c'est moins bien.
Euh... non, c'est la définition.
Un langage de script est un langage qui est compilé à la volée lors de l'exécution et c'est tout. Ce n'est pas une tare, c'est une spécificité du langage. Ca ne veut même pas dire qu'il ne peut pas être exécuté côté serveur (PHP, bash, perl, etc. sont exécutés côté serveur).
ça n'empêche pas de faire du compilé ça.
je me vois pas faire un photoshop en bash, pour les mêmes raisons, je ne le ferai pas non plus en js.
hors discussion.
très rapidement? sur mobile ou pc peu puissant, c'est monstrueusement lent, et c'est dans ce cas qu'on voit vraiment la différence avec du natif.
belles choses? il serait temps de donner des exemples, parce que sans exemple je peux avancer que l'opérateur virgule permet de faire du café.
langage (sans u au passage), ide étant la partie bonus de mise en surbrillance des erreurs.
chose qui devrait être de base et non désactivable.
c'est pas philosophique, il y a des langages de script qui te râlent dessus justement sur les points que j'ai cité, c'est, pour moi, pas les langages de script le problème, mais bien javascript en particulier ; et vu la promptitude (XD) d'apparition d'outils qui génèrent du js sans en faire une seule ligne souligne fortement qu'il y a un problème avec ce langage.
Le typage dynamique et faible est une caractéristique de beaucoup de langages interprétés.
Il ne faut pas voir ça comme une erreur de conception, c'est une approche différente et qui a des avantages différents (souplesse, reflexivité ...).
Quand on vient de langages comme Java, dans lesquels on est tenu par la main pour écrire du code propre, ça peut être un peu déroutant.
Mais quand on sait ce qu'on fait on n'a aucun problème avec le JS.
Le vrai problème est que la profusion d'outils d'aide au développement a fait naître beaucoup de pseudo-développeurs, qui sont dangereux parce qu'ils pensent maîtriser ce qu'ils font alors que la seule chose qu'ils maîtrisent c'est un IDE qui fait tout pour eux.
Quand on ne sait pas faire, on râle toujours sur l'outil au lieu de se remettre en question ...
11001.00101.10010.10000.00111
ceci pourrait être vrai dans le cas d'un dév amateur, mais dans le cadre pro, j'aurais du mal à croire une personne qui fait de la prog qu'avec le langage qu'il maitrise ou qu'il préfère. (ou alors je me suis trompé de boite ...)
possible sauf que dans le desktop par exemple, si ça te plait pas ou si tu ne maitrise pas, tu as le choix pour aller voir ailleurs, pas dans le web où il n'y a que javascript et que des gens ont l'air de tomber des nues quand on leur montre ce qui existe à coté.
Oui, mais j'ai dit qu'il valait mieux utiliser directement les technologies web plutôt que de passer par des couches intermédiaire.
C'est un choix personnel mais non une impossibilité technique.
Non, cf ta remarque au dessus. J'ai pu réussir à faire un Designer d'appli HTML5, un Designer c'est pratiquement aussi complexe qu'un photoshop-like en terme de fonctionnalité, et ce en JavaScript.
Forcément, si "pc peu puissant"...
Documentes toi un peu sur le sujet (je l'utilise pas mal dans les closures). Si tu ne le sais pas, c'est que tu ne connais pas assez le sujet.
no comment...
Au prix de casser à compatibilité avec l'existant ?
Si, c'est philosophique. Je pensais comme toi, mais à force de passer par des couches intermédiaires, tu ne sais plus comment fonctionne le web.
plutôt du au monopole de javascript.
bonne chance.
bah oui forcément, tout le monde n'a pas la chance de bosser sur des machines derniers cris, avec l'os à jour et le dernier navigateur à la mode, c'est exactement la même réaction quand j'ai parlé de désactivé les effets 3d de css, on croirait que parce que une nouveauté sort, il faut oublier tout le parc existant de machines.
non effectivement, je n'ai jamais prétendu être expert de js, vu que je ne peux pas blairer ce langage, mais j'en ai suffisamment soupé pour savoir que je ne veux pas en faire h24. mais merci d'éviter de donner un exemple.
tiens donc, pour faire des photoshop en js il y a du monde, mais pour gérer un parc de machines hétérogènes, il n'y a plus personne, pourtant c'est ça en partie être développeur.
le javascript étant déjà une couche intermédiaire, mettre une couche supplémentaire ne change pas énormément la donne, et ça n'empêche normalement pas de rajouter un autre langage de script pour concurrencer js.
de plus le web n'est pas en js, ton navigateur est fait en c, c++ ou autre (et tout en haut tu as le code machine) qui va prendre ton js, ton interpréteur et bien mixer le tout.
donc si le navigateur donnait l'accès à autre chose, le fonctionnement du web pourrait être fait avec une multitude de langages différents tout en gardant la même logique de séparation du contenu et de la façon d'afficher ce contenu.
Je ne comprends pas ta réponse. On peut parfaitement maîtriser plusieurs langages, et même plusieurs paradigmes.
Tu as le choix de ne pas faire du web !
11001.00101.10010.10000.00111
mouais, bizarrement je ne me permet pas la prétention de dire que je maitrise parfaitement tous les langages que j'utilise, loin de là.
mais après on peut toujours faire des suppositions pour les quelques % qui maitrisent réellement.
j'ai surtout le choix de faire le boulot qu'on me demande de faire ...
et tout ça parce que je ne sacralise pas javascript, c'est fou quand même.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager