Et pourtant on a quand même des contres exemples, voir toute la suite gmail/calendar/… + google docs, etc. Ben il y a quand même pas > mal de monde qui préfère cette ergo à un thunderbird par exemple.
Donc c'est loin d'être aussi 0 - 1
Quand je dis que c'est de la merde je parle pour moi. GMail il m'arrive de l'utiliser de temps en temps mais je préfère au quotidien un client natif. Et je constate par ailleurs le succès phénoménal de sparrow, un client mail natif sur Mac, visiblement une bonne partie de gens sont préfèrent le natif au web et payent même pour ça…
Idem pour les suites bureautique en web, elles ont leur succès via des usages casual, ou si leurs features suffit. Pour un usage avancé quotidien un client natif est indispensable.
Heu… non. Là on est justement pour les sites qui n'ont pas de design.
Et oui car c'est tellement chiant à faire le design en web que bootstrap permet de le faire très rapidement, structuré et joli.
Mais bon, les applis totalement moches en natif c'est quand même hyper facile à trouver malheureusement, et ça leur ferait du bien d'avoir un bootstrap aussi en natif
Je répète qu'il est inutile de designer une application native, le toolkit utilise le thème défini par le user, les apps natives sous KDE/GNOME/OS X/Windows ont presque toutes le même look heureusement, et s'il y a personnalisation c'est léger, rien à voir avec le web. Il suffit de regarder le desktop que tu as sous les yeux hein.
Et tu es aussi bridé par toutes les contraintes existantes (par exemple fw d'entreprise) qui font qu'au final dans 99% des cas on va faire, même en natif, du REST (ou autre) sur le port 80. Attention, je trouve ça très bien hein, c'est justement parfait pour faire du client serveur avec surtout des clients (natif, web, etc). Donc oui, théoriquement on peut faire plein de choses, en pratique, en multiplateforme, en entreprise toussa, on est beaucoup plus limité malheureusement.
Le protocole entre le client et le serveur n'est qu'une partie de l'architecture. En natif tu peux intégrer une lib torrent dans ton client procotole qui, oh, n'utilise pas HTTP, accéder à tout le matériel, à des fonctionnalités de l'OS inaccessible à un navigateur, etc etc …
[^] # Re: hum...
Posté par fredix . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 6. Dernière modification le 31 mars 2012 à 10:47.
Quand je dis que c'est de la merde je parle pour moi. GMail il m'arrive de l'utiliser de temps en temps mais je préfère au quotidien un client natif. Et je constate par ailleurs le succès phénoménal de sparrow, un client mail natif sur Mac, visiblement une bonne partie de gens sont préfèrent le natif au web et payent même pour ça…
Idem pour les suites bureautique en web, elles ont leur succès via des usages casual, ou si leurs features suffit. Pour un usage avancé quotidien un client natif est indispensable.
Je répète qu'il est inutile de designer une application native, le toolkit utilise le thème défini par le user, les apps natives sous KDE/GNOME/OS X/Windows ont presque toutes le même look heureusement, et s'il y a personnalisation c'est léger, rien à voir avec le web. Il suffit de regarder le desktop que tu as sous les yeux hein.
Le protocole entre le client et le serveur n'est qu'une partie de l'architecture. En natif tu peux intégrer une lib torrent dans ton client procotole qui, oh, n'utilise pas HTTP, accéder à tout le matériel, à des fonctionnalités de l'OS inaccessible à un navigateur, etc etc …