[LISP] [Web] Let's work on the new Lispweb! [Standard]

We're all sick of dealing with the verbosity of XML/SGML based languages, the inconsistency of CSS and the overall badness of Javashit. Transcompiling to any of these languages is just a half-assed try at sugarcoating a turd.

Post your ideas for syntax/semantic rules, document structure, protocols, rendering techniques or anything relevant to the topic.

Hopefully we will be able to create a basic clone of /prog/ using the newly designed languages. No need to work on retarded features like animations or ``single page applications'' because this project is aimed exclusively at EXPERT PROGRAMMERS.

>>98
>>99
I guess it depends on what exactly you want lispweb to be. If you want lispweb to be a suitable replacement for the web, it will have to more powerful than it, in the sense that it lets you do more things, and better. But the way people actually use the web is that it's just a shitty, (supposedly) sandboxed version of normal desktop programs, where the only programming language is javascript and you can't do anything too interesting, like access arbitrary hardware. Many web sights could probably fit into the format you described, but most of the places people go on the web (facebook, email, youtube, amazon) won't - they require more complex formatting and client-side logic to fulfill their intended purpose.

What, then, are people who want to make a web sight like that to do if they wanted to use your system? Would you use a programming language that didn't let you use your own algorithms, and instead made you choose between a few pre-implemented ones? I see the value in such a system, because a lot of web sights are one of a small number of layouts, so making a system where it was easy to make things like that could be good (in addition to giving you some guarantees for reasoning about such pages, such as knowing that they are all of a few different layouts - like you said, much easier to make a language/interpreter/spec for).

But, from the observation that many places on the web follow that same format, it follows that the web is already a superset of that functionality - if you were to implement that idea, what advantage would it have over the web (HTML/javascript/etc) itself? It certainly has an advantage for implementors, but what about people who would actually make pages in your system - what do they gain by using a system with a subset of the functionality of an existing alternative? Sometimes only allowing a subset of possible inputs can give you something better in return - that's the whole point of static type systems, after all, and what you get is a strong guarantee about some of the properties of the programs that are allowed. In this case, though, what kind of guarantees do the users of such a system get in return (especially for the price of not being able to implement an infinitely large set of ideas that involve alternate layouts)?

If what you want is a nice way to make certain kinds of web sights, then that's a great idea, but I don't think it can compete with the web itself - a competitor to the web will need to be a superset, to appeal to the people who might use it, and it will need to be easier to reason about, to appeal to implementors.