Discussion :

[Christian Olivier]

Mithril : un framework JavaScript moderne, simple, rapide et léger comparé à React ou Angular
Pour ceux qui privilégient la facilité d'intégration

La plupart des frameworks modernes sont rapides et bien adaptés pour créer des applis complexes si vous savez les utiliser efficacement.

Mithril.js est un framework JavaScript moderne qui permet notamment de concevoir des applications monopage (single-page application ou SPA). Il est petit (moins de 8 Ko pour son archive gzip), rapide et fournit des utilitaires XHR et de routage prêts à l’emploi. Il bénéficie, en outre, du soutien d’une communauté active qui contribue depuis quelques années déjà à son évolution.

Mithril offre des possibilités similaires à Angular.js (support de la « composantisation » par exemple) tout en étant beaucoup plus simple à manipuler. Il utilise aussi une représentation interne du DOM (ou Virtual DOM) et se sert de JavaScript comme d’un mécanisme de contrôle de flux dans les vues comme React.js. Ce framework a l’avantage d’être plus léger que React ou Angular et évite d’avoir recours à des librairies tierces telles que jQuery.

Habituellement, un composant fait référence à une partie bien précise et autonome d’une interface utilisateur. Un composant Mithril pour sa part peut se décomposer en deux parties : un contrôleur et une vue. C’est juste un objet avec une fonction de vue. Les composants Mithril facilitent l’écriture de code modulaire. Signalons au passage que Mithril.js identifie automatiquement le moyen le plus efficace pour mettre à jour un code, plutôt que de le recréer aveuglément à partir de zéro.

Mithril pourrait être considéré comme la solution idéale pour créer des widgets JavaScript intégrés et des interfaces utilisateur ayant des exigences de performances élevées. Il permet aussi d’améliorer les performances des applications conçues pour la communication interactive en temps réel entre différents interlocuteurs. De plus, ce framework de développement est supporté par un très grand nombre de navigateurs (incluant Internet Explorer 9) et par toutes leurs versions mobiles.

Mithril est utilisé par de nombreuses sociétés reconnues (Vimeo, Nike ou encore Fitbit) et alimente également de grandes plateformes open source comme Lichess ou Flarum. Ce framework a même déjà permis de concevoir l’application de jeu Guild Wars 2. Son approche pragmatique de la création d’applications le destinerait aux développeurs qui privilégient la cohérence et la facilité d’intégration.

Pour plus d’information sur ce framework et pour avoir la liste exhaustive de toutes ses fonctionnalités, n’hésitez pas à consulter le site officiel.

Source : Mithril

Et vous ?

Qu’en pensez-vous ?
Avez-vous déjà utilisé Mithril ? Comment le trouvez-vous ?
Quel framework JavaScript utilisez-vous le plus actuellement ? En êtes-vous satisfait ?

Voir aussi

Angular : la version 6.0.0 du framework JavaScript de Google est enfin disponible, mais sans le nouveau moteur de rendu Ivy

La version 5.1 du framework JavaScript Angular est disponible, en même temps qu'Angular CLI 1.6 et la première version stable d'Angular Material

Facebook annonce la réécriture des composants internes de son Framework React Native pour faciliter son utilisation avec les applications hybrides

pache Foundation proscrit l’utilisation de licence Facebook comme celle de React

[pterrat]

J'ai eu l'occasion de tester ce nouveau framework, j'en dégage plusieurs points:

Architecture MVC

Tout comme React, Mithril fournit une approche MVC qui permet de pouvoir appréhender le framework rapidement.

Création de composant

Mirthil permet la création de composant avec un controller non requis. Si on prend le cas de React, nous devons étendre les classes. Dans le cas d'Angular, on est obligé de créer un composant exigeant un controler.

La documentation

D'après ce que j'ai pu voir, la documentation est assez complète pour un (si petit) framework.

La performance

L'avantage le plus important de ce framework. Ultra rapide (inférieur à 1ms, il me semble au load) Il devance largement Angular et React sur la performance.
Pour plus d'informations concernant les performances, je renvois à ton lien qui est excellent

