ExtJS va-t-il mourir? [fermé]
https://stackoverflow.com/questions/1633406
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je regarde ExtJS, qui semble fournir de nombreuses fonctionnalités RIA proposées par des suites plus volumineuses telles que Flex, sans nécessiter de flash. Cependant, alors que les initiatives Open-source telles que jQuery-UI se poursuivent, ExtJS va-t-il simplement mourir à un moment donné? De plus, comme la pénétration du flash ne cesse d’augmenter, pourquoi placer des actions dans une bibliothèque javascript?
Cela étant dit, les bibliothèques JavaScript telles que jQuery ont fait des pas de géant en fournissant des API faciles à utiliser et très fonctionnelles, alors il y a peut-être un intérêt à cela.
Des pensées? Des avis? ExtJS a un prix, je dois donc poser cette question.
La solution
IMHO, le besoin de jQuery, ExtJS, etc. sera éliminé dès que XBL2, toute la collection de spécifications CSS3, SVG et HTML5 seront tous disponibles dans la même mesure sur tous les navigateurs Web pour ordinateurs de bureau / mobiles, ce qui ne se fera pas à rendre dans les 5 prochaines années.
Je regarde ExtJS, qui semble fournir de nombreuses fonctionnalités RIA proposées par des suites plus volumineuses telles que Flex, sans nécessiter de flash.
Pour exécuter l'application Flex, vous avez toujours besoin de Flash Player, qui n'est par exemple pas disponible sur les appareils mobiles
.Cependant, si des initiatives Open Source telles que jQuery-UI se poursuivent, ExtJS va-t-il tout simplement mourir à un moment donné?
Comparer ExtJS à jQuery-UI n’a pas de sens, car jQuery est avant tout une bibliothèque multi-navigateurs destinée à simplifier les opérations sur les documents HTML et à rendre les pages Web plus agréables, tandis que ExtJS est un véritable framework d’application qui apporte des données améliorées. des composants d'interface utilisateur pilotés pour faciliter les applications.
En outre, la pénétration du flash ne cessant d'augmenter, pourquoi placer des actions dans une bibliothèque javascript?
Peu importe que la pénétration de Flash "continue à augmenter", car elle est déjà disponible sur 98% des ordinateurs de bureau. Mettre du stock dans une bibliothèque Javascript prend sens, selon Google (qui a mis la majeure partie de son stock dans DHTML)
ExtJS va-t-il simplement mourir à un moment donné?
En effet, comme à un moment donné, Internet, Java, etc. mourra, il ne mourra pas dans un avenir prévisible, cependant, et la nécessité de ce type de solutions sans chair augmentera encore.
Vous pouvez également consulter un vaste kit de développement logiciel , qui passera à Open Source sur 1er novembre de cette année. Il permet l'utilisation de technologies telles que SVG, XUL et plus encore d'un navigateur à l'autre.
Autres conseils
Je ne pense pas qu'Ext JS mourra de si tôt. Quand ce sera fait, ce sera probablement l’un des derniers cadres JS existants. Je dis cela parce qu'ExtJS dispose d'une base solide d'utilisateurs et de développeurs et que de nombreux projets open source le construisent (par exemple, un CMS sous licence ASP.NET, Sense / Net construit son backend entièrement autour de celui-ci entre autres).
Ils ont une base d'utilisateurs solide et je ne les vois pas quitter la course de si tôt. Cela dit, vous pouvez toujours regarder Internet comme vous regardez le marché en général. Starbucks et le café local peuvent coexister.
Cela dit ...
Je ne suis pas un gourou javascript / DOM, je suis juste un programmeur ASP.NET et un codeur FlashBuilder qui se penche maintenant sur des bibliothèques 100% côté client. Ce que je constate, c’est que ExtJS est beaucoup plus riche en jNuery que jQuery - bien que jQuery ait beaucoup d’élan et que de nouveaux composants d’UI apparaissent tout le temps. Néanmoins, ExtJS a une avance importante à cet égard.
Avec jQuery, il est beaucoup plus facile d’obtenir quelque chose de base, principalement parce que jQuery suspend ses effets sur les éléments existants dans le balisage de votre page: vous pouvez créer une page HTML squelettique, puis appliquer la fonctionnalité jQuery aux éléments. Comparez cela à ExtJS où votre page est essentiellement une balise body vide et le contenu de la page est créé en écrivant Ext dans le DOM. Sans Ext (visual) Designer pour disposer mes pages et définir les propriétés, coder des objets de configuration ExtJS avec un éditeur de texte est beaucoup trop fastidieux pour moi et pas du tout à mon goût. Mais avec Visual Designer de Ext, vous vous approchez de RAD.
ExtJS sur IE8 peut être lent et bâclé à cause des faiblesses de IE8. D'après mon expérience, les mises en page ExtJS RIA fonctionnent parfaitement sur FF, Chrome et Opera, mais pas aussi bien sur IE8. Cependant, IE8 avec Google Chrome-Frame répond à cela. Bravo aux propriétaires de MSFT, aux gars de Google!
J'aime beaucoup l'approche hybride adoptée par FlashBuilder. Avec FB, vous pouvez écrire des classes mxml et / ou ActionScript. L'inconvénient, à mon sens, est que le plug-in Flash est nécessaire, et je crains que celui-ci ne se comporte comme un autre dodo, WordPerfect, qui parcourait autrefois la planète avec une part de marché de 99%. . J'aimerais vraiment que l'on puisse concevoir dans FlashBuilder en tirant pleinement parti des fonctionnalités OO d'ActionScript. mxml et le débogueur FB, puis compilation croisée sur ExtJS! FB: Ext :: GWT: Closure.
Comme avec chaque technologie, chacun aura son propre morceau de gâteau. ExtJS ne mourra pas tant que ExtJS LLC n’existera pas (ils l’utilisent :)) et jusqu’à ce que des fidèles utilisent leur lib (comme moi) lorsque vous êtes à un moment donné. Vous devez simplement utiliser la technologie choisie, qu’elle soit parfaite ou non. ne pas. Regardez Lotus Domino - c’est un morceau de merde et, d’autre part, un logiciel génial - et il est toujours vivant ...:)
ExtJS a une double licence et sa source est ouverte
Et je l’utilise. Une bonne bibliothèque pour travailler avec des données - grilles, arbres, etc. Et il a beaucoup de contrôles. donc juste une bonne bibliothèque ...
Tant que les développeurs continueront à travailler dessus, le framework ne mourra pas. Quelques cadres sont effectivement morts (par exemple, MochiKit, que j'aime mais que j'ai abandonné pour la première fois), mais cela signifie simplement qu'ils ne sont pas mis à jour, pas inutilisables. Si vous en préférez une, vous pouvez facilement sortir votre propre version et relancer le projet.
Personnellement, j'utilise Prototype, mais c'est le même argument. Je n'aime pas vraiment le flash en raison des nombreux problèmes de sécurité qui le suivent et du fait que tous les appareils ne peuvent pas lire le flash. L'iPhone est un exemple majeur. Il PEUT prendre en charge des animations et autres choses utilisant des bibliothèques JS.
Certaines entreprises désactivent également Flash en tant que stratégie de sécurité, bien que cela ne soit pas si courant. (J'ai toutefois travaillé dans des endroits où c'était le cas.)
Une autre question est de savoir si nous allons nous intéresser à Flash avec l’avènement des nouvelles normes HTML, ce qui éliminera en grande partie le besoin de Flash.
