Yes, we can have jsx style html authoring in Go. From 1 style to 2 is not a simple addition. In stead of directly writing inline styles, we adopted the data-slot approach from shadcn to compile components of different styles.
Also upgrade cli to support preset to apply created style into your project
It doesn't depend on node for runtime. Only for dev: the vite dev server, and js bundling, nothing else.
Also I've been a long time templ & html/template user, also used templui. gsx is born out of my ergonomics desire from templ. gsxui is similar to templui, but makes bundling possible. Also borrowed pipeline filters from html/template. But you're right, this does involve a _build_ step. But I think it's worth it.
Later I'll add the bundler free version. But really, vite has been so useful. Just treat it as another tool.
It's easy to follow, it's a knee jerk tribalism reaction and not a logical or informed one. Go attracts backend or anti-frontend people so anything intermingling the two will draw out the commenters who bemoan anything that realistically builds a modern website. Just ignore it, your choice for dev tooling is practical and makes sense to me.
As someone who has had to clean up systems that only did a _npm install_ to get compromised, despite being good Renovate citizens, it doesn't matter if it is not "on the production path".
I don't care to hear arguments about how npm was _configured wrong_.
A tool with insecure defaults, with a long and storied history of being the vector by which data has been exfiltrated and companies hacked, needs to do an awful lot to justify still being used for any infrastructure our team is responsible for.
The proxy caches and package solution for Go has had its own drama.
My big contention with this project is that if I wanted to use node (or npm; or vite) in any capacity, I would have chosen node for that. I don’t want to use those tools in this context because it serves me worse than a well thought out solution.
The thought out solution is to isolate your frontend into its own directory. You can embed and serve that as part of your Go server. That frontend could have been done with react, vite, jsx, whatever typescript nonsense you want; without the Go parts necessarily needing npm or node in the build process.
I'm in an advisor position, and I tried very hard to mentor the team, explaining that learning this technology deepens your understanding of the browser. Whereas React etc isolates you from the actual environment you're working in - the browser.
On html/template, I like the security by default, and obviously it's built-in. But the dynamicness leaves too many open-ended questions unanswered. Templ is great, but the ergonomics leaves many things to be desired. After writing a few large production applications in it. I decided to create gsx: https://github.com/gsxhq/gsx
I've worked with developers that don't even understand that the "form" tag exists and browser can send a request without any javascript. At some point in the early 2010's, perhaps even before, fundamental understanding disappeared. This makes it difficult to introduce alternative technologies like HTMX into a larger project.
yeah with tools like HTMX - your environment shapes you.
if your teams is less than 3 people - you've less politics to fight. & chances are people are already capable - no resume padding. so you choose what's pragmatic & that choice ends up being HTMX.
for big teams - politics takes over. even though HTMX will be beneficial - might as well go with the 'safer' political choice which doesn't cause much contention ie one of the big JS frameworks.
Templ tries to stay simple, but it sacrificies ergonomics for simplicity and verbosity.
Over the years, there are many proposals: inline elements, HTML tags, error hoisting. It's hard to retrofit into it.
Beside the above, I also tried solving the all the ergonomics problem I saw when using templ. E.g. auto class merging, easy javascript interpolation within attributes. Auto json interpolation etc
What i'd want is a way to revert back, if the user sees a problem.
The automatic updating toolchain is not a bad idea, and in most cases it works great. Once in a while though, there's a fuck up and breaks your build or something changes that you didnt expect.
The best way forward is to keep the old tool in a backup location, and have the user be able to revert the update with a single command. Then the user is able to safely return to the old one when the inevitable breakage happens. You could even opt-in to analytics for this action, and the owner of the tool would know if a particular update is a screwup (aka, many people reverted it).
To be clear, the new toolchain doesn't replace the old toolchain, but is installed alongside it, and is only used for modules that explicitly request the newer toolchain in their go.mod file.
If you have a `go.mod` that sets a `go` directive with a version bigger than the version your Go toolchain is currently running, it will download the binary automatically and pass the commands to the new binary. However this doesn't replace your `go` binary in say, PATH, the new toolchain will be downloaded at `GOPATH`, the same as it does with your modules. This is why there is nothing to backup here, nothing is deleted.
Also, keep in mind that if Go is downloading a new toolchain, it means your project will not work with the current toolchain: because if you set `go 1.23` in your `go.mod`, and your current `go` is version 1.22, it would fail regardless until you either fix your `go.mod` or upgrade your `go` toolchain. What Go is doing here is the later, automatically for you.
If you didn't commit the breaking change to the repo, couldn't you just revert your local changes? Trashing the mod and sum file and running "tidy" should take care of the rest, I would think. Maybe I'm missing something?
I've done a few interviews like this recently. I always thought I was a OK programmer, judging from the feedbacks I get from colleagues. But after these interviews, I felt terrible. Doing my daily Leetcode as we speak...
Also upgrade cli to support preset to apply created style into your project