Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

I think it’s cool that people are playing around with this sort of thing.

The truth is, though, I don’t understand why this architecture is attractive in this case. This is essentially a thin front-end UI on top of a fast cross-platform backend. That’s a great structure - but why not make the UI native for each platform?

Calling into a Rust backend from Swift, or from whatever UI framework you use on Linux or Windows, is going to be just as easy as with Neon. At the moment, you are including vast amounts of code and using a large amount of memory to display a very small amount of text on-screen. It seems very inefficient for such an otherwise elegant application!

View on HN

Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X.

I don't think Electron a good match for this project, which while fast during use, probably has horrendous startup times and memory usage. But I can certainly understand the sentiment pushing developers into Electron and driving them to avoid multiple native applications like the plague. I have developed and deployed custom Eclipse environments that supported Windows and Linux, with a mix of Java and C/C++. It costed me years out of my life.

It costs more to build native UIs, that’s true.

But a project like this specifically seems to have most of the secret sauce implemented in a cross-platform library. That seems to be to be a great application structure and candidate for native UI implementation. It increases the development effort from n+m to 3n+m, where n is hopefully much smaller than m.

> Because writing, testing and deploying on each of those platforms will increase your effort from X to N*X.

No, it won't. Building any non-trivial UI in HTML takes orders of magnitude more effort and time than building it in a UI toolkit that was actually designed to build user interfaces in.

That is absolutely false in my experience.

I can put together a full HTML/CSS/JS UI for a screen in hours where it will take me days to do it on Android or iOS alone, ignoring the fact that I'd have to make sure it's responsive on all those platforms anyway (because tablets), then still build it for windows, linux, mac, and sometimes a web version anyway.

A competant iOS or OS X developer can use Interface Builder to create great native UI’s in minutes.

If you are including the wiring of the UI into the application in that time I'm impressed, however you still will need to do another 3 major platforms.

And you'll need to have a designer look them over or design them in the first place for each platform, and write documentation for each platform, and test each platform, etc...

In many cases I won't argue that a native app won't be better for the user in many ways, but you can't argue that it's faster to re-create, document, and test your UI 5 different times.

I’ve found it faster.

Faster to build 3-4 native UIs instead of one HTML based one?

Sure, because the browser will go out of its way to render something sensible out of any tag soup thrown at it, as opposed to throwing an exception like native frameworks do.

> I can put together a full HTML/CSS/JS UI for a screen in hours

Hours for a single screen ? Exactly what I'm talking about. The fact you think that's quick is worrying.

You are the second person to say this, what are you doing that's faster?

I'm talking from start-to-finish creating the UI, wiring into business-logic, handling UI state, making it fully responsive, etc...

I've used WPF, QT, some old java swing stuff, and the Android studio layout editor, and none of them are a fraction as fast and capable as a well setup react web application (which to be fair, took a good chunk of time to setup).

> but why not make the UI native for each platform?

As a developer I prefer web tech for UIs, because it's actually a nice toolkit to work with, and has great tooling.

I can easily debug and live edit the UI with DevTools. OTOH in Xcode's constraint-based layout I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses). On Windows I don't even know which of the many UI frameworks is the least deprecated this year.

I can understand that, and certainly the web platform is much nicer than it used to be – especially when building for a constrained, known environment like Electron.

Don't discount the native platforms though, which are still very powerful. Constraint-based layout can be frustrating at first, but I've found it's not noticeably more awkward than CSS after a little experience.

Similarly, it's no worse figuring out how to build a native Windows GUI than it is figuring out what CSS or JS framework to use. Just a bit of research :)

> I struggle to even move buttons around (if I fail to update all constraints right, the whole layout collapses)

I would say that accurately describes my experience with CSS. Any selector has the potential to mess up the entire page.

With NSLayoutConstraints, not only does it match my mental model of how layout ought to work, but I know that in a properly-factored layout, constraints can only mess up their local section.

Globals make debugging tough in any context, and I wouldn't blame the language simply for allowing their use.

> Any selector has the potential to mess up the entire page.

That's true, but the modern web stack has several solutions to this. If you don't mind "CSS-in-JS", I've been using the excellent styled-components [1] library for my company's React app. I believe Vuejs supports scoped styles out of the box [2]. And if you'd prefer to just write plain CSS, CSS modules [3] will mangle the classnames in your CSS files so you don't have to worry about collision.

[1] https://www.styled-components.com/

[2] https://vue-loader.vuejs.org/en/features/scoped-css.html

[3] https://github.com/css-modules/css-modules

Yep, and I consider this one of the main advantages of tools like SASS, even.

So your hypothetical native layout is properly factored, but the CSS one isn’t in this comparison?

No. Even in perfectly factored CSS, one bad selector still can mess up the whole page, no? That's why all those nifty tools (mentioned in a sibling comment) exist.

