jackielii

Joined 13 years ago

Karma

Submissions

Member since

Mar 18

Recent submissions

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

gsxui (Shadcn for Go) now has a second style maia ui.gsxhq.dev

2 jackielii 3 months ago 1 comments

Comment · 3 months ago

I'm not sure I follow. Node is not on the production path

Comment · 3 months ago

Absolutely. I already ported my production app - enterprise customer to it. I use it with https://github.com/jackielii/structpages/

Comment · 3 months ago

Yep, exactly, you can also do code splitting by adding multiple entry points. https://github.com/gsxhq/vite does the heavy lifting

Comment · 3 months ago

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.

Comment · 3 months ago

because Vite is great. It only uses it in dev. In prod, no node involved. Try the gsx init. You'll know why. The dev experience you'll want.

EDIT: highlights are:

- live reload: it only reloads after new binary is built. also has /healthz check integration. I believe this is better than air, wgo etc

- dev panel & error overlay: see generate, build status: on syntax error, you get an error overlay explaining where the error is;

- status for slow builds: if you're working in a big project, you can see the building progress & log in the dev overlay

Gsxui – Shadcn-style components for Go ui.gsxhq.dev

73 jackielii 3 months ago 19 comments

Comment · 3 months ago

Exactly the same thing happen to me: https://www.reddit.com/r/htmx/s/DuXyGgsCWK

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

Why I built gsx instead of just templ jackieli.dev

3 jackielii 4 months ago 0 comments

Comment · 4 months ago

This is why I created gsx actually. I made a post: https://jackieli.dev/posts/why-i-built-gsx/

Comment · 4 months ago

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

References: