iamcalledrob

KMP is brilliant and arguably the best way to write a cross platform app that has Android as a target.

But what you can do with it on non-JVM platforms is a bit lacking. There are few libraries and the stdlib is rather minimal.

If you're just making some http calls and instantiating models it's pretty good though!

Shame it's part of the Grade hellscape though ;)

I've built and shipped some native-UI cross-platform apps to millions of devices, powered by a Go shared library. It works. It's fantastic to use the same language on client and server, and the end-to-end testing story is really strong.

However, in my opinion, "Go Mobile" is a bit of a red herring if you just want a cross-platform shared library. I wouldn't recommend starting there.

It's optimised for writing and packaging an entire app in Go. Incremental builds don't work well (or at all), and cobbled-together "build system" is more to debug. It's also oriented around iOS and Android, which isn't great if you eventually want a native desktop app too. The generated bindings are okay, but the author's approach of using Protobuf (or some kind of wire format + simple API) means you don't really need them.

I found that it's more straightforward to just compile Go code into a library that can be called from C -- and thus can be called from anywhere. Call into it natively from Swift, and via JNI on Android and desktop JVM. With the right toolchain, you can cross-compile pretty easily too.

The biggest issue is that on Android you often want to talk to the OS, but the OS only speaks JVM. https://github.com/timob/jnigi "solves" this, although you will hate your life manually constructing JVM calls that you can't easily test.

The root cause of this stuff, from experience, is that animations are hard to retro-fit after the fact. It's a lack of planning.

The UI code needs to be structured with animation in mind, with hooks in the right places. And to do that, you need to know what is likely to be animated together.

But what ends up happening is you encapsulated a few of the moving pieces in abstractions (e.g. "toolbar", "sidebar"), but you want to animate stuff within. You end up copy+pasting animation logic inside each (now leaky) abstraction and duct taping it all together. UI abstractions are hard!

(Yes, on apple platforms there are transition blocks which will capture changes to the entire view hierarchy, but then the battle becomes preventing animations on stuff that shouldn't change!)

Another issue: Paper was tied to your Dropbox account.

From Dropbox's perspective, this sounds great. Accounts become more useful and valuable. The addressable market of a Dropbox account grows! Plus, everyone has a Dropbox account already, right?

Unfortunately, it turns out that business customers generally don't deploy Dropbox wall-to-wall. It's expensive. Not all employees need file sync.

A Dropbox account ends up being an obstacle to adoption.

And a distraction: a common account creates an irresistible urge to spend a lot of time finding ways to tie this new product into the old one.

I would also bet that 90% of Swift training data is UI code.

And UI code quality tends to be technically pretty crummy/low-discipline. Your UI code doesn't need much consideration around data races, for example.

The micro-interactions and hotkeys in GIMP are just so poor though.

For example, basic stuff like zoom in and zoom out are bound differently to literally any other app on any platform. This catches me out every single time I try to use it, and I'll never learn the GIMP way.

Spoiler for anyone unfamiliar: it's not Ctrl+/Ctrl-.

...although the logic in the article is slightly odd:

  1. Discover complex native text rendering is hard
  2. Render text in a low-level way, complain about having to (re)implement native interactions
  3. Try WebKit and it works great!
  4. Throw WebKit away??
  5. Have to re-implement native interactions??

Fun fact: This is how Apple used to do it too.

Old versions of macOS / AppKit used to use WebKit to render rich text inside their native NSTextFields. Turns out text is hard :)

And besides, the native WebView is super fast and lightweight, and its not unreasonable to use it as a text layout engine. You could use separate webviews for every row in a table and you'd still get fantastic performance.

iMessage for mac used to use a webview too. Adium as well. HTML is absolutely the right tool for the job if you're rendering rich/marked-up text.

It baffles me a bit that people are working so hard to replace themselves with AI. It's such a high bar for the AI to hit, and takes the creativity away from the human.

I have a pet theory that perhaps the optimal way to use AI will be more like an "exoskeleton" that turns you into a super-human programmer. Something that plugs the deficiencies of the human programmer, rather than replacing you entirely.

Nitpick, but it bothers me: The human factors of their demo video don't stack up.

Horizontal dragging with a mouse is actually really hard. Nobody's going to use it like that.

Your arm can easily move your hand and cursor up/down by pivoting your shoulder, but there's no mechanism for left/right movement. It's always an arc.

Or put another way: selection will be a lot slower and more tedious than the demo.

Using the "system WebView" is not a positive on Linux.

