Hacker News Reader

Ultralight dev here-- I've been on the dev-tool side of this equation for the past 13 years so I have insight into why people are actually using HTML/JS/CSS over proprietary UI tech on the desktop.

It's several things-- tons of mature web development frameworks and ecosystems (React, Angular, et al), tons of developers with experience creating and maintaining them, and tons of debugging and support resources (Chrome Dev Tools, Stack Overflow, etc.).

Very difficult to compete against a content creation pipeline like that-- hence why I've made it my mission to get modern HTML UI running performantly everywhere without requiring web developers to learn some new language or toolset.

Also, FWIW, Ultralight does allow you to mix both HTML and native UI (the library can paint offscreen) so you can choose where/when to use each in your app.

If Ultralight is based on WebKit (the site says "Based on WebKit") how is it not LGPL? Isn't this basic software licensing?

WebKit is BSD but has sub-modules with LGPL code (specifically WebCore, JavaScriptCore, and WTF).

Ultralight is not WebKit (we have a totally different API and use our own renderer, compositor, and event-management code) but we do use a fork of WebCore and JavaScriptCore.

Our fork of WebCore is available under LGPL here: https://github.com/ultralight-ux/WebCore

Adam, we hung way back I was working on an on device search tool called Orbit that could’ve used Ultralight, I think at bespoke. Been keeping tabs on it since, congrats on the release.

The steps WebKit have made the last few years have been incredible and your further parallelization and optimization work would be so slick, can’t wait to try it out.

I’d love to use it with Tamagui and Vite running all bundling for RN. Silky smooth desktop app, web apps, sites, and mobile apps all easy to design together and deploy nicely to their respective platforms.

https://tamagui.dev

hey Nate! I still remember-- new website looks amazing!

For sure, feel free to hit me up on Discord if you want to chat.

>>> Ultralight can emit raw GPU geometry / low-level draw calls to paint directly on the GPU without an intermediate CPU bitmap. We recommend this integration method for best performance

This is sort of where I am, and a lot of people are doing similar explorations, in developing custom GUIs inside the browser that leverage WASM for high performance graphics. I'm using a hybrid bespoke GLSL translations and raw pixel manipulated bitmaps to Canvas2D, eventually targeting a custom webgpu renderer. Main issue is simply browser fragmentation. And, of course, ever larger data visualizations!

I was skeptical but curious that this tool might be a good candidate for some of my problems where a web app doesn’t quite work (commissioning robots at locales without Internet).

But once I got to the “this isn’t FOSS, here’s a pricing structure” I sighed and closed the tab.

I don’t dislike Electron the way some do. But I always prefer better tools if they’re available. Unfortunately this ain’t it.

Nah, we ended up with Electron because we have more front-end devs than C++/C#/ObjC devs and because doing layout in HTML + CSS is a million times easier than in native frameworks (AppKit and UIKit aside, those are nice).

It being cross-platform is probably secondary.

I agree with your first bit, but so far have been unable to find layout tools for HTML/CSS that compare to the ease of the VB6-era drag-n-drop component editor. I'd love to know of one, though.

Those tools didn't work well for things that need to adjust to different screen/window sizes or even for localization causing text elements to change size. For that kind of stuff you need some kind of dynamic layout like springs & struts, flexbox, etc. I think Qt and XCode have drag and drop UI designers for layout systems that work that way, instead of picking an exact position for things you pick their location and size relative to their contents and things around them. I find just using CSS to be easier to think about than those but they're nice for trying things out.

I find it's hard to rat-wrestle your way to a GUI that adapts nicely to different window sizes, resolutions, etc. Xcode probably comes the closest but I haven't tried it in years. I know there are purists who think "well, it's a VISUAL interface so you have to lay it out VISUALLY!" but this is actually trickier than you might think when you have to render the UI in a different context from when you created it.

I've found it easier just to do declarative layout. Tcl/Tk does this real well, and has since the early/mid 90s. I know that Tk uses imperative commands to build out the UI scene graph but it's effectively declarative. Tcl/Tk is pretty much VB done Unix style.

Except they always supported flexible layouts as well, no need for absolute positioning.

I was a mobile dev, mostly native iOS and some android/kotlin, for better than 10 years. I still maintain a dozen apps from my days as a full time consultant.

Before consulting I did web dev in early 2000s when the stack was LAMP and JavaScript felt like something that would never mature into anything. Hell, I was in my late teens so the feeling was likely mutual.

All this to say, good god, autolayout and storyboards and stack views. Last Friday I spent TWO HOURS troubleshooting why a UILabel wouldn’t word wrap inside two UIStackViews.

I’m so grateful for electron. It’s allowed me to become an indie dev and embrace/leverage react and the entire JS ecosystem to bootstrap a successful company.

My indie success would never have been possible if it wasn’t for these “inefficient” dev/deployment desktop stacks. And if they allow lowly old me to sell software to thousands of users around the world then they are doing something right. I hate to say it, but they really allow me to be 10x of what I’d be solo on mobile. Electron/React has that much potential when focused on solving a few painful tasks for my end users.

> JavaScript felt like something that would never mature into anything. Hell, I was in my late teens so the feeling was likely mutual.

Just want to say thanks for this gem ;)

> doing layout in HTML + CSS is a million times easier than in native frameworks

I agree with your comment, except here: Doing layout in GTK is much easier than using HTML. Especially using Blueprint[0] you don't even have to touch .ui files. And constructing the GUI using code is possible, too.

At least the few things I did in HTML were a lot more difficult than they would have been in GTK.

