PHP preprocessor for static HTML generation

[joeworkman]

What if we had the ability to run PHP code as a preprocessor in order to generate static HTML. This way the published website uses static HTML and does not need PHP to generate page content on every page load.

[yourhead]

I like the idea in principle. And technically it seems pretty easy I think. But I can't really think of any ways to use it.

What would you want to pre-process? What would you want to generate? Would this be to generate an HTML template? Or as an alternate template language?

I think we need a specific use-case to try to work through to try to understand the feasibility.

[joeworkman]

PHP preprocessor could be used to possible replace some of the functionally of the %repeat% Stacks API. I could use PHP to generate static HTML which could easily contain for loops. You could say that you could do this with JavaScript. But JS is not always the best solution when I can just have HTML.

This could be used in conjunction with the password feature request to add some encoding without actually publishing the logic on how it was generated. Because its all done with the preprocessor.

[yourhead]

well, if you wanted to do repeat-like things with a pre-processor we could totally do those without php -- and much faster -- natively.

but i'd be happy to let you use php/repeat as a pre-processor type thing. on the other hand, you can probably do that with your own build scripts -- and then it wouldn't impact your users at all.

but "replace repeat" -- well, preprocessing things doesn't really replace repeat. the deal with repeat was that the repeat count -- and even the content inside of the repeat -- could change based on the settings/content the user chose. so (repeat !== preprocessing)

repeat worked fine. repeat was just slow: why?

because it's not easily cache-able. the sub-units inside the repeat are not scoped or cache-able separately from the outside units.

in other words, when you put a huge stack inside a repeat -- and then repeat it 10 times -- you end up with a 10-times large stack. every time any part of that changes it has to be re-rendered and re-inserted into the DOM.

adding a php processing layer to that wouldn't help. it would just slow down the processing with another engine.

[yourhead]

so... let me put some ground-rules on this:

php as a pre-processor: yes (or, well, let's say maybe) php get user-settings from controls: no -- preprocessor doesn't have access to those

basically, we can call out to php and get some data back -- then cache that data and use it for the rest of the day. but there definitely should not be any more processing steps between user-settings and the DOM -- it's plenty slow enough.

the largest complaint i get from users (1000%) is stacks is too slow. we need to find ways of removing processing steps and increasing the efficiency of what we ask the DOM to re-render.

[joeworkman]

I was thinking that the pre-processor would only be triggered on preview/publish. Not inside Edit Mode.

[yourhead]

ah... that's interesting. but i'm really lost on how that would work. you need to be a lot more specific or concrete with an example.

[joeworkman]

This would allow for a much richer API experience. I could use PHP to create HTML output instead of Stacks API logic. I have many PHP stacks that based on the settings inside of the stack will always generate the same HTML code. Right now that is done on every page load on the server. What if that could be done once when the page was generated. This could really improve performance.