http://www.coect.net uses own Lisp dialect MetaJS http://metajs.coect.net

From my experience MetaJS allows to write much cleaner code eliminating a lot of typical boilerplate. Many frameworks assume that some functions always have some parameters (for example "request" or "callback") and MetaJS improves signal/noise ratio in such cases. Look at some examples at https://github.com/dogada/metajs

A year ago near last Google Reader redesign I made my own online RSS-reader http://www.cliws.com/ and now don't care.

We should less depend on the large corporations. The idea about I think last time is that we need some kind of distributed Twitter (like we have perfectly worked distributed email now).

If you can't replace one tool with another you are in trouble definitely.

I understand you but DSLs allows to reduce number of used languages/tools in a web-projects.

For example NodeJs allows to use same JavaScript for both client and server and if we will have smth like http://lispyscript.com/docs/#templates we can also seamless export business logic into templates (without need to create special template tags, filters, syntax, etc).

Single language for almost everything can be big performance boost IMO.

IMO Microsoft looks for web-developer loyalty because recent stupid policy of big monopoly drive them to zero share on web-browser market. The only remaining question: will IE10 support TypeScript or it will be added in IE11 only?

One of the key TypeScript features is not only the fact that JavaScript program is TypeScript programs but also ability to add type annotations to existing javascript libraries without changing of their source code. For example, see port of Backbone's TodoMVC: http://typescript.codeplex.com/SourceControl/changeset/view/...

On algorithmic level compression is mainly identical to JSONH. I didn't do performance tests yet, I still have ideas how to improve RJSON.

I agree that identification is important issue, but IMO it's protocol level issue. RJSON is not protocol, it's algorithm. Someone will prefer to wrap all in {"rjson": ...}, someone like {"format": "rjson", "data": ...} and so on. I belive, algorithm itself should create as less limitations as possible.

The MIME type is allowed to add information about the nature of the data encoded on top of the encoding. This is why we have application/xhtml+xml. It means "this is encoded using xml, and btw the parsed xml structure is xhtml".

The ideal place to handle this is (as pointed out above) content negociation - specifically as 'application/rjson+json'

It's an algo. But the resulting data is a protocol.

It doesn't matter. Even if order of keys will be changed somewhere in the middle during JSON.strigify, as schema id will be always used keys sorted alphabetically and object values are always stored in the same order as keys sorted: https://github.com/dogada/RJSON/blob/master/rjson.js#L213

RJSON not only compresses data of any structure but keeps it in JSON format that is huge advantage over gzip/7z and other binary compression algorithms. You can compress 1M of JSON to 300Kb of gzipped JSON but then you will to parse 1Mb of JSON on client anyway. With RJSON you can compress 1Mb of JSON to 500Kb of RJSON, then gzip it down to 200Kb and parse only 500Kb of JSON. Then you can analyze some core properties of parsed RJSON document and unpack it on demand. For example you may send to client collection of 20 documents, parse each and show title of each document to the client, then fully unpack only selected by client document.

I agree with Too that specialized protocol will always win, but RJSON IMO decreases structural entropy almost to 0 without need to debugging own protocol.