Hey tout, c'est plus une question de philosophie que tout. J'ai écrit ma première application Web, un calendrier d'événement Boston à http://bloozit.com que j'ai écrit en python et Je suis assez content de la simplicité de celui-ci, cependant, mon python contient des blobs de HTML, CSS et JavaScript, comme un ragoût avec des têtes de poisson et des globes oculaires qui y flottent.
Puis j'ai vu ce tutoriel sur les applications Web à l'aide de LISP: http://www.adampetersen.se /Articles/lispweb.htm J'ai lu sur Lisp et écrit certains logiciels dans Lisp, donc je ne suis pas Paul Graham, mais je le connais bien. Une chose qui m'appelle énormément fait était la manière dont l'auteur a généré à la fois le HTML et le JavaScript de LISP, ce qui rendait le tout agréable et homogène.
La question est la précieuse que l'homogénéité dans le monde réel? Chaque fois que quelque chose ne va pas, vous devez charger la page en Firebug, puis vous examinerez la source HTML, CSS et JavaScript générées, et non la source LISP, vous devez donc contenir la cartographie de votre tête. L'homogénéité fournie par LISP résout-t-elle vraiment quelque chose ou simplement du papier peint sur le problème, ce qui finit par tomber en aval?
S'il y a quelqu'un qui a déjà essayé les deux approches, je vraiment aime avoir de vos nouvelles!
3 Réponses :
Eh bien, j'ai passé un an codant avec le parenscript et le HT-AJAX et éventuellement abandonné et simplement généré le JavaScript à la main (toujours en utilisant Hunchentoot sur le serveur). J'ai constaté que le résultat était beaucoup plus prévisible et, comme vous l'impliquerez dans votre question, cela rendait beaucoup plus facile de déterminer ce qui se passait lors de l'utilisation de Firebug. (J'ai également changé d'utiliser JQuery, ce qui était beaucoup mieux que HT-AJAX, mais ce n'est pas vraiment ce que vous demandez).
Cela dit, je vous recommande massivement CL-Qui ( http://weitz.de/cl-who/ < / a>), qui rend la génération dynamique de HTML beaucoup Natre.
La question est, quelle est la valeur que l'homogénéité dans le monde réel?
Probablement assez significatif: Regardez toutes les personnes qui font du serveur JavaScript ces jours-ci. JavaScript n'est pas superlatif sur quoi que ce soit, et son support de bibliothèque pour le code côté serveur n'est pas aussi super, mais il y a de gros gains à avoir eues en l'utilisant.
Chaque fois que tout va mal, vous devez charger la page en Firebug,
dépend de ce que "n'importe quoi" est. Je ne me souviens pas réellement de la dernière fois que je devais ouvrir Firebug pour voir ce qui se passe mal - j'ai certainement été par phases où c'était, mais il y a aussi beaucoup de fois quand ce n'est pas.
Par exemple, si vous génèverez votre CSS à partir de S-EXPS, vous ne pouvez pas vous rendre compte que votre CSS ne vous permettra que de regarder le CSS "compilé" pour des problèmes de syntaxe étranges (comme IE6 Ticks). Si vous venez de regarder la page et de décider que vous avez besoin d'une bordure supplémentaire, vous pouvez ajouter
(: bordure 1) et être fait avec elle. (Bien sûr, si vous traitez cela pour générer un ensemble complet de règles CSS pour servir au client, c'est une victoire encore plus grande.)Une autre façon d'y penser: sur des occasions très rares, je devais retirer un sniffer de paquet et un désassembleur lorsque vous travaillez sur une application Web moderne. Ouais, ça craint, mais avec de bonnes bibliothèques, il est également très rare. Je ne préférerais pas écrire un code à bas niveau toute la journée juste pour éviter l'inadéquation d'impédance de passer à un sniffer de paquet sur une rare occasion lorsque j'ai besoin de ce niveau d'information.
Cela suppose que vous voulez et peut aller à un niveau où vous écrivez (v) code HLL. Les LISP communes ne peuvent pas battre C à être c, et si vous essayez simplement de cracher un simple blog en HTML, alors vous n'êtes pas dans la tache sucrée, non plus: les rails sont vraiment bons à ce genre de chose déjà. Mais il y a beaucoup de programmation expérimentale où pouvoir changer un indicateur et exécuter un code sur le client plutôt que le serveur est utile.
Ensuite, vous examinerez la source HTML, CSS et JavaScript générées, pas la source LISP, vous devez donc contenir la cartographie dans votre tête. L'homogénéité fournie par LISP résout-t-elle vraiment quelque chose ou simplement du papier peint sur le problème, ce qui finit par tomber en aval?
J'ai écrit les applications Web All-Lisp et All-JavaScript, et je pense que la meilleure réponse que je peux donner en ce moment est la suivante: c'est pourrait . J'ai utilisé la conversature et le problème majeur est que le parenlusion est un langage LISP-y, mais ce n'est pas commun LISP, ni une autre langue complète que vous puissiez utiliser du côté serveur. (S'il y avait une liaison commune au compilateur JavaScript, comme GWT est pour Java, alors ce serait génial. Je ne vois que personne d'essayer sérieusement de en faire un, cependant, vous l'avez encore, comme vous l'observe, Deux langues.
JavaScript est un peu mieux aujourd'hui, à cet égard, car vous pouvez exécuter exactement le même code dans les deux endroits. Ce n'est pas tout idéal parce que votre serveur-côté JavaScript dispose probablement de fonctionnalités que vous ne pouvez pas garantir existera sur le côté client (sauf si vous limitez vos utilisateurs à, dites, des versions récentes de Firefox). Si vous êtes comme moi, vous ne voulez pas limiter votre code de serveur à JS qui se déroulera dans chaque navigateur, de sorte que votre SERVER-côté JS et votre CLIENT JS seront subtilités différentes. Ce n'est pas un périficateur - c'est toujours assez gentil - mais c'est toujours 2 langues légèrement différentes.
Je pense que ce serait assez cool s'il existait un programme qui pourrait prendre le code écrit dans le dernier JavaScript (1.8.5) et généré JavaScript de la vieille école qui a couru dans n'importe quel navigateur. Je ne pense pas qu'un tel programme existe, mais je ne sais pas à quel point cela serait difficile.
Il existe des implémentations de système pour JavaScript, et peut-être que la situation avec le schéma est meilleure. Je devrais probablement regarder celui de ces jours.
Je suis souvent frustré lorsque vous devez utiliser un langage côté serveur qui est complètement différent de mon langage côté client (JavaScript). Mais alors je suis également frustré lorsque je dois utiliser une langue inférieure à la LISP (qui en est la plupart). Est-ce une plus grande victoire d'être plus liée à Lisp, ou plus de JavaScript? Je ne sais pas. J'aimerais avoir à choisir.
Ce n'est pas tant une réponse comme une opinion forte, mais le problème fondamental est que HTML et CSS sont tout simplement terribles (1). Non plus ce qu'il est censé être destiné à faire. JavaScript est meilleur et est souvent pressé en service pour compenser les lacunes de ces deux (2), mais ce n'est pas une solution idéale (3). Et en conséquence, les langages latéraux du serveur sont nécessaires pour générer HTML et CSS qui compliquent davantage le désordre. Il est risible que l'application Web la plus simple nécessite une programmation dans pas moins de quatre langues différentes.
Donc, oui, votre désir d'avoir un bon langage fiable qui que vous pouvez interfacer à la place de ces autres est compréhensible, mais tant que vous écrivez le code qui génère HTML / CSS tel que vous devez vous inquiéter des détails. de HTML et CSS, alors vous portez simplement des mitaines qui pourraient (lire "probablement") interférer lorsque vous allez jouer au piano. Si votre code LISP ressemble à ceci: (: Body (: Div (: @ (: Style (: frontière "1"))) (: P "Bonjour"))), alors tu n'es pas vraiment libre des préoccupations qui vous peste.
Personnellement, je pense que nous avons besoin de quelque chose d'autre pour prendre la place de la soupe que nous avons maintenant et il devrait compiler à HTML / CSS / JS, mais gardez l'utilisateur libre de leurs préoccupations. C compile à l'assemblage, mais le programmeur C ne voit jamais le STA, MOV, LDX OPCODES qu'il compile dans leur propre code écrit. Et, étiez-vous populaire, alors les navigateurs pourraient le soutenir directement. Quoi qu'il en soit, c'est juste une idée. Une lueur.
bonne chance,
Chris Perkins
(1) Les documents HTML sont des documents composés avec des images, des scripts, des feuilles de style, etc. Tous sont stockés dans d'autres fichiers. Mais la seule chose qu'un document HTML ne peut pas faire est d'intégrer de manière fluide un autre document HTML - la seule chose dont elle a le plus besoin. Les étiquettes IFrames / Object sont une taille fixe et un impact négatif sur le référencement. Cette tâche triviale est souvent la seule raison pour laquelle un langage côté serveur comme PHP est utilisé sur de nombreux sites Web. (2) Exemples abondants: moins (moins lescss.org), document.write, ajax, etc.
(3) L'inadéquation d'impédance entre les règles JavaScript DOM et CSS est presque incroyable. Combien de hauteurs un DIV a-t-il dans le DOM (Scrollheight, OffSetheight, Clientheight, et plus encore)? 4 ou plus, peut-être? Combien de ceux-ci sont adressables via CSS? 0 ou 1.
En outre, tandis que JavaScript peut brancher beaucoup de trous, cela le fait souvent au détriment de SEO
medialab.com
Vous n'avez pas besoin de moi pour vous dire à quel point CSS est mauvais.