[0] https://gitlab.gnome.org/jwestman/blueprint-compiler/

Yeah, but no one wants to look at GTK apps.

> doing layout in HTML + CSS is a million times easier than in native frameworks

Nonsense. Doing layout in Qt is much, much nicer than HTML/CSS. If you could just push a button and get executables for all the major platforms, by default, like you can with Electron, it would be winning.

I agree with the first part, but not with the second. Doing layout in e.g. WPF or QML was way easier than anything we had in HTML until flexbox became a thing - which is to say, for many years. Simply because those frameworks were designed from the ground up around laying out widgets, while HTML was oriented more towards document-like flow for a very long time.

Sure, but we do have flexbox now. And CSS grid. And have done for over a decade.

The question was why HTML-based UI became popular. And that predates widespread support for all these things.

Flexbox was supported in chrome since Chrome 21 (2012). Electron initial release was in 2013.

To make an electron app, you only care about that your chrome runtime support.

Yeah, but flexbox came around 2012 and Electron came around 2013. Web UI weren't that popular until electron.

WPF is well, windows only. QML is C++ or python and didn't look native at all, but it also didn't look very pretty either. With HTML + CSS you can easily make an eye candy.

If you’d asked me a couple years ago my bet would’ve been on Microsoft’s fork of React Native for desktop. They’re clearly actively developing it and using it for their own purposes. But its relative obscurity isn’t a great sign.

Luckiest ideal scenario: something like React Native that really does compile to actual UI APIs for the compile target. Doesn’t have to be JavaScript, but it probably will be because inertia.

Every time I see “native” and “UI” RN is still the only real option which means native. I’d really love to see more options in this space.

RN is maturing and becoming the go to and only necessary option. Flutter is dying and a total mess but also an alternative.

Every word in this sentence is the opposite of my experience and understanding. RN feels like a half maintained backwater compared to react for web. Lots of out of date docs, awful debugging experience, inconsistencies between ios and android, fidgety and flakey all the time. And it has all felt like that for a while. So I would beg to differ with "maturing" and would definitely call bs on anyone characterizing it as "mature".

About Flutter, I've never personally used it but last I read its marketshare was continuing to grow fast as RN's plateaued. I love TS and the react ecosystem but RN itself is so crappy that I'm considering dart (did I just say that???). I think architecturally Flutter made the right call to just implement their own components on skia to get perfect consistency across platforms and totally control their own destiny. Sadly they also chose a weird shitty language.

Sort of related, is there a project out there that reimplements enough of dom/css in the canvas to where you could theoretically run a lot of react projects with the canvas as the target instead of the dom itself?

I don't think Flutter is dying at all. I see it's adoption growing day by day. Also Google Trends indicates that Flutter has almost twice the search share compared to RN: https://trends.google.com/trends/explore?geo=IN&q=%2Fg%2F11h...

Yeah, React Native for Desktop seems really like it's be great (and the apps that use it like messenger for desktop are great). Unfortunately there hasn't been a stable mac release for several versions, and there's no linux version.

> I feel like the reason we have ended up with Electron is that well-funded developments from large companies (like WPF, SwiftUI) always seek to lock-in developers to their single platform, well-funded from independent ones (like Qt) cost $$, and the rest just stays permanently underdeveloped from lacking dev resources.

The latter half of your comment asks some good questions, but I don't buy this initial assumption. As in: "The reason we have Electron is <truth>, <truth> and <unsubstantiated>" and then the rest of your comment is based on the 3rd part.

I don't think that's why we have Electron either way - the reasons for that are much broader & more complex but two large components of it are (a) the proliferation of web-technology due to the incredible success of the open web & (b) the overall development story of KHTML->WebKit->Blink prioritising their embedding API.

I work at a university/research lab. We always fall between the chairs with those licencing rules, although we are non-profit. Also if you add 9000 ppl you easily pass 100k. Same with Docker Desktop btw. I guess there are so many more cases also outside of large enterprises are hesitant to use software with complicated licenses.

Add to it that contrary to every other profession, ours is full with people that refuse to pay for the tools on their toolbox.

So they get the tools that are available on the flea market, one gets what they are willing to pay for.

If other professions had the option to pick up free toolboxes that aren't necessarily the best quality in the world, but are decent enough, then I'm sure many of them would be pretty damn happy about it.

They do, not everyone buys 5 star tools, but they buy.

That would be disrupted by ToolHub, a big warehouse that's open 24/7, where you can walk in and pick up a toolbox of 3-star tools for free.

Even paying for tools at existing 1€ shops is more than many currently do.

ToolHub would need at very least to pay electricity and materials for their replicator devices, and when the bill becomes too high, the shop would close doors.

My point is that it's not exactly a moral failing of a software developer compared to another professional, if the other professional doesn't even have the opportunity to make such a decision

When one decides to pay more for suppa-duppa-chai-latte refills at coffee of choice than tooling, it is.

This is not not paying for tools. A lot of people pay, say, for JetBrains IDEs.

This is more about a critical piece that you want to be always, universally available and known through and through. Choosing a non-FOSS option for a critical piece is now rare, and only works for things which were on the market for ages, and are guaranteed to not go away, such as MS Excel.

Electron wins because it allows a single language to do what java failed: write on e, run everywhere.

Electron doesn't actually do this. Most Electron apps you know have a native iOS and native Android counterpart for mobile. React Native and Flutter do allow you to do this, though. They are the true Electron heir. Flutter / RN even run on stuff like Car infotainment systems, tvOS, watchOS and so on. They've got Flutter running on embedded too.