Il me reste encore à tester les templates et le testing.

[ShigruM]

Moi je n'aime pas javascript ni ces nouveaux framework qui sortent chaque jour qui se veulent plus "moderne, simple, rapide et léger"

par contre je ne peut que recommander le nom donné a ce projet, il donne l'impression d'etre solide et léger, c'est la fibre de carbonne du monde fantastique.
de plus le Mithril est la matière qui nous protège des forces du mal à savoir Saumon


perso je préfère rester sur python car c'est 1 framework pour les gouverner tous, a savoir django.

question : existe t'il un framework pour coder en webassembly ? comme dit il y'a 10 ligne n'aimant pas javascript j'ai l'intention de ne plus coder en JS et de faire exclusivement sur web asm.
je cherche un framework web assembly qui soit moderne, simple, rapide et léger

[bouchery]

perso je préfère rester sur python car c'est 1 framework pour les gouverner tous, a savoir django.

Tu ne sembles pas avoir compris ce dont parle l'article

[archqt]

Moi je n'aime pas javascript ni ces nouveaux framework qui sortent chaque jour qui se veulent plus "moderne, simple, rapide et léger"

par contre je ne peut que recommander le nom donné a ce projet, il donne l'impression d'etre solide et léger, c'est la fibre de carbonne du monde fantastique.
de plus le Mithril est la matière qui nous protège des forces du mal à savoir Saumon


perso je préfère rester sur python car c'est 1 framework pour les gouverner tous, a savoir django.

question : existe t'il un framework pour coder en webassembly ? comme dit il y'a 10 ligne n'aimant pas javascript j'ai l'intention de ne plus coder en JS et de faire exclusivement sur web asm.
je cherche un framework web assembly qui soit moderne, simple, rapide et léger

Sauf erreur Django n'a pas encore réussi à passer du côté client et même si il propose (je n'ai pas testé) des widgets qui génèrent du javascript qui sera exécuté côté client (navigateur donc) il y aura forcément des cas ou il faudra faire du javascript.
Ou alors il faudra un "transpileur" qui permettra de tout coder en python mais comme le navigateur ne sait pas exécuter du pyhton il faudra forcément faire une transformation quelque part.

[Daïmanu]

Ou alors il faudra un "transpileur" qui permettra de tout coder en python mais comme le navigateur ne sait pas exécuter du pyhton il faudra forcément faire une transformation quelque part.

Un transpileur comme Brython ? (Découvert sur le chat aujourd'hui)
Brython est un interpréteur Python 3 sous forme de fichier javascript qui offre des méthodes pour manipuler le DOM.

[TrAsHeR]

grand fan des frameworks JS, je vais le testé, car je ne le connaissais, en tout cas il a l'air d'avoir un sacré potentiel avec une communauté exemplaire, donc à voir ;=)

[Jitou]

On va aller jusqu'où avec tous ces framework JS qui sortent tous les 6 mois ? Le dernier est plus mieux, il va révolutionner le secteur etc ... ça rime à quoi de changer et de réapprendre un nouveau paradigme à chaque nouveautés ? Pour l'instant je reste utilisateur de loisir et surtout spectateur de ces technos JS qui se cherchent et qui n'arrivent manifestement pas à satisfaire complètement leurs adeptes

[frfancha]

Moi je n'aime pas ces nouveaux framework qui sortent chaque jour

Ce framework est intéressant et vaut la peine de s'y arrêter, mais il n'est pas nouveau, c'est assez ancien en fait. Ce n'est pas vraiment une "news"

[frfancha]

On va aller jusqu'où avec tous ces framework JS qui sortent tous les 6 mois ? Le dernier est plus mieux

Sauf que ce n'est pas le dernier, c'est un vieux brol. Ce qui ne l'empêche pas d'être excellent.

[grunk]

On va aller jusqu'où avec tous ces framework JS qui sortent tous les 6 mois ?

6 mois ? t'es vachement optimiste ^^ : https://dayssincelastjavascriptframework.com/


