Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Change due to Golang APIs v1.22 - use of dependencies #3

Open
surfmuggle opened this issue Aug 6, 2024 · 2 comments
Open

Comments

@surfmuggle
Copy link

surfmuggle commented Aug 6, 2024

In your great Video How to create your Golang APIs from now on with v1.22 you suggested to go without dependencies until there is a clear reason to add one.
You said that two questions can help decide whether to add a package dependency

  • Do the team or I have the resources or time to implement the package's functionality ourselves?
  • Do I want to maintain this feature implementation in the future?

This is a tricky question for someone new to Go and without knowledge about the packages / dependencies used in this project fullstack-go-htmx.

I would prefer to avoid dependencies but i would not be willing to reinvent the wheel that 3rd party dependencies already solve. But without a better understanding what Templ and gorialla/mux offer compared to the standard library and what features i might need i am unable to decide.

I asked ChatGPT about the differences but as known this could be outdated or plain wrong.

Edge Conditions:

  • no prior knowledge of templ, gorilla/mux nor net/http, template/html
  • use of htmx is planned but also no prior knowledge

What would you recommend use the 3rd party packages or avoid them?

Dependencies

The file go.mod has these direct dependencies

  1. Templ - HTML templating. Alternative standard library html/templ
  2. gorilla/mux a request router and dispatcher. Alternative possibly http/net from the standard library?
  3. Database migrations Alternative in standard library ? none ?
  4. MySQL-Driver for Go's database/sql. Alternative in standard library ? none ?

And these indirect dependencies - a direct dependency depends on other packages

@sikozonpc
Copy link
Owner

Hey @surfmuggle thanks for the great question.

When it comes to Go, there is a big thing going around saying that we shouldn't use dependencies. However that is not so binary as it sounds, most of biggest software out there, take Linux for example (the operating system) it's built using 3rd party software as well.

Now, answering your question depends on what your building, do want to learn or speed? Using code that someone wrote is going to make you go faster, but in the future do you foresee too much configuration of that code? If so maybe that package doesn't give you that flexibility and you have to build your own solution.

In content online and in the industry packages are used a lot for speed purposes, in content to make the video short and in business to get the a faster time to market.

So, TLDR; I wouldn't worry to much about packages, just be pragmatic on what you need and what you can possibly build yourself. I wouldn't want to build HTMX from scratch or Templ but I need a server side UI built, so I consume those packages. On the other hand I might not need gorilla/mux and I can easily build my HTTP routing layer with std library.

Hope that helps.

@surfmuggle
Copy link
Author

surfmuggle commented Nov 3, 2024

I wanted to understand at least a little why templ was created and found

Building HTML Frontend with Go & Templ - Adrian Hesketh | #HTMXCon2024
channel: The Code Critical

Adrian is the initial creator of templ. And below you can find some of my notes from the video above

Why Server Side Rendering

  • Create static pages for Search Enginge Optimization (SEO)
  • Accessibility (for instance UK GDs: page does not need javascript)
  • Team skills (no javscript know how -> learning curve)
  • SPA offers no rendering adavantage since backend must wait for API
  • Performance

Why templ - and what are the stdlib templates shortcomings

  • you can not use arbitary functions {{.Material | toUpper}}
  • no checks during build - accessing non existing vars {{.Rpice}} fails at run time
  • developer experience is inferior compared to react (JSX) or .Net razor pages
    • Autocompletion
    • Syntax highlghting
    • compiled into MSIL then JIT compiled into machine code

templ - history, goals and advantages

  • history: first attempt was to built on stdlib templating but was not easy
  • goals / advantages:
    • offer autocompletion (templ LSP uses gopls),
    • get compile time errors
    • use go code (func, control flow) inside templates if person.Age == 42 { <p>...<p> }
    • reduce render time (be fast)
    • temple offers hot reload (via watchmode and or vs extension CTRL+R)

I hope that the documentation or FAQ will be modified to include the benefits of templ: a-h/templ#987

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants