6 ms·

Is template parsing a major bottleneck ? What I know, most web apps need template parsing only at the beginning. Once initial startup is done, delivery of cont

Is template parsing a major bottleneck ? What I know, most web apps need template parsing only at the beginning. Once initial startup is done, delivery of content is mostly constant.

tiborsaas 10y ago
It shouldn't be. I prefer template engines that I like the syntax and documentation the most. For low traffic efficacy doesn't matter, for high traffic you should always cache the templates.
- junke 10y ago
  Ideally, a template should be compiled into native code.
  - masklinn 10y ago
    Not necessarily. 1. that requires parsing the template at compile-time (making it non-overridable at runtime) or the ability to generate executable code at runtime which break in NX-mandatory environment (e.g. appstore applications) 2. the runtime version may be much faster than the compile-time one, e.g. the rust Regex crate has both a runtime Regex structure and a regex! compiler plugin, the latter is currently significantly slower at runtime: https://github.com/rust-lang/regex#usage-regex-compiler-plugin https://github.com/rust-lang/regex#usage-regex-compiler-plug...
    - junke 10y ago
      Yes, "compile/load/execute" can take longer than simply "eval". You have to consider amortized costs: how often do you need to recompile your template (or your regex)? Likewise, are you really going to override the template at runtime or is the variable part of the template already compiled as branches in the resulting code? Whatever needs to be dynamic can be dynamic while compiling as much as possible ahead of time.
  - Zoadian 10y ago
    There is a web framework (vibed.org) written in the D programming language that does compile templates to native code.
  - micmus 10y ago
    Elixir's EEx templating engine compiles templates into plain elixir functions, which makes the templates really fast.
- asitdhal 10y ago
  Exactly, I used django and jinja templates. Those two are feature rich. Golang template engine is mostly minimal with enough feature to do things. The problem with Golang, most developers look for performance instead of the features. People who use python or ruby look for better features and ease of development. So, Golang engineers develop applications and libraries which doesn't help anyone.
  - camus2 10y ago
    Go template language has a nice context sensitive escape mechanism. But the syntax is kind of garbage and it's very limited when it comes to features ( no template inheritance, curb-some API for plugins ... ). Like everything in Go it gets you 50% there and but it's PITA to do something complex with it. Go is really bait+switch . You can get started fast but then you run into a vast amount of issues when it's time to deliver a professional product with std lib. It's true for testing,logging,writing web-apps, debugging and even concurrency. I hope the more Google rely on it, the more the maintainers will be pressured withing Google to fix its shortcomings.
    - Zach_the_Lizard 10y ago
      Can't help but agree. I write Go professionally now and it's just not a productive language. The concepts are there, but the execution was frankly quite lazy and inconsistent. Never panic in an external API, but closing closed channels and random number functions panic in the same way Java throws checked exceptions. Generics aren't important, except for slices, maps, and channels which are generic. Really minor things like this add up
      - icholy 10y ago
        When a program panics, it's saying that there is a fundamental problem with your logic. Closing closed channels and dividing by zero are both examples of those.
    - sheeshkebab 10y ago
      Complex json parsing is kind of bad too in go - and rather surprising for a modern vm/go based language. (I guess they really tried to go for c/c++ with go but why vm/gc) Google will probably fix these things with time though, or so I hope - at the moment go seems like a conflicted language.
thewhitetulip 10y ago
If you are using a front end framework, even this is not an issue.
- mi100hael 10y ago
  Only because you've offloaded half your CPU load to your user's cell phone.

Is template parsing a major bottleneck ? What I know, most web apps need template parsing only at the beginning. Once initial startup is done, delivery of content is mostly constant.

tiborsaas 10y ago

It shouldn't be. I prefer template engines that I like the syntax and documentation the most. For low traffic efficacy doesn't matter, for high traffic you should always cache the templates.

junke 10y ago
Ideally, a template should be compiled into native code.
- masklinn 10y ago
  Not necessarily. 1. that requires parsing the template at compile-time (making it non-overridable at runtime) or the ability to generate executable code at runtime which break in NX-mandatory environment (e.g. appstore applications) 2. the runtime version may be much faster than the compile-time one, e.g. the rust Regex crate has both a runtime Regex structure and a regex! compiler plugin, the latter is currently significantly slower at runtime: https://github.com/rust-lang/regex#usage-regex-compiler-plugin https://github.com/rust-lang/regex#usage-regex-compiler-plug...
  - junke 10y ago
    Yes, "compile/load/execute" can take longer than simply "eval". You have to consider amortized costs: how often do you need to recompile your template (or your regex)? Likewise, are you really going to override the template at runtime or is the variable part of the template already compiled as branches in the resulting code? Whatever needs to be dynamic can be dynamic while compiling as much as possible ahead of time.
- Zoadian 10y ago
  There is a web framework (vibed.org) written in the D programming language that does compile templates to native code.
- micmus 10y ago
  Elixir's EEx templating engine compiles templates into plain elixir functions, which makes the templates really fast.
asitdhal 10y ago
Exactly, I used django and jinja templates. Those two are feature rich. Golang template engine is mostly minimal with enough feature to do things. The problem with Golang, most developers look for performance instead of the features. People who use python or ruby look for better features and ease of development. So, Golang engineers develop applications and libraries which doesn't help anyone.
- camus2 10y ago
  Go template language has a nice context sensitive escape mechanism. But the syntax is kind of garbage and it's very limited when it comes to features ( no template inheritance, curb-some API for plugins ... ). Like everything in Go it gets you 50% there and but it's PITA to do something complex with it. Go is really bait+switch . You can get started fast but then you run into a vast amount of issues when it's time to deliver a professional product with std lib. It's true for testing,logging,writing web-apps, debugging and even concurrency. I hope the more Google rely on it, the more the maintainers will be pressured withing Google to fix its shortcomings.
  - Zach_the_Lizard 10y ago
    Can't help but agree. I write Go professionally now and it's just not a productive language. The concepts are there, but the execution was frankly quite lazy and inconsistent. Never panic in an external API, but closing closed channels and random number functions panic in the same way Java throws checked exceptions. Generics aren't important, except for slices, maps, and channels which are generic. Really minor things like this add up
    - icholy 10y ago
      When a program panics, it's saying that there is a fundamental problem with your logic. Closing closed channels and dividing by zero are both examples of those.
  - sheeshkebab 10y ago
    Complex json parsing is kind of bad too in go - and rather surprising for a modern vm/go based language. (I guess they really tried to go for c/c++ with go but why vm/gc) Google will probably fix these things with time though, or so I hope - at the moment go seems like a conflicted language.

thewhitetulip 10y ago

If you are using a front end framework, even this is not an issue.

mi100hael 10y ago
Only because you've offloaded half your CPU load to your user's cell phone.