Also upgrade cli to support preset to apply created style into your project
74 karma · joined March 18, 2013
Also upgrade cli to support preset to apply created style into your project
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.
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
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
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
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))>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").
Currently I'm buying a old X61s and going to convert it to X62: https://www.notebookcheck.net/Lenovo-X62-Laptop-Review.21159...