• [^] # Re: TypeScript

    Posté par (site web personnel) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 3. Dernière modification le 13 novembre 2018 à 11:16.

    Ah ah, oui, cette image m'amuse beaucoup.

    En C++, tu as aussi intérêt à te limiter à un sous-ensemble assez restreint du langage.

    J'aime bien ton article, il est bien documenté et soulève des points valides de manière respectueuse et agréable à lire.
    Il se trouve que je ne suis quasiment pas affecté par les points négatifs que tu soulèves : je n'utilise pas (beaucoup) npm ni de bibliothèques externes, ni les webworkers. Je n'ai pour l'instant pas trop adopté la syntaxe des déconstructions pour des raisons de compatibilité des navigateurs mais je vais certainement bientôt m'y mettre, et pour null et undefined je me suis fait un modèle qui fonctionne pour moi (undefined = la fonction ne retourne rien de particulier, null est explicitement renvoyé quand l'élément n'existe pas mais effectivement ce n'est pas forcément idéal).

    Pour ton { a, b } = o, ça s'explique certainement par le fait que { a, b } est interprété comme un bloc de code qui contient une instruction pas terminée par un point virgule (ce qui est autorisé en JS, et je ne suis pas fan de ça), et cette instruction a, b est composée de deux sous-instructions (qui sont des expressions...) séparées avec l'opérateur virgule. L'analyse syntaxique échoue au niveau du = parce = après un bloc de code n'a pas de sens. Les parenthèses interdisent l'analyseur de considérer les accolades comme un bloc de code. Je sais, c'est dommage. Ce n'est pas incompréhensible, mais je reconnais que c'est pénible.

    Pour le ===, C'est pénible et c'est la même chose en PHP : j'ai décidé de considérer que == ne devait pas être utilisé.