11–20 of 185 posts
Same old topic. I use gin. It's not perfect, especially streaming (EventSource) is broken. But the rest has actual hand on solutions. ctx.SecureJSON() Not a single one of the other packages has something like that. Keyword: JSON hijacking protection. Yes it's still a thing.
Wired: Browser WASM (from Go source) that accepts commands over websockets to modify & render the DOM. (Is this "client hydration"?) Tight integration with htmlx (for pizazz + ruthless efficiency) and Javascript (for rich text editors + other advanced widgetry). This may require full Go, if tinygo continues to lack reflection support.
For junior developers reading this: frameworks are great, learn to love them, they will save you much time and stress when shipping real products.
Definitely try something like Python + Django, Ruby + Rails, Java/Kotlin + Spring to get a feel for what a mature framework can really do.
Then if you find you still don't like frameworks and the style of programming associated with them then sure, find a home in one of the ecosystems that are more inclined to roll it your own way.
Frameworks certainly aren't for everyone but using bad frameworks and then pretending all frameworks are therefore bad is highly prevalent among more recent developers. Try the good ones and then make up your own mind.
This is one of the better things about Go and its community: eschewing frameworks like this. Having an ecosystem of in-house libraries tailored to your products' use cases is not the same as developing an "ad-hoc framework". Where I work, we have several languages deployed in our fleet of microservices. A couple have frameworks, and these frameworks are "try to do it all" types, complete with dependency injection and…
Now that I'm exploring Go, I'm surprised at how many books/learning materials are basically surveys of the features of the language, and then it's basically - "Start building!" "Introducing Go" is just 100 pages for example.
And all the proto + protoc + protoc-gen-go + grpc + swagger/openapi + json-grpc-gateway dance is… not easy to understand at first
Go having a standard library that is so good for building simple services is what sets it aside from all the other languages that have come out in the last while in the same space. It has a great collection of community libraries but I so rarely need to fall back to them as I can usually cobble together whatever I need to pretty easily just using the standard library. It makes it easy to get started on a project as t…
Same old topic. I use gin. It's not perfect, especially streaming (EventSource) is broken. But the rest has actual hand on solutions. ctx.SecureJSON() Not a single one of the other packages has something like that. Keyword: JSON hijacking protection. Yes it's still a thing.
Isn't it just prepending "while(1);" to your responses? If that's all you need, it seems like a dependency overkill
This is one of the better things about Go and its community: eschewing frameworks like this. Having an ecosystem of in-house libraries tailored to your products' use cases is not the same as developing an "ad-hoc framework". Where I work, we have several languages deployed in our fleet of microservices. A couple have frameworks, and these frameworks are "try to do it all" types, complete with dependency injection and…
For junior developers reading this: frameworks are great, learn to love them, they will save you much time and stress when shipping real products.
However maybe also learn to love a language that embraces them at the same time so you don't come away with a poor experience because of only trying a language that has poor frameworks (Go, JS/TS, etc). Definitely try something like Python + Django, Ruby + Rails, Java/Kotlin + Spring to get a feel for what a mature framework can really do. Then if you find you still don't like frameworks and the style of programming…
Lack of a decent Rails/Django option for JS/TS is part of the issue IMO, since that ecosystem is so popular atm.
I also wonder if you have to get burned a few times rolling your own and that's just part of the journey :)
99% of cases people are better off using a boring conventional web framework and implementing their actual business logic on top of it.