 |
| Google Chrome | |
| johnatemps | 2-Sep-2008/22:52:22+2:00 |
| Je viens de découvrir la BD de présentation de Google Chrome ici : http://www.google.com/googlebooks/chrome/ Et... je ne peux m'empêcher de penser à rebol, en lisant des keep it simple, du multiplateforme, et cette migration grandissante de l'os au navigateur. ça me touche d'autant plus directement, que je code encore en rebol certains projets, et que j'envisage de plus en plus de migrer vers la solution appliweb javascript (encore plus simple à installer, car directement opérationnelle, un peu comme certains avec le flash) Evidement, les libs javascript, la manipulation des dom css, et autres appels complexes à la ajax, c'est pas simple à gérer, ni à (d)écrire. On aurait bien envie de pouvoir écrire du rebol, et sortir une appli web, à la magic ammélioré quoi, avec le code serveur en rebol, le code client en javascript généré, et l'interface html/css décrite à la vid-like Mais je vais aller me coucher, et demain j'aurai oublié ce rêve gentillet. Google n'a pas acheté RT, et RT n'a pas les moyens de ses ambitions. Dans un monde parallèle, peut-être... | |
| shadwolf | 3-Sep-2008/13:17:46+2:00 |
| marrant j'ai eu lameme réaction enlisant cette BD ... | |
| GreG | 3-Sep-2008/20:17:36+2:00 |
| Certainement. On appelait cette revolution le web 2.0, mais comme ce sont finalement les frameworks javascripts qui se sont attribues ce nom, on parle maintenant de Web 3.0 L'enjeu est tellement enorme que le marche, faute d'entente cordiale, est completement morcele. On connait .net, Air, ... et biensur Rebol. Rebol est une solution tres elegante pour adresser le Web 3.0. Helas, il n'a pas le poids d'un Google ou d'un Microsoft... | |
| Philippe | 4-Sep-2008/15:24:35+2:00 |
| Salut, Comme je bosse depuis 1 an et 1/2 sur une suite de com' bâtie sur Dojo, et que je lis assez souvent les articles d'Ajaxian, je ne peux m'empêcher de réagir. Non, Ajax, les CSS, ce n'est pas simple. Aller voir les fichiers de code source des frameworks comme Dojo ou autres. Des milliers de ligne de code, dont une gross . Des mois qu'on travaille à tuner une appli : le poste client, les serveurs, les échanges XML-JSON et l'interprétation du DOM, les aspects réseau et les optimisations de tout poils (Ah les CSS Sprites !). En fait, je trouve que Javascript a eu de la "chance" d'être intégré aux navigateurs. Aujourd'hui la grosse tendance à mon avis, c'est de mettre dans les navigateurs d'autres langages (Python, en plus de JS, Ruby ..erlang ?). (certaines pages de Google qui sont en Python). Mais RT y a pensé aussi de son côté : en 2006 avec le plugin, Carl se faisait déjà la réflexion (article 247 "Also, this year, we have a much bigger REBOL project that we will be putting into web browsers, but that's a secret right now."), et récemment, il me semble qu'il en a reparlé dans le remaniement de la console qui serait une sorte de mini-browser. Egalement, Dockimbel travaille sur un Framework permettant de séparer HTML du code Rebol (Voir la discussion sur le forum Altme Cheyenne). Rebol c'est simple, léger, facilement debuggable. Ce n'est pas les idées qui manquent, c'est le temps, le nombre, la publicité, le grain de je-ne-sais-pas-quoi qui permettrait à Rebol de décoller : enfin, ce débat, on l'a déjà eu 1000 fois non ? Et toujours pas de recette miracle. ===Philippe | |
| Philippe | 4-Sep-2008/15:25:42+2:00 |
| Des milliers de ligne de code, dont une grosse partie va atterrir sur votre navigateur. | |
| rosanoff | 5-Sep-2008/8:44:26+2:00 |
| Bonjour, Juste une petite constatation : Par mesure de sécurité de plus en plus de personnes bloquent le javascript et autres plugins. Moi j'utilise rebol "cheyenne" html et css et comme bases ou "mysql" ou "rebdb". il faut juste bien gérer le css pour optimiser le cache côté client. Pour la sécurité sur le serveur il faut bien contenir les renseignements reçus. C'est vrai que cela n'est pas obligatoirement simple mais face aux trous de sécurité des langages côté client j'ai tranché. C'est vrai aussi que de ne pas utiliser ajax ou autre ressemble à un retour en arrière. Mais quand vous expliquez à votre clientèle que c'est pour sa sécurité, qu'elle n'a pas à changer ses machines et que cela ne ralenti pas le travail, elle est partante. Donc actuellement je suis contre l'utilisation d'un langage côté client. | |
| drikc | 6-Sep-2008/1:11:23+2:00 |
| Oui, "Rebol c'est simple, léger, facilement debuggable. " Le soucis dans mon cas spécifique c'est que j'utiliserais plus que volontiers rebol pour des projets web mais je suis freiné par le déployement via .cgi. Si on pouvait utiliser le mode fastcgi ou un module apache ce serait vraiement un +. J'imagine que si rebol était un peu plus "open source" on aurait déjà un module apache ou l'interface fastcgi (oui je sais, disponible en rebol command à 350$) cela aurait peut-être contribué à populariser le langage... Et Rebol2 en open-source dès maintenant ce serait (trop) tard mais peut-être bien. Ah, le modèle économique de rebol, pas comme les autres... Pour moi rebol a déjà atteint ses objectifs conceptuels depuis longtemps : - Léger - Riche - Simple - Multiplateform (enfin ça c'est devenu un peu moins super dernièrement) Certes, rebol3 amène sans conteste sont lot d'amélioration. En attendant je trouve assez décourageant d'utiliser rebol2 en l'état des choses et rien n'est moins sûre que l'apprentissage de rebol soit un bon investissement! ++, drikc un peu snif. | |
| Philippe | 6-Sep-2008/16:06:24+2:00 |
| Salut, Pour le web+cgi avec Rebol, on ne le redira jamais assez, il existe des solutions : Cheyenne de Dockimbel est un bijou de vitesse et de simplicité en serveur web, et il existe des solutions clés en main. EasyRebol, Magic, etc sont des exemples.. ===Philippe | |
| drikc | 6-Sep-2008/17:42:12+2:00 |
| Oui je connais l'existence de Cheyenne et j'utilise Magic. Il s'agit juste des déploiements possibles : - en cgi c'est facilement utilisable chez n'importe quel fournisseur, c'est bien mais ça peut ne pas être une bonne solution si l'on veut répondre à une certrtiane charge. Et selon la complexité du service cela devient coûteux de charger un contrôleur complet à chaque requête. - en fastcgi ben il faut se procurer "command" (US350$) - Cheyenne faut louer un serveur dédié(virtuel ou pas) sur lequel on install Cheyenne. En fastcgi ce serait pas mal car c'est souvent disponible chez les fournisseurs ou au pire ils seraient d'accord de l'installer le module. by, drik. | |
|
Login required to Post. | |