Pom Pom Idou a écrit :



D’un autre côté, essaie de développer un OS sous Java/Javascript et tu m’en diras des nouvelles… " />





Evudemment qu’il y a du plus bas niveau derrière, qui représente l’api sur laquelle s’appuie le code javascript, et qui est développé avec des outils adaptés.



Ça ne change rien à l’idée que le javascript est parfaitement adapté à nombre de cas d’utilisation dand le cadre d’applis destinées à tourner sur un mobile.



Et par expérience, une fois qu’on a réellement mis le pied dedans (en se débarrassant des à prioris du JS des années 1990 et compris que le JS c’est pas jQuery), on y trouve une efficacité de développement qui rend les autres langages tout à coup moins savoureux.

Pom Pom Idou a écrit :



Je te trouve très affirmatif sur un sujet et un “produit” que tu ne connais absolument pas





Non: TU ne le connais pas, et tu es celui qui affirme à tort que c’est mon cas également.





tu ne sais strictement, surtout quand tu as une lecture de l’article très sélective





Relisons le en détails:





build an operating system that is essentially nothing more than a browser



C’est faux: c’est un OS qui utilise principalement des technos en userland qui sont également celle habituellement utilisées dans un browser. Il n’est pas le seul. Quand Qt fait du QtQuick ou que Gnome fait de JS le langage par défaut, ils ne font pas un browser pour autant.





mobile platform built entirely on HTML5 that treats websites as apps. In fact, websites are the “apps” – there is no such thing as native code



C’est à nouveau faux: les applications peuvent être packagées sous différentes formes, et ne ressemblent en rien à des site web.



On a déjà finit le second paragraphe.





Mozilla has focused exclusively on mobile sites



Juste idiot. Il n’y a strictement rien pour étayer cette affirmation.





Ultimately the web-as-app



Je répète ce que j’ai déjà dit avant: il confond le web et les technos du web.





As Facebook has discovered, there are serious performance issues with HTML5.



Facebook a justement fait un site web en HTML5. Comparaison sans fondement.





On en a fini pour le troisième paragraphe.





The issues are only exacerbated when faced with limited bandwidth.



On parle du réseau pour critiquer les applications, comme si elles en avaient besoin. C’est à nouveau mélanger la notion d’application et de website.





Firefox phones won’t be terribly different from the original iPhone in functionality, though, they will have significantly faster data connections. That landmark device launched without support for third-party apps, as you might recall, and Steve Jobs famously told developers they could start creating applications months before the phone officially went on sale, because they were simply mobile websites.



Il réaffirme une nouvelle fois clairement son amalgame site-web = application sous firefox OS. Ce qui est encore une fois faux.





Granted, it relied on Cingular’s painful EDGE network, but things are only marginally better on 3G or 4G as web apps have become more complex.



A nouveau, il parle du réseau comme d’un problème pour une expérience riche pour les applications. Ce qui exclu totalement l’hypothèse qu’il envisage les applis offline.





On en a fini pour le troisième paragraphe.





the wireless infrastructure in South Asia and Africa is nowhere near as robust as it is in the Western world. This poses significant problems for the fledgling OS since it relies on constant connectivity to deliver information



Encore et toujours la même chose.





Sure, some services can cache data locally for offline use



Non, c’est bien plus que mettre en cache quelques données localement, c’est être capable d’avoir une application et l’ensemble de ses ressources disponibles en oflline. Au même titre que ce que contient le package d’une application sur un autre OS. A nouveau, il s’enfonce dans son erreur.





that’s a feature of HTML5 that has yet to be widely embraced by devs.



On parle d’un des plus grands standard qui va justement éviter aux développeurs qui ont un poil touché à HTML5 qui sera ultra largement répandu dans quelques mois/années de devoir apprendre une nouvelle API, contrairement à Android, ontrairement à iOS, ontrairement à winRT, etc…

Son argument est juste idiot.





most “apps” (…) will require an internet connection to function.



un “most” totalement sorti du chapeau. Rien pour étayer une contre vérité totale.





On en a fini pour le cinquième paragraphe.





Sparse coverage and slow speeds will pose significant usability issues for these new consumers, but perhaps an even bigger stumbling block will be price. (…) A device that relies so heavily on the web apps, will inevitably suck down a significant amount of data.



A novueau il part du principe que son téléphone va devoir constamment utiliser une connexion au net.





it will likely be more than if most of your applications were installed locally.



Encore la preuve qu’il n’a pas compris la notion d’application sous Firefox OS.





Nokia’s Xpress Browser and Opera Mini do this through extensive use of compression that relies on a middleman server operated by those companies. It’s not unthinkable that Firefox OS could use a similar technique on its “apps”



Encore une fois, dans sa tête: FireFoxOS + apps = browser + site web.





the phone is going to literally be nothing more than a portal to the web{/quote]

Une de plus.





On arrive enfin à l’update de l’article:



[quote]Update: There appears to be some confusion over Firefox OS and the state of offline apps. As noted in the editorial, it is possible for HTML5 apps to be downloaded and installed locally.



Ah ben tiens, on n’en a pas parlé deux lignes dans le trilion de paragraphes d’avant.





However, many apps are not “packaged” (in Mozilla’s terminology) and installable.



Stat sortie du chapeau, le ‘many’ renvoie au ‘most d’avant: rien de concret, si ce n’est l’amorce d’une pirouette.





The “packaged” versions of the apps are, essentially, just websites zipped up in an archive.



Il reprend encore l’idée du site web, qui est fausse. C’est une application autonome avec ses assets, son modèle de données, son lifecycle, etc…





many devs struggle to produce efficient products using it



Ben tien, encore un ‘many’. Et comme d’hab, rien de concret pour étayer l’information.





while Mozilla has created hooks for apps to get deeper access to the hardware



Encore une fois, il n’a pas comrpis que c’était l’API exposée pour les apps, il croit que ce sont juste quelques ‘hooks’ pour que ce qu’il voit comme des “sites web” s’adaptent à la marge.



Alors quand je dis que 90% de l’article dit des conneries, ce n’est pas usurpé. Au passage, quand tu relèves les commentaires des lecteurs qui expriment exactement le même problème dans l’article, tu ne fais qu’abonder dans mon sens.

thibsert a écrit :



J’attends justement de Firefox OS un truc bien plus léger qu’Android, du coup j’ai peur d’être déçu… C’est vraiment pas possible un OS mobile qui n’ait pas besoin d’un double coeur pour faire du web et téléphoner ? " />





C’est un faux problème pour moi: l’évolution des performances du hardware des appareils mobiles fait de toute façon que le “smartphone-de-la-mort-qui-joue-en-3d-en-1080p”, soit le haut de gamme aujourd’hui, ce sera le moyen de gamme dans 12 mois et le bas de gamme dans 24 mois.

thibsert a écrit :



Donc le bas de gamme dans 2 ans, ce sera un gros proco qui bouffe toute la batterie en 12h, juste pour afficher une jolie horloge avec la météo animée ?





Les évolutions se font sur la puissance et sur la performance par watt. Le haut de gamme d’aujourd’hui est à la fois capable de délivrer plus de puissance, mais également d’être plus économe quand la puissance n’est pas nécessaire.





le matos devrait être suffisant pour l’usage que j’en ai (téléphoner, envoyer des sms, lire des sites web).



Il ne faut pas croire: le web, c’est devenu quelque chose de complexe et relativement consommateur en ressources. Plus on avance, moins c’est proche de la catégorie d’usage “léger” d’il y a quelques années.



Les choses se sont réellement accélérées depuis qu’on a un marché concurrentiel, où les navigateurs font la course à l’échalotte au niveau des perfs.



Quand tu vois des sites qui surfent sur le ‘responsive design’ par exemple, avec de plus en plus de logique déportée côté client (*) auxquels on ajoute la quantité de contenu (vidéos hd, images de plus en plus grosses, …), on arrive assez loin des sites “à papa” d’il y a ne serait-ce qu’il y a 3 ou 4 ans. Et forcément ça se ressent au niveau des besoins en traitement côté client.







(* Allez, je digresse comme un ouf): c’est d’ailleurs un peu la nouvelle ‘vague’ du web tel qui pousse fort en ce moment:

• jusqu’ici: un client fait une requête pour une page “tartampion.php”. L’ensemble du contenu est traité côté serveur (on choppe les données dans une base, on la met en forme en fonction des caractéristiques du navigateur du client, on génère le HTML correspondant) et on renvoie l’HTML complet “tel quel” que le navigateur du client n’a “plus qu’à” parser et afficher
  
  
  


• désormais, les choses évoluent vers une logique orientée ‘RESTful’, beaucoup plus proche de ce qu’on connait dans une ‘vraie’ application : le browser charge la partie ‘controleur’ (au sens large) qui est du code JS, et qui va gérer l’initialisation, le routage en fonction de l’url, la persistance des données au cours de la visite, la création et l’affichage des vues, le modèle de données, le tout en récupérant les données elles-même avec une logique REST (en gros je demande au serveur telle donnée, il me la retourne en quasi brut, sans mise en forme, affichage, etc ; tout ça c’est le navigateur qui va faire le taf).
  
  
  
  Bref, là où tout le boulot et la logique était jusque-là codée côté serveur, il devient petit à petit qu’un simple pourvoyeur de données (une sorte de ‘grosse’ surcouche de la BdD) que le navigateur va gérer entièrement pour tout le reste: interactions, navigations, mise en forme, mise en page, affichage, etc…
  
  
  
  Historiquement, c’est un peu une redite (mais pas pour les même raisons) du passage du paradigme des clients légers à des applications qui s’exécutent en local sur le terminal lui-même

thibsert a écrit :



Justement non, le gros lourdingue haut de gamme d’hier n’est pas une évolution : il reste le gros lourdingue de service, sauf qu’il passe entrée de gamme parce qu’il n’est plus aussi cher qu’avant.





Non: le gros lourdingue auquel on ne demande pas grand chose est capable de jouer au petit moineau.





on se retrouve avec des fermes de Xeon qui se tripotent la nouille, et des milliers de proco bas de gamme qui se démerdent avec ça…

