GRATUIT

Vos offres d'emploi informatique

Développeurs, chefs de projets, ingénieurs, informaticiens
Postez gratuitement vos offres d'emploi ici visibles par 4 000 000 de visiteurs uniques par mois

emploi.developpez.com

Dropbox abandonne JavaScript au profit de CoffeeScript
Et vous, envisageriez-vous une telle migration ?

Le , par Nissa Comet, Expert confirmé
Dropbox, le service de stockage et de partage de fichiers en ligne, déclare avoir complètement abandonné JavaScript et avoir réécrit la totalité de son code source pour navigateur dans un langage relativement nouveau appelé CoffeeScript.


Dans leur blog, les développeurs de Dropbox affirment que la migration vers CoffeeScript s’est faite en l’espace d’une semaine seulement. Et ce grâce à l'outil "js2coffee". Ils affirment aussi que grâce à cette migration, ils ont réussi à réduire de 20 % le nombre de lignes de code de l’interface Dropbox. En effet, la nouvelle base de code contient 5000 lignes et 200.000 caractères de moins que le code original.

23 000 lignes de code, c’est ce que compte maintenant l’interface web de Dropbox en langage CoffeeScript. Cependant, CoffeeScript est compilé en JavaScript et les utilisateurs ne verront aucun changement dans l’interface Dropbox après la migration. « Le site fonctionne et se comporte comme avant » rassurent les développeurs sur le blog de Dropbox.

Comparé à JavaScript, CoffeeScript offre une syntaxe semblable à celles de Python ou Ruby. Les développeurs de Dropbox dénombrent parmi les avantages de CoffeeScript un code moins chargé, moins long à taper et une syntaxe plus claire et plus lisible qui utilise les fonctions et les boucles de manière très compacte.

Étant donné que l’utilisateur final de la plateforme Dropbox ne verra aucun changement dans son fonctionnement, la réduction des lignes du code source est-elle un indicateur suffisant pour savoir, si oui ou non, le langage CoffeeScript est meilleur que JavaScript ? Et vous seriez vous capable et surtout curieux de tenter une telle expérience de migration pour vos applications ?

Source : blog officiel de Dropbox


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de wanou wanou - Nouveau membre du Club http://www.developpez.com
le 24/09/2012 à 13:50
Citation Envoyé par stardeath  Voir le message
compilation = possible vérification statique du code, ça évite certains crashs à l'exécution.

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.

Citation Envoyé par stardeath  Voir le message
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 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.

Citation Envoyé par stardeath  Voir le message
je connais pas coffeescript, mais pour js : typage dynamique, gestion de la portée exécrable, déclaration des variables entre autres.

- 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 ?
Avatar de stardeath stardeath - Membre expert http://www.developpez.com
le 24/09/2012 à 14:49
Citation Envoyé par wanou  Voir le message
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.

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.

Citation Envoyé par wanou  Voir le message
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.

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.

Citation Envoyé par wanou  Voir le message
- 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 ?

- 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.
Avatar de wanou wanou - Nouveau membre du Club http://www.developpez.com
le 24/09/2012 à 15:54
Citation Envoyé par stardeath  Voir le message
pourquoi ne pourrait-on pas faire du compilé quand on fait du web?

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.

Citation Envoyé par stardeath  Voir le message
le monopole de js impose ça : du code finalement illisible et lent reçu par le client.



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).

Citation Envoyé par stardeath  Voir le message
- caster/transtyper son code c'est pas une nécessité, ça participe à la vérification statique du code.

Tout à fait d'accord, mais je ne considère pas cela comme une "bad part" mais comme un avantage.

Citation Envoyé par stardeath  Voir le message
- 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.

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).

Citation Envoyé par stardeath  Voir le message
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.

Tu me parles language ou IDE là ?

Citation Envoyé par stardeath  Voir le message
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.

Il existe en JavaScript l'instruction "use strict;" qui permet de faire ce que tu me décrit.

Citation Envoyé par stardeath  Voir le message
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.

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.
Avatar de Loceka Loceka - Expert confirmé http://www.developpez.com
le 24/09/2012 à 16:09
Citation Envoyé par wanou  Voir le message
Appeler JavaScript un language de script est très réducteur.

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).
Avatar de stardeath stardeath - Membre expert http://www.developpez.com
le 24/09/2012 à 16:51
Citation Envoyé par wanou  Voir le message
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.

ça n'empêche pas de faire du compilé ça.

Citation Envoyé par wanou  Voir le message
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 me vois pas faire un photoshop en bash, pour les mêmes raisons, je ne le ferai pas non plus en js.

Citation Envoyé par wanou  Voir le message
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.

hors discussion.

Citation Envoyé par wanou  Voir le message
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).

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.

Citation Envoyé par wanou  Voir le message
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).

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é.

Citation Envoyé par wanou  Voir le message
Tu me parles language ou IDE là ?

langage (sans u au passage), ide étant la partie bonus de mise en surbrillance des erreurs.

Citation Envoyé par wanou  Voir le message
Il existe en JavaScript l'instruction "use strict;" qui permet de faire ce que tu me décrit.

chose qui devrait être de base et non désactivable.

Citation Envoyé par wanou  Voir le message
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.

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.
Avatar de marts marts - Membre averti http://www.developpez.com
le 24/09/2012 à 17:47
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 ...
Avatar de stardeath stardeath - Membre expert http://www.developpez.com
le 24/09/2012 à 18:10
Citation Envoyé par marts  Voir le message
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.

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 ...)

Citation Envoyé par marts  Voir le message
Quand on ne sait pas faire, on râle toujours sur l'outil au lieu de se remettre en question ...

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é.
Avatar de wanou wanou - Nouveau membre du Club http://www.developpez.com
le 24/09/2012 à 18:12
Citation Envoyé par stardeath  Voir le message
ça n'empêche pas de faire du compilé ça.

Oui, mais j'ai dit qu'il valait mieux utiliser directement les technologies web plutôt que de passer par des couches intermédiaire.

Citation Envoyé par stardeath  Voir le message
je me vois pas faire un photoshop en bash, pour les mêmes raisons, je ne le ferai pas non plus en js.

C'est un choix personnel mais non une impossibilité technique.

Citation Envoyé par stardeath  Voir le message
hors discussion.

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.

Citation Envoyé par stardeath  Voir le message
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.

Forcément, si "pc peu puissant"...

Citation Envoyé par stardeath  Voir le message
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é.

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.

Citation Envoyé par stardeath  Voir le message
langage (sans u au passage), ide étant la partie bonus de mise en surbrillance des erreurs.

no comment...

Citation Envoyé par stardeath  Voir le message
chose qui devrait être de base et non désactivable.

Au prix de casser à compatibilité avec l'existant ?

Citation Envoyé par stardeath  Voir le message
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.

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.
Avatar de stardeath stardeath - Membre expert http://www.developpez.com
le 24/09/2012 à 18:47
Citation Envoyé par wanou  Voir le message
Oui, mais j'ai dit qu'il valait mieux utiliser directement les technologies web plutôt que de passer par des couches intermédiaire.

plutôt du au monopole de javascript.

Citation Envoyé par wanou  Voir le message
C'est un choix personnel mais non une impossibilité technique.

bonne chance.

Citation Envoyé par wanou  Voir le message
Forcément, si "pc peu puissant"...

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.

Citation Envoyé par wanou  Voir le message
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.

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.

Citation Envoyé par wanou  Voir le message
Au prix de casser à compatibilité avec l'existant ?

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.

Citation Envoyé par wanou  Voir le message
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.

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.
Avatar de marts marts - Membre averti http://www.developpez.com
le 24/09/2012 à 19:03
Citation Envoyé par stardeath  Voir le message
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 ...)

Je ne comprends pas ta réponse. On peut parfaitement maîtriser plusieurs langages, et même plusieurs paradigmes.

Citation Envoyé par stardeath  Voir le message
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é.

Tu as le choix de ne pas faire du web !
Avatar de stardeath stardeath - Membre expert http://www.developpez.com
le 24/09/2012 à 19:11
Citation Envoyé par marts  Voir le message
Je ne comprends pas ta réponse. On peut parfaitement maîtriser plusieurs langages, et même plusieurs paradigmes.

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.

Citation Envoyé par marts  Voir le message
Tu as le choix de ne pas faire du web !

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.
Offres d'emploi IT
Ingénieur en développement logiciel expérimenté h/f
Microsoft Engineering Center Paris - Ile de France - Issy-les-Moulineaux (92130)
Chef de produit
Work4 Labs - Ile de France - Paris
Développer talend h/f
CTS Consulting - Pays de la Loire - Nantes (44000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil