Je salue l'initiative jolibulle même si je ne me sers pas du logiciel pour des raisons sensiblement identiques à celles évoquées au début du fil de discussion. Je te rejoins sur l'idée qu'il est préférable d'utiliser des techno que l'on maîtrise quitte à laisser de coté certaines fonctionalités. Visiblement tu code avec PyQt et QDesigner comme IDE, ce qui n'est pas un mauvais choix en terme de portablité, après c'est juste une histoire de gouts, perso j'aime pas Trolltech (vieille bagarre gnome kde).314r a écrit : Je peux peut-être t'apporter des éléments de réponse. Faire un logiciel full web je pense que tout développeur qui commence un projet se pose la question depuis quelques années, et visiblement la réponse est souvent négative. Perso il y a plusieurs points qui me rebutent :
- la sécurité, qui est nettement plus critique que sur un logiciel de bureau.
- le coût : à partir du moment où tu mets un site en ligne il coûte de l'argent ce qui impose d'avoir un modèle économique dès le jour du lancement. Ça ne m'intéresse pas.
- javascript : le langage n'a rien d'évident dès que tu commence à programmer sérieusement (en gros, dès que tu fais autre chose que jouer avec jquery).
- l'immaturité de l'écosystème logiciel, qui bouge constamment, très vite. Ça a un côté très excitant, mais pour un amateur qui essaie de faire du code maintenable dans le temps c'est l'enfer.
Le résultat c'est qu'au jour d'aujourd'hui faire une application web qui tienne la route est une affaire de gens très compétents et bien financés y compris pour un truc aussi simple qu'un logiciel de brassage.
En attendant que les lignes bougent, la transition peut passer par une application hybride (par exemple base Qt, interface et une partie de la logique en html/javascript, la version 3.0 de JolieBulle va dans ce sens ). Des outils comme NodeWebkit ont également de l'avenir je pense, mais sont encore trop rustiques pour constituer une alternative complète à un framework type Qt (un simple exemple : la gestion dynamique des traductions).
A propos de tes remarques sur les web applis, je te rejoins sur les points suivants :
1 : le coût : effectivement, externaliser l'applicatif et les data génère un coût ne serait ce que pour la location d'une dedibox ou d'une unitée virtualisé chez gandi, enfin bref de quoi à faire tourner un serveur web/sql. Mais rien d'impossible et je dirais même le minimum pour un informaticien (a ma belle époque je tournais à 4 dedibox juste pour faire du torrent over vpn entre amis, ou m'amuser à recompiler le kernel) , et si le projet est intéressant je veux bien me fendre d'un dédié à 9,99 € HT/mois pour héberger une appli qui me fait un peut rêver.
2 : Est à prendre en compte aussi comme tu l'indique l'aspect sécuritaire. Du coté système ce sont les entrées/sorties réseaux à contrôler, et coté applicatif il faut soigner la sécurité du code à propos des injection SQL, appels systèmes etc ... Note qu'un framework mature comme rails, django (tiens du python !!!), ou yii coté php, intégrent ces vérifications dans leur core (et le contrôleur est la pour faire son boulot tudieux !!!!) et par là même, tu à moins à te soucier de ces aspect que si tu partait directement from scratch. De plus on est loin des premières versions PHP dont les applicatifs se sont fait multi-hacker (pauvre php-bb quand j'y repense comment il s'est fait défoncer au début), le core des interpréteurs est désormais nettement plus sécure qu'il n'a été.
Je ne te rejoins pas du tout sur "l'immaturité" qui remettrait en question 90 % du travail des développeurs à l'heure actuelle , ni sur ce que tu avance sur javascript surtout pour un logiciel présentant aussi peut de fonctionnalité complexes que le corps de métier qui nous intéresse. Je ne te rejoins pas non plus sur le coté "je code web donc j'ai besoin de buisness angels pour des liquidités", c'est uniquement vrai pour des projets d'envergure importante qui de plus vont demander de la haute dispo et de la répartition de charge.
Tout ça pour dire que beersmith et joliebulle ne me sont pas satisfaisants malgré leur valeur, tout comme les spreadsheet de brassage que l'on trouve sur le web et qui d'ailleurs sont souvent bien faites (quoiqu'en anglais), pour principalement les raisons suivantes.
En premier lieu, je suis régulièrement hors de chez moi, soit pour le travail, soit pour le plaisir, soit pour aller brasser chez d'autres, et donc j'utilise, soit le PC des amis sur lequel je ne permet pas d'installer quoique ce soit, soit dans le cas du travail et là je ne dois rien installer du tout. Le navigateur web est le logiciel commun à l'ensemble des système d'exploitations. Que ce soit joliebulle ou beersmith aucun ne me permet cette souplesse. Partager des recettes, retrouver son paramétrage matériel ou que ce soit, c'est très pratique. Je peux être en intervention à l'autre bout de la France, et le soir à l’hôtel paufiner les recettes pour le brassage du week end. Quand on passe 7 heures dans le train à se faire chier, tuer le temps avec sa petite appli android qui est capable de travailler connecté et déconnecté est aussi très appréciable.
Beersmith tente le cloud et l'appli smartphone mais bon, il abuse. On paye le client lourd, passé 15 recettes il faut à nouveau payer pour bénéficier du cloud, et rebelotte pour l'appli smartphone. C'est vraiment le modèle commercial que je déteste car les lacunes du logiciel se transforment en prestations commerciales, et cette logique une feature == des sous c'est vraiment badddd.
Le paysage numérique à changé, les périphériques évoluent, les tablettes par exemple arrivent massivement et il me semble que le navigateur est le point d'entrée commun à toutes ces techno pour l'utilisateur, les appli lourdes de courriel ont quasiment disparues des pc au profit des webmails, idem pour les traitements de textes, et même les jeux s'embarquent dans chrome, et html5 permet en plus des truc de foufou.
Voilà voilà, tout ça sent le troll à plein nez, mais n'y cédons pas !!! mieux vaux brasser.
Pour terminer je relis le début de ton post, franchement est tu est sur de toi lors que tu dit ". Faire un logiciel full web je pense que tout développeur qui commence un projet se pose la question depuis quelques années, et visiblement la réponse est souvent négative. " C'est l'exact inverse qui se passe depuis quelques années et même dans mon cas personnel les quelques soft que j'ai écrit (sauf système) sont tous basés sur des interpréteurs PHP PERLCGI ou Ruby ce malgré les problématiques asynchrones. C'est peut être mon profil d'admin réseau qui veux ça.
Je te souhaite bonne continuation dans ton code et tes expériences de brassage.