Excuse moi si en terme fonctionnel, je trouve ça un peu idiot. Surtout que niveau dev ça ajoute des difficultés (enfin, il me semble) et que niveau utilisateur, ça ajoute des contraintes (avoir un terminal puissant, avoir des biblios à jours, ce genre de trucs).



C’est l’inverse: au niveau fonctionnel, c’est beaucoup plus efficient

• efficience côté réseau, expérience utilisateur améliorée avec une réactivité sans pareille
  
  
  


• efficience en terme de charge de calcul: les xeons vont faire tourner 100 sites web là où avant les mêmes avaient du mal avec 50. Les xeons vont pouvoir faire plus avec
  
  
  


• ça évolue de concert avec les besoins (site avec capacité de faire du (semi) offline, single page applications, etc…
  
  
  


• niveau dév. c’est beaucoup plus homogène avec du code et des modèles de données communs des deux côtés, cf. nodeJS et des frameworks clients genre angularjs: tout est en JS, le code métier (et le reste) est identique des deux côtés, du JSON pour papoter, voir même du MongoDB (srv) en parallèle avec du WebStorage (cli) qui se comportent de la même façon pour la persistance des données)
  
  
  


• le déploiement n’est pas un problème puisque les libs sont mises en cache côté client et mises à jour de façon transparente comme n’importe quelle autre ressource du web (une image, une page, …).
  

Pom Pom Idou a écrit :



Je n’ai jamais dis autre chose !





Tu as

• axé l’ensemble de ton argumentaire sur le seul aspect de la performance
  


• laissé entendre qu’une hiérarchisation des compétences des développeurs existait, et qu’elle était corrélée avec leur langage de prédilection,
  


• que la notion de rendement/productivité n’avait qu’un INpact dans un cadre professionnel (que je n’ai pas relevé jusque là, mais c’est également une connerie: la ressource ‘temps / effort n’étant pas infinie quel que soit la nature du projet, perdre en productivité a forcément un INpact sur le reste: étendue des fonctionnalités, temps accordé au test, etc…).
  
  
  
  Surtout, tu as tiré le premier en présentant le JS comme quelque chose qu’on se forcerait à se coltiner à défaut d’avoir le choix d’un langage tiers.
  
  
  
  
  
  Tu comprendras qu’il y avait quand même un minimum de bases pour que tu puisses raisonnablement t’attendre à une réaction, il me semble.
  

Pom Pom Idou a écrit :



Une réaction d’Engadget datant de mars 2013 concernant Firefox OS et son mode de fonctionnement





Article hautement inexact étant donné que la plupart de l’argumentation se base sur l’idée qu’une application FireFoxOS est un site web amélioré, nécessitant nécessairement une connexion internet et un serveur en face pour pouvoir fonctionner.

La seule chose que montre cet article, c’est l’incompétence de l’auteur, qui entretien une confusion totale entre la plateforme technologique (HTML5 + JS) et le web. Or dans FireFoxOS, le HTML5+JS est avant tout un set de technologies pour faire du code qui s’exécute en totale autonomie en local, au même titre que Java, ObjectiveC, etc… sur d’autre plateformes.



L’update de l’article montre que l’auteur a tellement déconné qu’il s’est senti obligé d’une pirouette maladroite pour essayer de retomber sur ses pattes (genre “ah ouais, j’ai oublié qu’on pouvait faire du offline” (dit autrement il flingue 90% de son article), “mais c’est juste un zip d’un site online”, or c’est toujours aussi partiel et rend son raisonnement pas moins faux).



La réalité du développement d’applications sur FireFoxOS est totalement différente de ce qui est exposé dans cet article, et la lecture des commentaires qui le suivent rétablissent déjà une partie de la réalité.



Pour le reste de notre discussion, tu argumentes avec du contre exemple et du cas particulier (LE cas du développeur miracle qui fait plier la SSII parce qu’il est indispensable. On sait tous que c’est l’exception pas la règle. LE cas du code dont on peut supprimer 70% du volume, le truc totalement extrême, etc…).

Bref, aucun intérêt. Tu sembles vouloir rester arc-bouté sur ta position, c’est ton droit. Aies au moins l’obligeance de ne pas remettre en cause la probité et les compétences de tes interlocuteurs (“tu n’as pas ta place dans ce métier”, etc…)

Scorpion01 a écrit :



Le javascript est le langage le plus incompris au monde …





Je pense que c’est une question de “génération” de développeurs.



C’était la même chose quand d’autres grands concepts sont apparus: la POO, les design patterns, etc… Très peu de gens les utilisaient alors que ça présentait un avantage évident dans certains domaines.



Puis les choses ont évolué, et petit à petit et les gens s’y sont mis à force que les frameworks, les outils, etc. en fassent l’usage et généralisent les concepts. Aujourd’hui, un développeur qui n’a pas la moindre base en POO ou ne connait pas une notion basique comme le pattern MVC est vu comme un ovni.



Je pense que c’est un peu pareil pour l’intérêt d’un langage de script en général, et de la prog orientée “prototype + événementiel + closures + lambda” en particulier.