cljfx VS stories

More broadly, non-Electron apps have been uncommon for a while. I just don't work in the webspace and I need to write code that's relatively performant. I understand it's all possible with Electron.. but it's a bit daunting to have a client-server web stack and multiple languages and some numbercrunching backend

JavaFX was a nice solution that's crossplatform and near-native. It has a very nice react-like library in Clojure called `cljfx`

https://github.com/cljfx/cljfx/

For desktop, there is cljfx which is a JavaFX wrapper, and has a similar API to reagent.

If you have an application server then you still have RPCs coming from your user interface, even if you run the whole DB in process. And indeed POSIX has nothing to say about this. Instead people tend to abuse HTTP as a pseudo-RPC mechanism because that's what the browser understands, it tends to be unblocked by firewalls etc.

I think there's a better way to structure things to get that same simplicity and in fact even more, but without many of the downsides. I'm planning to write about it more at some point on my company blog (https://hydraulic.software/blog.html) but here's a quick summary. See what you think.

---

In a traditional 3-tier CRUD web app you have the RDBMS, then stateless web servers, then JavaScript and HTML in the browser running a pseudo-stateless app. Because browsers don't understand load balancing you probably also have an LB in there so you can scale and upgrade the web server layer without user-visible downtime. The JS/HTML speaks an app specific ad-hoc RPC protocol that represents RPCs as document fetches, and your web server (mostly) translates back and forth between this protocol and whatever protocol your RDBMS speaks layering access control on top (because the RDBMS doesn't know who is logged in).

This approach is standard and lets people use web browsers which have some advantages, but creates numerous problems. It's complex, expensive, limiting for the end user, every app requires large amounts of boilerplate glue code, and it's extremely error prone. XSS, XSRF and SQL injection are all bugs that are created by this choice of architecture.

These problems can be fixed by using "two tier architecture". In two tier architecture you have your RDBMS cluster directly exposed to end users, and users log in directly to their RDBMS account using an app. The app ships the full database driver and uses it to obtain RPC services. Ordinary CRUD/ACL logic can be done with common SQL features like views, stored procedures and row level security [1][2][3]. Any server-side code that isn't neatly expressible with SQL is implemented as RDBMS server plugins.

At a stroke this architecture solves the following problems:

1. SQL injection bugs disappear by design because the RDBMS enforces security, not a highly privileged web app. By implication you can happily give power users like business analysts direct SQL query access to do obscure/one-off things that might otherwise turn into abandoned backlog items.

2. XSS, XSRF and all the other escaping bugs go away, because you're not writing a web app anymore - data is pulled straight from the database's binary protocol into your UI toolkit's data structures. Buffer lengths are signalled OOB across the entire stack.

3. You don't need a hardware/DNS load balancer anymore because good DB drivers (e.g. JDBC drivers) understand clustering and load balancing directly.

4. You don't need to design ad-hoc JSON/REST protocols that e.g. frequently suck at pagination or handling of large results, because you can just invoke server-side procedures directly. The DB takes care of argument serialization, streaming of results, type safety, access control and more.

5. With some databases like PostgreSQL you get server push/notifications for free.

6. The protocol gives you batching for free, so if you have some server logic written in e.g. JavaScript, Python, Kotlin, Java etc then it can easily use query results as input or output and you can control latency costs.

This architecture lacks popularity today because to make it viable you need a few things that weren't available until very recently (and a few useful things still aren't yet). At minimum:

1. You need a way to distribute and update GUI desktop apps that isn't incredibly painful, ideally one that works well with JVM apps because JDBC drivers tend to have lots of features. Enter my new company, stage left (yes! that's right! this whole comment is a giant ad for my product). Hydraulic Conveyor was launched in July and makes distributing and updating desktop apps as easy as with a web app [4].

2. You need databases with really flexible ACLs. Free DBs like PostgreSQL didn't support RLS until somewhat recently.

3. You need solid UI toolkits with modern themes. JetBrains has ported the new Android UI toolkit to the desktop [5] allowing lots of code sharing. It's reactive and thus has a Kotlin language dependency. JavaFX is a more traditional OOP toolkit with CSS support, good business widgets and is accessible from more languages for those who prefer that; it also now has a modern GitHub-inspired SASS based style pack that looks great [6] (grab the sampler app here [7]). For Lispers there's a reactive layer over the top [8].

4. There's some smaller tools that would be useful e.g. for letting you log into your DB with OAuth, for ensuring DB traffic can get through proxies.

Downsides?

1. Migrating between DB vendors is maybe harder. Though, the moment you have >1 web server you have the problem of doing a 'live' migration anyway, so the issues aren't fundamentally different, it'd just take longer.

2. Users have install your app. That's not hard and in a managed IT environment the apps can be pushed out centrally. Developers often get hung up on this point but the success of the installed app model on mobile, games consoles and Steam shows users don't actually care much as long as they plan to use the app regularly.

3. To do mobile/tablet you'd want to ship the DB driver as part of your app. There might be oddities involved, though in theory JDBC drivers could run on Android and be compiled to native for iOS using GraalVM.

4. Skills, hiring, etc. You'd want more senior devs to trailblaze this first before asking juniors to learn it.

[1] https://www.postgresql.org/docs/current/ddl-rowsecurity.html

[2] https://docs.microsoft.com/en-us/sql/relational-databases/se...

[3] https://docs.oracle.com/database/121/TDPSG/GUID-72D524FF-5A8...

[4] https://hydraulic.software/

[5] https://www.jetbrains.com/lp/compose-mpp/

