4/13/2020 Mac Ui For Electron App -photon
Open your favorite editor or shell from the app, or jump back to GitHub Desktop from your shell. GitHub Desktop is your springboard for work. Community supported GitHub Desktop is open source now! Check out our roadmap, contribute, and help us make collaboration even easier.
![]() ![]()
I really like where the author went with this. Everytime I read something like this though I can't help but think how we as developers really need a better low level, UI framework for cross platform applications. What the author has done here is a cool idea, but ultimately this still feels flawed, and like it's a workaround to the difficulties of writing a cross platform UI. Everytime I read something like this I can't help but think about how great a low level, cross platform C (or C ABI) library would be (think something like libuv but for UIs).
Such a library would abstract away the OS specific system calls of the UI while still providing the ability to easily do things like:. Create a window. Draw to the screen. Declaratively (i.e. Html like) add UI widgets to a scene. Apply CSS like styling (like QML, JavaFX, or XAML).
Use native file dialogs, menus, notifications, etc. Statically link as a single dependencyI don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. It needs to provide common UI elements like buttons, textboxes, divs, grid layouts, etc, but judging by the popularity of electron - I don't think those necessarily need to use native elements.Qt is close to this, but it feels heavyweight and in my opinion its biggest flaw is that it's difficult to link to an application and setup a development environment for. Tk is kind of like this, but way too limited. JavaFX is a really good example, and would be perfect if it wasn't Java only (same with WPF but it's C# only). Right now the closest attempt to something like this that I know of isI think libui could even be a starting point for such a library, but the library I'm thinking of would need some type of declarative UI support (i.e.
Html like, maybe even support for a subset of html), built in support for styling, and less of a focus on using native widgets. I really wish somebody would build something like this. Am I the only one with the opposite opinion?I don't think cross-platform UI toolkits should exist, period. Your cross platform code should live underneath the UI layer, and you should write a custom UI for each platform you're bringing your logic to.Mac apps should look and feel like mac apps, windows apps should look and feel like windows apps, etc.Trying to abstract away all these platform differences either nets you a lowest common denominator that doesn't feel at home on any platform, or is so complicated to develop for that you end up doing more work in the end (and still isn't as good as writing native UI's for each platform.). One thing I can do in almost every Windows application is press Alt, or Alt+F, and use the arrow keys to navigate the menus. This has been broken forever in Electron's menu.
It's my biggest complaint, even above RAM usage now that I have enough RAM. I guess the Electron devs can take that as a compliment if they want to, but it still gives me a 'damn you Electron' moment every few days.I think it's the sum of those little inconsistencies that bug people about cross-platform apps. On the other hand, people now spend so much time in the browser that a browser-based desktop application can probably feel more natural than a native UI if done right. I think it's great that so many apps are available for mac or linux that wouldn't otherwise be available. Electron provides a baseline that simply is much more difficult with platform specific code, or other cross platform applications.
It's not all in the box, and far from perfect. But the fact is, I get to use VS Code, Teams, Spotify (I know not electron specifically, but similar enough) and a handful of other apps everywhere I run.For the most part I stick to cross platform apps, if that means a 'lesser' electron based app, so be it. And most of them look far better than other cross platform and even native options a lot of the time. It sounds like your main concern is preserving the native look and feel of the OS.I understand the argument, but I don't really understand the reasoning behind it.
This is probably me being naive, but (assuming any performance problems are solved) the only reasoning I see to prefer native OS widgets would be to preserve compatibility with adaptive technologies (i.e. Screen readers, OS keyboard shortcuts, high scale displays, etc), and to allow for automation of the UI.Maintaining compatibility with adaptive technologies and allowing for automation both seem like good arguments to me. I think it would be challenging to solve those problems, but I think it could be done. Html already has mechanisms to deal with this, so I think another tool kit could take a similar approach.Preserving the native look and feel however, doesn't seem nearly as important to me. I usually customize the look and feel of most desktop applications anyway.
For example, changing the color scheme of my terminal, text editor, and IDE. I would hate it if I was forced to use the OS defaults. For example, on osx it's not possible to customize the look and feel of the iterm window, where as with hyper (an electron based terminal emulator) it is possible, and I find that I strongly prefer the later's UI (despite the electron performance issues). Even chrome allows me the ability to customize its UI. Of all the desktop applications I regularly use, there's very few these days that exclusively use the native OS widgets - at the moment evernote is the only one that actually comes to mind.With some exceptions, users seem to manage pretty well on the web where every website already implements a different style of UI.
For simple widgets like windows, buttons, textboxes, checkboxes, etc minor differences in style just don't seem like an issue to me. I think users will be able to visually identify a button even if it looks slightly different, and the advantage of allowing customization feels like a worthwhile tradeoff. For more complex UIs (like 3d renders, music editors, video editors, or games) most seem to already implement customized UI elements anyway.What you're suggesting actually feels like a step backwards to me, so I'm genuinely interested to understand why you would want to maintain the same look and feel between applications?
How do you currently customize the look and feel of your own environment? Well, I don't see the value in having multiple UI platforms in the first place. So I would rather have one very good UI toolkit for all platforms than having a lot of pros and cons for all the native toolkits.I think the most common place to find people with your opinion is in mobile app development.
And I in my opinion there are two major reasons here at work:1. Apple is very good at building UIs2. Mobile devices are comparable weak in processing power, while their use-cases mostly always require an instant & animated result.So on the one hand iOS users expect the same quality when you build a custom UI and that is hard to match when you start with a UI project. The second reason might be the cause why web-based UI are kinda hard to build for mobile apps.
I mean I heard a lot more mobile developers complain about web-app performance than desktop app developers. But maybe that is just because of the different rendering engines. you should write a custom UI for each platform you're bringing your logic toThe question isn't of 'bringing' your logic to a platform, though. The question is how people who you don't care enough to provide first-party support for, will run your application.Consider a situation where someone codes native apps for Windows and macOS, but also provides an electron app as source. Who is that app for?
Everyone who is using any other platform.Also consider the 'native-ized' apps that exist to wrap web-apps that never created a native app at all. For example, there are numerous Electron wrappers for the Facebook Messenger web-app created by third parties who just wanted to be able to use Facebook Messenger on their PCs as an 'app' rather than a webpage. This doesn't work, though, and we can use Qt and wxwidgets as the reasons why.Qt has tried a lot of different ways to render GUIs. Traditional qwidget applications use, depending on the widget object, either native platform specific controls that you try to uniformly mutate despite the stylistic differences, psuedo-themes Qt writes for non-standard elements or things that aren't universal and thus you need a facade for where they try to impersonate the native toolkit (this is why so many Qt programs on Windows 'feel wrong'), and user-styled controls that don't even attempt to be native but you can mix those freely with the base widgets that emulate the native look and feel. This is how VLC can have its volume slider look the same everywhere.Then in Qt4 and much more comprehensively in Qt5 they moved to QML, which completely drops the idea of trying to use native window systems and renders the entire UI with 3d acceleration.
They also, at first, made no attempt to even provide common toolkit elements - you got basic drawing primitives and the ability to query get a color pallette that you are told by Qt should be the 'native' colors.Turns out not a lot of people took off with that offering so Qt developed QtQuickControls1 - which was a giant mess of depending on qwidgets to map native widget styling into the OpenGL scenegraph they had. It actually did somewhat work, but only insofar as you got buttons that looked native - go try resizing these Controls 1 windows and you discover a lot of incongruency, especially on less practiced platforms like Android, especially where faux-native widgets and GL components mixed.QtQuickControls2 I feel is an accurate representation of what all GUI development has to be - if you want native look and feel you do need to do some manual management to get it, making your own themes and having logic to change the design to accomodate the target platform. But it also is meant to make good looking software by using the style guides of platforms rather than the lower level actual widgets - the original release has Material and Universal from Google and Microsoft respectively. They don't try to look native, but they try to preserve the stylistic guidelines of the host platforms. They later added a few other options - a 'desktop-like' theme, one that you can easily restyle with generic images, and a default that is super plain.Wxwidgets presents the other extreme. It tried super hard to never implement a widget itself - it was always meant to be a facade over native toolkits. In other to accomplish that they had to sacrifice ergonomics and introduce means to distinguish the platform native widgets that don't map cleanly across platforms.
You never get a perfectly universal cross platform UI this way, but you also don't benefit from native toolkit workflows because you are trying to abstract something that isn't a 1 to 1 mapping.There is one more aspect to all this - native toolkits generally blow chunks. And that precludes how Windows has at least three actively maintained 'first class' GUI toolkits now. All first party toolkits today are derived either from bitmap or raster graphics, mangled over years or decades to support new paradigms that they weren't meant to, and to this day have errant behavior abound and little to no consistency due to their backwards commitments.That would not have been a problem if we were all still operating on computers without GPUs with displays from 1995, but the evolution of hardware keeps pushing on our desktops to take advantage of the resources available - in particular, GPU acceleration. 2d acceleration is completely dead. If the world made sense and legacy could be eschewed for reason every desktop would be from the ground up built on 3d acceleration. I haven't checked in a while but I believe it wasn't until Windows 8 that Microsoft dropped the non-accelerated bitmap Windows desktop for 2d acceleration. KDE on Linux went through a huge churning to migrate their desktop to 3d acceleration and that still only applies to their newer tech - anything QML based - while the bulk of KDE applications are stuck being unaccelerated qwidgets programs.
Gnome is in the same boat, and never made the leap to a 3d UI paradigm across the board that they should have made when GTK3 broke everything.Because mixing these two worlds is just an exercise in suffering, but every UI design on every platform either has to wage the war or just succumb to using the broken old bitmap style with hacks to try to make DPI scaling work.Not all the blame should fall on UI designers though - this is a structural problem. Before Vulkan we had no seriously universal and working acceleration API. You could not rely on OpenGL a decade ago much less now - just look at Godot, whom released their 3.0 with OpenGL ES 3 and is now forced to adopt an ES2 renderer since so many ES3 implementations on both desktops and mobile are broken. There was simply no universal API to ground the foundations of a 'next gen' 3d toolkit in, which is why Qt supports a myriad of backends to QML including an unaccelerated one they were forced to implement because so many edge cases broke the renderer.Call it the 14 + 1 standards problem, but whoever writes a declarative toolkit built on Vulkan that can be like QML except without all the attached baggage (theres a reason the Rust QML crate has been dead for over a year) would be my choice any day. Its just a hard engineering problem, not just because Vulkan is hard, but because providing simplicity to start without constraining possibility and expandability is an even harder design problem.Maybe the answer will come from game engines?
The overlap gets more and more blatant every day - I've been having a lot of fun in Godot and I ask myself why not just do general GUI development in here. Its accelerated, cross platform, and the scripting is a joy.
It just lacks API coverage for comprehensive support of what apps expect since its only meant to make games. There is a point that is always missed about Electron - UI.By using HTML, CSS & JS you have an extremely rich toolkit to create UI with constant improvements from browser vendors and standards bodies.If a designer can create a pattern library in sketch then chances are it can be implemented using web technologies.This is a much bigger and more active open platform when contrasted to the capabilities of a particular framework and community.Theres another topic around whether you should detour from the OS UI look and feel. But most designers and product owners worth their salt are conscious of keeping known UX patterns and least surprise. I think about this lately and write about this on:-Is well know the problem of try to do a cross-platform GUIs.
But in the other end, the necessity to do that have increased with the arrival of mobile and the emergence of OSX as a viable target for commercial apps.Is kind of ironic that is easier to port a full 3d-game but a “simple” business app is a huge undertaking:)The key, IMHO, is decouple some tasks (kind of separate “back-end” UI from “front-end” UI).We can do “partial/almost” cross-platform UI, if we think that some stuff can actually cross cleanly:- Layout (the big one, IMHO) with something like. This one was my main block before.- A well defined way to separate the back from the front UIs. The ELM architecture is a good contender (called Update-Model-View, similar to react + redux but simpler and easier to call servers/async)A big chunk of the logic is totally cross-platform and “only” need to adapt the render of controls. This way of working allow to work with pure objects for the model and the view without actually commit to exactly what is the view UI. Instead, is delegated to the “update” side.
It can totally be just in-memory, testeable object.Dispatching, events and similar stuff, that is not visual. This need a bridge but I don’t think will be complicated.Then finally, the rest can be fully native:- Controls- Drawing- Animations- Call to native libsThis mean that we build components instead of a class hierarchy and is possible to swap what is a “control”, like, from HTML to iOS Views without moving the rest of the logic.The big question is what to use for coding this. I’m using.net but wish to have something more low-level. I know swift and it could work for other targets (Java,.NET, native) with elements.Wish to have a coding partner to do this:slightsmile. In fact, there are many downsides performance wise when you think about electron:- it is as slow as any other web rendering engine- it uses as much memory as any other browser- you have huge binariesThe key benefit of electron is that you can easily build cross-platform apps which run on every notable platform. Many of the general weaknesses of electron can be eliminated by building a Progressive Web App, but that doesn't solve the performance challenges that come with building a web app.Performance wise web apps are very slow when compared to C/C/Rust/Go.
For a C program, a single millisecond itself is a long time. For web-apps you struggle to get everything in a 16ms window to not break your 60fps experience.But the point is that while web apps are in fact much slower, they can be fast enough. And if you have a technology that is very platform independent and you can built good experiences with it, then you probably find some nice use-cases. The key benefit of electron is that you can easily build cross-platform apps which run on every notable platform.I've been a bit confused about the draw of this feature.
I understand that there are a lot of JavaScript developers out there, and things like Electron allow them to use their JavaScript knowledge to make applications on many platforms. But there are now a large number of GUI libraries (GUI being a typical obstacle for cross-platform support) that can target all these platforms (and sometimes more) as well. GTK+, Qt, and WxWidgets name a few.
And they have bindings across many languages! Of course, to make something that's completely custom-looking using these libraries may be more of a hassle than an html/css document.Maybe Electron's popularity is primarily driven simply by the high numbers of JavaScript programmers out there.I guess it's like you pointed out: if you can get it to be fast enough, it's acceptable. Kind of similar to interpreted vs compiled languages. The problem with Qt, GTK, etc. Is that you can't use them on websites1. Meanwhile you can build most applications as websites, which don't require any installation and are available everywhere and instantly.I am a Linux desktop user myself, so I have some sympathy for Qt, GTK and software distribution via package managers. Nevertheless, as a developer I like the web better, as that is a platform which allows me to easily distribute my applications to anybody on any platform within seconds.Performance on the other hand is a topic by itself.
The problem I see with web applications here, is that it is much easier to create a bad performing program with web technology than with compiled languages and toolkits. But that is something you can learn and if you create some performance critical software, easy distribution might not be your top priority.1: I mean I have seen GTK rendered on a html canvas some years ago, but as far as I know nobody actually uses that kind of tech.
Wikipedia had this: (under High-level widget toolkits). Not too detailed though.In terms of language support, I've seen bindings for the more popular ones on all major languages and even some more minor ones. There's probably better comparisons out there; this one doesn't have Electron at all (since Electron is more of an environment/VM than a GUI-only toolkit).Often running in a VM bubble has it's own features/benefits though.
For programmer benefits, I can't think of a better example than Smalltalk VMs. But I digress. That's a pretty big exaggeration. Taken from the first GPU review I looked at, a GTX 1070 Ti can run DOOM (the new one) at ultra settings at 170 FPS.
1 Sure that's a bit faster than an average gamer's card, and DOOM is better optimized than many games. But the most powerful hardware running a decade old game at low settings will easily get several hundred FPS. (It's hard to find benchmarks of this, though, so I settled for a recent game at Max quality).The counterexample is games which were designed for fixed 30fps which fall apart at higher framerates, but those are generally limited to Bethesda games and Japanese console ports.1. Author here.For more background on product development about Finda, there are notes on my personal website here:I started this as a UI research project to try and replace OS X Finder with a keyboard-only UI. 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! 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.
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 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. 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:). HTML/CSS/JavaScript is something that the most developers tend to already knowIf 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. 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 singleimplementation. 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 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. would have been the gold standard for years to comeI'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. Generally platforms providers optimise graphics highly for their own platform.
A generic cross platform library rarely invests similar effort for every platform it can run on. The usually applies more to mobile however - most desktops require even the platform providers implementation to be somewhat generic.The other part of the inefficiency is more to do with what the cross platform engine is internally guaranteeing vs what the platform providers will guarantee. For example, let’s say skia here always runs at 60fps. Great, and a lovely user experience - but does it then respect low power mode in iOS or Android, or does it just continue at 60fps eating away through battery power because it’s geared to the common case of all platforms?I’d love this to work, but years of the reality of using cross platform renders has made me quite skeptical of their ultimate benefit to the user.
They’re great for developers though - but that’s the wrong way round for convenience usually, I think. 'Google' is actually a key differentiator here, because I think Google is uniquely focused on both design (it's been a long road to get here, but at this point I think Google is second only to Apple in design focus.) and interopability.
Apple would never make a cross-platform UI framework. What does this mean? Google's vast resources in design, development, & testing, equaled by very few, are behind this initiative. There's no doubt that is a competitive advantage.The more interesting question is 'Why does Flutter exist?' Google is, after all, a business.
What's the ROI? Here's my theory: Google is known to be developing a new operating system from scratch called Fuschia1. Many many OSes have died in the crib because there was no app ecosystem for them, and thus the cost of switching to the 'new thing' was too high for users. How do you solve this problem?
Maybe if you create a cross-platform app development framework that lets developers write for the two incumbents while also ensuring compatibility with your new OS.1. Popularity of Electron proves that they are not easier. Even Microsoft wrote VS Code in it.I don't care much about Google but they did pretty good job with Flutter:1. No special designer needed, you do everything in code. That means everyone can use their preferred editor.2.
Hot reload - you change something and it changes in the running app.3. Headless testing - No need to own iOS/Android device to test iOS/Android UI.4. Nice tooling - autocompletion, formatting, etc. Everything done via command line, with optional support for IDE.5. Extensible - very easy to write your own widgets. There is nothing special about provided components.6.
Platform agnostic - 'native look' of Qt/GTK is a lie, they still look off. To me it just triggers uncanny valley vibe. Not to mention that they implement native look from 5 years ago or more. And completely useless on mobiles. Flutter looks the same on every platform unless specified otherwise. Way less platform specific bugs.
Electron is popular because web 'developers' can't be arsed to learn anything other than JS. It's as simple as that.
They live in the lie they tell themselves that JS development is easy, when it really isn't, tooling is disastrous, IDE is nonexistent, apps look bad, etc. They are just happy they manage to run something 'desktop'.All those things you mentioned are true of Xamarin.qt uses actual native controls, so not sure what is a 'lie' about it; if something is not behaving correctly, it's a bug, and you open an issue. GTK does look bad and out of place, I agree with that, bug so does Electron. If it's between GTK and Electron, I'll take a proper GTK application.Looks the same = looks bad on all platforms. You should use Flutter for a bit before you strongly opine how it's no different than Xamarin or whatever.Flutter is different.
What is it about 'hot reload' that is so appealing to people? Running an app takes less than a second on Xcode. And.NET had 'modify, recompile and continue' in 2005 at the latest. I fail to see the revolution here.Your nonchalant mention of 'Xamarin or whatever' means to me you have little experience with that.You say that Flutter takes the best ideas of UI toolkits, but then say it's mostly web engine developers. So which one is it?
Let me guess, they are using Flex as layout? So hardly the 'best ideas'. Edit: Yes, flex 0On the other hand, I don't need to use it to predict how bad quality apps will turn out to be.
Just like Electron and React Native apps are bad, so will Flutter apps be, for the simple facts no native controls are used. (React 'Native' is not native at all.) Even the best implementation (which Electron and React Native do not have) would still mean bad apps simply because they are not using native widgets.You seem to only care about developer experience—which I disagree as well. I only care about user experience. User experience is king and developer experience is complimentary.0. and hire 3 iOS + 3 Android devsThe usual fallacy. What you can do with 2 cross platform developers + 1 iOS + 1 Android, you can achieve with 1 iOS expert, 1 Android expert and one who can do both iOS and Android well enough.
but who will do thisAnyone who wants quality apps. So basically not most start ups, I guess.
can have 95% of the same with 2 flutter devsFalse. Just like it's false with Electron and React Native. At most you have 75%, and that's the most simplest apps. At least with React Native, you can somewhat easily integrate native components. It's ridiculously hard with Flutter.
(For example, see how long it took to integrate with MapKit.). Nativeview is just a NSView which is where you have to render your stuff on macOS, whatever the toolkit used. But the actual widget implementation is custom: take for instance QComboBox.It is painted here:This calls at some point QStyle::drawControl which ends up here on mac:this ends up here in this big switch:which leads us here, in the drawComboBox function where mostly everything is done by hand:and also here: tadam, actually it just uses the 'windows' (actually fairly generic and themeable) style for drawing:See also this qt blog.
Author here.I'm compiling Rust to WASM on another project, so I can address this question.I haven't studied relative perf, so can't make any claims there.But for this application your guess is correct: It's iterop.It's easier to go with Rust via Neon rather than WASM because Finda needs to:+ Walk the filesystem for file results+ Call OS X CoreGraphics APIs to list windows+ Run a websocket server to collect results from browsers and VSCodeAll of this requires leaving the browser sandbox, and so can't be done in WASM. I think this is often the perception - and I understand why, because I shared it for a very long time - but I don’t think it’s true.Building a simple UI for multiple platforms may be somewhat more time consuming than a single cross-platform Electron implementation. This will scale with the complexity of the UI.This particular application has about the simplest UI imaginable. Consume some keystrokes, render some rows of text.
Implementing this is any native UI platform will not be hard - but it will reduce the memory footprint, rendering time, and application bundle size.Native UI frameworks are actually really good at rendering simple applications on their platforms. There’s usually plenty of documentation and good development tools. Building an application using one of them is definitely different from web tech - but I don’t think it qualifies as hard.
And I reckon it would be useful for more of us to experience as many different platforms as possible - it’s a great way to learn! I think it's wild that the browser has become the UI layer in so many applications.
CSS + HTML simply make things more consistent in a way that no other toolkit ever has. On the flip side, it's sad that every app now packages the entire jungle (so to speak).I know that this is what Adobe Air was supposed to be, and part of me would love to see something akin to Chrome's autoupdate mechanisms for an Air-like platform around Electron's base that could be shared. That doesn't get around performance issues, but would at least mean some reduction.I think it's a great option to have, but still concerning in some ways.
I also think that React-Native will probably grow to be easier to create more native-like cross platform apps over time. Definitely interesting times. Interesting that nobody seems to talk about the software itself and maybe it's alternatives.I for once welcome the concept of something like Finda and am looking for alternatives for me.
Finda finds things — windows, browser tabs, code editor buffers, browser history, apps, files, etc.Finda looks and acts like a normal launcher. The concept isn't new, but fast good launchers are rare.
Awesome Mac Now we have become very big, Different from the original idea.Collect premium software in various categories. Feel free to star and fork.Any comments, suggestions?. We love PRs:) Please take a look at the Contributing guidelines before opening one. Follow the list. Explanation means open source, click to open open source repo;means free to use, or free personal license;means App store hyperlink;means hyperlink to a corresponding Awesome list for the item;Awesome Mac App for macOS.
![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2023
Categories |