"Mozilla pourrait être une victime collatérale de la défaite de Google aux États-Unis. La position dominante du géant de la recherche pourrait couper la fondation de 86% de ses revenus."
[…] Si Google n’a plus le droit de continuer de tels accords en raison de sa position dominante, Mozilla pourrait perdre l’accès à une part très importante de ses revenus.
J'en parlais dans les commentaires d'un autre journal au sujet de uBlock0 vs Chrome : Si la MOFO coule, est-ce qu'il n'est pas temps de sortir un beau navigateur tout neuf sur une base Webkit ? D'autres attendent https://ladybird.org/ mais Webkit est déjà là. Il faudrait un navigateur avec des conteneurs, sessions séparées par onglet, gestion avancée des onglets (stacking, disposition verticale, …), bloqueur de pubs efficace (pas gagné chez Safari),…
Ou peut-être que Mozilla retournera à ses premiers amours, une petite team proche des geeks et centrée sur les standards et la vie privée plutôt que sur «the next big thing» (l'IA après le Metaverse ou l'OS pour téléphones…)
Autre solution pas idéale : tout le monde chez Blink et les développeurs s'arrangent pour faire un navigateur respecteux par dessus (à la Brave sans la blockchain…)
Bref, je balance des trucs en vrac, je ne sais pas trop où l'on va ni où l'on devrait aller mais ça me saoule de devoir jongler entre les navigateurs parce que tel site a décidé qu'il était Chrome-only. Et de voir Mozilla se perdre dans je ne sais quoi.
Journal posté depuis Chromium parce que j'avais une visio Teams (ouille) et que ça ne marche pas dans Firefox (Ouillouillouille)
# https://www.mozilla.ai/
Posté par flagos . Évalué à 8.
J'adore ton site, quand je l'ouvre avec Firefox ca rame un truc de barge. Bon Chromium s'en sert a peine mieux pour etre honnete…
Ah c'est marrant ca. Pour ma part ca marche nettement mieux dans Firefox depuis plusieurs mois, je m'en sers tous les jours.
[^] # Re: https://www.mozilla.ai/
Posté par Faya . Évalué à 5.
Tu parles de Teams ? Ça fait longtemps que je n'avais pas eu d'invitations sur truc de l'enfer mais il y a environ 1 an ça ne fonctionnait pas du tout (le partage d'écran) donc aujourd'hui quand j'ai vu le lien Teams je suis passé direct sur Chromium. J'aurais ptêt dû réessayer.
[^] # Re: https://www.mozilla.ai/
Posté par Aldebaran (site web personnel) . Évalué à 2. Dernière modification le 08 août 2024 à 18:41.
Y a plus ou moins un an j'avais reussi à m'y connecter et à faire un partage en modifiant mon user agent pour immiter chrome. Mais de temps à autre ça foirait (sans info).
[^] # Re: https://www.mozilla.ai/
Posté par ted (site web personnel) . Évalué à 7.
J'ai occasionnellement des réunions sur Teams, ça marche bien avec Firefox aujourd'hui.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: https://www.mozilla.ai/
Posté par gUI (Mastodon) . Évalué à 10.
J'ai fait du 100% Microsoft sous Ubuntu/FF pendant 2 ans chez mon précédent employeur sans aucun soucis. Teams, Outlook, Office, nickel !
Tellement que je me demandais pourquoi la DSI continuait de proposer Windows par défaut, et Linux seulement en option (pour les devs en général).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: https://www.mozilla.ai/
Posté par Bruno (Mastodon) . Évalué à 2.
Obligé d'y passer pour des clients je confirme que teams fonctionne très bien sous Linux/firefox
[^] # Re: https://www.mozilla.ai/
Posté par khertan . Évalué à 1.
Question de paramétrage, la protection renforcée contre le pistage est elle activée en mode normal ou strict ?
En mode strict, teams ne fonctionne pas.
[^] # Re: https://www.mozilla.ai/
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'utilise Teams avec le mode strict : ça fonctionne !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# The next big thing
Posté par Aldebaran (site web personnel) . Évalué à 6.
C'est dommage ce qui se passe avec firefox, avec mozilla en general. Mais je dois dire que firefox os j'y ai cru, j'aimais bien mon zte open c.
En projet fous qui a bien reussi on a le rust aussi.
Je me demande si on ne devrait pas (les developpeurs) mettre plus les mains dans sous le capot de firefox ou de webkit. Je ne sais pas à quel point la base de code est horrible à reprendre, mais elle doit être à la fois, collossale, particulierement complexe et comporter pas mal de code historique plus ou moins documenté.
Peut être que ce serait plus simple de faire autre chose qu'un navigateur web standard, ou quelque chose de différent.
J'ai vu plusieurs articles ici sur HTMX, ça serait peut etre interessant de se passer du js et d'integrer HTMX dans un navigateur. Ne resterait "que" le code du rendu.
Mais c'est comme mes projets persos, je commenece un truc en me disant que telle approche sera plus simple et que ce sera facile et au final ça devient quand même une usine petrochimique.
[^] # Re: The next big thing
Posté par Thomas Douillard . Évalué à 10.
Le problème c'est pas, potentiellement, de faire des trucs simples genre gemini le problème c'est de faire migrer tous les utilisateurs du web dessus. Et potentiellement, en admettant que ça arrive, de garder la ligne (et les utilisateurs) si jamais (et ça ne manquera pas d'arriver) les demandes de fonctionnalités diverses et variées commencent à pleuvoir …
[^] # Re: The next big thing
Posté par wilk . Évalué à 7.
On pourrait très bien se passer de JS dans la grande majorité des cas et le peu qui pourrait être utile pourrait être intégré au html.
Quelqu'un travaille dessus par rapport à htmx :
https://github.com/alexpetros/triptych
Par contre il y a de telles évolutions dans le CSS que ça ne va pas arranger les choses.
[^] # Re: The next big thing
Posté par ff9097 . Évalué à 5.
Pas mal d'application interne d'entreprise sont des apps avec énormément de JS
[^] # Re: The next big thing
Posté par wilk . Évalué à 0.
La question est de savoir si ce JS était réellement indispensable. En app d'entreprise je n'en ai quasiment jamais besoin et le peu de cas où j'en ai besoin c'est pratiquement tout le temps remplaçable par htmx. Et même la plupart du temps les utilisateurs ne voient même pas la différence entre une page qui se réaffiche ou juste un morceau tellement c'est déjà rapide avec les réseaux actuels quand justement on ne s'encombre pas de futilités.
[^] # Re: The next big thing
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Remplacer du js par htmx qui lui même du js ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: The next big thing
Posté par wilk . Évalué à 3.
Non, l'idée du fil était d'intégrer les fonctionnalités de base de htmx au html, en natif (voir le lien que j'ai indiqué, la branche proposal).
Par exemple
<a target=xyz
xyz ne peut être qu'un frame, on est obligé d'utiliser JS pour avec un target vers un autre élément. L'idée est que target puisse être#id
et renvoyer vers un quelconque élément et qu'unbutton
puisse se comporter comme una
.J'ai fait un inventaire de mes applications, ça représente la quasi totalité des cas où j'ai du utiliser du JS (ou htmx).
Ceci dit je ne sais pas si c'est le JS qui pose problème pour écrire un browser… J'ai plus peur pour le css !
[^] # Re: The next big thing
Posté par antistress (site web personnel) . Évalué à 4.
Ya des éléments css qui ont permis de remplacer du JS pour faire des jolies choses depuis qq années, déjà
[^] # Re: The next big thing
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 12 août 2024 à 20:58.
https://devdoc.net/web/developer.mozilla.org/en-US/docs/CSS/CSS3.html
(Je grasse)
Ex : https://www.joshwcomeau.com/animation/css-transitions/
https://alvarotrigo.com/blog/css-page-transitions/
[^] # Re: The next big thing
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Bonjour,
Je maintiens le navigateur WebPositive de Haiku qui est basé sur WebKit. Je me rend la vie compliquée avec une version de WebKit fonctionnant sur un OS différent, et je dois donc maintenir tout un tas de choses en particulier au niveau du rendu graphique (branché sur nos APIs natives au lieu d'utiliser Skia ou Cairo comme tout le monde), par exemple.
Mais pour développer un navigateur pour Linux ou Windows, il n'y a pas besoin de ça: vous prenez la dernière version de GTKWebKit et cela vous fournit les APIs nécessaires pour développer un navigateur. C'est faisable sans toucher à 99% du code de WebKit.
Ensuite il sera toujours possible de commencer à creuser pour régler des problèmes. Mes contacts avec les développeurs de WebKit sont assez bons lorsque j'ai des questions. Ils utilisent Slack pour collaborer (c'est pas génial, je préférais quand il y avait un canal IRC, mais ça a été tué par le rachat de Freenode). Les contributeurs externes m'ont l'air plutôt bien accueillis.
Je ne sais pas du tout comment les choses se passent pour Firefox à ce niveau. Mais je sais qu'il n'y a pas d'API permettant de créer un nouveau navigateur utilisant le même moteur. Dans ce cas, il faudrait plutôt partir sur un fork de tout l'ensemble (moteur + navigateur) ce qui ne facilite pas la collaboration entre projets. Ou alors envoyer des patchs à Mozilla pour retirer les fonctionnalités pénibles (trackers, add-ons préinstallés, …) mais là, bon courage pour faire accepter les changements?
[^] # Re: The next big thing
Posté par HL . Évalué à 7.
Ah tiens, ils n'ont pas migré vers Libera.Chat du coup ? J'ai fait un tour là bas et il semble que le canal #webkit ne soit pas officiel.
[^] # Re: The next big thing
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Le coût d'entrée est important :
Côté Ladybird, ça a l'air d'être un socle plus classique C++/cmake/Qt, mais avec des pratiques un peu dégueu :pourquoi il faut installer des dépendances depuis des dépôts tiers (kitware, llvm) ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: The next big thing
Posté par freem . Évalué à 9.
Sinon y'a otter-browser qui est aussi basé sur C++/Qt/cmake. Pour ce qui est du moteur de rendu, il y a même le choix entre qtwebkit et un truc de qt, qui je pense intègre blink.
Bref, le simple fait qu'il supporte deux moteurs de rendus implique une certaine isolation entre les modules, généralement un plutôt bon signe en terme de qualité de code.
Pour l'avoir testé à plusieurs reprises, il fonctionne. Sur mon système il semble avoir un problème de lenteurs, et je ne dirais pas que tout est parfait, loin de la, mais bon, c'est le brouteur libre dans lequel j'ai le plus d'espoirs. Déjà l'auteur sait a qui il s'adresse, et sait qu'il ne peut pas jouer sur tous les aspects, donc j'ai l'impression que l'aspect principal est plutôt autour du contrôle, justement, de ce qui JS est autorisé ou non à faire, dans une interface moins hostile que la moyenne. Bon, en vrai, je sais qu'il s'agit d'un descendant spirituel d'Opera avant qu'ils ne détruisent tout.
Bref, ça pourrais être une piste pour d'éventuels intéressés.
# Si la MOFO coule, est-ce qu'il n'est pas temps de sortir un beau navigateur tout neuf sur une base W
Posté par totof2000 . Évalué à 10.
Mais pourquoi faire ? Je suis d'avis que d'avoir un moteur indépendant d'Apple par exemple est une bonne chose.
Bah … perso je ne reproche pas à Mozilla d'avoir tenté l'OS pour téléphone. Le truc c'est qu'ils n'auraient pas dû y aller seuls. Parce que perso, ça me gonfle bien qu'il n'y ait que deux acteurs sur ce segment. Peut-$être auraient-ils dû partir d'une base existante ou contribuer à un truc existant (Meegoo, Tizen ou autre …) et ne pas se cantonner aux téléphones mobiles et viser les cartes style raspberry pi, et les trucs comme les smart tv, les boitiers TV style androïd …. ils auraient même pu s'associer aux FAI pour équiper leurs box.
[^] # titre trop long
Posté par Faya . Évalué à 7.
Moi aussi mais bon, ça a l'air particulièrement compliqué de faire un moteur aujourd'hui. Je ne sais pas si c'est réaliste de partir de zéro. Safari est assez gros aujourd'hui pour que les devs y fassent attention et Webkit est libre. Donc je me dis qu'on pourrait capitaliser dessus pour ne pas retourner dans la situation "Installez Chrome pour visiter ce site".
Sinon j'avoue, FirefoxOS est un mauvais exemple quand on le met à côté de leur Metatruc et mozilla.ai, c'est vrai. Et ça m'a emballé à l'époque aussi même si j'avais déjà mon Noki N9 sous Meego (meilleur téléphone de l'histoire des téléphones…) C'est juste que c'est frustrant, surtout qu'ils l'ont sorti au moment où Chrome passait devant.
[^] # Re: titre trop long
Posté par totof2000 . Évalué à 5.
Mais pourquoi ne pas reprendre le moteur de firefox ? Pourquoi repartir de zero, ou d'un autre moteur ? Il n'est pas si mauvais queça le moteur de firefox non ? C'est ça que je ne comprends pas.
[^] # Re: titre trop long
Posté par Faya . Évalué à 4.
cf. Sébastien Wilmet plus bas, et d'autres commentaires ailleurs qui expliquaient que le moteur Gecko n'était pas vraiment séparable de Firefox. Je ne suis pas allé vérifier mais je fais confiance à pulkomandy par exemple, vu qu'il a les mains dans le dev de browser pour Haiku.
[^] # Re: titre trop long
Posté par Jérôme FIX (site web personnel) . Évalué à 6.
Mais est ce que c'est plus de boulot :
1. de séparer le Gecko/WebRender de Firefox ?
2. de tout recommencer à zéro ?
Parce que globalement aujourd'hui Firefox fonctionne plus que correctement.
[^] # Re: titre trop long
Posté par totof2000 . Évalué à 5.
Je pense que si on voulait séparer le moteur de l'IHM de firefox, tout en gardant la compatibilité avec firefox, ce serait compliqué, mais si on voulait refaire un truc from scratch, beaucoup de code de firefox pourrait être réutilisé et adapté.
[^] # Re: titre trop long
Posté par Renault (site web personnel) . Évalué à 10.
Pour info le navigateur de Sailfish OS en Qt utilise Gecko, comme quoi c'est possible.
[^] # Re: titre trop long
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 10 août 2024 à 23:30.
Dans mes messages j'ai comparé plutôt partir de WebKit et partir de Firefox. Je me suis jamais posé la question de recréer un truc à partir de zéro.
Même pour des besoins plus simple, on pourrait regarder du côté de NetSurf, dont l'équipe fait un très bon travail sur les performances pour les petites machines (utilisation mémoire qui se mesure en Mo et vitesse en MHz) ou de Dillo qui est à nouveau actif depuis quelque temps.
Donc, personellement, je n'envisagerai ni de partir de zéro, ni de regarder chez Firefox,parce qu'il y a pas mal de choix ailleurs et que, pour les autres moteurs, on ne parle pas d'un fork "dur", mais d'un truc où on peut collaborer avec l'upstream et intégrer facilement leurs développements. Sinon, on se retrouve assez vite dépassé, comme c'est arrivé il me semble à Classilla, Camino, Galeon, K-Meleon et autres navigateurs basés sur Gecko. Il reste peut-être PaleMoon, mais j'ai pas envie d'aller voir de ce côté à cause de l'ambiance et des opinions politiques des développeurs. Il est basé sur Firefox 52 et backporte certains trucs des versions suivantes mais conserve l'API XUL qui permet de construire des applications web utilisant le moteur (rebaptisé Goanna). Je ne sais pas trop quel est le résultat pour naviguer sur le web moderne.
[^] # Tizen, webOS et c'est tout.
Posté par Nico7as . Évalué à 4.
Il y a eu un paquet de tentative d'OS à l'époque.
Rares sont ceux à avoir une vie non confidentielle.
Tizen pour Samsung, et webOS passé de Palm, à HP, puis LG.
Je n'en vois pas d'autres.
[^] # Re: Tizen, webOS et c'est tout.
Posté par Epy . Évalué à 4.
Sailfish OS (Venant de Meego, lui même venant de Maemo et Moblin et dont Tizen est un frangin)
Ils (Jolla, anciens employés Nokia) ont un OS mobile qui fonctionne (et qui peut émuler Android) et des versions pour voiture et TV en developpement (avec un nom différent maintenant ?)
[^] # et pourtant
Posté par ben51 . Évalué à 4.
Justement firefox OS était sur smartTV, et il on un peut planté Panasonic en arrêtant le projet brusquement.
[^] # Re: Si la MOFO coule, est-ce qu'il n'est pas temps de sortir un beau navigateur
Posté par Renault (site web personnel) . Évalué à 6.
Mais ils ont tenté en dehors du téléphone et avaient techniquement des partenariats. Le soucis était ailleurs.
Ils l'ont dit qu'ils ont sous estimé la tâche devant eux, notamment les obligations règlementaires parfois bizarres de certains pays.
Pour moi ils avaient une belle base, j'aimais bien le système pour l'avoir testé. Le soucis c'est que globalement il n'y avait de facilement disponible que le ZTE Open C qui n'était pas une bonne configuration, trop légère. Cela est bien de proposer un téléphone pas cher pour tester ou développer rapidement sans trop investir, mais avoir un modèle plus haut de gamme d'accessible aurait été aussi important pour avoir des développeurs qui travaillent sur leur application en utilisant le téléphone au quotidien.
Puis il y avait de gros manques, le GPS pas à la hauteur alors que c'est une fonction de base, même le navigateur Firefox fourni était trop minimaliste ce qui est dommage car avec un nom pareil tu espères quelque chose de plus qualitatif.
Je pense qu'il y a toujours une place pour un système alternatif en soi, et reposer sur les technos Web peut être une bonne piste d'ailleurs car beaucoup d'applications mobiles affichent en fait un site web. Mais la barre reste haute et il faut des finances et du temps pour aller au bout.
# Autres navigateurs basés sur WebKit
Posté par Sébastien Wilmet . Évalué à 8. Dernière modification le 10 août 2024 à 13:00.
Il existe d'autres navigateurs web basés sur WebKit.
Basé sur WebKitGTK il y a :
- Epiphany (GNOME Web)
- Eolie (voir le tag eolie sur LinuxFr)
- Tangram
Dans KDE (donc basé sur Qt) il y a :
- Falkon (plus récent que Konqueror)
- Konqueror (qui fait aussi le café)
- Angelfish (pour smartphones et tablettes)
Le moteur de rendu de Firefox (Gecko, WebRender) n'est pas vraiment réutilisable en-dehors de Firefox, ce n'est pas développé comme un toolkit à part. Donc c'est pas pour rien que presque tous les autres navigateurs web (en GUI) sont basés sur WebKit.
Donc, pour répondre à la question du journal :
Il en existe déjà plein :-) Pas besoin d'en créer un nouveau. Il y a déjà suffisamment de projets comme ça, autant participer au développement d'un navigateur existant.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Psychofox (Mastodon) . Évalué à 8. Dernière modification le 10 août 2024 à 13:32.
Gnumdk a abandonné le développement de Eolie il y a déjà 3 ans. Du coup tu ne peux plus raisonnablement l'utiliser tel quel, il nécessiterait une dépoussiérage. Dommage j'aimais bien son interface.
On m'a dit dans l'oreillette l'autre jour que Falkon n'est plus basé sur webkit mais sur QTWebengine (blink). C'est à priori aussi le cas pour Angelfish après une rapide visite du code source.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par mahikeulbody . Évalué à 6.
Pour prendre l'exemple de Falkon (vu que je suis sous KDE), qu'est-ce qui lui manque par rapport à Firefox ? Autrement dit, y a t-il des raisons pratiques pour que je reste sur Firefox encore aujourd'hui ?
[^] # Re: Autres navigateurs basés sur WebKit
Posté par antistress (site web personnel) . Évalué à 10. Dernière modification le 11 août 2024 à 11:19.
En ce qui me concerne, il y en a de deux types : des raisons collectives — politiques et sociétales (promouvoir la diversité des moteurs pour éviter que 2 des GAFA ne décident de ce que doit etre le Web : c'est pas rien !) comme individuelles (protection de la vie privée, performances etc).
Un peu comme le bio, tiens (l'environnement ; ma santé immédiate)
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Jérôme FIX (site web personnel) . Évalué à 5.
Pareil.
Webkit, Chromium même problème. Ce n'est pas technique ils sont tous les deux très bon, mais rattachés à un des GAFAM et à un quasi monopole (les 17% de Webkit sont presque uniquement des machines sous IOS).
Il faut conserver à minima un troisième acteur dans le jeu : Firefox ou d'autres.
Réellement je regrette que Microsoft ai lâché la partie avec l'abandon de Trident (Internet Explorer), idem pour Opéra. Une répartition entre 15 et 30% de part de marché avec au moins 4 acteurs (même des GAFAMS) aurait été une bonne chose permettant l'innovation, obligeant au dialogue et aux compromis.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Internet Explorer/Trident comme moteur de l'innovation? Mouais, c'est plus compliqué que ça.
À l'époque, le w3c était fonctionnel: on avait oes versions majeures de html (la dernière étant la 4) avec un ensemble bien défini de fonctionalités. Même chose pour le css. L'innovation était donc plus lente, ou alors il fallait développer des sites fonctionnant avec les 3 ou 4 moteurs concurrents avec chacun leurs extensions non-standard.
Maintenant qu'on a un moteur dominant, Google peut unilatéralement innover des trucs dedans, et les autres courrent derrière pour rattraper. Les choses sont ensuites standardisées par le whatwg et ajoutées dans "html5" qui est en évolution perpétuelle.
De mon point de vue de développeur de navigateur, la différence se voit très bien. Autour de 2010, avoir un navigateur avec 4 ans de retard sur les concurrents ne posait pas trop de problèmes, parce que internet explorer 6 tirait les choses vers l'arrière et que le html4 était un standard fixe n'évoluant pas du tout. Aujourd'hui, si on ne déploie pas dans les 6 mois les dernières nouveautés et corrections de bugs, on a des sites qui se mettent à ne plus fonctionner.
Dans cet environnement complexe, assez technique, et ou l'innovation ne fait pas vendre (les navigateurs sont gratuits et les sites web gagnent surtout à s'afficher correctement partout), les règles théorique de l'économie et de la concurrence libre et non faussée ne s'appliquent pas.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Jérôme FIX (site web personnel) . Évalué à 4.
Non mon propos n'est pas de conserver Trident en l'état… merci j'ai vécu les affres des années 2000 sur le web !
Par contre de conserver un "gros" comme Microsoft comme développeur d'un troisième ou quatrième moteur de rendu différent cela a un intérêt !
Ils (et aucun des autres acteurs) ne pourront plus faire de la merde dans leur coin ou avancer seul car quand 60-70% d'un marché t'échappe tu discutes avec les autres acteurs et tu fais du standard.
Tu es entrain de dire qu'avoir un seul acteur c'est bien ? J'en crois pas mes yeux on est sur LinuxFR ?
On applique cela aussi aux OS, aux traitements de texte, … Tout serait tellement plus simple non ?
[^] # Re: Autres navigateurs basés sur WebKit
Posté par ted (site web personnel) . Évalué à 6.
Moi j'ai compris qu'il dit l'inverse
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Autres navigateurs basés sur WebKit
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Non, pour me faire dire ça, il faudrait penser que l'innovation, c'est forcément bien.
Je constate que, avec un quasi-monopole, Google peut se permettre de faire évoluer la plateforme web et jintroduire comme il veut plein de fonctionalités ou d'anti-fonctionalités, sans se préoccuper de discuter ça avec les autres imhlémentations.
Je suis bien hlus à lwaise dans un univers technologique qui évolue moins vite, en prenant le temps de ne faire que les évolutions qui sont nécessaires. Moins d'innovation, mais plus d'améliorations. Par exemple POSIX ou le langage C, avec une version tous les 5 ans, c'est un rythme qui permet d'anticiper. Si on avait une version majeure de HTML ou de CSS tous les 5 ans, ça serait mieux cue le bazar actuel. Tout en étant moins propice à l'innovation à coup d'extensions non standardisées.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Jérôme FIX (site web personnel) . Évalué à 2.
Donc on dit la même chose. Cela me rassure.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Psychofox (Mastodon) . Évalué à 5.
Dans mon cas c'est l'ecosystème qui est important. Je ne me vois pas vivre dans un bon adblocker configurable, une extension comme multicontainers, etc.
Le slam dunk serait qu'un dev arrive à faire un navigateur web qui supporte les extensions firefox sans réécriture de celles-ci.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Faya . Évalué à 7.
C'est tout de même un comble qu'on en soit à souhaiter que quelqu'un d'autre fasse un autre Firefox, avec les extensions de Firefox, alors que Firefox est déjà là… Finalement ce qu'il faut c'est réparer la MoFo. Mais est-ce que ça permettra d'avoir suffisamment de parts de marché pour que les dev web s'intéressent à la compatibilité ? En 2010 c'était suicidaire de faire un site qui ne marche pas sous FF. Les questions que je me pose :
[^] # Re: Autres navigateurs basés sur WebKit
Posté par barmic 🦦 . Évalué à 4.
Les navigateurs comme d'autres logiciels ont fini leur période d'innovation importante à mon avis. Maintenant les habitudes sont encrées, les usages ne bougent pas beaucoup. Les changements comme des onglets verticaux, hiérarchiques, sinusoïdaux ou en fractales de dimension N ça fait intéresse les utilisateurs qui sont sur brave, opera ou autre, ça ne fera pas venir la masse.
Ce qui est drôle c'est que peut être qu'un truc qui pourrait plaire c'est de l'IA en remplaçant ta page d'accueil par un prompt prêt à faire la recherche pour toi ou t'amener à un élément de ton historique ou à un de tes signets.
Je ne dis pas que c'est ce que j'attends mais si c'est bien fait. Un modèle de langage locale qui est entraîné spécifiquement et qui a ton place comme base de connaissances ça peu faire un truc face au quel je n'aurais pas grand chose à redire
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Un navigateur pourrait mémoriser les sites que j'ouvre le matin (genre Linuxfr.org), les actions que j'y fais (regarder les nouveaux comptes, les nouveaux contenus, les nouveaux commentaires, etc.), ceux que j'ouvre à un autre moment, m'aider dans ma veille, devenir mon assistant, me parler du contenu mais aussi des métadonnées et du code, suivre les infos qui fuitent, stocker/mémoriser/rechercher dans des pages capturées, lire/écrire/parler/traduire toutes les langues, offrir un mode léger pour réduire la conso électrique et de bande passante, s'intégrer mieux avec Wikipédia/OSM/OpenFoodFacts/…
Bref on peut toujours trouver des nouvelles fonctionnalités ou des besoins techniques (moins lourd, plus rapide, moins consommateur, plus stable, mise à jour à chaud, …)
[^] # Re: Autres navigateurs basés sur WebKit
Posté par barmic 🦦 . Évalué à 3.
Ce qui est vendu par les assistants IA des navigateurs comme :
(pour ce que je trouve en première page de mon moteur de recherche)
Tout n'existe pas encore, mais c'est clairement ce que je décrivais par l'IA et ce que le marché tente de faire et ce que le commentaire au quel je répondais demandait de ne pas faire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Autres navigateurs basés sur WebKit
Posté par Faya . Évalué à 2.
Effectivement j'ai écrit "pas de l'IA" mais je sous-entendais "pas nous sortir un autre LLM dont on ne sait pas encore exactement quoi faire", comme lorsqu'ils ont sorti leur metavers. La page mozilla.ai donne peu d'informations à part "develop AI agents to solve real-world use cases." Si ils trouvent l'un de ces use cases qui améliorerait sensibement l'utilisation de FF, pas de soucis mais bon je vais pas retenir ma respiration en les attendant. Et dans l'intervalle, oui une meilleure gestion des onglets je prends (rien que les grouper ! juste ça, tout le monde le fait sous Chrome et c'est très pratique).
[^] # Re: Autres navigateurs basés sur WebKit
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Sur les plateformes mobile (c'est là que beaucoup de choses se jouent désormais) il y a sûrement plein de choses à faire. La preuve, c'est que plein d'entreprises insistent pour développer des applications natives pour les téléphones, là où un site web conviendrait parfaitement. Si le site pouvait envoyer des notifications sans le garder dans un onglet ouvert. Si on pouvait facilement mettre temporairement une page en marque-page (par exemple pour y retrouver un billet de train dématérialisé, avec les infos si le train est à l'heure, etc).
Cela dit, après une ou deux décénnies de révolution constante des interfaces informatiques, on a peut-être aussi besoin de respirer un peu avant de plonger dans le prochain changement de paradigme?
[^] # Re: Autres navigateurs basés sur WebKit
Posté par barmic 🦦 . Évalué à 3.
Ca ne changerait rien. Parce qu'il y a toujours le "risque" d'être simplement affiché dans une webview et donc que rien de tout cela marche (pas parce que c'est pas à jour, mais parce que les webview ne sont pas de vrais navigateurs et ont un cycle de vie différent).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Autres navigateurs basés sur WebKit
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
C'est possible avec un service worker.
C'est possible aujourd'hui. Moi je le fais en enregistrant les liens ou les numéros de billet dans un mail pour les retrouver sur mes appareils et les partager avec les gens qui voyagent avec moi si je fais la réservation pour le groupe.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par barmic 🦦 . Évalué à 2.
Je crois pas qu'un navigateur mobile fasse tourner les service worker lorsque le navigateur lui-même est en background et je comprends très bien pourquoi.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Autres navigateurs basés sur WebKit
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
En théorie le poussage et la synchro périodique sont là pour ça.
A tester…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Autres navigateurs basés sur WebKit
Posté par barmic 🦦 . Évalué à 4.
En théorie, mais dans la vraie vie tu as des comportements comme ça https://stackoverflow.com/questions/76901306/why-dont-web-push-notifications-on-chrome-work-when-android-is-inactive
Chaque navigateur a sa petite tambouille pour tenter de ne pas être un tueur de batterie et chaque constructeur tente aussi sa petite sauce (pour toutes les applications, donc pour les navigateurs) pour tenter d'annoncer une durée de vie de la batterie pas trop court.
De loin la plus fiable des notifications est Firebase Cloud Messaging et elle est loin d'être fiable (pour de la notification sans activité utilisateur).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Servo
Posté par cosmocat . Évalué à 3.
Pour être exhaustif, il y a le moteur de rendu web Servo en cours de développement comme alternative.
https://servo.org/
Et un embryon de navigateur: https://www.osnews.com/story/140462/verso-a-browser-using-servo/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.