substrate VS htmx

Haha, it's amusing that the history essays are one of the things you remember :)

Yes you can compile Scala and ScalaFX apps down to native binaries this way. Look at Gluon Substrate:

https://github.com/gluonhq/substrate

One of our customers is experimenting with shipping such apps with Conveyor. There's a discussion ongoing here:

https://github.com/hydraulic-software/conveyor/discussions/6...

We got a console hello world working, albeit the DX is a bit rough. You need some ugly config boilerplate and some additional Native Image json files. But, it works, at least enough to create a Mac package with the regular Conveyor feature set. There are some limits though. I think the WebView doesn't work when the app is natively compiled this way.

If it all starts working well it could be quite interesting for desktop app development, as suddenly you could use high level languages and portable UI toolkits but with the sort of startup time, performance and memory usage you'd expect from native apps (modulo binary size which is still quite large). If you want to use HTML as the UI then you can use the Chromium Embedding Framework, which would give you an Electron-like experience but with many more available languages:

https://hydraulic.dev/blog/13-deploying-apps-with-jcef.html

I've been using JVM GUI for years for various tasks. It was appropriate for Bitcoin tasks because it's immune to injection attacks, because you can run everything locally with P2P protocols like the original Bitcoin app did, it's portable etc. Also I learned GUI programming decades ago and find classical UI toolkit concepts like VBox, HBox, StackPane, TableView etc more intuitive than HTML.

I ran into quite a few issues during Android/iOS development (e.g. java.util.prefs and GraalVM pulling in unused methods), but Windows was comparatively smooth. Most of my issues were related to understanding the toolchain,e.g., not knowing how arguments are passed to run.

With JavaFX and Gluon Substrate + GraalVM you can even compile you app to an executable.

missing methods in Android library

Hello, I've recently stumbled across this project from Gluon and I've been wondering for some days how the project actually works. I've read the source code, but it appears that no code is responsible for implementing the hundreds of classes that make up JavaFX. Does this mean that JavaFX can work out of the box on IOS and Android but there didn't use to be a way to compile the code to a native executable for said platforms? Thanks in advance

Don't tested memory difference myself yet but maybe your solution could be to convert to native with graalvm and gluon substrate? https://github.com/gluonhq/substrate

Hi there! I want to show off a little feature I made using hanami, htmx and a little bit of redis + sidekiq.

Recently, I just rewrite one of my application Stashbin from Next.js to GO. Though my main motivation of this migration was to learn GO and experimenting with HTMX. I also aiming to reduce the resource usage of my application and simplify the deployment process. Initially, Stashbin codebase are split into two seperate repository, one for the frontend that uses Next.js and another for the backend that already uses GO. The backend repository is just a REST API responsible for storing and retreiving data from the database.

HTMX is another library that gained popularity due to its server-first approach to rendering data, although seeking a much simpler way of appealing to developers.

When I work with HTMX I need isolated component that can be reusable a form. So I create a PHP Function that generate the Input Datalist.

I was inspired by htmz (which was in turn inspired by htmx) and how the author got pretty close to a basic htmx-like experience just using an iframe. I wanted to push it a little further so whipped this demo together. My submission demonstrates progressive enhancement for the form - with js enabled the request targets an iframe that is inserted into the dom, meaning the page doesn't actually navigate (similar to event.preventDefault()). The iframe receives the html response from the request and on load triggers a function to swap out it's contents into the main page.

As described on htmx.org: "htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext"

Apart from the source code itself, the repo's README also gives a bit more details about the various packages I used.

1. htmx: https://htmx.org/

Also, there’s some response header juggling you have to do when submitting forms that have a validation step before redirecting: https://github.com/bigskysoftware/htmx/issues/369

I’ve tried to iron out any footguns or server requirements I’ve bumped into while using HTMX & Hotwire in my projects.

✨ In recent months, I have been developing web projects using GOTTHA stack: Go + Templ + Tailwind CSS + htmx + Alpine.js. As soon as I'm ready to talk about all the subtleties and pitfalls, I'll post it on my social networks.