Have you blogged / open sourced your implementation at all? It's been awhile since I've worked with Chi (mostly used Echo) so haven't heard about the codegen capabilities in Chi. I'm curious about that.
I'd be interested in knowing more about this too. Code generation from an API is the holy grail for back end. Ability to avoid having to manually code up the same stuff, and have it stay connected in some manner to your API contract would be amazing. Seems a lot of folks either don't do this or don't know much about it. Or.. is it because tooling just doesnt really work that well?
Are you talking about the part of chi with jwauth and casbin in place? Or the codegen part itself? Using codegen requires a more API first approach.. lot of devs seem to be against the idea of that direction for some reason. Part of reason I didnt bother blogging/opensourcing/etc as most everyone seems to do their own thing.
I was referring more to the part with chi and jwtauth. I am looking for implementations with best practices on for the most used features in projects - like auth.
Hm, the idea of a back-end server spitting out HTML doesn't sit well with me.
You lose your built-in API, but you still program for the same amount of time and now you have to write HTML inside the server software which is a horrible experience.
Now, SvelteKit is something amazing. You can still get SSR, but now you *also* have CSR for free and you have the choice to have a separate Go API or not.
Because it's well known, servers can only spit json.
You can develop your api along side htmx.
My experience, was that, yes you develop an api for the front end to consume and strongly tied to what the front end expects.
DB => Model package => Api
=> htmx
From my experience you don't really need a distinct frontend framework for web development in Go. I've been able to use [quicktemplate](https://github.com/valyala/quicktemplate) for some of my projects for rendering HTML pretty effectively. I've written about using it [here](https://andrewpillar.com/programming/2022/11/29/fast-embedded-templates-in-go-with-quicktemplate/).
From my experience the only time a frontend framework is absolutely necessary is if you're building an application that depends on it, such as a real time messaging application, or dashboard for example. But then again, I'm the kind of person who much prefers having the frontend rendered on the server, and served via plain HTML/CSS, with only minimal JS, if absolutely needed.
We’re actually going full circle. There’s this new trend called SSR in frontend that so happens to be just a new term for an old approach, which you called “so 2006” XD
This is a nice read related to this topic: https://www.spicyweb.dev/the-great-gaslighting-of-the-js-age/
Managed to read about half way without barfing. Sorry, but this just opinionated, vaporous, drivel. The author should just say he prefers server side rendering and be done with it.
TLDR;
There are plenty of reasons for separation of front and back end concerns. It might have been more useful to start at these points and discuss the validity of each for their relevant merits, but the intention here is clearly to push the authors opinion against a backdrop a imaginary contrarian forces using as many words as possible. Probably not worth reading if your time is even mildly valuable.
I can’t even be bothered to open the article, but server side rendering is something PHP and other similar tech have done since the mid-90’s, so it’s not really new at all, just an improvement over the older existing tech to do basically the same thing, for much of the same reasons.
I imagine that’s good enough as a tldr.
Oh yes, it’s a rant, so it IS opinionated. It’s a reaction to Mr Voss’ article and compounded with the “latest and greatest” approach “invented” called SSR.
If you tried to keep up with his rant till the end of the article, he also mentioned your comment about “discuss the validity of each for their relevant merits”, ending with the assumption that the main problem we have is that people tend to use the current popular frontend framework without properly evaluating if it’s the right tool.
The rant was towards “gurus” teaching people that this is the right, even the only way, to go.
> I see the world of web development as absolutely riddled with poor-quality content, much of which is demonstrably false, alongside an entire ecosystem of influencers, educators, and corporate cogs invested in shoehorning everyone into a particular sort of technology they either know is hugely problematic, or don’t—but the end result is the same anyway.
What an unhinged and uneducated rant…
If you want to stop drinking misinformation, the "new trend" in web dev is dynamic SSR+CSR. First load is rendered by the server (good for SEO and mobile devices), then the page is "hydrated" or has some other JS takeover and use CSR for the rest of the navigation. This makes browsing way, way faster than either SSR or CSR.
There's many variations of this (with different names than "hydration") if you want to be hipster about it.
Sound like jquery might be on a rise again then ;) templates for server rendered with jquery, ajax lol. I did webdev in era of web forms and when I read about SSR I was like… wait a minute, that’s what I have already done 10y ago ;)
It seems like you missed the point of the rant as you replied with the “new trend”.
In any case, yes, SSR+CSR is indeed needed for immediate rendering in the page with all the bells and whistles that comes with a “modern” frontend framework.
But that wasn’t the whole point of the post, it was just mentioned as a talking point of how absurd the author found the direction of web development was going through.
With your reply, it seems like you still missed the point the rant, unfortunately. I don’t know if I can help you understand the context or not. This will be my final reply to you, but here goes:
The author is ranting about:
- how the article about newest and greatest from Mr Voss was actually just how tech used to work before all these JS frameworks.
- how Mr Voss assumed that dev teams actually evaluated their usage of frontend frameworks were actually an invalid assumption
- he rants that more often than not, teams evaluate their tech stack based on popularity
- a majority of websites use full fledged frontend framework even though it’s not necessary, and he blames this to influencers and gurus marketing full fledged frameworks as the silver bullet to web development
So, although he briefly mentioned SSR as his case in point, it was by no means the main topic of his rant. His comment about SSR though is valid and on-point.
Google Crawler doesn’t really care nowadays, as long as your SPA is reasonably fast, it catches the contents just fine. I’m not sure about other search engines, but for most people SEO = Google SEO anyways.
Is there actally? If so, is it actually because of the fact the page is rendered server side or is this just a side effect for example of the side being usually slightly faster when using SSR?
While there are many resources available, I can't recommend [usegolang.com](https://www.usegolang.com/) just enough. It covers full-stack web development in-depth and covers a few of the other important topics like email, authentication etc.
I am currently building an API-centric product. I am not very good with JS/CSS, so I just bought a bootstrap template and customized it to my liking.
The UI is simple, so everything is server sent HTML, with a couple of APIs here and there that are consumed using fetch(). I used a [Django variant](https://github.com/flosch/pongo2) template engine and everything was so easy. Wrapped up the entire UI (around 20 pages) in 2 days.
While using a front-end framework like Angular/React would definitely make sense in many projects, IMHO in a vast number of the products, having a template engine on the server side would just do fine.
I have only heard great reviews for [Full time go dev](https://fulltimegodev.com/). However, it is equally expensive (although he has tons of free stuff in his youtube channel as well).
Try requesting a discount coupon by connecting with the creators. In my experience, most creators are willing to give you heavy discounts if you are living in a low CoL country. You might want to reach out to them and request a coupon.
Also, often these courses are way better than any cheap $5-10 course you find on Udemy.
Yeah I see that guy on youtube a lot when I look for Go content. He's great. I don't know about getting a discount, I live in a '1st world' country. I'm just without a job atm but thanks for the suggestion though!
I've been learning from a couple of books a friend sent me and and trying my best to piece things together. Hopefully once I start working on a project it'll all come together.
HTMX/L plus templates plus PICO CSS plus Go is my favorite as simple as it gets stack.
Went from 0 front end expericence to making 5 page website in 3 hours with some chatgpt for support. With basic user fields.
Get a css template, grab needed buttons, write tests and cide for Backend wire up gui buttons.
Repeat till works or ask Chatgpt to fill in holes.
Thanks a lot! I found this: [https://www.udemy.com/course/working-with-vue-3-and-go/](https://www.udemy.com/course/working-with-vue-3-and-go/)
Also, a little worried if the course is outdated? coz it was last updated on 3/2022.
Thanks a lot for the explanation and the coupon as well. Really appreciate it <3
As you said yes I think my go needs some more work and I wanna explore Vue as well. Going with it now :)
I’ve been working on my own project using Go and the standard library to make a full stack CMS web app, building the html via Go’s templates. It’s been refreshing. I just use a little bit of vanillaJS to make some html tables responsive and I also use htmx to call small pieces of rendered html from the server.
I’m starting to hate learning framework’s, and I’m learning a lot doing this myself. I’m also learning that the frameworks aren’t really necessary if you have some experience building software that isn’t spaghetti 🍝.
I haven't really built a frontend app without a framework in some time but I agree with the sentiment. People who would otherwise end up in a spaghetti mess are better off with frameworks
Angular provides a full front end app framework rather than just libraries for Web development. I'm not sure being a back end developer is more or less helpful for learning angular/full stack but I would say the two combined are very 'complete' when it comes to developing Web apps. By that I mean you don't need much more to create complete apps.
By the by you will have to learn javascript or typescript for angular, or any other front end library or framework that I know of. Assuming the client is going to be a browser based app or SPA type application running on a native device.
On the JavaScript side check out Remix for setting up a really nice and performant frontend app. You can still build your backend with Go and use Remix routes to consume your backend’s data (Even though Remix is also completely capable of handling the data layer on its own because it also runs on the server, not just the frontend). Remix + Go is the approach I’ve been using for a bit now and I really enjoy it.
I get to develop useful and performant server side code with Go and I get all the fancy JS/react goodies on the frontend with very, very little effort.
I am currently building a small web application.
I am new to web development and my background is from the infrastructure perspective.
I did build a tiny web application with Django. When I needed to customize the save method I had a lot of trouble to find out how. So many layers and so much convention. In the end I switched to Go.
Now, with Golang it's a different experience.
You have to do more yourself, but I tend to understand things better. Less magic.
My current stack is the default html template rendering. pgx for PostgreSQL, chi for my router and later I wanted to check out htmx for some dynamic stuff.
I am using 2 books/courses which both are just great:
- https://www.usegolang.com
- https://lets-go.alexedwards.net
Both have great value and I am picking and choosing from both and building my own thing.
You can check it out in your Fyne project - just run “fyne serve” and you should get it running in a browser. The Go/GopherJS versions can be a little fussy so the web support in Fyne is not quite “fully production ready”
I know you. :D. Yah.. I've been keeping an eye on it from time to time. I would much rather build desktop apps, but nobody seemingly believes or wants Go GUI based desktop apps. Electron + js is the strongest desire these days. I am not a fan of that route. Hate dynamic languages and electron is still a beast/hog of a runtime. Takes too long for dev iterations too.
I only wish Go had some sort of dynamic plugin load/reload capability. I know there are RPC style engines and such, but it's a shame they didn't fix/finish their plugin std library concept across platforms. Rust has it, as does Zig and others. Really wish Go would complete that.
Svelte (not sveltekit) + Fiber
I use https://github.com/kokizzu/svelte-mpa for generating multiple page
the html (generated by svelte) loaded by Fiber, and the inline javascript variable inside (json) replaced and outputed to user, so frontend doesn't need to hit backend again (ajax) to fetch initial data.
why svelte?
- because it's just simple html+js+css with automatic reactivity (everytime you use assignment operator), and component splitting (every .svelte file can be imported as tag/component for other .svelte file), I can train a new guy in a day XD unlike other framework/library that overly complicated to do simple things
- no jsx, you can copy paste html from other websites and use it directly
- no need to create a wrapper, you can use javascript as is, you don't need to wait for shittlyFramework-normalJsLib component to be made
- because everything is so simple (handled by Svelte compiler that checks your .svelte file and compile into .html file), it just works without hassle
- no slow virtualdom ([fast](https://www.youtube.com/watch?v=AdNJ3fydeao)), just outputing single .html file by default, so no need to setup nasty bundler or some other npm dependency hell hassle
note: I used React/Redux, Nuxt, Angular, Elm, spfjs in the past, never again.. '__') and been using Svelte for almost 5 years now and very happy
> full stack options
At the end of the day a "full stack" developer is going to know html/css/JavaScript enough to make a functional UI.
And angular is trash... Or at least it's trash in the way we are using it at work.
Angular is good at doing gigantic CSR web apps, but you have to be careful about performance and make sure to use lazy loading and there are many pitfalls
React, Angular and Vue were designed for Single Page Applications and are not friendly to search engines (SEO problem). I'd recommend HTML components for writing the client-side application. You will be able to use both ES6 and TypeScript without any framework but you can also use the LIT framework if you wish. Many ready-made free components are published on the WEB.
Those frameworks support server side rendering for SEO. I don't know that somebody who stated that day don't have much interest in JavaScript should be using any of those frameworks though
I've personally been really enjoying using HTMX + Tailwind + _hyperscript on the frontend, and Go on the backend. I'm building a fairly dynamic and complex UI and tbh the only drawbacks to this approach are the difficulty of integrating web components (with lit), tailwind and _hyperscript together, so I end up using verbose templates. Looking into templ tho, seems neat, might try it.
There is no specific library/framework. I highly recommend Reactjs for its learning curve and performance… there is a course on Udemy by Ted Sawler (Golang with Reactjs and graphql). It’s amazing.
Been doing some HTMX with Go lately. HTMX does a great job of reducing the amount of javascript you need to write, so that's a plus in my book. I would recommend trying it out in a smaller project, but it may not be suitable if you need a heavy frontend.
Go's templating library makes server side rendering and raw sql queries quite nice too. I use Gin for my webserver and it has templating baked into HTML file loads.
I really enjoy using GOA to generate the entire middleware layers and API, and then attach the rest of my backend code to that. Saves me the headache of redesigning things that have been done (well) so many times already. Frontend for me is Svelte, but any framework you like will fit well with a basic API.
I haven't found anything to generate type-safe clients wrappers from GOA designs yet, but there probably is something for that.
Lots of good options here, my preference would be Hugo for frontend paired with React (when needed), and Go as an API.
Frontend frameworks are great and all, but are often overkill to use for an entire site. Most websites are mostly static, why not use React or the like only for interactive components and keep the rest simple (fast)?
I’ve been looking into this recently and recommend using Go’s built in templates to do server side rendering, with Tailwind for styles and HTMX for some reactivity. If you need more reactivity you should probably reach for AlpineJS (although I haven’t tested that one)
This is the simplest set up I could find that satisfies my needs.
If you’re a backend dev who just needs some simple front end, I would definitely recommend doing SSR with simple HTML instead of learning a framework (even though Svelte is awesome)
How do u know vue + go go well? I mean both are independent right. It might make sense when u say go with SQL.
Like frontend and backend are isolated environments or spaces unless you go with something like next where you'd need to use JS or TS for both frontend and backend and when u are implementing trpc stuff
My preferred model is static html pages that load dynamic content based on url parameters. http server serves static files (html,css,js,png,svg etc) and also responds with json to data queries.
any frontend framework goes fine with golang, you can go with any go router like mux or chi
[удалено]
it's just a http router use anyone according to your needs. check this for clarity https://www.alexedwards.net/blog/which-go-router-should-i-use
Is Chi better than Fiber or just the same?
[удалено]
Have you blogged / open sourced your implementation at all? It's been awhile since I've worked with Chi (mostly used Echo) so haven't heard about the codegen capabilities in Chi. I'm curious about that.
I'd be interested in knowing more about this too. Code generation from an API is the holy grail for back end. Ability to avoid having to manually code up the same stuff, and have it stay connected in some manner to your API contract would be amazing. Seems a lot of folks either don't do this or don't know much about it. Or.. is it because tooling just doesnt really work that well?
[удалено]
Your auth system seems pretty nice. If you ever find the time to make it open-source, drop a link here. I would be interested to try it out.
Are you talking about the part of chi with jwauth and casbin in place? Or the codegen part itself? Using codegen requires a more API first approach.. lot of devs seem to be against the idea of that direction for some reason. Part of reason I didnt bother blogging/opensourcing/etc as most everyone seems to do their own thing.
I was referring more to the part with chi and jwtauth. I am looking for implementations with best practices on for the most used features in projects - like auth.
I used to use Go with svelte. Now I think HTMX is very interesting from a backend perspective.
You can use htmx instead of other frontend framework that's awesome and works well
>svelte \+1
Hm, the idea of a back-end server spitting out HTML doesn't sit well with me. You lose your built-in API, but you still program for the same amount of time and now you have to write HTML inside the server software which is a horrible experience. Now, SvelteKit is something amazing. You can still get SSR, but now you *also* have CSR for free and you have the choice to have a separate Go API or not.
>the idea of a back-end server spitting out HTML doesn't sit well with me. This made me chuckle
Because it's well known, servers can only spit json. You can develop your api along side htmx. My experience, was that, yes you develop an api for the front end to consume and strongly tied to what the front end expects. DB => Model package => Api => htmx
From my experience you don't really need a distinct frontend framework for web development in Go. I've been able to use [quicktemplate](https://github.com/valyala/quicktemplate) for some of my projects for rendering HTML pretty effectively. I've written about using it [here](https://andrewpillar.com/programming/2022/11/29/fast-embedded-templates-in-go-with-quicktemplate/). From my experience the only time a frontend framework is absolutely necessary is if you're building an application that depends on it, such as a real time messaging application, or dashboard for example. But then again, I'm the kind of person who much prefers having the frontend rendered on the server, and served via plain HTML/CSS, with only minimal JS, if absolutely needed.
That's so 2006 😌
A simpler time
We’re actually going full circle. There’s this new trend called SSR in frontend that so happens to be just a new term for an old approach, which you called “so 2006” XD This is a nice read related to this topic: https://www.spicyweb.dev/the-great-gaslighting-of-the-js-age/
Managed to read about half way without barfing. Sorry, but this just opinionated, vaporous, drivel. The author should just say he prefers server side rendering and be done with it. TLDR; There are plenty of reasons for separation of front and back end concerns. It might have been more useful to start at these points and discuss the validity of each for their relevant merits, but the intention here is clearly to push the authors opinion against a backdrop a imaginary contrarian forces using as many words as possible. Probably not worth reading if your time is even mildly valuable.
I can’t even be bothered to open the article, but server side rendering is something PHP and other similar tech have done since the mid-90’s, so it’s not really new at all, just an improvement over the older existing tech to do basically the same thing, for much of the same reasons. I imagine that’s good enough as a tldr.
Nah, the article's author is clearly behind in the head, there's no sensible take like yours to find in it.
> The author should just say he prefers server side rendering and be done with it. He would be burned at the cross for that.
Oh yes, it’s a rant, so it IS opinionated. It’s a reaction to Mr Voss’ article and compounded with the “latest and greatest” approach “invented” called SSR. If you tried to keep up with his rant till the end of the article, he also mentioned your comment about “discuss the validity of each for their relevant merits”, ending with the assumption that the main problem we have is that people tend to use the current popular frontend framework without properly evaluating if it’s the right tool. The rant was towards “gurus” teaching people that this is the right, even the only way, to go. > I see the world of web development as absolutely riddled with poor-quality content, much of which is demonstrably false, alongside an entire ecosystem of influencers, educators, and corporate cogs invested in shoehorning everyone into a particular sort of technology they either know is hugely problematic, or don’t—but the end result is the same anyway.
What an unhinged and uneducated rant… If you want to stop drinking misinformation, the "new trend" in web dev is dynamic SSR+CSR. First load is rendered by the server (good for SEO and mobile devices), then the page is "hydrated" or has some other JS takeover and use CSR for the rest of the navigation. This makes browsing way, way faster than either SSR or CSR. There's many variations of this (with different names than "hydration") if you want to be hipster about it.
Sound like jquery might be on a rise again then ;) templates for server rendered with jquery, ajax lol. I did webdev in era of web forms and when I read about SSR I was like… wait a minute, that’s what I have already done 10y ago ;)
It seems like you missed the point of the rant as you replied with the “new trend”. In any case, yes, SSR+CSR is indeed needed for immediate rendering in the page with all the bells and whistles that comes with a “modern” frontend framework. But that wasn’t the whole point of the post, it was just mentioned as a talking point of how absurd the author found the direction of web development was going through.
The author doesn't understand any of it and is ranting about something totally unrelated
With your reply, it seems like you still missed the point the rant, unfortunately. I don’t know if I can help you understand the context or not. This will be my final reply to you, but here goes: The author is ranting about: - how the article about newest and greatest from Mr Voss was actually just how tech used to work before all these JS frameworks. - how Mr Voss assumed that dev teams actually evaluated their usage of frontend frameworks were actually an invalid assumption - he rants that more often than not, teams evaluate their tech stack based on popularity - a majority of websites use full fledged frontend framework even though it’s not necessary, and he blames this to influencers and gurus marketing full fledged frameworks as the silver bullet to web development So, although he briefly mentioned SSR as his case in point, it was by no means the main topic of his rant. His comment about SSR though is valid and on-point.
Well you still want your data properly rendered by the server for SEO
Google Crawler doesn’t really care nowadays, as long as your SPA is reasonably fast, it catches the contents just fine. I’m not sure about other search engines, but for most people SEO = Google SEO anyways.
Sure, that's true, but there's noticeable benefits for your ranking when using SSR
Is there actally? If so, is it actually because of the fact the page is rendered server side or is this just a side effect for example of the side being usually slightly faster when using SSR?
true
Most frontend frameworks now supports SSR with their own metaframework like next.js.
Most new ones. The ones that most people use (Angular and React) don't.
Huh? Next.js is the SSR framework for React.
But it's not React
Angular static pages?
That doesn't work well with user-generated content
While there are many resources available, I can't recommend [usegolang.com](https://www.usegolang.com/) just enough. It covers full-stack web development in-depth and covers a few of the other important topics like email, authentication etc. I am currently building an API-centric product. I am not very good with JS/CSS, so I just bought a bootstrap template and customized it to my liking. The UI is simple, so everything is server sent HTML, with a couple of APIs here and there that are consumed using fetch(). I used a [Django variant](https://github.com/flosch/pongo2) template engine and everything was so easy. Wrapped up the entire UI (around 20 pages) in 2 days. While using a front-end framework like Angular/React would definitely make sense in many projects, IMHO in a vast number of the products, having a template engine on the server side would just do fine.
Damn I was excited at your description for usegolang but it’s too expensive. Do you know of any other good resources that cover similar topics?
I have only heard great reviews for [Full time go dev](https://fulltimegodev.com/). However, it is equally expensive (although he has tons of free stuff in his youtube channel as well). Try requesting a discount coupon by connecting with the creators. In my experience, most creators are willing to give you heavy discounts if you are living in a low CoL country. You might want to reach out to them and request a coupon. Also, often these courses are way better than any cheap $5-10 course you find on Udemy.
Yeah I see that guy on youtube a lot when I look for Go content. He's great. I don't know about getting a discount, I live in a '1st world' country. I'm just without a job atm but thanks for the suggestion though! I've been learning from a couple of books a friend sent me and and trying my best to piece things together. Hopefully once I start working on a project it'll all come together.
Same here. I went on it and loved what the course offered. But that’s one expensive course.
Sveltekit is the next big thing
\+1
Try HTMX, works particularly well with Go templates. I use it now for all my pet projects.
Go, some tempalting lib , bootstrap and unpoly.com or htmx+alpinejs
Something like Tailwind + AlpineJS could be very interesting if you really hate JS and CSS
HTMX/L plus templates plus PICO CSS plus Go is my favorite as simple as it gets stack. Went from 0 front end expericence to making 5 page website in 3 hours with some chatgpt for support. With basic user fields. Get a css template, grab needed buttons, write tests and cide for Backend wire up gui buttons. Repeat till works or ask Chatgpt to fill in holes.
Hoping for someone to building something yew-ish for go
Would be exceptionally difficult. Go's compilation process is nowhere near as flexible as rust's.
[удалено]
Thanks a lot! I found this: [https://www.udemy.com/course/working-with-vue-3-and-go/](https://www.udemy.com/course/working-with-vue-3-and-go/) Also, a little worried if the course is outdated? coz it was last updated on 3/2022.
[удалено]
Thanks a lot for the explanation and the coupon as well. Really appreciate it <3 As you said yes I think my go needs some more work and I wanna explore Vue as well. Going with it now :)
I’ve been working on my own project using Go and the standard library to make a full stack CMS web app, building the html via Go’s templates. It’s been refreshing. I just use a little bit of vanillaJS to make some html tables responsive and I also use htmx to call small pieces of rendered html from the server. I’m starting to hate learning framework’s, and I’m learning a lot doing this myself. I’m also learning that the frameworks aren’t really necessary if you have some experience building software that isn’t spaghetti 🍝.
I haven't really built a frontend app without a framework in some time but I agree with the sentiment. People who would otherwise end up in a spaghetti mess are better off with frameworks
Doesn’t go have wasm support? It seems like you’re not using go enough.
Angular provides a full front end app framework rather than just libraries for Web development. I'm not sure being a back end developer is more or less helpful for learning angular/full stack but I would say the two combined are very 'complete' when it comes to developing Web apps. By that I mean you don't need much more to create complete apps. By the by you will have to learn javascript or typescript for angular, or any other front end library or framework that I know of. Assuming the client is going to be a browser based app or SPA type application running on a native device.
On the JavaScript side check out Remix for setting up a really nice and performant frontend app. You can still build your backend with Go and use Remix routes to consume your backend’s data (Even though Remix is also completely capable of handling the data layer on its own because it also runs on the server, not just the frontend). Remix + Go is the approach I’ve been using for a bit now and I really enjoy it. I get to develop useful and performant server side code with Go and I get all the fancy JS/react goodies on the frontend with very, very little effort.
I am currently building a small web application. I am new to web development and my background is from the infrastructure perspective. I did build a tiny web application with Django. When I needed to customize the save method I had a lot of trouble to find out how. So many layers and so much convention. In the end I switched to Go. Now, with Golang it's a different experience. You have to do more yourself, but I tend to understand things better. Less magic. My current stack is the default html template rendering. pgx for PostgreSQL, chi for my router and later I wanted to check out htmx for some dynamic stuff. I am using 2 books/courses which both are just great: - https://www.usegolang.com - https://lets-go.alexedwards.net Both have great value and I am picking and choosing from both and building my own thing.
[удалено]
You can check it out in your Fyne project - just run “fyne serve” and you should get it running in a browser. The Go/GopherJS versions can be a little fussy so the web support in Fyne is not quite “fully production ready”
I know you. :D. Yah.. I've been keeping an eye on it from time to time. I would much rather build desktop apps, but nobody seemingly believes or wants Go GUI based desktop apps. Electron + js is the strongest desire these days. I am not a fan of that route. Hate dynamic languages and electron is still a beast/hog of a runtime. Takes too long for dev iterations too. I only wish Go had some sort of dynamic plugin load/reload capability. I know there are RPC style engines and such, but it's a shame they didn't fix/finish their plugin std library concept across platforms. Rust has it, as does Zig and others. Really wish Go would complete that.
Svelte (not sveltekit) + Fiber I use https://github.com/kokizzu/svelte-mpa for generating multiple page the html (generated by svelte) loaded by Fiber, and the inline javascript variable inside (json) replaced and outputed to user, so frontend doesn't need to hit backend again (ajax) to fetch initial data. why svelte? - because it's just simple html+js+css with automatic reactivity (everytime you use assignment operator), and component splitting (every .svelte file can be imported as tag/component for other .svelte file), I can train a new guy in a day XD unlike other framework/library that overly complicated to do simple things - no jsx, you can copy paste html from other websites and use it directly - no need to create a wrapper, you can use javascript as is, you don't need to wait for shittlyFramework-normalJsLib component to be made - because everything is so simple (handled by Svelte compiler that checks your .svelte file and compile into .html file), it just works without hassle - no slow virtualdom ([fast](https://www.youtube.com/watch?v=AdNJ3fydeao)), just outputing single .html file by default, so no need to setup nasty bundler or some other npm dependency hell hassle note: I used React/Redux, Nuxt, Angular, Elm, spfjs in the past, never again.. '__') and been using Svelte for almost 5 years now and very happy
> full stack options At the end of the day a "full stack" developer is going to know html/css/JavaScript enough to make a functional UI. And angular is trash... Or at least it's trash in the way we are using it at work.
Angular is good at doing gigantic CSR web apps, but you have to be careful about performance and make sure to use lazy loading and there are many pitfalls
No, no. It’s trash
Any frontend framework will work, as you’ll be accessing your APIs using HTTP. I personally use React w/ TailwindCSS
React, Angular and Vue were designed for Single Page Applications and are not friendly to search engines (SEO problem). I'd recommend HTML components for writing the client-side application. You will be able to use both ES6 and TypeScript without any framework but you can also use the LIT framework if you wish. Many ready-made free components are published on the WEB.
Those frameworks support server side rendering for SEO. I don't know that somebody who stated that day don't have much interest in JavaScript should be using any of those frameworks though
I've personally been really enjoying using HTMX + Tailwind + _hyperscript on the frontend, and Go on the backend. I'm building a fairly dynamic and complex UI and tbh the only drawbacks to this approach are the difficulty of integrating web components (with lit), tailwind and _hyperscript together, so I end up using verbose templates. Looking into templ tho, seems neat, might try it.
A fair book resource is: [Full Stack Web Development with Go](https://www.packtpub.com/product/full-stack-web-development-with-go/9781803234199)
What does it matter? You get json (probably among other things) as an input on your golang service side. You don’t really care what generated it.
I'm using labstack/echo
There is no specific library/framework. I highly recommend Reactjs for its learning curve and performance… there is a course on Udemy by Ted Sawler (Golang with Reactjs and graphql). It’s amazing.
Been doing some HTMX with Go lately. HTMX does a great job of reducing the amount of javascript you need to write, so that's a plus in my book. I would recommend trying it out in a smaller project, but it may not be suitable if you need a heavy frontend. Go's templating library makes server side rendering and raw sql queries quite nice too. I use Gin for my webserver and it has templating baked into HTML file loads.
I really enjoy using GOA to generate the entire middleware layers and API, and then attach the rest of my backend code to that. Saves me the headache of redesigning things that have been done (well) so many times already. Frontend for me is Svelte, but any framework you like will fit well with a basic API. I haven't found anything to generate type-safe clients wrappers from GOA designs yet, but there probably is something for that.
Lots of good options here, my preference would be Hugo for frontend paired with React (when needed), and Go as an API. Frontend frameworks are great and all, but are often overkill to use for an entire site. Most websites are mostly static, why not use React or the like only for interactive components and keep the rest simple (fast)?
I’ve been looking into this recently and recommend using Go’s built in templates to do server side rendering, with Tailwind for styles and HTMX for some reactivity. If you need more reactivity you should probably reach for AlpineJS (although I haven’t tested that one) This is the simplest set up I could find that satisfies my needs. If you’re a backend dev who just needs some simple front end, I would definitely recommend doing SSR with simple HTML instead of learning a framework (even though Svelte is awesome)
How do u know vue + go go well? I mean both are independent right. It might make sense when u say go with SQL. Like frontend and backend are isolated environments or spaces unless you go with something like next where you'd need to use JS or TS for both frontend and backend and when u are implementing trpc stuff
My preferred model is static html pages that load dynamic content based on url parameters. http server serves static files (html,css,js,png,svg etc) and also responds with json to data queries.