Agree, removing the need for any special editor support would be great, even if offered as a compiler option. Makes the detection of JS a non-issue too.

This seems like a great idea, even if it's just optional tags that get ignored. With <script> you suddenly have a valid html fragment that should work with any editor.

I guess as is, a make could include a grep -v </?script> step.

I can clearly see the benefits here. I'm also resistant to it because of the added syntax. Deciding later :)

The idea of having integrated components (HTML+JS) is certainly interesting and forward-thinking. However, I hope it doesn't lead you to limit us to the integrated style, by making the Riot compiler a required build step.

Personally, I greatly prefer the direct coding style, i.e., riot.tag(). Not only because of the editor issues mentioned here, but because I can include my own modules in my scripts. I.e., can I use require() inside a Riot-compiled module?

Stuff starts getting very hoop-jumpy once you start creating your own compiler & syntax, and bringing too much "magic" to the table. One of the big appeals of Riot is how UN-magical it is!