Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hero – A handy, fast and powerful Go template engine

github.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Hero – A handy, fast and powerful Go template engine

#21

Post by camus2 »

warent wrote: post #4

I acknowledge the capability of the engine which seems rather impressive. But unfortunately it's basically obsolete. How exactly are designers supposed to easily update? Why reinvent the wheel when far more matured templating engines exist? As the web moves to the front end, this seems like a step backwards

> As the web moves to the front end, this seems like a step backwards

The web isn't really "moving front end". I hate these fulljavascript websites that serves you articles, there is no need to use Javascript for that. Furthermore, isn't server-side rendering a thing even for "front-end frameworks"? server-side templates are still relevant. What is not is abusing Javascript everywhere even when it doesn't make sense.

Re: Hero – A handy, fast and powerful Go template engine

#22

Post by lime66 »

grey-area wrote: post #17
marcus_holmes wrote: post #12

Adding a whole dependency to shave a few milliseconds off serve times (at most) seems like a bad deal to me. All the usual bad stuff that comes with dependencies: will it be maintained? Will it have breaking changes? Will it leftpad? And everyone knows the standard library template format, all the editors support it, if another coder joins the team they'll know it. Meh, maybe I'm just not the target market for this..…

These are not even milliseconds, the charts are in microseconds and a reduction of 40 to I agree it's not worth the focus on fast, they should be focussed on improving the API for the stdlib templates (for example loading templates is not obvious, what I'd like to do is point it at a directory and load all templates under that dir, being able to set layouts and partials would be nice etc). Speed is not a big problem…

It's not noise. The benchmark's result is stable. Maybe the benchmark is too simple. In production the templates are more complex than the benchmarks, so the speed does count! But that doesn't mean that the easy-of-use is not important. I want Hero to be fast, and easy of use too.

Re: Hero – A handy, fast and powerful Go template engine

#23

Post by lime66 »

TeeWEE wrote: post #5

Template parsing doesnt need to be super duper fast. Most of the time you can cache the whole result. I think its more important, to choose a good template language thats easy, and doesnt mix code with template content.

Hero aims to be easy of use and fast.

Re: Hero – A handy, fast and powerful Go template engine

#25

Post by camus2 »

lime66 wrote: post #22
grey-area wrote: post #17

Earlier quoted context omitted.

These are not even milliseconds, the charts are in microseconds and a reduction of 40 to I agree it's not worth the focus on fast, they should be focussed on improving the API for the stdlib templates (for example loading templates is not obvious, what I'd like to do is point it at a directory and load all templates under that dir, being able to set layouts and partials would be nice etc). Speed is not a big problem…

It's not noise. The benchmark's result is stable. Maybe the benchmark is too simple. In production the templates are more complex than the benchmarks, so the speed does count! But that doesn't mean that the easy-of-use is not important. I want Hero to be fast, and easy of use too.

> It's not noise. The benchmark's result is stable

All things considered, it absolutely is noise. Unless the only thing your application does is serving templates. Even then, the entire response should be cached, both on the server and the client at first place.

Re: Hero – A handy, fast and powerful Go template engine

#26

Post by junke »

masklinn wrote: post #9
junke wrote: post #6

Earlier quoted context omitted.

Ideally, a template should be compiled into native code.

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 sig…

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.

Re: Hero – A handy, fast and powerful Go template engine

#27

Post by grey-area »

lime66 wrote: post #22
grey-area wrote: post #17

Earlier quoted context omitted.

These are not even milliseconds, the charts are in microseconds and a reduction of 40 to I agree it's not worth the focus on fast, they should be focussed on improving the API for the stdlib templates (for example loading templates is not obvious, what I'd like to do is point it at a directory and load all templates under that dir, being able to set layouts and partials would be nice etc). Speed is not a big problem…

It's not noise. The benchmark's result is stable. Maybe the benchmark is too simple. In production the templates are more complex than the benchmarks, so the speed does count! But that doesn't mean that the easy-of-use is not important. I want Hero to be fast, and easy of use too.

It's very hard to benchmark things which are that fast, and very easy to make mistakes (for example optimising away the thing you think you are measuring because your benchmark does no real work with it and the compiler notices). So on this homepage you have two benchmarks, which give these stats for stdlib:

Time: ~0.04ms

Memory usage: 2Kb

There is no context here and just a link to another benchmark which most aren't going to bother to read. If your selling point is that you're the fastest, you need to tell people why that's important, and what exactly is faster. These graphs give zero details on the work done, and the timings/memory usage suggest trivial work is done in the benchmark, which means it's likely to be wrong. Is it measuring loading or evaluating or both at once? How many templates, what is in them? Are they properly evaluated with lots of keys in them? Do they test functions, methods, built-in functions?

If you're interested in speed, I'd suggest setting up your own real-world benchmark, with separate charts for parse time (typically done once, of little importance) and evaluation time for sets of templates which are 30-100 templates big and include lots of dynamic content and other templates. That's close to real world use and will tell you if your library is a lot faster, it might even give you far more impressive numbers (reduced render time of typical templates from 100ms to 10ms for example).

Personally, like the parent, fastest is about 10th on my priorities list as long as speed is adequate (and 0.04ms per template is adequate), below: Correctness, Contextual escaping (very handy in stdlib, not supported?), Ease of Use, Partials, Layouts, Syntax, Docs, Adding another dependency, etc.

As a third party dependency for a core feature which would require me to impose your library on everyone who uses my library/app, your argument has to be very strong and there have to be multiple reasons to adopt the library and strong guarantees about future development/support. Speed is not enough, even if it was an order of magnitude better on significantly slower results (say 100ms -> 10ms), it would be just one bullet point and far down the list.

I hope this is helpful.

Re: Hero – A handy, fast and powerful Go template engine

#29

Post by Zach_the_Lizard »

camus2 wrote: post #19
asitdhal wrote: post #16

Earlier quoted context omitted.

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.

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…

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

Post reply on HN