templ Hello(name string) {
<div>Hello, { name }</div>
}
For me personally, the latter seems nicer
- I can see at a glance the structure of the HTML
- Completion on the HTML tags, attributes, etc
- Completion on CSS (TailwindCSS LSP for VSCode)
- Logic can still be shared with other types of UIs (e.g. CLI, Native Apps, Webkit, gRPC)
If what you want is option 1, isn't this solution incomplete. That is, the fully realised vision would be a native component / widgets API (e.g. Fyne, QT, GTK), and then generate HTML from the components?
However, "since Dagger Cloud is built as a PWA, it can be installed as a desktop or a mobile application. This makes it possible to launch Dagger Cloud like a native application and get a full-screen experience without needing to open a browser first, or just have a dedicated icon in your desktop taskbar/dock", so it sounds like the "Native App" is using a Webkit (e.g. Wails, Tauri, Electron)
Anyway, congrats on having commercial users building stuff with your project!
Have to admit I've never used this code, and didn't know what it was about. Quickly read up about it. So ETag is a hash of the resource. You must provide it with requests that modify the resource. If your hash doesn't match the server hash, then 412 Precondition Failed is returned?
I'm working on a server/backend for htmx that's intended to run as a local service beside the browser. In theory you could do this with any server stack that is self host-able. My goal is to produce a single binary with no external service dependancies. I'm using Go, and a lot of the components are readily available, e.g. self updating local service, replicated database, etc. It's easy to cross-compile for different target OS and architectures. As an alternative to building everything into the browser, and assuming you're able to run a separate process, this approach makes a lot of sense to me. It would be great if Go had something similar to Deno's permission management though...
Been renovating an old house with a large garden for almost ten years now. I tell myself this is better than building something from scratch, but it definitely doesn't always feel more efficient. It helps that I didn't have the option back then, but now maybe I do? Sometimes it's also hard to tell, in the moment, which things to keep and what to rip out.
Touch typing is something I should've invested in much earlier, can't imagine how I ever coped without this ability. Another thing that really helped me is the "Alternative finger positioning" described here: https://typingsoft.com/typing.htm It feel much more natural not having to bend your wrists. Is anyone else also doing this? Whenever people ask me how to learn touch typing I look for native Linux or macOS app that teach this technique, but I haven't found any yet...
Actually, just remembered why I haven't used it. Although it "Ships with IDE autocompletion", last time I checked that's only on the Go code, not the HTML. Usually I keep my templates as .html files, and find the IDE autocompletion and linter on the HTML more valuable
I applied for a UK visa from South-Africa about a year ago. To start my application I had to submit a form on this domain. The navigation to the form was obscured by a giant banner about the Ukraine invasion and a message about how service levels might be reduced due to refugees... no matter how I resized my browser window I couldn't get to the part of the page behind the banner. Eventually I opened up the Dev Tools and added some CSS to hide the banner. The link was revealed and I could continue with my application
Last time I checked it's not possible on iOS. On Android it's possible with some effort (e.g. you have to use Termux), not something you could expect a user to setup
Instead of wrapping the application with something like Electron, why not install as a service and connect to a localhost port using your default browser?
I know this is not the same UX as installing an app. But why isn't this technique more standard?
Besides more efficient resource usage, another benefit is that it keeps the client/server architecture.
This default behaviour makes sense. If you're going to be using it for hosting in production, then read the documentation, and it's trivial to disable. If I recall, AWS has a similar default for some services. That is, access to the subnet (VPC) gives you full access to the attached service, no password required.
"This project attempts to push TypeScript's type system to its limits by actually implementing various functions and algorithms, purely on top of the type system... Please note that this project is meant to be used for fun and learning purposes and not for practical use"
The hx-disable attribute can be used to disable htmx for parts of the DOM that load user generated content, is that what you're referring to? https://htmx.org/docs/#security
> suspense (or another form of components loading their own data)
The htmx lib https://htmx.org/ mostly takes care of this: "gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML". The hx-boost tag can also be used for progressive enhancement.
> as soon as you need the bloat you’re just reinventing a wobbly wheel without one
When building a rich client, using a framework could be productive. For example a photo/video editor app. For a news site and CMS I would probably stick to the approach I've described above.
> by wrapping a vanilla lib to a component or an action, you’ve essentially created basic Svelte version of that lib
This is the key to making framework churn go away. The DX of using vanilla JavaScript is getting better every day. And is a much better experience than it was a decade ago.
> Islands architecture and partial hydration can help you render static HTML with just a small portion of JavaScript for those components who need it
I'm doing this with Hugo for rendering the static parts, and htmx for loading hydrated partials. The HATEOAS approach simplifies state management in the application. There is no client side "routing", just links and the back button.
In addition to vanilla libs, I include one "app.js" bundle. This file is created with esbuild and linted with deno. My "business logic" can be written in TypeScript in VSCode with the Deno extension and LSP server.
1. With go-app
2. Compared to using templ
For me personally, the latter seems nicer
- I can see at a glance the structure of the HTML
- Completion on the HTML tags, attributes, etc
- Completion on CSS (TailwindCSS LSP for VSCode)
- Logic can still be shared with other types of UIs (e.g. CLI, Native Apps, Webkit, gRPC)
If what you want is option 1, isn't this solution incomplete. That is, the fully realised vision would be a native component / widgets API (e.g. Fyne, QT, GTK), and then generate HTML from the components?
However, "since Dagger Cloud is built as a PWA, it can be installed as a desktop or a mobile application. This makes it possible to launch Dagger Cloud like a native application and get a full-screen experience without needing to open a browser first, or just have a dedicated icon in your desktop taskbar/dock", so it sounds like the "Native App" is using a Webkit (e.g. Wails, Tauri, Electron)
Anyway, congrats on having commercial users building stuff with your project!