jackielii

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

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

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

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

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.

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

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

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

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:

- HTML-style component authoring: https://github.com/a-h/templ/issues/663 and https://github.com/a-h/templ/issues/1181

- Inline/anonymous templ functions: https://github.com/a-h/templ/issues/1150

- Passing Go data to JS: https://github.com/a-h/templ/issues/944 and https://github.com/a-h/templ/issues/838

- JSON helpers for frontend data: https://github.com/a-h/templ/issues/739

- Deprecating script-tag Go interpolation due parser complexity: https://github.com/a-h/templ/issues/1408

- CSS/class ergonomics: https://github.com/a-h/templ/issues/61

- Duplicate class behavior: https://github.com/a-h/templ/issues/902

- Conditional attributes / else-if: https://github.com/a-h/templ/issues/933

- Dev mode/watch ergonomics: https://github.com/a-h/templ/issues/318

- Dynamic HTML element helper: https://github.com/a-h/templ/issues/1113

I'm the author, AMA

Well said!

It's not automatic though. You explicitly change your go.mod file and then it downloads the toolchains.

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...

I have an alternative solution to work with an existing struct that you can't change, e.g. protobuf generated code: https://jackieli.dev/posts/pointers-in-go-used-in-sql-scanne...

  type nullString struct {
    s *string
  }
  
  func (ts nullString) Scan(value interface{}) error {
    if value == nil {
        *ts.s = "" // nil to empty
        return nil
    }
    switch t := value.(type) {
    case string:
        *ts.s = t
    default:
        return fmt.Errorf("expect string in sql scan, got: %T", value)
    }
    return nil
  }
  
  func (n *nullString) Value() (driver.Value, error) {
    if n.s == nil {
        return "", nil
    }
    return *n.s, nil
  }

Then use it:

  var node struct { Name string }
  db.QueryRow("select name from node where id=?", id).Scan(nullString(&node.Name))

Nothing is perfect. I focus on solving problems

I believe this is discussed and decided quite early on: https://docs.google.com/document/d/19kfhro7-CnBdFqFk7l4_Hmwa...

>According to the Import Compatiability Rule for versioned Go, this implies that the new proto package must have a new import path. Since "github.com/protobuf/proto/v2" will incur great confusion with the proto2 syntax, we may take this time to use an import path like "google.golang.org/proto" (similar to how gRPC lives at "google.golang.org/grpc").

Thinkpad in 3:2 for me

Exactly! if only have have 3:2 screens!!! or better yet, a 4:3 screen!

Currently I'm buying a old X61s and going to convert it to X62: https://www.notebookcheck.net/Lenovo-X62-Laptop-Review.21159...

Same here. I can live without touch or stylus, just want a performance laptop with good screen (3:2 ratio) and keyboard.

I just run away

OMG I want this!!!