6 ms·
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
by matthewmacleod 9y ago
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!
- miohtama 9y agoThe 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.
- matthewmacleod 9y agoI 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.
- Aaargh20318 9y ago> 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'
- matthewmacleod 9y agoI 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!
- Aaargh20318 9y ago> 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.
- _Tev 9y agoMaybe you have distorted view as well.
- postfacto 9y ago> 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.
- _Tev 9y agoFrankly 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"
- Aaargh20318 9y ago> 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.
- ctw 9y agoWhich 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?
- wander_homer 9y agoObviously this depends on what you want to do. Most importantly: Which platforms do you want to target?
- Aaargh20318 9y agoUse whatever is the native toolkit for the OS you're targeting.
- CyberDildonics 9y agoJuce (GPL unless you pay for a license) FLTK Nanogui (simplistic GUI for openGL)
- cornholio 9y agoBecause 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.
- matthewmacleod 9y agoIt 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.
- Aaargh20318 9y ago> 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.
- Klathmon 9y agoThat 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.
- postfacto 9y agoA competant iOS or OS X developer can use Interface Builder to create great native UI’s in minutes.
- steveklabnik 9y agoThat’s the approach Xi is taking, incidentally.
- dualogy 9y agoWhat's Xi? Not the most websearch-able name, care to drop a url?
- kiejo 9y agohttps://github.com/google/xi-editor https://github.com/google/xi-editor
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- matthewmacleod 9y agoThat’s a really interesting approach to take for an editor - I love the idea!
- deleted 9y ago[deleted]
- hacker_9 9y agoIt'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.
- Const-me 9y agoWindows 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.
- seabrookmx 9y ago> 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.
- pas 9y agoMaybe you have missed the part about the laughably hostile native APIs. No hotkey support, no easy windowing (or lack of thereof).
- matthewmacleod 9y agoI 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.
- pornel 9y ago> 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.
- matthewmacleod 9y agoI 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 :)
- ken 9y ago> 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.
- jakelazaroff 9y ago> 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/ https://www.styled-components.com/ [2] https://vue-loader.vuejs.org/en/features/scoped-css.html https://vue-loader.vuejs.org/en/features/scoped-css.html [3] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
- amarsahinovic 9y agoSome might find this interesting for native cross-platform apps http://www.lazarus-ide.org/ http://www.lazarus-ide.org/