Alors que HTML est un gros hack. Si tu fait du natif, alors je vois pas l'interrêt de se restreindre au limitations du HTML qui est conçu pour faire des pages web.
Le bon gros mantra qu'on annone bêtement depuis 10 ans : « HTML c'est pas fait pour faire des applications », et que je commence franchement à avoir marre d'entendre. C'était sûrement vrai y'a 10 ans, mais plus maintenant. Faut savoir mettre à jour ses parti pris. Section 1.1 de la spécification HTML5 (Introduction, Background):
The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.
C'est la deuxième phrase du document. HTML5 a été explicitement conçu pour faciliter l'écriture d'application web. Une section complète (Section 6, Web application APIs) est dédiée aux applications Web.
Alors oui, je sais c'est "un gros hack". Ah bon. C'est ça l'esprit "hack", bidouille, détournement de l'usage initial cher aux libristes/hackers ? À la base tout était un gros hack, le language C n'était qu'un gros hack pour éviter d'avoir à écrire Unix en assembleur. Linux était une bidouille d'étudiant etc. La question n'est pas de savoir si HTML est fait pour faire telle chose, mais si HTML marche pour faire telle chose. Les applications web ont plein de bonnes propriétés par rapport aux applications natives: très facilement distribuables, collaboration entre plusieurs utilisateurs facilitée etc. Tout ça fait que beaucoup de gens développent des applications web, et donc des frameworks pratiques pour développer ces applications. On peut avoir envie de réutiliser des frameworks web ou même simplement les connaissances qu'on maîtrise (HTML, CSS, JS) pour faire des applications natives. Ensuite un moteur de rendu HTML + Javascript, c'est une base facile à utiliser pour développer son propre framework d'interface graphique.
Après, ça n'empêche pas de critiquer les limitations de HTML pour faire des interfaces graphiques (ex: communication particulièrement lourde via des appels HTTP entre l'UI et le cœur de l'application, lenteur de certains widgets complexes, complexité de la pile logicielle etc.). Juste l'argument de "c'est pas fait pour ça" est irrecevable.
[^] # Re: Qt, QML
Posté par X345 . En réponse au journal De l’utilisation des technologies web dans une application native.. Évalué à 8.
Le bon gros mantra qu'on annone bêtement depuis 10 ans : « HTML c'est pas fait pour faire des applications », et que je commence franchement à avoir marre d'entendre. C'était sûrement vrai y'a 10 ans, mais plus maintenant. Faut savoir mettre à jour ses parti pris. Section 1.1 de la spécification HTML5 (Introduction, Background):
C'est la deuxième phrase du document. HTML5 a été explicitement conçu pour faciliter l'écriture d'application web. Une section complète (Section 6, Web application APIs) est dédiée aux applications Web.
Alors oui, je sais c'est "un gros hack". Ah bon. C'est ça l'esprit "hack", bidouille, détournement de l'usage initial cher aux libristes/hackers ? À la base tout était un gros hack, le language C n'était qu'un gros hack pour éviter d'avoir à écrire Unix en assembleur. Linux était une bidouille d'étudiant etc. La question n'est pas de savoir si HTML est fait pour faire telle chose, mais si HTML marche pour faire telle chose. Les applications web ont plein de bonnes propriétés par rapport aux applications natives: très facilement distribuables, collaboration entre plusieurs utilisateurs facilitée etc. Tout ça fait que beaucoup de gens développent des applications web, et donc des frameworks pratiques pour développer ces applications. On peut avoir envie de réutiliser des frameworks web ou même simplement les connaissances qu'on maîtrise (HTML, CSS, JS) pour faire des applications natives. Ensuite un moteur de rendu HTML + Javascript, c'est une base facile à utiliser pour développer son propre framework d'interface graphique.
Après, ça n'empêche pas de critiquer les limitations de HTML pour faire des interfaces graphiques (ex: communication particulièrement lourde via des appels HTTP entre l'UI et le cœur de l'application, lenteur de certains widgets complexes, complexité de la pile logicielle etc.). Juste l'argument de "c'est pas fait pour ça" est irrecevable.