So what does this mean? Well I'll tell you. Avian exposes a few publicly available directories for your application. For many frameworks, these are known as the "public" directory, or the "static" directory. Avian already allows you to select which of these is to be used to host static files. You can even choose which one serves static files at /. This is cool.
But one thing that Avian supports that most frameworks do not, is a natively available /assets directory. Many modern application frameworks organize UI related "assets" in a directory known as "assets". It's very common, and you see it more and more. This is why since in the very early days of Avian we acknowledged that this directory could exist in your app home, and we should make it exposed to the internet.
Great, ok...
But wouldn't it be cool if that assets directory could also break up assets like "less, sass, pug, ejs, and even ts files?" Yes it would.
The "static" and "public" directories would work as they do now, they are express.static directories and so there is no way that I know of to preprocess files behind rendered before being exposed to the client.
That's fine. But with assets, we can make it not a static directory. We can have the directory exist, yes, we can have it serve assets, yes, they can even be static, yes, however, if a file being called from /assets/pug/myexample.pug is requested, Avian would be intelligent enough to render the file into html. Same with the other template engines and css preprocessors we support.
We should do this. I don't know of other frameworks that do. Sure, yes, there is a performance penalty for doing this for those files but, if you want to do it you should be able to.
So what does this mean? Well I'll tell you. Avian exposes a few publicly available directories for your application. For many frameworks, these are known as the "public" directory, or the "static" directory. Avian already allows you to select which of these is to be used to host static files. You can even choose which one serves static files at /. This is cool.
But one thing that Avian supports that most frameworks do not, is a natively available /assets directory. Many modern application frameworks organize UI related "assets" in a directory known as "assets". It's very common, and you see it more and more. This is why since in the very early days of Avian we acknowledged that this directory could exist in your app home, and we should make it exposed to the internet.
Great, ok...
But wouldn't it be cool if that assets directory could also break up assets like "less, sass, pug, ejs, and even ts files?" Yes it would.
The "static" and "public" directories would work as they do now, they are express.static directories and so there is no way that I know of to preprocess files behind rendered before being exposed to the client.
That's fine. But with assets, we can make it not a static directory. We can have the directory exist, yes, we can have it serve assets, yes, they can even be static, yes, however, if a file being called from /assets/pug/myexample.pug is requested, Avian would be intelligent enough to render the file into html. Same with the other template engines and css preprocessors we support.
We should do this. I don't know of other frameworks that do. Sure, yes, there is a performance penalty for doing this for those files but, if you want to do it you should be able to.