Our great sponsors
-
-
TinyGo
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
ribbit
A small and portable Scheme implementation with AOT and incremental compilers that fits in 4K. It supports closures, tail calls, first-class continuations and a REPL.
> Overhead breeds complacency — if your program is already several megabytes in size, what's a few extra bytes wasted? Such thinking leads to atrocities like writing desktop text editors bundled on top of an entire web browser, and I think it would be nice to have a language that pushes people to be a bit more mindful of the amount of resources they're using.
You know, reading this kind of hurts. On one hand, i fully agree. If we take something like Visual Studio Code as an example, the folks at Microsoft have seemingly done much of what's possible to make it feel snappy and responsive, sometimes to surprisingly good results, yet i also remember how sluggish Brackets or Atom were as editors, both also based on browser technology.
On the other hand, i feel that it's not the filesize that developers care about when choosing browser tech, but rather their hands are forced because of a lack of other good options out there. Show me a widely supported cross platform GUI framework that's as easy to pick up and use as Electron's stack for the developers of our current year - people who in many cases don't have years to master many different technologies, but just want/need to apply much of what they already know to deliver software in short amounts of time. For better or worse, browser technologies have become the one common platform, in more ways than one.
Of course, i'll actually try to answer my own question above. In my eyes, the way how Lazarus/Pascal approached this issue was great: their LCL (https://en.wikipedia.org/wiki/Lazarus_Component_Library) provided a set of common components and then allowed them to target Win32, GTK, Qt, Carbon, ... based on the compile target, while on the tooling side they still had a really great RAD environment, with all of the drag & drop functionality of yesteryear. Now, Lazarus/Pascal are basically dead due to lack of hype/interest in those technologies, but they came pretty close to being the best option out there in my eyes!
Apart from that, i'm not quite sure. Over the years there have been many attempts at creating cross platform GUI frameworks for .NET, but there's still nothing truly stable yet. In Java, i really liked Swing because it was just so darn functional and simple to implement (with IDEs also having GUI builders), however many rather disliked how it didn't really look or feel native in many cases, which may or may not be relevant for particular types of software. In recent years, there also was JavaFX/OpenJFX (https://openjfx.io/) which i think is a good step in the right direction, but last i checked the tooling wasn't quite there yet - an integrated workflow that just lets you create and drag around windows/components without bothering too much to read the docs, whilst also letting you edit the autogenerated code after a rough wireframing/prototyping pass, should the need arise. In most other tech stacks, like Python, packaging and other concerns can be a mess, as can the loosely coupled tools be cumbersome to work with - sometimes you just want one executable (or close to it) at the end of your build steps, which can run on any supported platform.
The fact of the matter is, that if there was something easy to use, many would switch away from Electron on a whim. Not everyone is smart enough or has the time to grok lots of different technologies, or learn something a bit lower level like Qt or GTK, which in lieu of bindings for higher abstraction level languages, will typically be used in language with plenty of footguns, avoiding which takes discipline and knowledge. Regardless, not everyone needs the high customizability of the web platform. Sometimes just having native UI components being created from some abstracted common set of components would be fully enough.
But until technologies that make that easy surface, we'll just keep complaining about Electron every year.
Link for those interested: https://tinygo.org/.
> TinyGo brings the Go programming language to embedded systems and to the modern web by creating a new compiler based on LLVM.
> You can compile and run TinyGo programs on over 60 different microcontroller boards such as the BBC micro:bit and the Arduino Uno.
> TinyGo can also produce WebAssembly (WASM) code which is very compact in size. You can compile programs for web browsers, as well as for server and edge computing environments that support the WebAssembly System Interface (WASI) family of interfaces.
> No dynamic memory allocation = no garbage collector, no non-deterministic allocation/deallocation, no write barriers, no out-of-memory possibilities, no fragmentation. For a surprisingly large class of programs, this is a great situation!
I know you know this already, but your statement is a little too broad. Those problems all still exist, but are greatly reduced. Data structures still need to be compacted, caches evicted, scratch space cleared, etc. It is just that one class of intractable issues gets removed when dynamic memory allocation goes away.
On a side note, have you seen this? https://github.com/udem-dlteam/ribbit