Hacker News Reader

Comment by tipiirai | Hacker News Reader

Not sure but this might indeed fail. Can you place an issue to github? Thanks!

Maybe it's good to split HTML and JS with the last HTML tag.

The compiler also fails if a multi-line comment doesn't end at the end of a line.

  <!-- a comment --> and more text

It outputs an empty compiled file.

My honest opinion is that you should consider rewriting the compiler in a classic tokenize-parse-compile style. Several projects (like mustache.js) have had to go through this evolution. Your current solution -- line-by-line with regexes and state flags -- will only get hairier and hairier.

I'm aware of this. Just wanting to avoid going there at this point and hoping that a smaller regex- based thing can do it.

Well, maybe a line-by-line solution is good enough, I mean, it would only target a subset but the code will be readable. I still think though that any compiler which is intended for real apps should do the classic tokenize-parse-compile steps.

I'll start by improving the current implementation and see how far I can go with it without making it crazy.

I'll start tokenizing after a concrete use case.

Definitely keep this in mind. Thanks!

Idea: require a <script> tag around the JS in the template (but just for your parser's benefit, not as a tag you intend to embed literally in the rendered DOM -- you can remove it at parse time as necessary).

This has the nice side benefit that it will make editors happy. (E.g. emacs recognizes <script> tags within HTML and does JS highlighting/indenting on their content.)

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.

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.

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!

Confirmed. Just take the demo app and insert the line 'this is some text.' anywhere in it. It looks like it's particularly bad if you put it into a nested element: the compiler treats everything after the line (including html markup) as javascript.

Issues logged for this, the multi-line comment termination issue, and for treating any line that ends with')' or '}' as javascript.

Reply on news.ycombinator.com