Native all the way, until you need text
48 points by diktomat
48 points by diktomat
I agree that web views are the way to go for complex text layouts*. But I don’t understand going full Electron, other than convenience. Electron is basically a wrapper around a WebView, it just happens to drag an entire Chromium engine along with it. That's a huge size cost to pay for convenience!
* In 2001-2 I implemented iChat's iconic text-balloon layout with NSTextView and a lot of trickery. It was a pain in the ass, even with help from AppKit's text architect (Hideki Itamura IIRC.) Nowadays of course it’s pretty trivial with HTML+CSS.
Mostly just simplicity when it comes to supporting many systems. I’m involved with an app that was using Tauri and switched to Chromium via Electron as it worked a lot better (also worth noting we are targeting a very wide range of systems from win7 to win11) Tauri and friends sound great: use the systems web view except that means you get chrome or edge on windows, safari on mac and a dice roll on anything else. Predictability and maturity won over in the end. And it performs better for unknown reasons.
Is browser-engine compatibility that big an issue? Regular web-apps deal with it all the time, and it seems like the components one builds apps out of work well in all browsers.
Regular web apps also get tripped up by it fairly regularly. There was an article here fairly recently about how Firefox and Safari both have all sorts of hardcoded fixes for popular websites that don't correctly render because they rely on Chrome-only quirks. Part of the problem is that it's not usually obvious in advance what's going to trigger a compatibility issue, so you need to do a lot of testing to catch issues.
As I understand it, native web views are also more varied and older than the web browsers most people use, especially on Linux, so there tend to be more quirks to deal with.
It's not like it's an insurmountable challenge — in my experience, the issues are usually fairly simple to work around once you've found them, it's just about making sure you've got a strong enough testing regime to catch them all. But I can also see teams deciding that the simpler option is to just go for Electron.
Can Tauri be forced into, say, using Blink when on Mac (and other non-default combos)? If not, I can imagine that people who don't have easy access to all the platforms may have some trouble testing, which could be a blocker even in situations where no tweaks would be needed.
native web views are also more varied and older than the web browsers most people use
Huh. The one I’m familiar with (Apple's) is literally the same code as Safari; or rather, WebView and Safari are both wrappers around the WebKit system framework. I assumed that would be true of web views on other platforms too.
I think this is a personal choice. I am ready to pay the price for convenience, whether that means app size or RAM consumption. And it seems that millions of users of apps like Visual Studio Code agree. In the end, I would rather have better software than satisfying htop charts. But it is me.
The main point of the blog post is not that "everyone should choose Electron!". It is exactly what I stated at the end: I now understand why plenty of companies with resources & money still choose Electron or web technologies. They compromise on the right things as to me, but deliver a good user experience. People like to defend Apple’s TextKit 2 or other native text frameworks, but there are almost no popular, high-performance text editors built purely on Apple’s SDKs. Xcode is doing reasonably well, though, perhaps it is the only real example. Zed, Sublime Text, Visual Studio Code, JetBrains IDEs: they all use custom text-rendering solutions for a reason.
Do you happen to know what MacVim uses? I am very unfamiliar with Apple dev libraries. As a MacVim user the text always seems well rendered, both visually and in terms of performance.
One of the problems with the world is that the people who write software do so from the top 0.1% best computers and phones in the world, so they can do everything in the worst possible way and still think it's great.
Meanwhile the rest of humanity using much worse devices are left with bloated laggy crap forever.
How's the scene on GTK/QT/etc? Haven't done GUI in a long time
As I understand it, this could also be implemented in Qt without requiring a webview. The author never got around to exploring it here though.
To be honest, I still have nightmares from Qt in the Symbian S60 days, when we tried to port plenty of software to it. But I did not consider Qt for another reason: I was trying to solve what I understand to be a common problem with native tools & native knowledge, and failed. That brought me to the world of Electron purely out of curiosity, because I knew there were good tools that handle these situations just fine. I was not looking for a replacement for Swift or SwiftUI.
In the end, I am continuing with my pet project using an embedded WebView (WebKit-based) for Markdown rendering & streaming, and it works reasonably well. Much better than the other native options I tried. Perhaps I have been dealing with native technologies for too long, and it caught me by surprise that embedding a web engine into a native app (yes, in a limited & optimised form, but still) could actually improve the overall performance.
How does Electron compare with Flutter? To an outside observer, it looks to me like Flutter is the answer to "what if we took Chromium, stripped it down to just the renderer (Skia) and used that for GUI apps." It seems like it should be lighter than Electron but still cross-platform with similar capabilities.
Posts like this just make me wish we had kept Postscript around…
By the way, it's not important for the chat applications the OP is talking about, but can browsers do Knuth-Plass line breaking these days? I mean, the textual quality of browsers wasn't reallly that stellar. They're good at colorful text, but tend(ed) to be more the PageMaker of the party, then the TeX or FrameMaker…
can browsers do Knuth-Plass line breaking these days?
From what I reckon the current state of affairs is that Safari has a more fancy line breaking algorithm with text-wrap: pretty; while Chrome and Firefox still suck. Firefox does not support text-wrap: pretty; at all, while Chrome has a more rudimentary algorithm that prevents orphans somewhat but isn't a global pass over the whole paragraph.
From the author of https://github.com/stevengharris/MarkupEditor, he suggests that this is one of the best available solutions: https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-promised-land/
But MarkupEditor uses a WebView! Not TextKit2. From its README:
Behind the scenes, the MarkupEditor interacts with an HTML document (created in markup.html) that uses a single contentEditable DIV element to modify the DOM of the document you are editing. It uses a subclass of WKWebView
The ironic thing is that Apple's native text engines use a much better data model — a string plus run-length-encoded style attributes — than HTML's DOM tree. Editing text in a DOM is a nightmare because the selection often spans multiple elements at multiple levels of hierarchy and you have to split/merge them in very complex ways. (I remember when I first got my hands on a Safari build with contenteditable support I quickly filed a buttload of bug reports. Even today many web rich-text editors screw up when cutting/pasting list items.)
I think what’s happened is sort of parallel to CISC vs RISC in the 90s/00s — the ‘inferior’ architecture produced superior implementations because it had more resources applied to it.
I think you misunderstood me. The author of MarkupEditor is an old friend of mine (and one of the old time Smalltalkers with Dave Thomas, and an ex-boss of mine, FWIW). He told me that the polish blogger that I linked to is the go-to guy for TextKit2 stuff, and sells some sort of product or solution around TextKit2 that compensates for a lot of the issues with it.
I've not worked with this stuff at all, so whatever I know is from a distance.
Marcin (the Polish blogger) is indeed a good engineer. Though even he agrees that TextKit 2 is not ready for prime time in any form. After playing with STTextView for a while, he is now working on a completely custom solution for text rendering as I understand. I also tested STTextView for the app from the blog post, and the results were mediocre.
As Marcin said on HN:
There’s a lot of complexity that adds up to the overall performance issues. And TextKit 2 is pretty bad at things. Especially the public API, which in my case results in needing to work around things I should not have to.
And in general, is it not strange that for something as common as Markdown rendering, my only option is to maintain a low-level custom solution on top of TextKit 2 which still does not even support basic native macOS behaviours like context menus, etc.? I think it is strange & non-practical.