[HN Gopher] Ask HN: How do you create a cross-platform GUI witho...
___________________________________________________________________
Ask HN: How do you create a cross-platform GUI without using
Electron?
I have the idea of an app that is mostly about communicating with
an API on the WEB. It feels a considerable overkill for an Electron
App. The size of a hello world app in Electron is 100x the size of
my backend! On the business side, I understand that many people on
HN prefer to ship that spend time on technologies discussions. But
if you have the time, and your goal is to do something
maintainable, reasonably close the most to the Desktop, and well-
integrated to the OS, what tech/stack will you use? Windows/Linux
GTK/MacOS
Author : mariocesar
Score : 41 points
Date : 2021-09-10 17:27 UTC (5 hours ago)
| password4321 wrote:
| https://news.ycombinator.com/item?id=28469498#28475543
|
| > Free and open source: https://www.lazarus-ide.org/index.php
|
| > Other 30+ cross-platform GUI toolkits / frameworks:
| https://www.slant.co/topics/983/~best-cross-platform-gui-too...
|
| Lazarus has the opposite problem of all the other UI toolkits -
| relatively awesome UI across all platforms (especially if you're
| a fan of WinForms) but stuck with only support for Pascal.
| squarefoot wrote:
| One word: Lazarus.
|
| Cross platform done right (native code, no intepreter, no VM).
| Both IDE and generated code run native just about everywhere,
| from small ARM boards to virtual machines, and of course x86. As
| fast as C, decent sized executables, lots of built in or
| available libraries and components to do a lot of things, from
| managing databases to low level access to hardware, graphics,
| sound, etc. And of course it's 100% FOSS.
|
| My last use case was a few years ago when a friend needed to
| monitor some security cameras, but they were of different brands
| and needed either their crappy Android/iOS app or a even more
| crappy XP-only ActiveX control on Internet Explorer, while he
| wanted to monitor them from a single screen on a Windows 7 PC. As
| soon as I discovered the right URL for each one to grab their
| video feed, I arranged a window container in Lazarus dropping
| there a bunch of media player components, each one linking to a
| camera, a few other controls and bingo, he could fire up the
| application and have the mutiple camera view on a monitor.
|
| If it compiled more modern languages such as Nim, Rust or Crystal
| it would be perfect, but even by current standards Object Pascal
| it's still really powerful.
|
| https://www.lazarus-ide.org/
|
| https://wiki.lazarus.freepascal.org/Screenshots
|
| https://wiki.freepascal.org/Projects_using_Free_Pascal
|
| https://www.devstructor.com/index.php?page=tutorials
| mjevans wrote:
| What's the Lazarus experience like for cross-compiling to other
| platforms? E.G. how hard is it to build a working result for
| Windows, OSX and Linux (maybe BSD) from Linux or BSD?
| squarefoot wrote:
| I don't recall having to cross compile, since the IDE itself
| runs on so many platforms. For not too complex projects, or
| not resource constrained hardware, importing the project and
| compiling it directly on the target might be the quickest
| solution.
| smoldesu wrote:
| I'll get shot for suggesting this most places, but I feel like
| GTK has the most 'native' feel across every operating system.
| That's not to say that it's easy to get working (setting up
| proper build targets is going to be your biggest hurdle), but
| your reward is a stylish and robust UI with proper touchscreen
| support on Windows/Linux.
| jeroenhd wrote:
| I personally think the exact opposite. GTK needs a lot of
| custom styling to get the "native" style to work, and even then
| it's kind of lacking.
|
| GTK feels right at home in the GNOME desktop environment (which
| I use, and like!) but for cross platform I don't really think
| it feels native at all. As a user, I've had much better native
| experiences with QT or WxWidgets to be honest (on Windows, at
| least).
| timw4mail wrote:
| GTK doesn't look native in KDE, yet QT looks more native in
| Gnome.
| joeld42 wrote:
| It depends. I've built a lot of these. The best approach is to
| keep the UI very lightweight and just build it using native
| controls for each platform. Keep all the application logic in a
| common library and just rewrite the parts that are interactive.
| This isn't as much work as it seems, especially if you design it
| upfront, and there's no other way to get a native feel. There's
| also some "product management" advantages to this approach, such
| as building new features first on your smallest platform so you
| can test/iterate quickly with few users and then moving them to
| Windows when they are proven. Don't build new features on all
| three at once, take turns.
|
| If the app has a whole lot of dense UI screens, or if you don't
| particularly care about it looking nice and feeling platform
| native, something like Qt or many of the other frameworks
| suggested here work well, but do be aware that you'll be making
| it harder to use platform features. For example, on MacOS you
| wouldn't support the TouchBar and would have some extra
| complexity to support Metal graphics vs GL (which Qt supports).
|
| You can also do something similar to Electron but much more
| lightweight using a platform WebView. Then you can have common
| controls built in a htmlish way, and still have custom and native
| controls mixed in. One example of an app I worked on that was
| built this way and worked well was an app to browse/view 100s of
| video clips, we had a common html-based widget to filter and
| display search results and thumbnails (which had a bunch of
| interesting layout requirements) but the video playback itself
| was in a native panel (it needed to play custom formats so using
| web for everything wasn't appropriate).
|
| Flutter looks promising but it still feels a little early. Try it
| out if you're willing to take some risks and maybe bend your
| thinking a bit. I found it too indirect and felt like I had to
| give up too much design responsibility to the toolkit when I last
| tried it but maybe that's an advantage.
|
| If you're thinking about Electron, why not make it a purely web
| app? Then you'll save yourself lots of hassles distributing and
| downloading.
|
| Also, for graphically intensive or in-house tools (like a game
| level editor) i use Dear ImGui, it's very fast to develop and
| great cross platform support, but I wouldn't ship it to a
| customer.
| c7DJTLrn wrote:
| This thread doesn't inspire confidence. It's mostly small and
| unproven projects, some maintained by hobbyists.
|
| I think the mess we're in with GUIs is because we've failed to
| find a way to convey at a very high level what the inputs and
| outputs of software are. In a utopian world, you'd define what
| you want the user to see and how the user can interact with the
| information. Something would then work out how to lay that for
| you (in a way that makes sense to a human) and construct a GUI
| using native OS APIs.
|
| Instead, we have only three options that I'm aware of:
|
| * Use a framework that ignores the native APIs, throws away the
| OS design language and does all the rendering inside
|
| * Build separate applications for each platform
|
| * Use Electron and potentially reuse work you already did on the
| web version
|
| When looking at it this way, it's easy to see why Electron is
| popular. Not that I'm a fan of it in any way.
|
| I think what we need is a lot of really smart people to come
| together to reinvent the presentation layer.
| rubyn00bie wrote:
| I'd highly suggest using Dart and Flutter.
|
| I've probably written GUI apps in C, Java, Ruby, Objective-C,
| Swift, JavaScript, and probably a couple I forgot about.
| Dart+Flutter come the closest to being "good" and correct.
| There's some missing documentation for Desktop development with
| regards to Flutter + Dart but nothing is totally intractable if
| you're willing to read through issues. My only caveat is that
| Google is truly an awful company to depend on for your business;
| since, they 100% do not give a a single fuck about you unless
| you're paying them ~$100 million or more a year, or an EXTREMELY
| high profile client.
|
| I've been getting ready to give Pascal a solid try but I still
| totally lose my mind when working in Lazarus (like where did the
| thing I just used go? Ah yes, tiny, free-floating window, of
| course). I have a feeling Pascal is probably the real diamond in
| the rough of UI application development these days.
|
| Qt is probably fine but their licensing turns me off from ever
| using or considering it.
| mariocesar wrote:
| Qt has been mention a lot, it's confusing all the license deal.
| I kind of understand that is free of use if it's not embedded.
|
| But flutter looks like a good option.
| superjan wrote:
| There's also Xamarin. Uses C# and dotnet. You can choose between
| native widgets and platform-agnostic.
|
| https://dotnet.microsoft.com/apps/xamarin
| imagine99 wrote:
| Delphi, believe it or not. Might even be the most mature and
| feature-rich of any of the technologies and frameworks mentioned
| here.
|
| RAD Studio 11 just got released and allows native development for
| "all platforms" from a single codebase and GUI at the click of a
| button. [0]
|
| I have ranted about and harshly criticised Embarcadero's
| misguided product policies as much as the next guy but that
| doesn't change the fact that Delphi is still the most mature and
| versatile Rapid (sic) Application Development environment out
| there, especially if UX and UI are important to you.
|
| And the twenty-year old adage that you can knock out an MVP with
| a really nice and polished GUI in a Saturday afternoon is now
| even more true than ever.
|
| In the end, a native binary with a small footprint (easily
| 1/100th the size of an Electron project) will fall out at the
| press of the F9 key and that's really something to behold...
|
| The free Delphi community edition [1] might even offer all the
| features that you need, although I really wish Embarcadero would
| see the light already and sync its release cycle with the full
| version.
|
| Delphi might not officially be regarded as hip or cool these days
| (mostly due to severely and ongoing errant product and community
| management by the company that makes it) but some great people
| and brilliant minds are associated with it and compared to the
| olden days Delphi is now somewhat of a secret underground Swiss
| army knife that ironically gets used now mainly in big and medium
| corporations.
|
| I like to think its versatility combined with the fact that it's
| technically uncool and against the mainstream to do projects in
| Delphi these days might fit a hacker's (and HN user's) mindset
| very well...
|
| [0] https://www.embarcadero.com
|
| [1]
| https://www.embarcadero.com/products/delphi/starter?aldSet=e...
| Gys wrote:
| > The free Delphi community edition
|
| For a moment I was tempted to look into Delphi again, as I have
| spend many years in that environment. However, I see now its
| free until you hit USD 5.000 revenue per year. Not 0 USD, not
| USD 50.000, but only USD 5.000. Yes, that is the Embercadero
| that I knew. Probably this 'free' edition is canceled next
| year. Would not be the first time...
|
| Edit: yes, still only runs on Windows
| ptx wrote:
| Have you tried Free Pascal with Lazarus[1]? How does it stack
| up compared to Delphi?
|
| [1] https://www.lazarus-ide.org/
| imagine99 wrote:
| I like Lazarus and I think it's great and important that it
| exists, especially with Embarcadero refusing to recognise and
| take seriously the needs of a developer community outside of
| Fortune 500 orgs (I'm slightly exaggerating but not much).
|
| Lazarus is Free Software, which is awesome, and its feature
| set is also mature and impressive (I wouldn't have thought
| that the project also has a 20+ year history already).
|
| I do recommend it highly if you can't get your hands on
| Delphi, don't want to support Embarcadero's antics, or work
| with an open-source project anyway. Several major component
| developers, including the great guys at TMS with their cloud
| pack and Raspberry Pi components [0] make a ton of awesome
| components that are available for both Delphi and Lazarus and
| I can highly recommend them.
|
| If you're operating in the commercial space and have a
| budget, a bigger team, strong network, database or certain
| other commercial requirements, you might appreciate the
| support options and greater choice of 3rd party components
| which can be installed in Delphi with just a click and that
| save just so, so much time in getting your product to market.
|
| If you're learning or teaching the language, working in a
| small team or alone, or require a feature set fully supported
| by Lazarus or just like free software, I wholeheartedly
| recommend Lazarus as a great alternative indeed. If you're
| somehow in the middle, check out the Delphi Community Edition
| too and just find out what suits you better. I guess it also
| comes down to what you're used to...
|
| [0] https://www.tmssoftware.com/site/products.asp?t=lcl
| phendrenad2 wrote:
| > take seriously the needs of a developer community outside
| of Fortune 500 orgs
|
| Yeah no kidding. Last year I tried to download the trial of
| their paid C++ IDE. The licensing tool wouldn't work, and
| support never returned my emails. People complained in the
| official forum, no company response their either. I took
| that to mean "We see you as such a low-value potential
| customer, we won't lift a finger to get our own demo to
| work for you".
| irq-1 wrote:
| Does the community edition work on linux, or compile to linux?
| The page says:
|
| > Delphi Community Edition is a full featured IDE for building
| iOS, Android, Windows and macOS apps ...
|
| But looking at the feature matrix for the full product it says:
|
| > deploy to the platforms you need to support and with RAD
| Studio that includes Windows, macOS, iOS, Android and Linux!
| password4321 wrote:
| https://www.embarcadero.com/products/delphi/product-editions
|
| > Build Linux client / server applications (includes FMX GUI
| for Linux) _The RAD Studio Linux Compiler enables compiling
| applications to popular Linux platforms. FireMonkey GUI for
| Linux extends the FireMonkey UI framework to provide full
| Linux GUI support._
|
| Only offered on Enterprise ($4K) / Architect ($6K) editions.
| mshekow wrote:
| I've successfully built apps with Python and Qt (PyQt6 and
| PySide6 are both working fine). The overall file size of the
| resulting folder is about 60-80 MB on Windows, mostly due to all
| the Qt DLLs/plugins you'll need to ship. By manually deleting
| non-necessary DLLs, you might save maybe up to 20 MB. Just
| considering the file size, this might not a huge gain compared to
| Electron, I suppose?
|
| However, keep in mind that desktop apps have the major
| disadvantage of figuring out distribution (separately for each
| platform!!), which includes the following two steps: 1) packaging
| the application in some format (e.g. an MSI installer for Windows
| and a Disk Image Bundle for macOS), and 2) distributing that
| package (including auto-updates). I have written a number of
| articles about this topic, see
| https://www.augmentedmind.de/2021/05/30/distributing-windows...
| and https://www.augmentedmind.de/2021/06/13/distributing-
| macos-a... . You get rid of all that if you just built a PWA or
| other kind of web app.
|
| In addition, if you use Python, you also need to choose a
| "freezing" solution, such as PyInstaller (more details at
| https://www.augmentedmind.de/2021/05/16/distribute-python-ap...
| ).
| vorpalhex wrote:
| I recently built one using Fyne for golang. It works well for my
| case but Fyne is still very new and in development.
|
| http://fyne.io/
| cosmotic wrote:
| Java and Swing are still a great option.
| kody wrote:
| Qt/QML is my choice.
| mjevans wrote:
| It would be really nice if there was a shared widget API that
| would work for the major operating systems. If most of simple app
| could work on Windows, OSX, maybe mobile (Android / iOS) and
| Linux / BSD.
|
| Something that was mostly native for all of them.
|
| Currently the only alternative to Electron that is similar is a
| program that hosts a local webserver and the local browser is
| pointed at it, but that's a second class experience.
| bleair wrote:
| https://www.fltk.org/ - fast light graphics toolkit
| https://nanogui.readthedocs.io/en/latest/ - nanogui
| tored wrote:
| What is the status on the different FLTK versions?
| samf wrote:
| I haven't used this, but it should be mentioned:
|
| https://tauri.studio/
| unnouinceput wrote:
| I use Delphi with its FireMonkey framework. It targets all major
| operating systems (Win/Lin/Mac/Droid/iOS) natively. From all the
| cross-platform frameworks that I've seen in 25+ years of working
| in the industry Delphi's switching target is the easiest - a
| simple combobox and kaboom!, you're good to deploy for that OS.
|
| Their roadmap include, in some years I suspect, probably 5, to
| also target WASM at which point, if Embarcadero is smart enough
| to lower their ridiculous license pricing to under $300, will
| become the most powerful tool to write cross-platform
| applications.
| xvedejas wrote:
| I'm not the best person to explain or recommend it, but I'll
| suggest "immediate mode" GUIs partially because I want to hear
| more about the pros/cons from those more experienced (I haven't
| ever worked on UIs professionally). It seems these graphics
| libraries just need some kind of context to draw to, like from
| OpenGL, and also have a simpler implementation in general. That
| might make them more portable and smaller, if less native-
| feeling. I just started looking into egui (a Rust crate) myself.
| joeld42 wrote:
| I love IMGUIs but you have to be careful with the to get them
| to play nice with the event loop. If you're using it for a game
| where you're drawing every frame anyways, they're great. But
| for something that the user might keep running alongside other
| apps they can be a cpu/memory hog. You can of course only
| process/redraw when an event happens but that can be easier
| said than done sometimes.
| alphaomegacode wrote:
| Is there a particular language that you needed to use or have
| skills in? That's a very important qualifier.
| mariocesar wrote:
| Python, JavaScript a little of C, and similars
| ppetty wrote:
| So just for the sake of completeness, maybe, and since Electron
| seems to be the most popular solution; what about a website?
| Fairly ubiquitous across all platforms with the help of Chrome,
| Firefox, and even Safari or Edge. I don't think should be
| dismissed as often as is, consider VS Code on Github.com (hit the
| period key in a repo and the repo's code is presented with VS
| Code in a browser -- and it supports syncing extensions -- though
| not all, for example).
|
| To me it makes sense from tne perspective of the work being done
| in HTML, CSS & JS to make an Electron app. Why not start as a
| website then desktop?
|
| I get there are certain pieces of functionality not suited for a
| website; but based on the original post's question and
| description it seems feasible.
| mariocesar wrote:
| I need to read/write to the filesystem, think the app is like a
| personal document manager. Also will like to associate
| filetypes with it, and for the most important thing is being
| able to send notifications and make sure my backend is syncing
| data all the time
| brundolf wrote:
| For the record you can do the last two things with a website
| these days. Still sounds like it won't work for your project,
| though.
| slater wrote:
| QT?
| verdverm wrote:
| QT https://www.qt.io/ is one option I know of. There might be
| some Python or Golang libraries?
| mynegation wrote:
| https://tauri.studio/ - I haven't used it myself but looks pretty
| interesting. They say they use existing browser engine shipped
| with OS and desktop integration layer written in Rust. The claim
| is that you get an application size under 1MB
| sto_hristo wrote:
| Can you share any insight in the cross-os implementation
| inconsistencies of those browser engines?
| mynegation wrote:
| Not a front end developer, and I do not know much about it,
| but I imagine that native engines would be Edge on Windows
| 10, Safari on iOS and whatever is installed on Linux by
| default - usually Firefox. From here you would need to figure
| out the differences between those engines with something like
| caniuse. Like support for service workers etc.
| tlackemann wrote:
| Used this for a small linux GUI proof-of-concept.
|
| I really liked it. It was awesome to use something I'm familiar
| with (Next.js) and have it drive the UI. Resulting application
| was indeed about 1MB after all said and done.
| teebee wrote:
| You probably are wasting your time - multi-billion dollar
| companies have abandoned native desktop development - pretty sure
| they decided it was just easier and cheaper to maintain. If you
| are doing this for fun or profit - you need to decide how much
| your time is worth.
| antender wrote:
| There is also an interesting solution to this problem: use native
| WebView, so you don't have to pack the whole Chrome with your
| app. Basically every "electron alternative" with HTML+CSS+JS
| works this way.
|
| https://github.com/sudhakar3697/electron-alternatives
| 908B64B197 wrote:
| You'll have a little bit more testing to do, as the web-views
| shipped by different OS might not be exactly in sync feature
| wise, but if your app is really simple it shouldn't be much of
| a problem.
| diskzero wrote:
| There are several options, each with their own pros and cons.
|
| Qt [1]
|
| The main codebase is C++, but bindings are available for Python
| and several other languages. I have developed and shipped
| multiple cross-platorm applications using Qt, using both C++ and
| Python. Documentation and source code examples are readily
| available.
|
| JUCE [2]
|
| Another C++ framework, with Python bindings. The focus is on
| music and audio apps, but a cross-platform GUI framework is also
| part of the library.
|
| Blazor Desktop [3]
|
| I have developed C# web applications using Blazor and WASM and
| moved them to the desktop easily. Using C# and the Dotnet
| ecosystem is really interesing and worth looking at.
|
| Flutter for Desktop [4]
|
| Still in beta, but has the support of Google, for better or
| worse.
|
| JavaFX [5]
|
| A Java cross-platform still under active development. I think it
| is pretty nice if you like Java.
|
| Red [6]
|
| Let's add an outsider just to keep things interesting!
|
| This github site seems somewhat current about other Electron
| alternatives as well. [7]
|
| Good luck! You will find there are lots of alternatives out
| there.
|
| [1] https://www.qt.io/
|
| [2] https://juce.com/
|
| [3] https://visualstudiomagazine.com/articles/2021/02
| /17/net-6-preview-1.aspx
|
| [4] https://flutter.dev/desktop
|
| [5] https://openjfx.io/
|
| [6] https://www.red-lang.org/p/about.html
|
| [7] https://github.com/sudhakar3697/electron-alternatives
| miovoid wrote:
| Vote for Flutter and QT
| babarganesh wrote:
| Is there a good grid control (ie a data grid) for Blazor? A
| colleague reviewed the offering from Infragistics and it wasn't
| anywhere near their WPF data grid control.
| mherrmann wrote:
| If you have access to Python 3.5 or 3.6, you can use my open
| source library https://build-system.fman.io to create a Python
| / Qt app with an installer for all the OSs in minutes. Python
| 3.7-3.9 is also supported, but only available commercially.
| irq-1 wrote:
| From https://juce.com/get-juce "JUCE is dual licenced under
| both the JUCE licence and the GPLv3."
| Zelphyr wrote:
| I am really looking forward to the day that I can build cross-
| platform GUI apps in Red. Based on Rebol, it is a beautiful yet
| powerful language. They are always looking for more
| contributors, if anyone is interested.
|
| Here's an example of what it could do on macOS four years ago:
| https://www.red-lang.org/2017/07/063-macos-gui-backend.html
|
| Edit to add: You can build cross-platform GUI apps in Red now
| but, while they're very close to the finish line, and making
| progress every day, there are still a few missing pieces yet to
| complete on the 1.0 roadmap.
| emerged wrote:
| Funny, I actually use JUCE for audio and yet it never crossed
| my mind to use it as a general purpose cross platform UI. Good
| call!
| billconan wrote:
| imgui
| mintplant wrote:
| NodeGui [0] is an option I haven't seen mentioned here yet. It
| comes in many flavors [1] [2] [3].
|
| [0] https://docs.nodegui.org/
|
| [1] https://react.nodegui.org/
|
| [2] https://vue.nodegui.org/
|
| [3] https://svelte.nodegui.org/
| arpyzo wrote:
| I personally like wxWidgets: https://www.wxwidgets.org/
|
| It's open source, the code has always felt reasonably clean to
| me, and it gives your apps native look and feel.
| Shorel wrote:
| I second this choice. It is the only toolkit that looks native
| in Windows.
|
| And it is ridiculously fast compared to alternatives.
| pengo wrote:
| We write apps like this in Object Pascal using Lazarus. Think
| Delphi but open source.
|
| We have a suite of framework-specific developer apps for tasks
| like packaging deployments, managing common database tasks,
| onboarding new clients etc. They were written on Linux using
| Lazarus, then recompiled on MacOS and Windows as required. There
| are occasionally OS-specific variations for small pieces of these
| apps, but Object Pascal has inline compiler switches to make this
| easy to manage.
| ofou wrote:
| any good open source one?
| boban_dj wrote:
| godot: https://godotengine.org/ most of godot UI itself is made
| with godot engine
| marczellm wrote:
| We've test driven UNO at our company https://platform.uno/ but
| you really have to stick to the beaten path as some more complex
| controls are only partly implemented. It's a variation on Xamarin
| basically.
| rcarr wrote:
| Tauri looks promising if you can code Rust
| phkahler wrote:
| In Solvespace we use native GUI on Windows, MacOS, and Linux
| (GTK). This is probably not what you want to do, as we don't use
| any GUI widgets - only popup dialogs and menus. Everything in the
| app itself is rendered using OpenGL. Even our "text window" is
| drawn using OpenGL and GNU unifont (this is something that really
| needs to change BTW).
|
| The platform abstraction code is here:
| https://github.com/solvespace/solvespace/tree/master/src/pla...
|
| There is no other platform specific code anywhere in the app, but
| like I said above we don't support widgets.
|
| There is also an emscripten port in a branch, but it doesn't want
| to build recently.
| riskneutral wrote:
| > our "text window" is drawn using OpenGL and GNU unifont (this
| is something that really needs to change BTW)
|
| What would you change it to? I've implemented a GUI toolkit
| from scratch a couple times, and text editing was the hardest
| part by far.
| phkahler wrote:
| >> What would you change it to? I've implemented a GUI
| toolkit from scratch a couple times, and text editing was the
| hardest part by far.
|
| I have no idea. The biggest problem with it now is that it's
| not resizable. We could use pango or something to render text
| at different sizes but that'd be a new dependency.
|
| Also forgot: we do use a platform specific text entry widget.
|
| Also2: when I say "we" I mean the previous maintainer did all
| the cross platform code. Since then it _just works_.
| wongarsu wrote:
| Sciter [1] is kind of a really lightweight electron. It's about
| 8Mb, cross platform, and you can either run it standalone (like
| electron) or use it as a library from Rust/D/Python/C#/whatever.
| You pay for the small size with a lack of compatibility with the
| existing Javascript ecosystem. Any moderately complex JavaScript
| library that interacts with the dom will probably use something
| that Sciter doesn't implement, so you end up reimplementing stuff
| like graph libraries. On the other hand there are a couple of
| very useful additional APIs that regular browsers don't have
| (like SQLite, control over window borders, transparent windows
| etc).
|
| 1: https://sciter.com/
___________________________________________________________________
(page generated 2021-09-10 23:02 UTC)