Plus sérieusement l'argument du poids n'en ai pas un pour moi. On voit trop souvent l'argument de "Moi j'utilise X , il fait que Y ko" ... Ce que je vois surtout c'est que derrière tu as un package.json long comme le bras avec 5 mo de dépendance sauf que tu t'en rend pas vraiment compte. Au final ton appli est lourde et t'es pas capable de le solutionner parce que tu ne maîtrise pas les dépendances.

Perso ma préférence reste sur Angular 2 ,4 ,5 ,6 qui me convient mieux dans son approche. La façon de développer est plus proche de ce que je retrouve dans les autres langages que je pratique (et par conséquent plus éloigné de ce qu'on voit habituellement en js).

[Kikuts]

Juste un mot : woaw.

Je suis dév C# XAML (WPF/UWP/XF). J'ai toujours été allergique à JQuery (je préfère largement écrire du Vanilla JS).

J'ai testé vite fait à midi le tuto de Mithril. Il n'y a pas à dire. C'est autre chose que Angular & co. J'ai vraiment envie de tester ce framework.
Si en plus, les perfs sont bonnes et c'est très light, alors je suis preneur !

[Sonagno]

Moi je reste jquery

[oooopppp]

Salut à tous,
houlà, comme toujours ça s'annonce simple et ça donne vite mal au crâne ...

Personnellement je développe ma propre méthode de travail à base de fonction étendues en jQuery
qui me permet de faire aussi bien c'est comme avoir des classes on peut faire des appels de fonctions
comme $.send.mail_to_user(id); ( ou alors $.mon_back_office.send_mail_to_user(id); )

Et on se tape le luxe de se créer un objet JS toujours accessible en console (très pratique)
en tapant juste $.o (dans la console bien sûr!) [faut'il le remplir de quelque chose - voir suite]

Un peu de XHR, rien de méchant avec $.ajax,
un peut de routage à la html5 avec history.pushstate() / onpopstate() c'est pas trop compliqué non plus ...

Au milieu du sandwich, un contrôleur en PHP qui reçoit toutes les requêtes ajax ou non-ajax (très pratique aussi)

il contient un autoloader de classes qui charge toutes les classes de mon dossier ... classes ! (PHP offre une méthode qui permet de charger des classes super facilement)
dans le contrôleur j'appelle directement toutes mes classes, je m'en sert au besoin, celles-ci me renvoyant
des tableaux d'objet sous forme Json (ou pas ... selon le besoin),

par exemple une requête POST['set'] = 'init' (ajax) demande à une classe PHP de mettre en tableau et de renvoyer tout un objet JS
$.o avec tous les datas de l'application dedans [tu tapes $.o en cosole et tu as tout l'objet qui se déploie devant tes yeux ébahis ! )
ex:
$.o.datas_users[].nom;
$.o.datas_users[].prenom; etc ... on peut terriblement remplir notre objet !
-> le consulter à chaque instant en console
ex: en console -> $.o.datas_users[5].prenom; // Raf
et le changer pourquoi pas :
ex: $.o.datas_users[5].prenom = 'Fred'; // Fred

On peut boucler avec un forEach(function(item, key){ // do something }); (je suis très FAN!)
ex: $.o.datas_users.forEach(function(item, key){ // do something });

Bref c'est très rapide aussi, on a l'impression de travailler tout en fonctions et en objets en JS comme en PHP,
c'est simple à comprendre et c'est
redoutable d'efficacité ...

Ah, j'oubliais le templating avec Mustache - JS/PHP ça tombe bien car Mustache adore les tableaux / tableaux d'objets,

il suffit de passer notre objet à Mustache (et de lui dire quel template aller chercher, où l'afficher) [ou un tableau global pour Mustache PHP]
ça tombe bien car datas_users[] est déjà présent dans l'objet global $.o

$('#mes_petits_users').mustache('template_users', $.o);

ex : (dans le template_users.html )

{{#data_users}}
<li>
{{nom}} {{prenom}}
</li>
{{/datas_users}}
{{^datas_users}}
- Hélas, aucun user !
{{/datas_users}}

Et voilà le tour est joué, c'est mon petit framework perso., tout simple, tout puissant,
que j'appelle "Placido" de son petit nom.

Je me suis largement inspiré d'un framework qui s’appelle Chagry et
www.chagry.com.

Voilà, un framework en quelques lignes ! et sans prise de tête !
(enfin, la prise de tête t'en a suffisamment à t'en prendre ailleurs avec la logique).

Je développe actuellement un système de boutique en ligne avec -> "Placido Shop" - Bien sûr !
quand j'aurais fignolé la version béta,
je créerais un repository pour expliquer ma méthode
qui teint en quelques ligne en fait !

Pour conclure, je dirais que je vois pas mal de projets hipe - hypercool passer en REACT, Angular, VUE ou celui-ci bien nommé ,
qu'on ne sait pas comment va évoluer la techno, que les grands couillons du web n'arrivent pas à se mettre d'accord pour se réunir autour
d'une table et de nous concocter une méthode globale efficace, durable dans le temps et simple (par pitié !),
de fait pourquoi facebook, google et consors développent t'ils leur framework chacun de leur coté, je trouve cela stupide ! (boh, - moi aussi du coup !)

Je préfère utiliser (au risque de me faire rire au nez) des technos simples comme jQuery et PHP (pourquoi pas NODE, même, mais même mon
hébergeur, bien François, a du mal à l'implanter sur le serveur ... il faut faire tout un tas de conneries en console ... )

De plus tu peux y aller, beaucoup (vraiment beaucoup) seront capable de reprendre ton code sans difficultés.
Ma banque elle même utilise du jQuery sur son front-view ...

- 'Niang !

Une (Placido) console :

[Sodium]

Je suis et resterai sous Angular.
Ce framework a justement l'énorme avantage de pouvoir se passer de faire du JavaScript.
Il pallie ainsi au principal défaut de JavaScript, qui est justement d'être JavaScript.

Les premiers exemples de Mythril ne donnent clairement pas envie : c'est du bon gros JavaScript bien dégueulasse des familles avec des variables qui retournent des fonctions qui retournent des fonctions ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
var root = document.body
var count = 0 // added a variable
 
var Hello = {
    view: function() {
        return m("main", [
            m("h1", {
                class: "title"
            }, "My first app"),
            m("button", {
                onclick: function() {count++}
            }, count + " clicks")
        ])
    }
}
 
m.mount(root, Hello)

[blbird]

Je vais jeter un coup d’œil, mais pour moi, Vue.js a largement ma préférence sur React et Angular : il n'y a absolument pas photo.

Il est complet, très simple à appréhender, très bien documenté, ultra rapide, efficace, et possède énormément de passionnés qui font énormément d'outils complémentaires, en fonction de votre besoin. Rien que le Discord Vue.js c'est un plaisir pour discuter, avoir des infos et avoir des réponses : beaucoup de monde dessus dans toutes les langues.

Quand je lit dans le comparatif de Mihtril vs Vue : "Vue is a view library similar to Angular". WTF? Il n'y a juste rien à voir entre Angular et Vue... Déjà ca commence très mal.

[psychadelic]

ça ne fait jamais qu'un framework js de plus...

On est contents, mais pour un dev le vrai problème, c'est d'utiliser un framework que tout le monde connais, histoire de profiter du partage de connaissance et d'informations sur le sujet.
Si c'est pour être tout seul à maintenir du code fait un truc génial, mais que personne ne comprend, alors ça va pas le faire.

Les outils et les technologie géniales qui devaient tout écraser sur leur passage, il y en à une sacrée collection.

[manuscle]

Encore un ènième framework JS .....

[nhugodot]

A ceux qui crient 'encore un framework du jour ?' : j'ai été comme vous mais finalement, c'est comme dire à un artisan 'tenez j'ai créé un nouvel outil / boîte à outil' 'ou un enfant' tiens, après duplo Lego etc j'ai inventé unr autre boîte de briques vis etc ! ': pour chaque besoin et compétences, sa solution / boîte à outils. Mithril ne répond absolument pas au même cas d'usage et besoins qu' Angular.

Nous avons essayé et développé la même solution (chat de groupe, photo, mobile et desktop, alertes, notifications...) en vanilla JS, Ionic (angular inside), Vue, et sommes en train de le refaire en React... : conclusion : si c'était à refaire, on aurait fait le proto asap en pur JS, suffisant, responsive, et basta, mais parce que le dev savait maîtriser parfaitement JS et qu'il n'y a rien de complexe dans ce type de SPA. Mais pour l'industrialiser sur Android et iOS, avec notifications et badges sur icône, rien d'autre que React Native n'est assez mûr, efficace, semble t-il... (on a voulu faire moderne, essayer autre chose, éviter React dont la courbe d'apprentissage est plus dure que Vue ou les PWA, raté... Y'a toujours un point bloquant....)

On ne saurait se suffire d'un seul framework, comme un tournevis ne peut remplacer tous les outils, marteau agrafeuse colle etc à lui seul !

Ce que je reproche énormément à la communauté des développeurs de ces frameworks, c'est de ne pas préciser exactement non pas 'qui a la plus petite' (sic) mais à quels contextes (compétences, équipes, client, existant, problèmes, évolutions...) leur boîte à outil répond !

React n'est qu'une librairie de vue (et à introduit une nouvelle manière de faire, réactive) , Angular un vrai framework complet. Rien à voir. Une grande entreprise choisira Angular pour la standardisation poussée, complète, des méthodes de travail, outils, composants, interchangeable entre développeurs qui quittent et arrivent dans une équipe nombreuse, alors que React répondra o'us à la liberté et créativité d'une agence Web ou startup, sans besoin de standardisation aussi poussée, ni d'obligation d'utiliser les méthodes outils et composants imposés et tamponnés par le fournisseur officiel, Google. Il en va de même pour les Django, Symfony, et tout autre frameworks complets, mûrs. React n'est pas un framework. Il est parfaitement normal donc qu'Angular soit plus lourd, tout comme Playmobil est plus 'lourd' que Lego...

Concernant WASM, j'en espérais aussi beaucoup, et qu'un Django s'y mette et offre de court-circuiter JS.... Ou qu'un nouveau, plutôt qu'un ancien (qui à le mérite d'être mûr, robuste, documenté, etc.), comme Elixir (puissant, multiprocesseur, etc.) ou Pharo (ultra simple clair productif, français, cocorico) s'y mette.
Ou inversement qu'un langage 'front 'moderne (clair, multiprocesseur vu nos quad core ARM..., ce que JS ne sait pas exploiter) actuellement transpilable, comme Dart, Elm, ou ReasonML (du créateur de React, je crois beaucoup en ce dernier langage, issu de OcaML, cocorico again), passe du côté serveur de la force (Dart est aussi compilable tant côté client mobile - Flutter- que serveur et à des frameworks serveurs).
Compilé multiprocesseur d'un côté (serveur, apps mobiles) , compilable binaire WASM d'un autre (navigateurs Web), full stack (comme MeteorJS, paix à son âme...), et un framework aussi complet et bien documenté que Django...?

Le bazar vs la cathédrale : JS vs Python, Node vs Django, Web vs l'Apple appstore, React vs Angular, le PC vs le Mac, Android vs iOS, les freelance vs les grandes équipes informatiques internes avec du legacy à maintenir... Chaos créatif vs organisation solide et pérenne. Y'a de la place et des besoins pour les deux modèles...!

Si vous n'êtes pas content, changez de côté de la Force

Bon, qui se colle à une page Web de '' quel framework pour quels use case '? (ToDoMVC n'est pas encore ça...)

Merci !

[kantin34]

Bonne analyse de la situation ,chaque tech a ses avantages ni plus ni moins

A ceux qui crient 'encore un framework du jour ?' : j'ai été comme vous mais finalement, c'est comme dire à un artisan 'tenez j'ai créé un nouvel outil / boîte à outil' 'ou un enfant' tiens, après duplo Lego etc j'ai inventé unr autre boîte de briques vis etc ! ': pour chaque besoin et compétences, sa solution / boîte à outils. Mithril ne répond absolument pas au même cas d'usage et besoins qu' Angular.

Nous avons essayé et développé la même solution (chat de groupe, photo, mobile et desktop, alertes, notifications...) en vanilla JS, Ionic (angular inside), Vue, et sommes en train de le refaire en React... : conclusion : si c'était à refaire, on aurait fait le proto asap en pur JS, suffisant, responsive, et basta, mais parce que le dev savait maîtriser parfaitement JS et qu'il n'y a rien de complexe dans ce type de SPA. Mais pour l'industrialiser sur Android et iOS, avec notifications et badges sur icône, rien d'autre que React Native n'est assez mûr, efficace, semble t-il... (on a voulu faire moderne, essayer autre chose, éviter React dont la courbe d'apprentissage est plus dure que Vue ou les PWA, raté... Y'a toujours un point bloquant....)

On ne saurait se suffire d'un seul framework, comme un tournevis ne peut remplacer tous les outils, marteau agrafeuse colle etc à lui seul !

Ce que je reproche énormément à la communauté des développeurs de ces frameworks, c'est de ne pas préciser exactement non pas 'qui a la plus petite' (sic) mais à quels contextes (compétences, équipes, client, existant, problèmes, évolutions...) leur boîte à outil répond !

React n'est qu'une librairie de vue (et à introduit une nouvelle manière de faire, réactive) , Angular un vrai framework complet. Rien à voir. Une grande entreprise choisira Angular pour la standardisation poussée, complète, des méthodes de travail, outils, composants, interchangeable entre développeurs qui quittent et arrivent dans une équipe nombreuse, alors que React répondra o'us à la liberté et créativité d'une agence Web ou startup, sans besoin de standardisation aussi poussée, ni d'obligation d'utiliser les méthodes outils et composants imposés et tamponnés par le fournisseur officiel, Google. Il en va de même pour les Django, Symfony, et tout autre frameworks complets, mûrs. React n'est pas un framework. Il est parfaitement normal donc qu'Angular soit plus lourd, tout comme Playmobil est plus 'lourd' que Lego...

Concernant WASM, j'en espérais aussi beaucoup, et qu'un Django s'y mette et offre de court-circuiter JS.... Ou qu'un nouveau, plutôt qu'un ancien (qui à le mérite d'être mûr, robuste, documenté, etc.), comme Elixir (puissant, multiprocesseur, etc.) ou Pharo (ultra simple clair productif, français, cocorico) s'y mette.
Ou inversement qu'un langage 'front 'moderne (clair, multiprocesseur vu nos quad core ARM..., ce que JS ne sait pas exploiter) actuellement transpilable, comme Dart, Elm, ou ReasonML (du créateur de React, je crois beaucoup en ce dernier langage, issu de OcaML, cocorico again), passe du côté serveur de la force (Dart est aussi compilable tant côté client mobile - Flutter- que serveur et à des frameworks serveurs).
Compilé multiprocesseur d'un côté (serveur, apps mobiles) , compilable binaire WASM d'un autre (navigateurs Web), full stack (comme MeteorJS, paix à son âme...), et un framework aussi complet et bien documenté que Django...?

Le bazar vs la cathédrale : JS vs Python, Node vs Django, Web vs l'Apple appstore, React vs Angular, le PC vs le Mac, Android vs iOS, les freelance vs les grandes équipes informatiques internes avec du legacy à maintenir... Chaos créatif vs organisation solide et pérenne. Y'a de la place et des besoins pour les deux modèles...!

Si vous n'êtes pas content, changez de côté de la Force

Bon, qui se colle à une page Web de '' quel framework pour quels use case '? (ToDoMVC n'est pas encore ça...)

Merci !