quicktemplate VS fasthttp

Here are a couple:

https://github.com/julvo/htmlgo

https://github.com/rohanthewiz/element

I'm sure there are many more.

The thing about these is that performance is often not as good as when using templates, especially when the templates are compiled to native code. Quicktemplate [1] is still the leader here IMO, and I don't think the OP project brings much that couldn't be done pretty easily with QT.

[1] https://github.com/valyala/quicktemplate

From my experience you don't really need a distinct frontend framework for web development in Go. I've been able to use quicktemplate for some of my projects for rendering HTML pretty effectively. I've written about using it here.

If the question is about templating libraries, then I've seen people use other libraries than the html/template, like https://github.com/hoisie/mustache or https://github.com/valyala/quicktemplate

I originally started out trying to add features to quicktemplate, but didn't get any engagement, so went my own way: https://github.com/valyala/quicktemplate/issues/80

I've been using quick template with htmx and I'm really enjoying the combo. As a mostly backend developer it's a pretty intuitive approach. Now if someone could just build something to simplify working with CSS...

Like with the previous post, we're going to use djinn-ci/imgsrv as an example of using multiple sources in a build manifest. If we look at the top of the manifest file, we will see that it requires three repositories to build. These are, the source code for djinn-ci/imgsrv itself, golang/tools, and valyala/quicktemplate, defined like so,

I like Hugo quite a lot, but I don't like Go's standard library templates. I wonder if it is possible to use https://github.com/valyala/quicktemplate with Hugo?

For encoding, the receivers usually want very specific encoding (namespaces, nil as xsi:nil, not omitted value...) - templating with text/template or github.com/valyala/quicktemplate is easier on the long run, than fight with xml.Marshal and the other end's unspoken assumptions.

The "Hello World" example is up at https://github.com/a-h/qt-lsp - it's called qt-lsp because I started down this track looking to build IDE support for quicktemplate - https://github.com/valyala/quicktemplate/issues/80 - but didn't think it was practical when I dug into the design of quicktemplate more.

Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.

By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).

There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.

--

1: https://github.com/alecthomas/go_serialization_benchmarks

2: https://github.com/golang/go/issues/29766#issuecomment-45492...

--

3: https://github.com/goccy/go-json

4: https://github.com/vmihailenco/msgpack

5: https://github.com/fxamacker/cbor

--

6: https://github.com/valyala/fasthttp#faq

--

7: https://github.com/tidwall/gjson

8: https://github.com/tidwall/sjson

Fasthttp is one of the most powerful webservers written in Go, I'm working on a project that makes it possible to use it as a webserver for Python.

IDE: use whatever make you productive. I personally use vscode. VCS: git, as golang communities use github heavily as base for many libraries. AFAIK Linter: use staticcheck for linting as it looks like mostly used linting tool in go, supported by many also. In Vscode it will be recommended once you install go plugin. Libraries/Framework: actually the standard libraries already included many things you need, decent enough for your day-to-day development cycles(e.g. `net/http`). But here are things for extra: - Struct fields validator: validator - Http server lib: chi router , httprouter , fasthttp (for non standard http implementations, but fast) - Web Framework: echo , gin , fiber , beego , etc - Http client lib: most already covered by stdlib(net/http), so you rarely need extra lib for this, but if you really need some are: resty - CLI: cobra - Config: godotenv , viper - DB Drivers: sqlx , postgre , sqlite , mysql - nosql: redis , mongodb , elasticsearch - ORM: gorm , entgo , sqlc(codegen) - JS Transpiler: gopherjs - GUI: fyne - grpc: grpc - logging: zerolog - test: testify , gomock , dockertest - and many others you can find here

The best example I can give you is https://github.com/nutsdb/nutsdb it’s great project that got me started, one thing one should know is Go is different “yep” so there’re some coding habits that may bite you in Go and the Go compiler won’t correct you, you wanna learn about optimizations, unsafe usage check out https://github.com/valyala/fasthttp (note this is deep the rabbit hole), wanna learn concurrency check out ants https://github.com/panjf2000/ants with a little aid from “Go by example” you’re good to go

As I said in another comment, I think net/http is a good cautionary tale here. It was designed to be easy to use, and then grew organically, but performance never seems to have been a goal. fasthttp solves this, but bifurcates the ecosystem and passes on those costs to everyone who uses it. If net/http had been designed with performance in mind, this could have been avoided. net/http can't be removed or optimized, so this is a situation the Go ecosystem is effectively stuck with forever. At best, a faster version may end up in the std lib, just like netip is more modern and faster than net but the ecosystem is still bifurcated and adoption of the new package has been slow.

Fiber, while has a lot of batteries included and decent for many use cases, is known for having corner cases (because of internals like fasthttp) like https://github.com/valyala/fasthttp/issues/622