The cost of UI development is substantial; as you say "whatever" framework it means that you would need to learn 1) what frameworks are available 2) what paradigms they use 3) what programming languages and tools you need to know to drive them.

As the development is mostly web driven nowadays, HTML/CSS/JavaScript is something that the most developers tend to already know and thus have crossed the first barriers of entry to this kind of development.

I have no doubt that native UI development for multiple platforms is tricker than a single cross-platform browser-based implementation. But I do think the level of those barriers to entry can be overstated. Building a simple MacOS GUI is not complex; likewise for Windows and say QT for Linux. It requires a little bit of thought and a little bit of research, and more time than a single implementation. The output is also better by quite a few metrics, and my general feeling is that an application where most of the complexity is hidden away in a cross platform library with a very simple API is the best possible case for this approach.

> I have no doubt that native UI development for multiple platforms is tricker than a single cross-platform browser-based implementation.

I would argue the exact opposite is true for anything more complicated than 'hello world'

I can agree with that from the perspective of a single front-end. If I were building multiple front-ends for different platforms, I’m less sure.

I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps. It turned out that native UI toolkits really are very well suited to building native UIs with minimal effort!

> I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though. I spent my whole career working on the web, intimidated by the complexity of native apps.

As a native developer I have the exact opposite view. Web development is insanely complicated compared to native. It's a complete jungle of flavour-of-the-day frameworks all designed to make web-development somewhat workable (and all of them failing in some ways.

If you're building a website, you have little choice, but if you're actually building a desktop app it's totally insane to use web based UI.

Maybe you have distorted view as well.

> I do think that developers who have previously only worked with web tech have a distorted idea about native platforms though.

There’s an irony that people who will drop whatever they’re doing to learn this week’s hot crazy brain-bending quasi-DSL JavaScript framework think that learning Swift is too hard and don’t want to have to learn something new.

Frankly you have no clue about web development if you think they are learning every "this week’s hot crazy brain-bending quasi-DSL JavaScript framework"

> HTML/CSS/JavaScript is something that the most developers tend to already know

If you know both HTML and a proper UI toolkit, you'll see how insane it is to use HTML for anything else than marking up text. It's like launching a space shuttle to go to the supermarket around the corner instead of just walking. The only thing HTML has got going for it is how easy it is to show 'Hello World' on screen. Anything more complicated than that and it becomes a total horror show, especially compared to how easy to use and simple regular UI toolkits are.

Which regular, simple UI toolkits do you recommend to a web developer who wants to learn desktop development? Do you also have a recommendation on which resources/approaches to use to learn those toolkits?

Obviously this depends on what you want to do. Most importantly: Which platforms do you want to target?

Use whatever is the native toolkit for the OS you're targeting.

Juce (GPL unless you pay for a license) FLTK Nanogui (simplistic GUI for openGL)

It's a valid point, simply because browser UI kits are outdated, memory hogs, and have a ton of legacy cruft.

I've recently been using Windows Forms with C# again and am amazed at the ease of use, if only they had made styling easy this framework would have been a gold standard for years to come. It's even cross platform too thanks to Mono.

Windows forms is based on decides old WinApi. There's some support for styling there, e.g. owner drawn items, custom painted controls, but using it correctly is tricky as hell.

WPF is based on Direct3D 9, and is easily stylable. I consider it is the gold standard. But it is Windows only. There are cross platform alternatives, xamarin, avalonia, but I don't have hands on experience with them.

> would have been the gold standard for years to come

I've written a lot of webforms and do really like it for "quick and dirty" UI's, but it has a lot of limitations that make it a bad choice for non-trivial apps.

Off the top of my head: -styling -resizing (text reflow and re-layout of items is very hard to get right/working) -screen scaling (non-integer, say 150%)

I also found it requires a ton of boilerplate code to programmatically change the UI.

That said, my favourite part is the first class support for events. Knowing this paradigm made my shift to Qt (which has something similar called signals) much easier.

Some might find this interesting for native cross-platform apps http://www.lazarus-ide.org/

That’s the approach Xi is taking, incidentally.

What's Xi? Not the most websearch-able name, care to drop a url?

https://github.com/google/xi-editor

That’s a really interesting approach to take for an editor - I love the idea!

Maybe you have missed the part about the laughably hostile native APIs. No hotkey support, no easy windowing (or lack of thereof).

I didn't, but I'm wondering if you maybe misunderstood it – that was specifically about implementing the app in what the author describes as a 'game-like' manner, using an SDL library from Rust.

In contrast, platform-native UI frameworks are absolutely optimised for things like this. There's definitely no difficulty in using hotkeys or windowing functions in Appkit, for example.

Reply on news.ycombinator.com