For some reason that always means WebKitGTK, which is crummy.

Someone, anyone, please get CEF working with GTK4.

It was really interesting, like a third way of doing things that wasn't "windows" and wasn't "mac".

The OS being on ROM made booting insanely fast. Like 2-3 seconds from cold start to the desktop.

Programs were actually folders, like modern macOS, so you could poke around at how they work. BASIC was still a thing, and I remember being able to edit the BASIC source code of some programs. Felt like "view source" did for the web.

Plus nothing has ever come close to the blue mouse cursor :)

I would argue that WhatsApp's e2ee user experience is pretty decent, and didn't get worse when they introduced encryption.

But then again, their technical model has always been "fat client, dumb server" from the start.

4K is perfect because you can scale it to 200% and still have a lot of screen real-estate.

Personally, I'm highly allergic to fractional scaling. It's 200% or I'm not buying it!

Very happy to see a 4K display. Framework take note!

In UK highway terminology, you're "driving" in the bike lane if your vehicle enters it.

I'll be watching this project.

Looking forward to a Golang declarative framework.

My advice to the author: invest in rich multi-window support early on. It's easy not to, but you always need it in the end, and it's painful to retrofit.

I feel like there's a great cross-platform UI story to be told with Go, since cross compiling is so easy.

I'd imagine it depends what kind of emissions you're measuring? Are we talking air quality or climate change?

Two stroke engines are pretty terrible in terms of unburned hydrocarbons and are disgusting for local air quality, which is why I'm glad they're being phased out in many areas.

I'd expect these tractors with I6 diesel engines to run pretty efficiently. I'd bet that the CO2 emissions from tractors are tiny in comparison from the emissions from trucks, fertiliser, and transporting the food.

Perhaps this is naive, but I would imagine that farm equipment is a rounding error in terms of global emissions. Compare the number of tractors to the number of trucks...

I would have expected policy to be pragmatic here, with (relatively) relaxed emissions requirements, since an affordable and reliable food supply is in the national interest? Sounds like that's not the case

Glad it works for you. It runs fine, but details become blurry as they get spread across pixels,

I do UI design, so I find it important to see things in full fidelity (no pixel smudging).

It just, just not enough real estate!

I really wish this had a 4K display option. As someone who dislikes fractional scaling.

I'm clinging on to my older Thinkpad X1 because the 4K display is so good.

I wonder if the US is the only place where this applies?

The UK, I believe, can compel you to provide passwords that you would be reasonably expected to know.

The docs are great too.

Of course absolutely ancient, but once you learn how to read them, they're very comprehensive.

And the 3rd party content written about win32 is pretty evergreen. I regularly find articles written in the '90s that are helpful today. The beauty of an incredibly stable API, and documentation written before everyone had the internet.

Just like the frontend dev ecosystem. Wait...

But there is an issue with Win32 API programming. And the truth is that custom windows mean doing everything yourself, controlling every Windows message, and that is fragile

This isn't actually true though. You can delegate to the default window proc, and only customise what you want.

Sure, if your window is now a triangle, you need to think about how resizing is going to work. But you don't need to re-implement everything from scratch -- only the defaults that aren't compatible with your new design.

Personally, I find that any Windows application that is remotely polished will have its own win32 WindowProc anyway, even if written in higher-level tech.

For example, if you want custom window controls, you need to use a WindowProc + WM_NCHITTEST to tell windows where the buttons are, so the OS can do things like display the window snapping controls when you hover over the "Maximize" button.

Sidenote: as a designer, its disappointing how many Windows apps are subtly broken in a bunch of these ways. Its not that hard. "Modern" UI frameworks generally don't do this work for you either, there's a real lack of attention to detail.

Don't have to grep my go errors :)

You could argue that what you built isn't novel or complex in any way -- (politely) it's basically a clone of hundreds of other SAAS homepages. i.e. its a perfect use-case for AI.

Perhaps the results would be different if you had a specific novel design or interaction in mind, and you wanted the AI to implement that exactly as you wanted.

edit: My point proven by the other examples from this thread. Same format, same "feature cards" etc. https://bridge.ritza.co/ https://poolometer.com/

Similarly, the native Android photo picker strips the original filename. This causes daily customer support issues, where people keep asking the app developer why they're renaming their files.

https://issuetracker.google.com/issues/268079113 Status: Won't Fix (Intended Behavior).

Different strokes for different folks.

The Go errors that I encounter in quality codebases tend to be very well decorated and contain the info I need. Much better than the wall of text I get from a stack trace 24 levels deep.