Project direction

[waneck]

Currently, while I like a lot and use erazor daily in my own projects, I feel that we lack a little direction or ownership about it at the moment.

Can we use this issue to discuss that? I'd like to implement some extra features, and work on a better way to deal with escaping/raw, templating in general (following how razor does it), and better support for erazor macros. If no-one oposes to that, I propose that we release our current version as erazor 1.0, and start working on erazor 2.0 with these extra features - maybe breaking backwards compatibility.

cc @fponticelli @ciscoheat @jasononeil

[fponticelli]

Github is not the right place! Just kidding :)
What I'd really like to see is a subtle but substantial change in the syntax. Replacing @ with $. While that might look just like a nuisance, it would bring erazor closer to the current haxe format for string interpolation: $some and ${some} ... if played right it might resound for other Haxe developer and in the future we might have more erazor future in standard Haxe ... like interpolating the erazor way: 'my name is $name.toUpperCase()' (no need for braces).
I started doing some of these changes here: https://github.com/fponticelli/thx.tpl

[fponticelli]

A second improvement I'd like to see is to split backend from generators. I'd like to build a different backend Jaxe (based on Jade), and I'd like to reuse as much of the AST as I can. That and also be able to reuse the same templating engine in different context: static values interpolation (the way erazor currently works) but also implementing some Virtual Dom diffing (Mithril style).

[waneck]

About changing to $, I understand where you're going, but I'm not sure this would ever be changed on Haxe before Haxe 4, as I can't think of a way to make this backwards-compatible. I'm not sure it would be worth it, but we can discuss about it.

As for splitting backend from generators, can you tell me more about it? How do you see this working?

My main motivation now is to work on erazor/macro, add better raw/escaping support, allow some macro-only statements, like @switch (which can possibly be back-ported to hscript on the simple case), @import. Maybe follow its @model directive as well. I'm also silently working on a dispatch engine (I've just made it public at https://github.com/waneck/mweb - but shhh it's still unreleased :) ), and I'm looking for a better integration with erazor.

[fponticelli]

First of all, feel totally free to ignore my comments if so you wish, I think that any innovation is better than no innovation. If we split the project the prefix thing is not a thing anymore because I could have my variation of the template engine that just uses my syntax instead of the erazor one.

So here is the idea for the split (why do I always want to split things?). First of all we define a nice AST format that supports the most features that templates might need (conditionals, literals, tags, attributes, expressions, plain text ...). With that we can build template languages that feed this AST (Erazor, Jaxe, thx.tpl, haxe.Template, Templo ...). We can do it with independent lexers/parser or we can also try to unify that effort maybe using hxparse. I already started that process for Jaxe with a custom lexer/parser but I would be glad to trash it. The third piece is how to consume the AST. The classic way is just to generate a method that take arguments and spits a piece of string (erazor, templo style). But the same AST again could be used for more interesting things like Virtual Dom changes (mithril style).

[ciscoheat]

Would it be possible to use the AST we already have in haxe.macro.Expr?

[jasononeil]

Thanks for starting the discussion!

I use erazor in a few different projects, but have not yet attempted to get stuck into the internals and consider ways to develop it / change it. I will say I think it is the most promising paradigm for templating in Haxe, especially if we emphasise macro support and start considering a support for alternative backends (especially for DOM diffing) as Franco suggested.

For using the AST from haxe.macro.Expr if possible, you could extend it using something like:

enum ErazorExpr {
   Literal( s:String );
   CodeBlock( e:Expr );
   PrintBlock( e:Expr );
}

This would allow us to piggy-back on Simon's haxeparser / hxparse haxelibs:

https://github.com/Simn/hxparse
https://github.com/Simn/haxeparser
https://github.com/Simn/haxeparser/blob/master/src/haxeparser/HaxeParser.hx

to support as much Haxe syntax as possible.

[jasononeil]

Back to the project direction conversation:

If we can agree on a direction for this project that includes a) compile time safety, and b) some support for DOM diff-ing, or an obvious path to support that using another lib, then I would love to make this the default templating system in Ufront and encourage people to use it. In which case I can commit to contributing to it in the medium to long term also.

I think it would be wise to set up a repo on an organisation, rather than having many contributors each with their own forks. Some time ago I set up an erazor fork on the "ufront" organisation, which is what I used to publish to haxelib. We could use that, or set up a new "erazor" organisation, or ask for it to be hosted on the "HaxeFoundation" organisation, etc.

[fponticelli]

Hosting on ufront or a new erazor org both seem acceptable to me. About the AST I think it needs to be much richer than that. If we want to properly support HTML with dom diffing we need to be able to distinguish if we are in a tag, in an attribute, inside a text node, etc ... Also, something that is absolutely required regardless is positioning. Right now we lose source position as soon as we parse the template content.

[waneck]

I'm sorry, I don't quite understand how DOM diffing works, or why it's a desirable feature. My primary view of a templating system is to process some data and return a string from it. Something like typedef Template<T> = T->String. What kinds of features does DOM diffing bring?

Anyway, I'm of course fine with someone implementing it if they'd like ;)

About hosting it in ufront, I'm fine with it! As long as we decide some basic guidelines so we all agree on a direction to take.

[fponticelli]

There is nothing wrong about T -> String. It is the most common case so far for any template engine. What a virtual dom does (see react, shadow dom, mithril and many others) is to keep an AST in memory and at some point in the future diff the changes in the AST and apply such changes to the real DOM. The advantage is that you reduce and "compact" all the changes to the DOM very close together making them much more efficient and small (you change only what needs to be changed). I hope my explanation doesn't suck too much. Once more I insist, don't wait for this to happen to do your improvements!

[waneck]

I see, @fponticelli ! I gather this is for js-intensive sites, where navigation can be made without actually changing the page, right?

I don't know however how this could be done with erazor.

Anyway, about the changes I plan to do, I'll spend some time to summarize them here, and if OK, I'll get on to implement them

[fponticelli]

It needs a complete revamp to allow that ... let's see how far can I get
with Jaxe :)

Il giorno gio 11 giu 2015 alle ore 11:35 Cauê Waneck <
notifications@github.com> ha scritto:

I see, @fponticelli https://github.com/fponticelli ! I gather this is
for js-intensive sites, where navigation can be made without actually
changing the page, right?

I don't know however how this could be done with erazor.

Anyway, about the changes I plan to do, I'll spend some time to summarize
them here, and if OK, I'll get on to implement them

—
Reply to this email directly or view it on GitHub
#18 (comment).