On aborde ces nouveautés complètement différemment.
Tu as un point de vue purement utilisateur, et en cela on est d'accord sur à peu près tout ce que tu dis.
A un point près, qui n'a rien à voir avec l'expérience utilisateur,
J'ai l'impression que la défense des "techno web" est contradictoire:
…
-d'un autre côté, dès qu'on dit ça, on réponds "oui mais non, en fait, les techno web sont des applications natives avec un framework basé sur l'html5 et le javascript", mais dans ce cas, en quoi est-ce différent des applications natives traditionnelles (déployée et maintenue à jour via le gestionnaire de dépôt) ?
Ah oui définitivement les technos web n'ont rien inventé. Le principe ajax par exemple c'est faisable en .net ou Qt. Les designs patterns sont les mêmes. Les pratiques de tests et contrôles identiques.
Juste un détail mineur.
Toutes les technos desktop, disons client lourd, sont des tueurs de créativité.
C'est à dire que de part leurs degré de complexité, ces technos sont inaccessible à tout un tas de gens qui ont le besoin, ou le désire, d'écrire une application.
Et ça le HTML, c'est une des raisons de son existence, de son succès. On pensera par ailleurs à php dans la même veine.
C'est le petit détail mineur qui me semble être un killer feature.
Pour le reste, j'ai le sentiment que ce virage, c'est aussi le moment de repensé l'intégration du bureau dans l'écosystème logiciel d'aujourd'hui.
Avant on se fiché d'internet, après on à eu msn, pis vint l'intégration de facebook, twitter ect dans le bureau. Là on en est au moment où le web entre dans le bureau, et pour que ce soit possible, les développeurs webs ont juste besoin d'avoir des spécifications de webservice à suivre.
Hors ce travail là, c'est au développeur de l'OS de le fournir.
C'est du niveau des variables de PATH.
Un problème très concret, j'ai besoin de lancer une instance Java, en mode multiplateforme.
Aujourd'hui pour ce faire, en bash, cela donnes :
OS_TYPE=`"$UNAME" -s`
# ---------------------------------------------------------------------
# Locate a JDK installation directory which will be used to run the IDE.
# Try (in order): WEBIDE_JDK, JDK_HOME, JAVA_HOME, "java" in PATH.
# ---------------------------------------------------------------------
if [ -n "$WEBIDE_JDK" -a -x "$WEBIDE_JDK/bin/java" ]; then
JDK="$WEBIDE_JDK"
elif [ -n "$JDK_HOME" -a -x "$JDK_HOME/bin/java" ]; then
JDK="$JDK_HOME"
elif [ -n "$JAVA_HOME" -a -x "$JAVA_HOME/bin/java" ]; then
JDK="$JAVA_HOME"
else
JAVA_BIN_PATH=`which java`
if [ -n "$JAVA_BIN_PATH" ]; then
if [ "$OS_TYPE" = "FreeBSD" ]; then
JAVA_LOCATION=`JAVAVM_DRYRUN=yes java | "$GREP" '^JAVA_HOME' | "$CUT" -c11-`
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
elif [ "$OS_TYPE" = "SunOS" ]; then
JAVA_LOCATION="/usr/jdk/latest"
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
elif [ "$OS_TYPE" = "Darwin" ]; then
JAVA_LOCATION=`/usr/libexec/java_home`
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
fi
if [ -z "$JDK" -a -x "$READLINK" ]; then
JAVA_LOCATION=`"$READLINK" -f "$JAVA_BIN_PATH"`
case "$JAVA_LOCATION" in
*/jre/bin/java)
JAVA_LOCATION=`echo "$JAVA_LOCATION" | xargs dirname | xargs dirname | xargs dirname` ;;
*)
JAVA_LOCATION=`echo "$JAVA_LOCATION" | xargs dirname | xargs dirname` ;;
esac
if [ -x "$JAVA_LOCATION/bin/java" ]; then
JDK="$JAVA_LOCATION"
fi
fi
fi
fi
if [ -z "$JDK" ]; then
echo "ERROR: cannot start PhpStorm."
echo "No JDK found. Please validate either WEBIDE_JDK, JDK_HOME or JAVA_HOME environment variable points to valid JDK installation."
echo
echo "Press Enter to continue."
read IGNORE
exit 1
fi
pour trouver
un simple chemin d'accès,
d'un exécutable disponible sur 90% des appareils,
et l'exemple ne concerne que le monde linux friendly.
Honnêtement, on peut faire plus simple ?
-- Et je dirais même,
-- on peut faire simple à consommer pour le développeur d'application, et plus libre à développer pour le développeur système.
Bon bah le développeur de demain il à besoin de disposer d'un set de services simples et fonctionnels pour réaliser des tâches communes, récurrentes afin de laisser sa créativité parler.
Plutôt que de perdre son temps à gérer ces querelles d'informaticiens, ou bien encore des détails d'implémentation technique du style "out of memory".
Ces choses qui tuent la créativité instantanément par irradiation mortelle.
-le fait que le service soit centralisé sur des serveurs ayant peu de chance de tomber en panne est un inconvénient: cela signifie que les minorités n'auront pas droit à un outil qui correspond à leur gout et méthode de travail.
J'ai pas bien compris car aujourd’hui si je veux me monter un travis (serveur d'intégration continue) spécifique, je suis obliger de prendre le code, de le descendre et de le setup sur ma machine. De le personnaliser et enfin de le déployer sur une autre machine pour le mettre à dispo de ma communauté.
Demain, j'aurais une signature de webservice pour l'ui.
une définition d'implémentation pour le serveur.
Après, soit le webservice n'est implémenté que de manière fermer, et n'est consommable que via un seul provider.
Soit j'ai à disposition une version libre de son implémentation me permettant de déployer le serveur à ma guise.
Mais dans tous les cas, à minima, mon ui en est indépendante de son implémentation physique et logique, multi device, hébergée en ligne / hors ligne ect ect
bref je peux me brander,
et pour peu que je soit un mec cool, je mets à disposition mon implémentation du serveur pour que chacun puisse le déployer dans son coin.
Bon de toute façon,
le html et ses potes s'imposera.—Notes que, non ce n'est pas un troll, mais que oui, c'est une affirmation sans fondements évident.
Alors après oui on peut continuer à produire des Qt ou des GTK pour faire réaliser certains applications qui aujourd'hui nous semble hors de porter des technos web.
J'ai dans l'idée que ces gens là finiront par améliorer les technos web pour arriver à leurs fins et s'y intégrer, ne serait ce que par un effet mouton de panurge.
[^] # Re: en quoi l'interface de gmail justifie l'usage d'un service en ligne ?
Posté par maboiteaspam . En réponse au journal Les vieux cons et le progrès.... Évalué à -1.
On aborde ces nouveautés complètement différemment.
Tu as un point de vue purement utilisateur, et en cela on est d'accord sur à peu près tout ce que tu dis.
A un point près, qui n'a rien à voir avec l'expérience utilisateur,
Ah oui définitivement les technos web n'ont rien inventé. Le principe ajax par exemple c'est faisable en .net ou Qt. Les designs patterns sont les mêmes. Les pratiques de tests et contrôles identiques.
Juste un détail mineur.
Toutes les technos desktop, disons client lourd, sont des tueurs de créativité.
C'est à dire que de part leurs degré de complexité, ces technos sont inaccessible à tout un tas de gens qui ont le besoin, ou le désire, d'écrire une application.
Et ça le HTML, c'est une des raisons de son existence, de son succès. On pensera par ailleurs à php dans la même veine.
C'est le petit détail mineur qui me semble être un killer feature.
Pour le reste, j'ai le sentiment que ce virage, c'est aussi le moment de repensé l'intégration du bureau dans l'écosystème logiciel d'aujourd'hui.
Avant on se fiché d'internet, après on à eu msn, pis vint l'intégration de facebook, twitter ect dans le bureau. Là on en est au moment où le web entre dans le bureau, et pour que ce soit possible, les développeurs webs ont juste besoin d'avoir des spécifications de webservice à suivre.
Hors ce travail là, c'est au développeur de l'OS de le fournir.
C'est du niveau des variables de PATH.
Un problème très concret, j'ai besoin de lancer une instance Java, en mode multiplateforme.
Aujourd'hui pour ce faire, en bash, cela donnes :
pour trouver
un simple chemin d'accès,
d'un exécutable disponible sur 90% des appareils,
et l'exemple ne concerne que le monde linux friendly.
Honnêtement, on peut faire plus simple ?
-- Et je dirais même,
-- on peut faire simple à consommer pour le développeur d'application, et plus libre à développer pour le développeur système.
Bon bah le développeur de demain il à besoin de disposer d'un set de services simples et fonctionnels pour réaliser des tâches communes, récurrentes afin de laisser sa créativité parler.
Plutôt que de perdre son temps à gérer ces querelles d'informaticiens, ou bien encore des détails d'implémentation technique du style "out of memory".
Ces choses qui tuent la créativité instantanément par irradiation mortelle.
J'ai pas bien compris car aujourd’hui si je veux me monter un travis (serveur d'intégration continue) spécifique, je suis obliger de prendre le code, de le descendre et de le setup sur ma machine. De le personnaliser et enfin de le déployer sur une autre machine pour le mettre à dispo de ma communauté.
Demain, j'aurais une signature de webservice pour l'ui.
une définition d'implémentation pour le serveur.
Après, soit le webservice n'est implémenté que de manière fermer, et n'est consommable que via un seul provider.
Soit j'ai à disposition une version libre de son implémentation me permettant de déployer le serveur à ma guise.
Mais dans tous les cas, à minima, mon ui en est indépendante de son implémentation physique et logique, multi device, hébergée en ligne / hors ligne ect ect
bref je peux me brander,
et pour peu que je soit un mec cool, je mets à disposition mon implémentation du serveur pour que chacun puisse le déployer dans son coin.
Bon de toute façon,
le html et ses potes s'imposera.—Notes que, non ce n'est pas un troll, mais que oui, c'est une affirmation sans fondements évident.
Alors après oui on peut continuer à produire des Qt ou des GTK pour faire réaliser certains applications qui aujourd'hui nous semble hors de porter des technos web.
J'ai dans l'idée que ces gens là finiront par améliorer les technos web pour arriver à leurs fins et s'y intégrer, ne serait ce que par un effet mouton de panurge.
a+
PS
Je crois avoir bien dérivé du sujet….