[6] https://github.com/mkpaz/atlantafx

[7] https://downloads.hydraulic.dev/atlantafx/sampler/download.h...

[8] https://github.com/cljfx/cljfx

JavaFX is a mature and powerful toolkit easily accessed from many different languages. You don't have to use Java and can even layer on top entirely different paradigms, like cljfx does with a ReactJS/Compose style functional rerendering system. It's also accessible to Truffle languages. But the default Modena theme looks dated, and JavaFX lacks a small number of standard modern controls like an animated toggle switch.

cljfx is awesome

Maybe because: https://github.com/cljfx/cljfx

Super excited about this. I've been using cljfx (https://github.com/cljfx/cljfx) to build a few apps and it's so developer efficient.

In Clojure you can use JavaFX through cljfx

https://github.com/cljfx/cljfx/

I haven't used React, but I think it's very similar. You have a datastructure that represents the GUI and associated callbacks that modify the GUI. It doesn't use hiccup, but it's a similar structure. I've got to say it was fantastic. The least painful GUI programming I've ever done. The core architecture isn't opinionated so there is a little boilerplate to setup at first, but then it's very smooth sailing. I release an app using it and it was very performant, used some Java CV libs and drew diagrams to the canvas and it was all very snappy.

My only minor complaint was that the final bundle was like 150MB, which given the scope of the app seemed a bit gross - but it's manageable. In theory you could trim that further with GraalVM

I've made a few desktop apps in https://github.com/cljfx/cljfx (e.g., https://www.chronos-desk.com/), and cljfx (JavaFX + Clojure) is amazing and makes for rapid development, not to mention fun. I'm keeping an eye on https://github.com/HumbleUI/HumbleUI, which promises to be a step up.

Emacs/Cider - https://docs.cider.mx/cider/index.html

> and library ecosystem (building websites, parallelism, GUI, etc...)

Websites - Reagent, a ClojureScript wrapper for React https://github.com/reagent-project/reagent

GUIs - Clojure has the entirety of Java to steal GUIs from - Ex: https://github.com/cljfx/cljfx

Just because the Lisp family is old and has a simple syntax does not mean it's an antiquated language or that there are not new developments going on there.

A lot of my day job work is self directed because our managers expect a lot out of us but also leave us alone to do the work (amazing right?) but message received.

Let's take one not related to software at all! I turned a shed into an office over the course of many months: https://twitter.com/aarondfrancis/status/1333866090573811723. I wanted to give up and burn it down at some points, but I powered through and ended up with the perfect shedquarters!

I also did a podcast many years ago that was hard for me to produce, but I powered through until I felt like it had reached its natural conclusion: https://www.youtube.com/playlist?list=PLI72dgeNJtzr2Hd6Uscin....

I created a course teaching college students financial accounting that's made over 100k in the 5 or 6 years it's been live (http://acct229.com). That was a freakin grind that I thought about quitting a lot.

I also started doing tech YouTube videos recently and each one is a tiny exercise in finishing (and it feels great to ship!): https://www.youtube.com/@aarondfrancis/videos?view=0&sort=p&...

I wrote and released an open source package called Sidecar (https://github.com/hammerstonedev/sidecar) for managing Lambda functions from Laravel. That led to me speaking at Laracon Online (https://www.youtube.com/watch?v=0Rq-yHAwYjQ) and also to being asked to produce a course for Laracasts (https://youtu.be/0Rq-yHAwYjQ?t=11759). Speaking at the first Laracon led to speaking at the second Laracon Online (https://youtu.be/f4QShF42c6E?t=21744). Both of these led to me being profiled by GitHub's ReadME project at https://github.com/readme/stories/aaron-francis. (The shedquarters is featured here!)

That interview led to another piece called "Publishing your work increases your luck" at https://github.com/readme/guides/publishing-your-work. I gave a talk on that article at GitHub Universe. That article led to... this article. And here we are!

Each of these things have 1) felt awesome to release and 2) directly increased my luck, my bank account, or led to the next thing.

Hope those examples hit home a little harder!

> Tangentially, I'm curious if you could speak to what it's like creating content as a third party author? Are you given prompts regarding the tone or content of your work?

Happy to share! The first piece I wrote for GitHub's ReadME Project was called "Publishing your work increases your luck" (https://github.com/readme/guides/publishing-your-work) and I was able to write it as a result of an interview I did with them previously.

Before I wrote that first piece, I reached out to the ReadME Project and told them that I had wanted to tell the story of my past year of overcoming fear and embracing putting myself out there. They agreed that that fit in their "developer stories" section and did an interview of me, which they published here: https://github.com/readme/stories/aaron-francis.

After that they reached out and said "sometimes we have our developer stories have a corresponding guide, do you want to write one" and so that's where the Publishing guide came from. I wrote it all for them and then they have a full on team of editors, proofreaders, illustrators, etc to help push it over the finish line. Before I wrote it I gave them an idea / outline of what I was gonna say, to get the green light. Their editing has been very light, more flow than content. Like... move this sentence up; you repeated yourself there. That kinda thing.

The only time I had a piece really torn apart was this one https://handsontable.com/blog/modularizing-to-improve-the-de... and it was because my voice just didn't fit their blog at all. What you see on the site there is about 35% of what I originally wrote before it was completely toned down. It happens though! It's their blog, so it's gotta fit their voice. (Coincidentally that was the last piece I wrote for them. Ha!)

You made me look him up. He's the lead developer of clojurescript! And did a lot of other interesting things too.