search

ultraq / thymeleafjs

A basic implementation of the Thymeleaf templating engine in JavaScript
Apache License 2.0
52 stars 8 forks source link

Add build time compilation #15

Open jantimon opened 6 years ago

jantimon commented 6 years ago

Hey @ultraq

many javascript template languages allow to compile templates into javascript code so we don't have to transmit the rendering engine and can save the time to parse and process the templates during run time.

Do you plan something similar?

E.g. http://olado.github.io/doT/ dot_js_-_the_fastest_and_concise_javascript_template_engine_for_node_js_and_browsers

ultraq commented 6 years ago

It's a good idea, and I keep thinking of doing something like this, but my mind is struggling with how to make it work.

Other template engines basically compile down to a series of text strings interpolated by functions. Thymeleaf however is DOM-aware and works by using DOM APIs - eg: th:if removes the element it works on by using currentElement.remove() - so when compiled into strings, those APIs are not available.

I'm not saying it's impossible, but it'll be a lot harder (to my mind anyway) and I'd be open to ideas on how to make such pre-compilation possible.

So no, I'm not looking at doing something like this as part of my current/shorter-term plans for this library.

jantimon commented 6 years ago

Is there any reason why you would use the DOM api? This approach sounds way slower than building up a string based template. I would probably use an html ast parser (https://astexplorer.net/) - this would allow you to iterate over all elements quite easily and turn them into strings or javascript expressions

ultraq commented 6 years ago

I started with the DOM API because it's what Thymeleaf did, so porting enough features over so I could get something working was relatively easy. And when I started, I just wanted a bit of a proof-of-concept to see if it was possible (which it is, so yay!)

Using another parser does cross my mind every so often, especially now that Thymeleaf 3 does that (XML parsing in Java was always a bottleneck, although I'm yet to investigate how it compares in JS, particularly a browser environment which really should be built for such a task). But again, it's not something I plan to do in the short term. Discovering performance baselines and then improving on them is unlikely to happen until a proper 1.x release.