You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What if we had a highly performant coding language available to us as part of pOS?
Something like Go. And what if that made it so we could then separate our coding from our templating?
And as part of that, what if we could define our own globals that are processed before the first line of Liquid?
I imagine we could see not only massive performance benefits, but a healthy separation of concerns.
This thought is a result of a comment that Liquid is not a coding language, and my response that we use it as one. Both of those comments are correct.
Would this require a massive rewrite of the current system?
I don’t think so. Just introduce it as a globals layer. It’s something that runs before the first line of Liquid is processed. And it outputs the variables you’ll need in your Liquid.
No backwards compatibility issues.
We can even have it output to context.globals
For languages, perhaps Node is the best choice, just for familiarity. Not the fastest or the slowest either.
And this pre-rendering stage could be optimized independently of the liquid engine, resulting in a great speed advantage.
What if we had a highly performant coding language available to us as part of pOS?
Something like Go. And what if that made it so we could then separate our coding from our templating?
And as part of that, what if we could define our own globals that are processed before the first line of Liquid?
I imagine we could see not only massive performance benefits, but a healthy separation of concerns.
This thought is a result of a comment that Liquid is not a coding language, and my response that we use it as one. Both of those comments are correct.
Would this require a massive rewrite of the current system?
I don’t think so. Just introduce it as a globals layer. It’s something that runs before the first line of Liquid is processed. And it outputs the variables you’ll need in your Liquid.
No backwards compatibility issues.
We can even have it output to context.globals
For languages, perhaps Node is the best choice, just for familiarity. Not the fastest or the slowest either.
And this pre-rendering stage could be optimized independently of the liquid engine, resulting in a great speed advantage.
Would this give access to the servers?
No. This is still a layer.
Even Shopify has a concept like this.
https://help.shopify.com/en/manual/checkout-settings/script-editor
Does it give access to the database, etc?
Access is the same as it is in Liquid.
The big difference between is that liquid is a rendering layer, and this is a computing layer.
How will the two layers communicate with each other?
I’ve thought of two methods:
Like real functions.
The second is analogous to
api_call
: you call external service and then you are able to parse it’s response.The difference being that you should be able to deploy and host those external services on platformOS
Performance
I probably don’t have to sell you on the performance benefits of pulling intense logic out of liquid.
There are many benefits, including being able to use official sdk for various services.
What are your thoughts?
I wonder how many custom liquid filters would start getting lonely if we did this?
The text was updated successfully, but these errors were encountered: