Hacker News Reader

Comment by curveship | Hacker News Reader

Question: do I read your compiler right, that any line starting with 'var', 'function' or 'this' is assumed to be javascript? So for instance:

   <p>
      How will riot.js compile
      this line?
   </p>

would fail?

[Don't mean to sound negative: I've been playing around with my own minimalist framework, so this is right up my alley. I'm reading the code to get a feel for how we've solved problems the same or differently, including the compile phase. Neat stuff and I'll write more when I have time to go over it in more depth.]

View on HN

I tried making a simple dynamic page and failed repeatedly by attempting to put seemingly innocuous javascript in { } blocks. A simple case such as { platforms.join(' ') } works fine as where { technologies.map(function(t) {return t}).join('|') } does not. Until this is either fixed or (all limitations and work-arounds) documented, I consider this unusable for any real project.

Looking at the generated code:

  (function(v) {
        try {
            v = d.technologies.map(d.function(d.t) {
                    d.return d.t
                } finally {
                    return !v && v !== 0 ? "" : v
                }
            }).call(d), ").join('|') }"].join("")

There's two problems: (1) prefixing keywords with 'd.' which may possibly be solved by skipping keywords or with(d){...} and (2) the ").join('|') }" code became data.

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.

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.

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!

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

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!

Reply on news.ycombinator.com