I may be incorrect on this one, but past practice and ongoing practice may prove me correct. One of the problems javascript has had in the past was missing screen reader accessibility standards and missing illustrative code examples developers could look at and learn from so accessibility on one level could be possible to implement. So even if a developer could find and clear errors they had no guarantee doing so would make their code accessible. All of this may have changed for the better by now but if I were going to study javascript the first place I'd want to get to for first learning would be that or those sites with the screen reader accessibility standards and illustrative code samples. The reason for that is I've always needed a screen readr be it on dos, windows, linux, vax 1108 computers, Iphone or android phones and tablets. Some of that time got spent testing websites for the Government and that experience was educational for all involved.
I have one more task now before picking software to go js website and check whether it's based on electron if yes i just skip it and use other alternative. So much resources it consumes i dare all devs to use low spec machines and use such piece of crap. A simple note taking app why it has to open chromium? Plz don't use some shortcuts. Quality of software is affected using such shortcuts.
3:14 You are getting it wrong. Native means anything that is not a webapp. Or at least you should take it in such way. And by the way GTK and Qt don't count as native by your own definition because both can export to Windows, Linux and Mac.
By the way there is not living platform specific toolkit for Linux, all of them are able to export elsewhere, thus no being native by your own definition.
TLDR: It makes it easy to develop because you develop once and ship to every platform so devs love it but the end result uses a lot of system resources so users hate it.
I think this is a common understanding because "devs" choose it after all, but it's often not clear cut. If a product has designers, then the designers want their own HIGs, not to have to bend to HIGs from each desktop, and Electron works better in that regard. There's also the benefit of having a single codebase, which is a positive if the web is a necessary target. This means that often managers and architects will pick Electron rather than engineers. To look at the counterpoint, why is "electron" not the most common target for mobile platforms? They have a separate codebase and HIGs but companies will often have a separate "mobile" team and "web" team, to the extent that Mac can actually run the same code as iOS now.
this doesnt have to be the case. there are many electron apps you may not even know that they in fact use electron, while keeping your resource usage low. why do i know that? im working on a interpolation software, and used to uee purely python + pyqt5 for back- and frontend. ive decided to now build the interface on top of npm/html/css/js. the resource usage is relatively minimal (when everything is loaded into the interface, its barely using 60mb of ram and 0.1% of my cpu)
@@therealsunnyk they can be lazy on the desktop but they’d probs exceed the strict constraints on iOS and some things might not even be publishable on the App Store. On desktop they can get away with wasting resources. On Android even if you can why would you.
Another point: unused RAM can be used by the kernel to cache inodes (basically, applications/files that are frequently used by the user). RAM used up by electron to duplicate Chromium libraries can’t be used for caching.
4:30 From a former QA tester: Javascript is only easier to debug if you are using Typescript or a good framework. Vanilla Javascript is one of the worst languages to debug because it can cast data from one type to another without you noticing if you aren't careful and different web browsers will sometimes treat the same Javascript code differently. These can cause bugs in the business logic that can go unnoticed until after the code is in production. Javascript can be awesome IF you have proper tooling around it but the core language itself isn't really that good.
@@wallyhackenslacker I came from Python and C# to JavaScript. The first time I punched in == and didn't get a proper comparison like every other sane modern language on the planet I noped out on being a webdev. The more my JS obsessed webdev buddy showed me about the language, the further I ran screaming from it. Only language I hate more is PHP. Web development really has the absolute worst tools.
agreed. javascript is an abomination and brendan eich should be absolutely ashamed of himself. on the other hand, typescript is a fantastic language with a rich and powerful type system. the type system alone can be used to write programs although i don't know why you would do that in production code. the only thing that bugs me about typescript is the maintainers' refusal to add any form of runtime type information. this is the one thing that keeps typescript from being all that it could be - imagine having runtime typechecking, you could receive some object from an api and with one simple operation you would know if that object would crash your code. i've worked extensively with the typescript compiler and typechecker and i think it could be done pretty easily. i haven't had the time to attempt it but it's next up in my project queue so i'll try it soon
There is also the Maui toolkit which is also cross-platform and is a KDE Project and as such integrates into the standard KDE UI Guidelines although I think Electron, Tauri and Maui toolkits are aimed at different types of developers or rather different types of applications...
"Noticing where the error is is way easier." I could not disagree more. In TypeScript, sure, but debugging in JavaScript can be incredibly frustrating compared to compiled languages or even Python using type annotations and a capable linter.
yeah i remember beign like two hours debugging a js code, and the error was like 50 lines above where the console said, and was a variable named incorrectly. I shutdown the computer after that lol.
Thank you very much for that comment I could not agree more. Other language compilers are much more integrated them the one of JS. The line by line execution argument is also incorrect as you can set Break points in also languages a lot more precise then in js.
Sorta depends. It's easier to make invisible mistakes in JS that can that months to be caught. But troubleshooting mishandling of memory in C can feel like blind guessing when it compiles fine and the errors at runtime is just like "lol garbage data somewhere, heck if we know where." So you have a system trying desperately to assume what was meant unintentionally hiding mistakes vs a system that does exactly what it was told and is just as confused as the writer that something is wrong.
@@AnnCatsanndra That's why tools like valgrind exist. They're quite good at telling you what line of code triggers it, so then you can just step backwards.
@@AnnCatsanndra I maintain that it's mostly bad programmers that make those mistakes in C as not a lot of new developers come to it anymore. And there are a lot of tools for tracking down memory leaks if you really need it.
I agree it is better to have apps than not have them. I just don't want Chromium on my computer. I wish there was a Firefox, WebKit, or Servo based solution for developers to make cross platform apps.
@@oro6768 For firefox is just bad. But for webkit I can understand the reason. Apple don't want to lose their monopoly on the app store Imagine shipping your app as pwa on iOS just to dodge app store
Even better, it should be some kind of webpack - bundle of HTML/CSS/JS with resources which could be run by own browser - Chrome or Firefox or some other. In such case at least sone concerns would be eliminated.
As far as I'm aware it's a very new project though, so I wouldn't expect many apps to use it for the time being, although it will hopefully be super awesome in the future.
Tauri relies on system webview, so soon you will encounter some web compatibility issues. They will be much harder to solve in Tauri because you have to support some ancient webview versions from outdated systems.
@@knowledgenews5343 yeah it'll be interesting to see how that goes and if that will be the dealbreaker. Im really hoping for tauri to be good tho since Im tired with the problems of electron
It ships by using the only sane way to make linux apps You give me the app and the libs (the same way as windows) This way I'm safe from my repo killing my program for cutting packages
My two complaints with Godot are: -You can’t easily strip features. If you’re making a text editor, it want to save space by removing 3d aspects of Godot, you have to build your own version of Godot, which not everybody wants to do. -Godot’s clipboard support only covers raw text. Formatted text, image data, or anything else is not supported (my best guess as to why is because that’s all that vanilla Android can normally handle) Other than that, I love it! Exports to basically everything, has a visual designer, can use GDscript (basically Python) or C#, I love it
Just not Chrome. It ships the same JS engine V8 twice. One used inside Chrome & other one used inside Node Have you encountered extreme foolishness for minor simplicity? Well. If you had it was definitely Electron
No problem dude. Imo, Flutter actually has great potential. Is lightweight and resource efficient and looks beautiful in every platform Different platforms has different APIs for refining UI and logic. But has a pretty similar API for painting or rendering graphics on the screen Employees at google took advantage of it and Google created a graphics rendering engine named *Skia* which uses platform specific rendering engines e.g OpenGL in Linux, DirectX in Windows, HTML canvas in web etc & creates an abstraction layer that can be used anywhere. Then using the Dart programming language flutter created an UI component layer & an event handling layer on top of it & that's why flutter is performent & developer friendly at the same time. Where other cross platform UI frameworks tend to use bindings to native UI Components directly which makes it hard to work with & they break really easily on slight dependency version change Here's a flutter app github.com/KRTirtho/spotube that I created which is a Spotify Client. Just compare their performance & size difference Btw, if possible use the nightly version. It has most features & more optimized & is about to be released Also there's tons of other Flutter apps that are really good & also open source. Just bing "awesome-flutter" (ok don't bing, maybe duckduckgo XD)
@@krtirtho I've been developing a Flutter app and in my experience there were several things that aren't really great yet, the UI part of things I really dig, but the things that are platform specific have been a pain to work with for me, for example, it might be my limted knowledge, but I didn't find any library to access common user directories (Desktop, Pictures, Music, ...). I think it has a big potential, but in terms of platform APIs it isn't there just yet
I think there is a blog post from an ex-Chrome developer mentioning how Electron is the most ridiculous case of software obesity because it contains a user-land driver for XBox 360 gamepads despite no developer ever needing such a thing, just because base Chrome has such a driver and Electron didn't remove it. The driver was in fact coded by the author of the post IIRC.
@@quazar-omega Well, in desktop you've access to entire filesystem so you can do operations on Directories by just providing their paths. But in the case of Android you'll need permissions. In the case of Android you'll need externalStorage permission. In iOS there's no way to access user directories except document/appdata directory since Apple doesn't give any permission to access user directories at all About platform APIs, it depends on what want to achieve. Yeah, the plugin community is relatively small but its growing gradually. Android, iOS, Mac & Web is fine, you can create plugins for them pretty easily if you know Kotlin, Obj-C/Swift & JavaScript which are relatively easy to learn & work with. But the elephant in the room is Windows & Linux's C++ MethodChannels. C++ simply sucks. Yeah its performant & has great lib support but this is not what a developer uses typically. I really hope the Flutter team will add support for an alternative language e.g Rust/Zig/Go for writing Windows & Linux platform specific code
I'm a developer and I avoid electron whenever possible. Just making a website and packaging it with a browser doesn't make it a good solution, but a lazy one.
@@juanignacioaschura9437 if git gud or get out really stands, we wouldn't have this conversation by now. I know you like to be idealistic and such, and I don't like raining on your parade. The reality is most professional IT are done on good enough basis, and Electron is just that, simple and good enough framework that runs on almost any OS.
@@bltzcstrnx With performance issues that cripple low-end PCs? No, thank you. It's lazy. If being able to ship an application to low-end and high-end hardware alike, a BASIC requirement for all software products for daily use and non-productive focus, is "being idealistic", then so be it. Just because the First World is spoiled with multi-core chips and lots of RAM, doesn't mean the rest of the globe is on the same boat. Develop for the masses, not for the classes.
Devs don't have to resort to Electron to make cross-platform apps! GTK and Qt are also cross platform (GIMP and OBS are two examples of apps that meet this criteria). As a dev and KDE user, I've used Qt for my apps a few times, and it seems to work just as well on Windows as it does on Linux. It even picks up the native theme of each OS, but it also lets the dev choose a custom theme for their app (just like OBS does, actually it lets you switch between different themes or the default OS theme).
Issue with QT and GTK is the complexity of getting it going. Sure it is fine if you're using QT Creator as your IDE of choice, but still it takes time to get working. With electron you can hit the ground running quickly and the chromium Dev tools allow you to make GUI tweaks on the fly and immediately get feedback.
Another issue with Qt is the licensing. While Electron is under the MIT license and can be freely redistributed in proprietary apps, many Qt components are under the GPL, which requires any app using them to be under GPL as well, including making its source code available, or to buy an expensive license from the Qt company. Don't think I can put links here, so search for "qt features" for more information
@@hanro50 Qt is easy enough if you know CMake. If not then yes it's a pain to learn but pretty useful. It allows integration of C++ and C libraries which can be really good.
To regular Linux users out there: Electron isn't the only cross-platform UI toolkit. GTK, Qt with QML, Flutter, Tauri, can do the same and more in a more secure, efficient, and convenient way. To Electron developers: Don't fear native development! I used to think everything outside the modern web stack was too complicated, outdated, and unusable. I've learned Go and then Rust, and saw how JS and Python encouraged bad practices. I saw how CSS was just needlessly weird. If you prefer using TS+Electron for your app, it's fine. Just don't be afraid to learn new things.
THIS It might be really difficult to properly learn languages like C++, but when you're done with it, you have learned something you wouldn't have in python or so. I don't think actually implementing stuff in C++ should be done anymore, developing can be done in python or so, but I strongly encourage everyone to learn more than just the "easiest" languages, to get to know many design patterns you just wouldn't know otherwise. I myself started with Java, and when I started learning C++ I had so many "aha, that's how computers work" moments that I can't even tell you half of them, and I want to learn about functional programming & haskell soon
I never really liked Python or JavaScript. Not having explicit types makes my code much less predictable and destroys the ability for an IDE to provide robust autocomplete.
GTK looks like utter garbage on KDE, Windows and MacOS. Qt looks like garbage on GNOME and Windows. Flutter/Tauri are strictly better than Electron, but have the same issue of relying on a browser. There's no good crossplatform UI.
So basically it is fulfilling the promise of Java back in the 90's, that of letting companies -develop on the cheap by having one team developing for all platforms at the same time- write once, run everywhere. And it still feels as out of place on any desktop as most Java applications. If anything the one reason I really dislike Electron is because it encourages a que será será attitude towards memory and execution time optimization.
Not fulfilling it. Promising it anew, but with an even bulkier install. I'm not saying I wouldn't use it, but I've written many java desktop applications, and I find it a far more mature and workable solution. To each their own though.
As a user and a developer I don't like electron, its too slow and bloated (Also makes XSS possible for desktop apps). 2:56, Are electron apps native to all systems? They still run on the V8 engine, or do they compile ahead of time? 3:10 Gtk and QT are cross platform, you can use them in windows and mac. Its obvious why developers gravitate to electron, the web is the most popular platform to deliver apps, so focusing you effort on your web app and using minimal code to deliver a "desktop" version is efficient for developers. From my experience most electron apps are just clients for a remote service (discord, slack, etc...), and most of them can live inside the sandbox of the browser. For these apps I just prefer PWAs (or even just a bookmark), since at least I won't have to run multiple instances of V8.
This!! Electron is a perfect candidate to become a runtime. It's only when an app uses custom builds of chromium or node that some duplication would occur, but I'd guess that the vast majority of apps don't do so.
The reality is going in the reverse direction, unfortunately. Oracle is no longer shipping Java runtimes after version 8, instead they tell people to pack the runtime along with their app.
I feel like it'd be fine if Electron was bootstrapped by the installer as an included dependency. Like how many windows programs used to bundle .NET Framework 4 before windows started providing it. And also how old games used to include DirectX versions that they depend on in the installation. Technically it's a bit different from a runtime like Java but close enough. Even now multiple apps include redistributables as part of the install process and if it's already installed then no duplication occurs. I think the main reason why Java couldn't be included in the install process and had to be downloaded separately by the user was because of licensing issues, but I'm not sure so don't quote me on that. Electron as it's own redistributable package dependency thing would be perfect. But it'd need to be standardized by the electron maintainers and electron users.
4:52 it is way more difficult to figure out where javascript messes up, this was actually what caused a kde bug with the floating panel refactoring. JS basically just runs your code (without checking if it's syntax is ok!!!!) and just keeps running it until it crashes and burns, returning some cryptic errors for a simple syntax error like a missing semi-colon or curly brace. (or even reading from a variable you never created (which was what caused the kde bug), yep before you ask JS is that stupid) the creators of other scripting languages actually had a brain and implemented a system where it checks for basic errors BEFORE running the script. this is why most people prefer typescript now days instead of js, the creator of typescript actually had a brain and made a pretty decent language
This is mostly wrong, of course JS checks your syntax. It just doesn't require semicolons, which is quite common in programming languages (Python, Kotlin etc). Curly braces in JS behave the same as in other languages. Here is the error Firefox gives for a missing curly brace (at parse time, not runtime): "Uncaught SyntaxError: missing } in compound statement (debugger eval code:6:2) note: { opened at line 1, column 7" That's not cryptic at all and even tells you exactly where you opened it. Can you link me to this bug? It won't just randomly read a variable that doesn't exist, unless you're using the old var syntax rather than let which does act a bit strangely and lets you read variables before they're declared. I'm not saying JS is perfect, but this is just not true
@@circuit10 you can check Nicolo ve's channel its one of the more recent videos And Firefox has a good js linter and whatnot, vanilla js's error checking is just really bad and I hate js for that typescript is what you should be using, because JavaScript doesn't even care if a variable is undefined it just doesn't say anything and dies
@@etaashmathamsetty7399 Oh, you mean JS returning undefined when a property doesn’t exist? True, that is annoying. I’m pretty sure the JS syntax checking is part of the language specification and should be consistent across browsers, though.
3:13 QT compiles nicely and the GUI in really close to native on Mac and Win. GTK took a bit longer to get there, but is pretty good with cross platform too
Gtk looks pretty horrible on other platforms then linux. And the whole point of electron is is to reuse their web skills for desktop apps. Considering that qt is c++ only and gtk is junky in languages other then C C++ python or rust Don't get me wrong, i really don't like electron too but qt and gtk doesn't seem like a good alternative
@@ioneocla6577 or some things electron does work but I generally don't like it either. Gtk actually looks okay on Windows and not too bad on Mac, I think QT is generally a good compromise. I haven't use them, but there are Go & Rust bindings for QT
@@ioneocla6577 Qt has different bindings for different languages. It also has QML, which feels like Flutter with JS without the awful developer experience of CSS.
I personally use Tauri. An Alternative to Electron that uses Webview instead of Chromium which makes it alot smaller and faster. It also uses Rust for the Backend giving it even more peformance!
@@akza0729 actually it is. Webview uses Chromium which is using V8 aswell ofc giving it the same if not more peformance because of how lightweight it is
@@notarandom7 Um. Nope. Android Webview is Chromium. Linux users Webkit Gtk or QtWebview both off which are fork of Apple's Webkit. Mac uses Webkit same as Safari. Windows should be using Edge and new Edge is basically a Chromium. Edit: Remember. Tauri uses the OS's native Webview. It's doesn't ship a Chromium or browser parts.
Electron has serious screen reader accessibility prblems. Microsoft didn't start to clean up skypeforlinux until its second release using electron. Like javascript it's easy to write non-compliant code.
@@VictorMartins239 as a developer who uses less 'c' nowadays, i love electron and make side project on it,while thrashing microsoft for making teams in electron while screen sharing
I used to love web design until I discovered how terrible it is compared to native UI toolkits. The truth is that the web was built for fancy text pages, not full apps, which leads to the tools being less than ideal. GTK, Qt, and Android/iOS UI toolkit are much more productive to work with after you learn the basics. If you like it this way, it's fine, but just give QML or Rust+Gtk4 a try.
I'm on Linux just one year, never into informatics, but somehow Linux made me got this new interest.... Channels like this one shows me how dense and multilayered is the infrastructure our lifestyle relies on.
The best way IMO to build Linux apps is to design your applications with loose coupling to begin with. From what I've heard about Adobe suite is that their software is tightly coupled with windows and Mac and will require significant work to port to Linux. Eric S Raymond has specified some of the best engineering practices followed on Linux in the book 'The Art of Unix Programming' which includes cross platform applications like GIMP and how they are designed.
Unfortunately it's not as clear cut as it may seem. Tight integrations allows software to use the system's features for optimization reasons. Abstractions can add overhead and incompatibility issues (i.e. one system may not support the feature of another). Linux is especially difficult due to the distros having a different combinations of compositors, desktop environments, drivers, and more each with different levels of features and compatibility. Supporting that while providing high performance is not easy; in some cases impossible which results in inconsistencies.
@@dealloc Since I develop games for Windows and Linux in my day job, I got stuff to unpack based on experience. If you're planning abstractions right, the cost will be low, especially with languages like C++ and Rust. That's what senior software engineers are payed for, they work on software to keep them maintainable and performant. From my experience of developing GUI softwares, desktop environments and compositors don't dictate the front end at all. It's the widget set that dictates aesthetic and application programmers don't interact with window managers or compositors. As about drivers, unless you customize your Linux kernel, they're standard across all distributions. The fragmentation isn't as bad as you're saying especially the parameters you've provided.
Electron was the low-grade bread I used to serve business logic patties to people who didn't know how to use a fork or didn't want to get their hands dirty.
@@TheLinuxEXP But we still have some problems. We can't use OpenCL outside proprietary drivers (mesa team is working on that) and AMD only ships their drivers to RHEL and Ubuntu Maybe SteamOS (when published) will create a real case to AMD publish the amdgpu-pro driver for all systems
@@cacodemon345 But what of I want to use my pc as workstation AND gaming? I want to make some 3d models on blender and use my gpu to render but still want to play my games
@@talkysassis Honestly workstation machines do double as gaming as well but machines meant for gaming but not for workstation honestly are a poor choice to target professional drivers at.
Quite frustrating to see Discord, a very big and rich company slacking off at updating the Linux Discord app where its fixes are already upstream, so they don' t even have to bother doing much work!
@@TheLinuxEXP The worst part is when your package manager lags behind. Discord will then lock you out until you obtain the new version. There is no option to skip an update so you just have to wait for it or pull from somewhere else (i.e. Manjaro could pull from AUR) - Alternatively you could run discord inside your browser and never get locked out.
Electron could have gone the Java route by adding some sort of "virtual machine" that's native to the system and build apps from there (installing the VM when it's not yet installed). But instead, they're adding the whole Chromium engine to the app EVERY SINGLE TIME!. That's real bloat!
I respect the Electron framework. Thanks to him we got a huge number of apps that we never thought it will be available on Linux. it's true that it has performance issues and all that but there is new frameworks like Tauri that hopefully can replace Electron one day. As a developer i understand why devs choose Web tech instead of native GUI toolkits cuz it's way easier thanks espacially to CSS that gives the dev the power to make awesome UI/Animations with less effort compared to Qt, GTK, Winui, ...
Qt is _designed_ to be cross-platform. While it still has the classic "write once, debug everywhere" problem, it's certainly lighter than an entire freaking Chrome instance.
Microsoft is working on minimizing that problem integrating WebView2 not only in Windows 11, but also in Windows 10 in 22H2. So all the Webapps could share a central, always asap updated instance of Chromium (Edge Version) instead of running each their own, like they also do on Android and in iOS (WebKit). What would mean a way less usage of space in RAM and on Disk/SSD. MacOS has something similar build in based on WebKit. Linux distributions should have no problem to deliver such an option as well. Hopefully the developers will adapt to this very soon.
Funny. Electron and Proton don't work well on Atom :) As far as I understand, Electron is used mainly for proprietary software. In the free software world, it's considered good practice to develop software as little platform-specific as possible from the start. But even if the program is originally made only for Linux, thanks to the open source, someone will be able to port it to Windows if he needs it. A good example is the x11 screensaver. Its developer doesn't make builds for Windows (he hates Microsoft for personal reasons), but the Windows port still exists without any electrons.
And the plethora of lesser known apps? I'm sure that they also get plenty of developers just begging to go through the joys of writing a native looking GUI for their platform. And then when the bug reports come in, having to figure out in which project the problem actually lies. It's great fun, let me tell you.
it already exists in linux, just the companies wont do that, if you just install packages like electron, electron13, electron16, all the electron apps can run in same chromium windows. The company does not do that but community does, example arch user repo has discord_arch_electron which uses system electron packages, but there is catch in that too, discord would use electron 13, but other electron apps need electron 16 and some even 17, so in that case too, you would be running three electron separate electron instances
What I'd like to see happen, is for Electron to shift to a model where there only needs to be a single instance of the Electron runtime on a computer, and it's updated on it's own independent of the applications built with the runtime.
Love it or hate it, it's the best we get for cross platform desktop applications on Linux. Lets be fair, before electron the Linux desktop experience was not an actual experience.
I made many pwa, they just don't work that well yet, Firefox and Safari have dogshit implementation of pwa APIs, especially safari for obvious reasons (mehem, AppStore revenue). And even then, pwa lack the most important thing *access to the file system* the ability to write/read files is such an huge thing which is lacking in the pwa world, the best thing you can do is use indexeddb to save things, but then your user data relies on the browser wanting to clear your website data out of nowhere. And you still don't have access to file system
@@knoopx yes I know of it, but it's VERY limited and VERY annoying to use, both for UX and developer experience, you get a huge popup saying that the website wants to access X folder everutime u open it, if they removed the warning for PWA then it would be nice
The solution should be simple really ... standardize and make electron backwards compatible and then open only one instance of electron with multiple windows ... like multiple browser windows on chromium; i.e., if it is already running, just add to it ... basically the same thing a web browser does, minus combining tabs into windows.
You've just described the System WebView, except it's not entirely standardized. MacOS uses Safari WebKit, Windows uses Microsoft Edge Chromium, and Linux is usually webkit2gtk. Tauri already supports this, but as a developer it's fucking awful because the nightmarish hellscape of cross browser compatibility shows up. Also, this wouldn't solve the RAM usage. Load up discord in a browser, that tab will be comparable in RAM usage to the actual native app. In my case, it only saved about 30 MB to use browser.
@@kingofgamesyamiyami6269 Hmm. But shouldn't this be more popular? Also, cross-browser compatibility problems - shouldn't they be same for electron and this then?
@@arkoprovo1996 No, that isn't why it wastes RAM. All modern browsers run separate instances of the browser engine per tab, so there is very little benefit to consolidating to a single browser.
yeah, I've had the distinct displeasure of programming in ajax. Where something is broken in you're app but since javascript is interpreted it doesn't know that part of the code is broken unless you use that part of the app. Which meant essentially any time you made a change you made a system-level change that affected every part, of the application you had to manually go to each part, the more complicated a javascript application gets to see a bug, the more you hate javascript. An experience like that makes you hate not just javascript, but interpreted languages, in general. It's why they invented typescript.
For resource efficiency, I want to see an Electron shared dependency so Electron is installed once if you have VS Code and Discord installed. To completely quell the complaint of memory usage, share Electron rendering/scripting processes between VS Code and Discord but that’s a security and stability horror story.
I have a far different experience with electron regarding debugging versus C and the like. With something like GDB you can debug just as easily as js in the browser, but if the browser code was a compiler target (like if your application was written in typescript) then the debugging will be bound to said target code, not the source code. There are ways, but it's not as straight forward as you make it out to be compared to compiled languages.
So, you could use an OSes native webview right instead? I like using html, css and javascript to make apps too, it's really convinient, but then to deploy an app with this you could use the built in webview on Windows etc... right? Am I wrong about this? Make a C++ .dll for handling files and displaying the webview, it's not that difficult.
Same, as long as it isn't the worst of all worlds like Discord. I can stomach flatpak, I can stomach electron. Just... at least make it function man. Doesn't have to even be the latest, but at least make it close enough that expected functions works, the bugs get fixed, and gets some of the performance improvements. You're lucky you only have 400MB RAM use but mine with all the betterdiscord plugin I use is at 900MB and that's just brutal man.
Discord is practically a joke. Because if it notices a new version and your package manager is a little behind, it will lock you out completely. Since there is no option to skip an update your stuck with an unusable version until it gets updated to a matching version,
This is why I develop with C. Write once, compile anywhere. As long as I don't use weirdo libraries most platforms have the same basic functionality and layout and things just work. Also, even though I'm a KDE user, I still use GTK to write GUI's because it's written in C and it just works everywhere. I can't recall ever writing something that took up 100mb of space, for just the program itself anyway.
C varies vastly on different machines. I don't understand how you get the write once compile everywhere idea. You'd have to write gigabytes of macros for that to happen.
My computer graphics class had a lot of fun figuring out why the C code provided by the professor wasn't running. Spoiler, the code was written by some galaxy intellect that actually used "long" as a type.
@@isodoubIet Clearly that's not what was wrong with the code as `long` is a valid type in C. But I don't think TH-cam will send you a notification from my response, and you won't have a clue what the real problem was anyway. At least based on our past interactions you don't seem to have a brain.
ms teams on linux are pracictly not usable. just becouse they use older version of electron, which dont's support screen sharing on wayland. and it's browser version works perfectly fine.
I use Electron for various projects, thought I'd share a few thoughts. Memory usage is one of the low points of Electron. However, you can reduce it by writing memory efficient code and not creating additional processes. Electron has 1 main process and any number of renderer processes. As you increase renderer processes the usage goes up drastically. I'd assume that each process is something akin to a browser window in chrome. The less of them the better! I have all of my code in 1 process and use less than 200mb. The other way to reduce it is to avoid carelessly installing npm modules. I've seen projects with far too many third party dependencies. If what you want is simple its far better to build it yourself. Many modules have their own dependencies and this results in each module using its own instance of another dependency. This is more of a module/npm problem but it bleeds into electron as well. You really don't want 4 versions of jquery running at the same time... One extra method is to package your app properly. I made the mistake of not doing so because I thought it was solely to protect your source code (I was creating an open source app). While that is a goal of ASAR packaging the real benefit is it can cut load times down a ton. My app loads in abt 2 seconds now. Electron is easy to work with but its also easy to build poorly designed apps. However, if you put the time into it you can likely meet the constraints of your project.
I quite not agree about the cross-platform argument. Nowadays almost every GUI framework is cross platform. Let's take Qt for instance, with C++, QML and QtQuick you can develop an app either for android/IOS, Windows, Linux, OSX quite easily. GTK nor wxWidget or god only knows what framework does almost the same, they're just not as user-friendly as Qt. I personaly think that Qt is the best alternative to electron. It is dead easy to use, you only have to know C++ basics, the documentation is great and you can make something up and running in like 20 minutes with 10x less RAM usage and CPU overhead. And on the top of that, almost everything in Qt/C++ has a cross platform way to be done, using Qt toolkit or C++ STL.
It's a real shame that Firefox abandoned PWAs and that it isn't promoted more in browsers that do support it. The vast majority of Electron apps would be perfectly fine as a PWA.
At this point, Chromium just needs to be a new SDI web browser which will open applications found in a repository on local filesystem, and all installing an app should do is add the web assets for that application.
Not sure about the package size but flutter seems better than electron as of now, for these reasons: 1. It is backed up by google and also incorporates their material design 2. It is compiled so theoretically it should be faster and take up less space 3. It supports Windows, Linux, Mac, Android, and IOS. It can also turn your code into Web 4. It is based on Skia, google’s 2D rendering engine. I saw some benchmarks the other day and the speed was extremely close to the native apps I’m sure flutter still has its own flaws but a lot of developers are actually leaning towards it
@@riganburnwal1012 I have searched along this topic myself and there doesn’t seem to be a direct way of using flutter with any other language than dart. The only approach is to create a rest API with the unsupported language and then call it in your dart code.
I had the displeasure of developing for and of using Electron. On the development side you have a mess they call "main processor" and "secondary processor" that turns sharing data between windows a nightmare. Anything other than a Single-Page Application is awful, hell, horrible or insert your worse curse here to develop. At the user side, at least on Microsoft Teams for macOS we don't have a good support either: I work as an iOS developer at a tech consultancy, and we use Teams for basically everything at the work. Some days it simply refuses to ring my calls, to send my message notifications, just works when it wants, and now I'm using iOS 16 Beta, even in my iPhone it isn't working well (the iOS version was the only one I was able to use properly). So for me, it's just ugly, heavy and lazy.
Thanks for covering this. The theming is a massive one for me. For accessibility reasons, I _need_ a black theme (grey doesn't cut it.) And accent colours matter just as much.
@@isodoubIet - It’s very different in regards to most of the fears and complaints about Google’s data privacy practices. The code is auditable and scrutinized. Besides that, it’s a good browser (if you ignore its memory footprint).
10:28 That's the Flatpak version. The native packages take up 60-100MB. Edit: You addressed this very poorly. GIMP takes up close to 400MB when installed as a flatpak, which is "only" half the size of Discord. Still high, but I feel the core problem is with Flatpak in this particular case.
@@TheLinuxEXP This is true. However, you're comparing Discord's "installed size" number (which includes all reusable runtimes) to GIMP's "installed size" number on a traditional package, which won't. The traditional package number is only for GIMP and some core libraries.
On debugging Developer who works in a permissive language: Let's write the code quickly so we can debug it Developer who works in a strict language: Make sure to write the code correct by design (using language features), so we do not have to debug it
People hate it because there is literally no reason to render an entire web engine to make a multiplatform application when we already have tools that make multiplatform applications in a more efficient, safe way like java or c#. Devs use it because JS developers are everywhere (around 60% of developers use JS if I remember correctly) and most are too lazy to learn new, better tools.
13:00 Actually no, JavaScript doesn't leak memory. It's just that by default you create global variables with JavaScript, "var my_variable = 5; var my_variable = 5;" works and guess what happens if one of these two have a typo.
Heavily disagree on JS being easier to debug. Compiled languages force you to fix the little errors before they even run and, despite how good Chrome and Firefox devtools are, it's always better to get the errors directly in your IDE. Means you can go directly to the malformed syntax instead of hunting through your code in two different applications.
a native app almost always looks feels alot better while using alot less resources, it's just the way it is. the one good thing i will say is that i can instead of using an electron app, at least just use it in my browser most of the time, which is a good mercy for stuff like discord. and although i get your point, the proton comparison is not perfect cause using proton VS a native game is way less of a difference than a native app VS electron, proton is like 85-100+% of the performance (sometimes better than windows and/or the native port) with tons of nice features, vs electron which is a pretty sizable downgrade no matter which way you slice it.
Proton also has another benefit over Electron: _It only installs once._ Games don't come with their own Proton distribution; they just use a Proton installation that's already on the user's machine.
People don't realize some of their most favorite applications are written in Electron. Such as Discord, Guilded, Team, Slack, What's App, Telegram, Signal, etc. ALL Electron. I don't think Electron is as hated as you're making it seem.
Only exception I would point out here is VS Code - yes it's an Electron app, but it still performs so good! (And of course, it's full of nice developer conviniences 🙂)
There's already a electron alternative which lets you write a backend in rust and you can use any JS framework on the frontend, it's called tauri, also the bundle is much smaller and it's much faster, it opens almost instantanously, and also it's a lot safer.
I have to be radically honest… I don’t care what an application is built with. I care about what it feels like and if it solves my problem. VS Code is the best non-commandline-editor in my book and I have wasted a thought about it being built with Electron while it was helping me finish an assignment. Edit: and yes it sucks that some companies that distribute 3rd class products to lesser used platforms. But the thing is … why would the spend equal time on a lesser used version of their product when it’s not part of their vision?
I actually don't hate electron. I hate when developers use 5 year old versions (I'm looking at you, Discord!) that doesn't support modern Linux features like Wayland.
As being a developer who uses electron, I think the new alternatives like tauri are getting better and better, so I think the future is bright both for devs and users
From my experience Most Electron devs don't know anything outside JS Some guys that work close to me (not on the same company) don't even know what an interpreter is
My biggest issue with Electron is the fact that I don't need another browser. Browsers generally work best when managed by a single instance, so I'm not a fan of Electron apps launching completely new instances of Chromium completely disconnected from the browser I'm already running. This has a very simple solution: _use the user's existing browser!_ Python apps usually expect users to have Python installed. Java apps usually expect users to have Java installed. As a result, they don't need to package the runtime environment with them. Just do with Python and Java already do. In fact, _this is already possible!_ They're called Progressive Web Apps. You install them through the browser itself, and when you open them they appear just like a standalone app, except that they use the browser that you installed them through.
Big problem with all Electron apps is the bug that causes the display to "melt" on many screens. Takes a while to search for solution (turn off FXAA, either generally or for each app). Problems go years back and apparently have never been fixed.
It's mostly corporations that like it rather than developers, most enthusiast devs will usually just develop for their preferred platform but for corporations being able to basically make a single website and then port it as an app to every platform out there is a massive time and money saving. There aren't so many foss apps that use electron, I mean there are some (like Joplin) but they're by far a minority.
Flatpack version of Gnome Boxes does NOT support usb ports within the vm. Not sure if it's the same as mentioned in this video (as I have no clue about the technical things) but it sucks
If you need to create software that interfaces directly with the kernel or low-level system components like Blender does, Electron alone may not be the best choice. You may need integration Native Node.js Modules: Creating native Node.js modules using C/C++ bindings to access low-level functionality and then integrating them into your Electron application.
Electron (chromium) is good at rendering text boxes with a lot of text. Most GTK text editors (gedit, pluma, xed, bluefish) just halt or have graphics bugs when scroll down (like black background) when displaying big text files. Only GTK text editor that I know and can display big text files is CudaText (replace feature is slow tho). Notepad++ and wine's notepad.exe running though wine are way better than gedit. VSCodium was less laggy displaying large js file than gedit.
hahaha accurate messed up reality check. proof that native gui apps don't necessarily perform better. proof that runtimes don't necessarily add too much overhead. proof that is technically possible to have a better electron ecosystem.
What would be cool is if you had multiple electron apps running on one system, it would use the same Chromium pool to save memory while running many electron apps. Another thing that would be cool is if you could take any website and turn it into an electron app (I'd love to do this with my web games)
Isn't it possible to recognize within the electron app to recognize if it's running on windows/mac/Linux and passed on that recognition change which css (look/style) to use?
The obvious answer is to take a page out of Flatpak's book: have the browser part of the app be shared by multiple apps (as long as they use the same browser version), in order to save space both in RAM and on disk.
Some of the equipment I service has the user interface running in a chrome browser (Opera). I suppose this is using Electron? So ,in theory, I could run the UI in Linux rather than having to boot Windows and having to put up with the itchiness and multiple showers afterwards? I suspect the German developers for the equipment do all their work on Linux systems as the equipment itself is running embedded Ubuntu.
Nobody seems to have mentioned native Qt C++ apps (Qt being cross platform) or Qt + WebAssembly. Here you get a consistent UI and a single app that works on every platform.
Download the open source best practices report here: meet.tuxcare.com/idc-peerscape-study
I may be incorrect on this one, but past practice and ongoing practice may prove me correct. One of the problems javascript has had in the past was missing screen reader accessibility standards and missing illustrative code examples developers could look at and learn from so accessibility on one level could be possible to implement. So even if a developer could find and clear errors they had no guarantee doing so would make their code accessible. All of this may have changed for the better by now but if I were going to study javascript the first place I'd want to get to for first learning would be that or those sites with the screen reader accessibility standards and illustrative code samples. The reason for that is I've always needed a screen readr be it on dos, windows, linux, vax 1108 computers, Iphone or android phones and tablets. Some of that time got spent testing websites for the Government and that experience was educational for all involved.
Wish PWA's would succeed in replacing Electron.
I have one more task now before picking software to go js website and check whether it's based on electron if yes i just skip it and use other alternative.
So much resources it consumes i dare all devs to use low spec machines and use such piece of crap. A simple note taking app why it has to open chromium?
Plz don't use some shortcuts. Quality of software is affected using such shortcuts.
3:14 You are getting it wrong. Native means anything that is not a webapp. Or at least you should take it in such way. And by the way GTK and Qt don't count as native by your own definition because both can export to Windows, Linux and Mac.
By the way there is not living platform specific toolkit for Linux, all of them are able to export elsewhere, thus no being native by your own definition.
TLDR: It makes it easy to develop because you develop once and ship to every platform so devs love it but the end result uses a lot of system resources so users hate it.
I think this is a common understanding because "devs" choose it after all, but it's often not clear cut. If a product has designers, then the designers want their own HIGs, not to have to bend to HIGs from each desktop, and Electron works better in that regard. There's also the benefit of having a single codebase, which is a positive if the web is a necessary target. This means that often managers and architects will pick Electron rather than engineers.
To look at the counterpoint, why is "electron" not the most common target for mobile platforms? They have a separate codebase and HIGs but companies will often have a separate "mobile" team and "web" team, to the extent that Mac can actually run the same code as iOS now.
this doesnt have to be the case. there are many electron apps you may not even know that they in fact use electron, while keeping your resource usage low.
why do i know that? im working on a interpolation software, and used to uee purely python + pyqt5 for back- and frontend. ive decided to now build the interface on top of npm/html/css/js. the resource usage is relatively minimal (when everything is loaded into the interface, its barely using 60mb of ram and 0.1% of my cpu)
@@therealsunnyk they can be lazy on the desktop but they’d probs exceed the strict constraints on iOS and some things might not even be publishable on the App Store. On desktop they can get away with wasting resources. On Android even if you can why would you.
@@Freshbott2 ding ding ding
@@ZechariahB Yea i made like 2 apps in it the development process was easy but the app did not do well at all, tauri works best
Another point: unused RAM can be used by the kernel to cache inodes (basically, applications/files that are frequently used by the user). RAM used up by electron to duplicate Chromium libraries can’t be used for caching.
Yeah, I usually get >50% RAM usage all the time, not because I have like only 4GB, but because just so much things are cached
Not only metadata , but data are cached also.
@@ChipEstrada You really just went there....
@Xspire users are going to do that?
We have Tauri now. No more Electron.
4:30 From a former QA tester: Javascript is only easier to debug if you are using Typescript or a good framework. Vanilla Javascript is one of the worst languages to debug because it can cast data from one type to another without you noticing if you aren't careful and different web browsers will sometimes treat the same Javascript code differently. These can cause bugs in the business logic that can go unnoticed until after the code is in production. Javascript can be awesome IF you have proper tooling around it but the core language itself isn't really that good.
Gotta love how Javascript's equality comparison is not commutative for elements of different data types. Fun times!
@@wallyhackenslacker I came from Python and C# to JavaScript. The first time I punched in == and didn't get a proper comparison like every other sane modern language on the planet I noped out on being a webdev. The more my JS obsessed webdev buddy showed me about the language, the further I ran screaming from it.
Only language I hate more is PHP.
Web development really has the absolute worst tools.
@@mawnkey hey! PHP is quite a respectable language! ... compared to js...
agreed. javascript is an abomination and brendan eich should be absolutely ashamed of himself. on the other hand, typescript is a fantastic language with a rich and powerful type system. the type system alone can be used to write programs although i don't know why you would do that in production code. the only thing that bugs me about typescript is the maintainers' refusal to add any form of runtime type information. this is the one thing that keeps typescript from being all that it could be - imagine having runtime typechecking, you could receive some object from an api and with one simple operation you would know if that object would crash your code. i've worked extensively with the typescript compiler and typechecker and i think it could be done pretty easily. i haven't had the time to attempt it but it's next up in my project queue so i'll try it soon
@@mawnkey Look into the SAFE stack. F# code that is cross-compiled to JS. So far, I'm really loving it.
To be honest, if Sun/Oracle did not screw up JavaFX, most devs would probably use Java rather than JavaScript for desktop apps.
TBH, javafx never really took off, same as gradle, despite both been really good.
I suppose the HTML and CSS capabilities of electron makes it much more convenient to use
JavaFX with native image would be great. The kotlin team wants to push their solution for desktop.
Flutter | Tauri > JavaFx
@@SIMULATAN html & css are ugly for ui, they were designed for documents, not ui and that is still true
tauri is a new alternative that doesn't share most of electron problems.
and it uses my favorite programming language for backend
@@AshtonSnapp 🦀
There is also the Maui toolkit which is also cross-platform and is a KDE Project and as such integrates into the standard KDE UI Guidelines although I think Electron, Tauri and Maui toolkits are aimed at different types of developers or rather different types of applications...
Now I am learning svelte and I want to start learning to build apps with svelte and tauri
@@ANGELRA I think you can do that easily with vite
"Noticing where the error is is way easier." I could not disagree more. In TypeScript, sure, but debugging in JavaScript can be incredibly frustrating compared to compiled languages or even Python using type annotations and a capable linter.
yeah i remember beign like two hours debugging a js code, and the error was like 50 lines above where the console said, and was a variable named incorrectly. I shutdown the computer after that lol.
Thank you very much for that comment I could not agree more. Other language compilers are much more integrated them the one of JS. The line by line execution argument is also incorrect as you can set Break points in also languages a lot more precise then in js.
Sorta depends. It's easier to make invisible mistakes in JS that can that months to be caught. But troubleshooting mishandling of memory in C can feel like blind guessing when it compiles fine and the errors at runtime is just like "lol garbage data somewhere, heck if we know where."
So you have a system trying desperately to assume what was meant unintentionally hiding mistakes vs a system that does exactly what it was told and is just as confused as the writer that something is wrong.
@@AnnCatsanndra That's why tools like valgrind exist. They're quite good at telling you what line of code triggers it, so then you can just step backwards.
@@AnnCatsanndra I maintain that it's mostly bad programmers that make those mistakes in C as not a lot of new developers come to it anymore. And there are a lot of tools for tracking down memory leaks if you really need it.
I agree it is better to have apps than not have them. I just don't want Chromium on my computer. I wish there was a Firefox, WebKit, or Servo based solution for developers to make cross platform apps.
Agreed
Firefox used to have PWA support, but got the feature removed recently. Now, Chromium holds pretty much a monopoly in PWAs.
@@oro6768 For firefox is just bad. But for webkit I can understand the reason. Apple don't want to lose their monopoly on the app store
Imagine shipping your app as pwa on iOS just to dodge app store
There's tauri
Even better, it should be some kind of webpack - bundle of HTML/CSS/JS with resources which could be run by own browser - Chrome or Firefox or some other. In such case at least sone concerns would be eliminated.
There is Tauri, which is similar to Electron but written in Rust for Rust developement. It's significantly faster and smaller from what I know
As far as I'm aware it's a very new project though, so I wouldn't expect many apps to use it for the time being, although it will hopefully be super awesome in the future.
@@miguelguthridge it just got the full 1.0 release so its pretty much safe to use now
Tauri relies on system webview, so soon you will encounter some web compatibility issues.
They will be much harder to solve in Tauri because you have to support some ancient webview versions from outdated systems.
@@knowledgenews5343 yeah it'll be interesting to see how that goes and if that will be the dealbreaker. Im really hoping for tauri to be good tho since Im tired with the problems of electron
Very excited for Tauri to take off. I hate Electron, it's just too slow and inefficient.
Another alternative is also Godot, yes, the game engine. Some devs are creating desktop apps using it.
Damn I didn't know that!
It ships by using the only sane way to make linux apps
You give me the app and the libs (the same way as windows)
This way I'm safe from my repo killing my program for cutting packages
My two complaints with Godot are:
-You can’t easily strip features. If you’re making a text editor, it want to save space by removing 3d aspects of Godot, you have to build your own version of Godot, which not everybody wants to do.
-Godot’s clipboard support only covers raw text. Formatted text, image data, or anything else is not supported (my best guess as to why is because that’s all that vanilla Android can normally handle)
Other than that, I love it! Exports to basically everything, has a visual designer, can use GDscript (basically Python) or C#, I love it
The Godot IDE itself is written with Godot's own UI toolkit using Godot's own frameworks IIRC.
@@wallyhackenslacker * insert hand drawing itself drawing itself image here *
Just not Chrome. It ships the same JS engine V8 twice. One used inside Chrome & other one used inside Node
Have you encountered extreme foolishness for minor simplicity? Well. If you had it was definitely Electron
Ah yeah, I had forgotten about that!
No problem dude.
Imo, Flutter actually has great potential. Is lightweight and resource efficient and looks beautiful in every platform
Different platforms has different APIs for refining UI and logic. But has a pretty similar API for painting or rendering graphics on the screen
Employees at google took advantage of it and Google created a graphics rendering engine named *Skia* which uses platform specific rendering engines e.g OpenGL in Linux, DirectX in Windows, HTML canvas in web etc & creates an abstraction layer that can be used anywhere. Then using the Dart programming language flutter created an UI component layer & an event handling layer on top of it & that's why flutter is performent & developer friendly at the same time. Where other cross platform UI frameworks tend to use bindings to native UI Components directly which makes it hard to work with & they break really easily on slight dependency version change
Here's a flutter app github.com/KRTirtho/spotube that I created which is a Spotify Client. Just compare their performance & size difference
Btw, if possible use the nightly version. It has most features & more optimized & is about to be released
Also there's tons of other Flutter apps that are really good & also open source. Just bing "awesome-flutter" (ok don't bing, maybe duckduckgo XD)
@@krtirtho I've been developing a Flutter app and in my experience there were several things that aren't really great yet, the UI part of things I really dig, but the things that are platform specific have been a pain to work with for me, for example, it might be my limted knowledge, but I didn't find any library to access common user directories (Desktop, Pictures, Music, ...).
I think it has a big potential, but in terms of platform APIs it isn't there just yet
I think there is a blog post from an ex-Chrome developer mentioning how Electron is the most ridiculous case of software obesity because it contains a user-land driver for XBox 360 gamepads despite no developer ever needing such a thing, just because base Chrome has such a driver and Electron didn't remove it. The driver was in fact coded by the author of the post IIRC.
@@quazar-omega Well, in desktop you've access to entire filesystem so you can do operations on Directories by just providing their paths. But in the case of Android you'll need permissions. In the case of Android you'll need externalStorage permission. In iOS there's no way to access user directories except document/appdata directory since Apple doesn't give any permission to access user directories at all
About platform APIs, it depends on what want to achieve. Yeah, the plugin community is relatively small but its growing gradually. Android, iOS, Mac & Web is fine, you can create plugins for them pretty easily if you know Kotlin, Obj-C/Swift & JavaScript which are relatively easy to learn & work with. But the elephant in the room is Windows & Linux's C++ MethodChannels. C++ simply sucks. Yeah its performant & has great lib support but this is not what a developer uses typically. I really hope the Flutter team will add support for an alternative language e.g Rust/Zig/Go for writing Windows & Linux platform specific code
I'm a developer and I avoid electron whenever possible. Just making a website and packaging it with a browser doesn't make it a good solution, but a lazy one.
Props to you. Especially on older laptop you can really notice how heavy electron apps are on the system
And you distribute your apps for Windows, MacOS and Linux, right?
@@gogudelagaze1585 It's not lazier to develop and distribute an app to a single OS. OP's point still stands, git gud or get out.
@@juanignacioaschura9437 if git gud or get out really stands, we wouldn't have this conversation by now. I know you like to be idealistic and such, and I don't like raining on your parade. The reality is most professional IT are done on good enough basis, and Electron is just that, simple and good enough framework that runs on almost any OS.
@@bltzcstrnx With performance issues that cripple low-end PCs? No, thank you. It's lazy. If being able to ship an application to low-end and high-end hardware alike, a BASIC requirement for all software products for daily use and non-productive focus, is "being idealistic", then so be it.
Just because the First World is spoiled with multi-core chips and lots of RAM, doesn't mean the rest of the globe is on the same boat. Develop for the masses, not for the classes.
Devs don't have to resort to Electron to make cross-platform apps! GTK and Qt are also cross platform (GIMP and OBS are two examples of apps that meet this criteria). As a dev and KDE user, I've used Qt for my apps a few times, and it seems to work just as well on Windows as it does on Linux. It even picks up the native theme of each OS, but it also lets the dev choose a custom theme for their app (just like OBS does, actually it lets you switch between different themes or the default OS theme).
Issue with QT and GTK is the complexity of getting it going. Sure it is fine if you're using QT Creator as your IDE of choice, but still it takes time to get working.
With electron you can hit the ground running quickly and the chromium Dev tools allow you to make GUI tweaks on the fly and immediately get feedback.
Another issue with Qt is the licensing. While Electron is under the MIT license and can be freely redistributed in proprietary apps, many Qt components are under the GPL, which requires any app using them to be under GPL as well, including making its source code available, or to buy an expensive license from the Qt company. Don't think I can put links here, so search for "qt features" for more information
And both are sadly a royal pain, if you don't want to use C/C++
@@hanro50 Qt is easy enough if you know CMake. If not then yes it's a pain to learn but pretty useful. It allows integration of C++ and C libraries which can be really good.
Who in the hell designed the qt creator interface
To regular Linux users out there: Electron isn't the only cross-platform UI toolkit. GTK, Qt with QML, Flutter, Tauri, can do the same and more in a more secure, efficient, and convenient way.
To Electron developers: Don't fear native development! I used to think everything outside the modern web stack was too complicated, outdated, and unusable. I've learned Go and then Rust, and saw how JS and Python encouraged bad practices. I saw how CSS was just needlessly weird. If you prefer using TS+Electron for your app, it's fine. Just don't be afraid to learn new things.
THIS
It might be really difficult to properly learn languages like C++, but when you're done with it, you have learned something you wouldn't have in python or so. I don't think actually implementing stuff in C++ should be done anymore, developing can be done in python or so, but I strongly encourage everyone to learn more than just the "easiest" languages, to get to know many design patterns you just wouldn't know otherwise.
I myself started with Java, and when I started learning C++ I had so many "aha, that's how computers work" moments that I can't even tell you half of them, and I want to learn about functional programming & haskell soon
I never really liked Python or JavaScript. Not having explicit types makes my code much less predictable and destroys the ability for an IDE to provide robust autocomplete.
@@KillFrenzy96 there is typescript for that. It's a pain in this as to code in js...
The entire modern web stack is way too complicated and unusable lmao
People really see 1.5gb node_modules and go "ah yes, cutting-edge"
GTK looks like utter garbage on KDE, Windows and MacOS. Qt looks like garbage on GNOME and Windows. Flutter/Tauri are strictly better than Electron, but have the same issue of relying on a browser. There's no good crossplatform UI.
So basically it is fulfilling the promise of Java back in the 90's, that of letting companies -develop on the cheap by having one team developing for all platforms at the same time- write once, run everywhere. And it still feels as out of place on any desktop as most Java applications.
If anything the one reason I really dislike Electron is because it encourages a que será será attitude towards memory and execution time optimization.
write once, debug everywhere.
Not fulfilling it. Promising it anew, but with an even bulkier install. I'm not saying I wouldn't use it, but I've written many java desktop applications, and I find it a far more mature and workable solution.
To each their own though.
The electron is a subatomic particle whose electric charge is negative one elementary charge.
There's that as well 😅
Tragic
As a user and a developer I don't like electron, its too slow and bloated (Also makes XSS possible for desktop apps).
2:56, Are electron apps native to all systems? They still run on the V8 engine, or do they compile ahead of time?
3:10 Gtk and QT are cross platform, you can use them in windows and mac.
Its obvious why developers gravitate to electron, the web is the most popular platform to deliver apps, so focusing you effort on your web app and using minimal code to deliver a "desktop" version is efficient for developers.
From my experience most electron apps are just clients for a remote service (discord, slack, etc...), and most of them can live inside the sandbox of the browser. For these apps I just prefer PWAs (or even just a bookmark), since at least I won't have to run multiple instances of V8.
The problem is that some apps have exclusive features to the desktop version
Also, if you run web apps in your browser you can use extensions to block trackers or force dark mode.
@@talkysassis Which apps? Web first apps I use on the daily run perfectly on my browser (even stuff like Zoom).
@@narutrixil Teams have some features that came months earlier on desktop
@@talkysassis Oh, that sucks :\
electron needs to be shipped as a runtime and apps as packages, not full blown copies of chromium. that would solve many complaints against it.
This!! Electron is a perfect candidate to become a runtime. It's only when an app uses custom builds of chromium or node that some duplication would occur, but I'd guess that the vast majority of apps don't do so.
Java 2.0?
The reality is going in the reverse direction, unfortunately. Oracle is no longer shipping Java runtimes after version 8, instead they tell people to pack the runtime along with their app.
I feel like it'd be fine if Electron was bootstrapped by the installer as an included dependency. Like how many windows programs used to bundle .NET Framework 4 before windows started providing it. And also how old games used to include DirectX versions that they depend on in the installation. Technically it's a bit different from a runtime like Java but close enough. Even now multiple apps include redistributables as part of the install process and if it's already installed then no duplication occurs. I think the main reason why Java couldn't be included in the install process and had to be downloaded separately by the user was because of licensing issues, but I'm not sure so don't quote me on that. Electron as it's own redistributable package dependency thing would be perfect. But it'd need to be standardized by the electron maintainers and electron users.
4:52
it is way more difficult to figure out where javascript messes up, this was actually what caused a kde bug with the floating panel refactoring.
JS basically just runs your code (without checking if it's syntax is ok!!!!) and just keeps running it until it crashes and burns, returning some cryptic errors for a simple syntax error like a missing semi-colon or curly brace. (or even reading from a variable you never created (which was what caused the kde bug), yep before you ask JS is that stupid)
the creators of other scripting languages actually had a brain and implemented a system where it checks for basic errors BEFORE running the script.
this is why most people prefer typescript now days instead of js, the creator of typescript actually had a brain and made a pretty decent language
This is mostly wrong, of course JS checks your syntax. It just doesn't require semicolons, which is quite common in programming languages (Python, Kotlin etc). Curly braces in JS behave the same as in other languages. Here is the error Firefox gives for a missing curly brace (at parse time, not runtime):
"Uncaught SyntaxError: missing } in compound statement (debugger eval code:6:2)
note: { opened at line 1, column 7"
That's not cryptic at all and even tells you exactly where you opened it.
Can you link me to this bug? It won't just randomly read a variable that doesn't exist, unless you're using the old var syntax rather than let which does act a bit strangely and lets you read variables before they're declared.
I'm not saying JS is perfect, but this is just not true
@@circuit10 you can check Nicolo ve's channel its one of the more recent videos
And Firefox has a good js linter and whatnot, vanilla js's error checking is just really bad and I hate js for that typescript is what you should be using, because JavaScript doesn't even care if a variable is undefined it just doesn't say anything and dies
@@etaashmathamsetty7399 Oh, you mean JS returning undefined when a property doesn’t exist? True, that is annoying. I’m pretty sure the JS syntax checking is part of the language specification and should be consistent across browsers, though.
@@circuit10 good to know I usually just avoid JS these days so yeah
whotever you say I like JS😁
You just need more exp for JS
3:13 QT compiles nicely and the GUI in really close to native on Mac and Win. GTK took a bit longer to get there, but is pretty good with cross platform too
Gtk looks pretty horrible on other platforms then linux. And the whole point of electron is is to reuse their web skills for desktop apps. Considering that qt is c++ only and gtk is junky in languages other then C C++ python or rust
Don't get me wrong, i really don't like electron too but qt and gtk doesn't seem like a good alternative
@@ioneocla6577 or some things electron does work but I generally don't like it either. Gtk actually looks okay on Windows and not too bad on Mac, I think QT is generally a good compromise. I haven't use them, but there are Go & Rust bindings for QT
@@ioneocla6577 Qt has different bindings for different languages. It also has QML, which feels like Flutter with JS without the awful developer experience of CSS.
@@rkvkydqf Can you name some well maintained qt binding please ? Appart from pyQT maybe
@@ioneocla6577 ritual for Rust
I personally use Tauri. An Alternative to Electron that uses Webview instead of Chromium which makes it alot smaller and faster. It also uses Rust for the Backend giving it even more peformance!
Ya. Webview's JS is not really performant enough like V8 is. So Probably most won't bother switching.
@@akza0729 actually it is. Webview uses Chromium which is using V8 aswell ofc giving it the same if not more peformance because of how lightweight it is
@@notarandom7 Um. Nope.
Android Webview is Chromium.
Linux users Webkit Gtk or QtWebview both off which are fork of Apple's Webkit.
Mac uses Webkit same as Safari.
Windows should be using Edge and new Edge is basically a Chromium.
Edit: Remember. Tauri uses the OS's native Webview. It's doesn't ship a Chromium or browser parts.
@@akza0729 webkit is faster than V8. You can see that with the recently released js runtime called bun which can be 30x faster than Node and Deno
How about: link an actual benchmark?
Electron has serious screen reader accessibility prblems. Microsoft didn't start to clean up skypeforlinux until its second release using electron. Like javascript it's easy to write non-compliant code.
As a developer, yes. I love it.
As a Linux user, yes. I hate it.
It just screws up my full dark themed consistent desktop.
Yeah, the inconsistency is super frustrating
I am a developer and hate it, it's just bloatware.
I prefer using Tauri
@@VictorMartins239 as a developer who uses less 'c' nowadays, i love electron and make side project on it,while thrashing microsoft for making teams in electron while screen sharing
@@vaisakh_km I just can't like electron because of chromium. Have you tried Tauri?
I used to love web design until I discovered how terrible it is compared to native UI toolkits. The truth is that the web was built for fancy text pages, not full apps, which leads to the tools being less than ideal. GTK, Qt, and Android/iOS UI toolkit are much more productive to work with after you learn the basics. If you like it this way, it's fine, but just give QML or Rust+Gtk4 a try.
As a electron dev I hate electron so much is easy to use but is the literal bloat hell.
any docs or books would you recommend for electron?
I'm on Linux just one year, never into informatics, but somehow Linux made me got this new interest.... Channels like this one shows me how dense and multilayered is the infrastructure our lifestyle relies on.
Despite personally leaning more towards the user side of the argument, I like your nuanced stance on this sort of things.
The best way IMO to build Linux apps is to design your applications with loose coupling to begin with. From what I've heard about Adobe suite is that their software is tightly coupled with windows and Mac and will require significant work to port to Linux. Eric S Raymond has specified some of the best engineering practices followed on Linux in the book 'The Art of Unix Programming' which includes cross platform applications like GIMP and how they are designed.
Unfortunately it's not as clear cut as it may seem. Tight integrations allows software to use the system's features for optimization reasons. Abstractions can add overhead and incompatibility issues (i.e. one system may not support the feature of another).
Linux is especially difficult due to the distros having a different combinations of compositors, desktop environments, drivers, and more each with different levels of features and compatibility. Supporting that while providing high performance is not easy; in some cases impossible which results in inconsistencies.
@@dealloc Since I develop games for Windows and Linux in my day job, I got stuff to unpack based on experience. If you're planning abstractions right, the cost will be low, especially with languages like C++ and Rust. That's what senior software engineers are payed for, they work on software to keep them maintainable and performant.
From my experience of developing GUI softwares, desktop environments and compositors don't dictate the front end at all. It's the widget set that dictates aesthetic and application programmers don't interact with window managers or compositors. As about drivers, unless you customize your Linux kernel, they're standard across all distributions. The fragmentation isn't as bad as you're saying especially the parameters you've provided.
@@PixelTrik Photoshop and other Adobe applications are doing much more than just rendering a GUI.
@@dealloc Not sure how that defends your point.
@@dealloc least thing application programmer should care are drivers. What's next? Caring about GPU vendor?
Electron was the low-grade bread I used to serve business logic patties to people who didn't know how to use a fork or didn't want to get their hands dirty.
let's be honest, Linux is like 10x better than MAC OS AT GAMING. Years ago Linux couldnt even play a simple game now we can play AAA games. I'm happy
Oh yeah. Linux isn't far from Windows nowadays for gaming
@@TheLinuxEXP But we still have some problems.
We can't use OpenCL outside proprietary drivers (mesa team is working on that) and AMD only ships their drivers to RHEL and Ubuntu
Maybe SteamOS (when published) will create a real case to AMD publish the amdgpu-pro driver for all systems
@@talkysassis AMDGPU-PRO is meant for workstations not gaming devices. Don't expect it to be published for all systems.
@@cacodemon345 But what of I want to use my pc as workstation AND gaming?
I want to make some 3d models on blender and use my gpu to render but still want to play my games
@@talkysassis Honestly workstation machines do double as gaming as well but machines meant for gaming but not for workstation honestly are a poor choice to target professional drivers at.
Quite frustrating to see Discord, a very big and rich company slacking off at updating the Linux Discord app where its fixes are already upstream, so they don' t even have to bother doing much work!
Yeah, it's really annoying. Porting their patches to electron to a new version would take them a few weeks at most
@@TheLinuxEXP they can go open source and get free labor
@@TheLinuxEXP The worst part is when your package manager lags behind. Discord will then lock you out until you obtain the new version. There is no option to skip an update so you just have to wait for it or pull from somewhere else (i.e. Manjaro could pull from AUR) - Alternatively you could run discord inside your browser and never get locked out.
Electron could have gone the Java route by adding some sort of "virtual machine" that's native to the system and build apps from there (installing the VM when it's not yet installed). But instead, they're adding the whole Chromium engine to the app EVERY SINGLE TIME!. That's real bloat!
Because using system electron is too hard
There is also QT & QML where they allow html and js in their own engine. QT & QML is also used a lot in IOT devices.
I respect the Electron framework. Thanks to him we got a huge number of apps that we never thought it will be available on Linux. it's true that it has performance issues and all that but there is new frameworks like Tauri that hopefully can replace Electron one day. As a developer i understand why devs choose Web tech instead of native GUI toolkits cuz it's way easier thanks espacially to CSS that gives the dev the power to make awesome UI/Animations with less effort compared to Qt, GTK, Winui, ...
Qt is _designed_ to be cross-platform. While it still has the classic "write once, debug everywhere" problem, it's certainly lighter than an entire freaking Chrome instance.
Microsoft is working on minimizing that problem integrating WebView2 not only in Windows 11, but also in Windows 10 in 22H2. So all the Webapps could share a central, always asap updated instance of Chromium (Edge Version) instead of running each their own, like they also do on Android and in iOS (WebKit). What would mean a way less usage of space in RAM and on Disk/SSD. MacOS has something similar build in based on WebKit. Linux distributions should have no problem to deliver such an option as well. Hopefully the developers will adapt to this very soon.
It already exists with webkit-gtk on gnome/gtk based desktops and gt-webengine on kde/qt based desktops
@@ioneocla6577 Don't know if they work equally well, but cool if so.
Funny. Electron and Proton don't work well on Atom :)
As far as I understand, Electron is used mainly for proprietary software. In the free software world, it's considered good practice to develop software as little platform-specific as possible from the start. But even if the program is originally made only for Linux, thanks to the open source, someone will be able to port it to Windows if he needs it. A good example is the x11 screensaver. Its developer doesn't make builds for Windows (he hates Microsoft for personal reasons), but the Windows port still exists without any electrons.
And the plethora of lesser known apps? I'm sure that they also get plenty of developers just begging to go through the joys of writing a native looking GUI for their platform. And then when the bug reports come in, having to figure out in which project the problem actually lies. It's great fun, let me tell you.
I hope one day there will be an universal electron web view in every OS so the individual electron apps don't have to ship the whole browser
it already exists in linux, just the companies wont do that, if you just install packages like electron, electron13, electron16, all the electron apps can run in same chromium windows. The company does not do that but community does, example arch user repo has discord_arch_electron which uses system electron packages, but there is catch in that too, discord would use electron 13, but other electron apps need electron 16 and some even 17, so in that case too, you would be running three electron separate electron instances
@@imhemish to be honest there's a lot of room for improvement to be used as a runtime... that's probably why is not widely used.
Developers love it because tools we use are based on Electron, like VSCode and Obsidian.
oh Obsidian use Electron ? did not know that , thats cool
What I'd like to see happen, is for Electron to shift to a model where there only needs to be a single instance of the Electron runtime on a computer, and it's updated on it's own independent of the applications built with the runtime.
But that would mean developers should do what shitty developers can't: remember about package manager.
Love it or hate it, it's the best we get for cross platform desktop applications on Linux. Lets be fair, before electron the Linux desktop experience was not an actual experience.
It's frustrating when devs don't want to ship applications as PWAs when apps like Discord would run perfectly with it.
PWAs support on desktop is lame, you are limited to blink-based browsers and the integration is not great
I made many pwa, they just don't work that well yet, Firefox and Safari have dogshit implementation of pwa APIs, especially safari for obvious reasons (mehem, AppStore revenue). And even then, pwa lack the most important thing *access to the file system* the ability to write/read files is such an huge thing which is lacking in the pwa world, the best thing you can do is use indexeddb to save things, but then your user data relies on the browser wanting to clear your website data out of nowhere. And you still don't have access to file system
@@specy_ fyi, blink implements filesystem api but it sucks (there's no seeking or partial read/write)
@@knoopx yes I know of it, but it's VERY limited and VERY annoying to use, both for UX and developer experience, you get a huge popup saying that the website wants to access X folder everutime u open it, if they removed the warning for PWA then it would be nice
Is there a Firefox-based Electron alternative?
The solution should be simple really ... standardize and make electron backwards compatible and then open only one instance of electron with multiple windows ... like multiple browser windows on chromium; i.e., if it is already running, just add to it ... basically the same thing a web browser does, minus combining tabs into windows.
You've just described the System WebView, except it's not entirely standardized. MacOS uses Safari WebKit, Windows uses Microsoft Edge Chromium, and Linux is usually webkit2gtk.
Tauri already supports this, but as a developer it's fucking awful because the nightmarish hellscape of cross browser compatibility shows up.
Also, this wouldn't solve the RAM usage. Load up discord in a browser, that tab will be comparable in RAM usage to the actual native app. In my case, it only saved about 30 MB to use browser.
@@kingofgamesyamiyami6269 Hmm. But shouldn't this be more popular? Also, cross-browser compatibility problems - shouldn't they be same for electron and this then?
@@arkoprovo1996 electron ships the entire browser with the app. So your app is never relying on a different browser it's all the same.
@@kingofgamesyamiyami6269 Yes but that's why it wastes RAM ... like runs a new browser instance for every app essentially.
@@arkoprovo1996 No, that isn't why it wastes RAM. All modern browsers run separate instances of the browser engine per tab, so there is very little benefit to consolidating to a single browser.
yeah, I've had the distinct displeasure of programming in ajax. Where something is broken in you're app but since javascript is interpreted it doesn't know that part of the code is broken unless you use that part of the app. Which meant essentially any time you made a change you made a system-level change that affected every part, of the application you had to manually go to each part, the more complicated a javascript application gets to see a bug, the more you hate javascript. An experience like that makes you hate not just javascript, but interpreted languages, in general. It's why they invented typescript.
For resource efficiency, I want to see an Electron shared dependency so Electron is installed once if you have VS Code and Discord installed. To completely quell the complaint of memory usage, share Electron rendering/scripting processes between VS Code and Discord but that’s a security and stability horror story.
But that would mean developers should do what shitty developers fear to do: remember about user and package manager
I have a far different experience with electron regarding debugging versus C and the like. With something like GDB you can debug just as easily as js in the browser, but if the browser code was a compiler target (like if your application was written in typescript) then the debugging will be bound to said target code, not the source code. There are ways, but it's not as straight forward as you make it out to be compared to compiled languages.
Someone said electron is like Flash on desktop environment.
So, you could use an OSes native webview right instead? I like using html, css and javascript to make apps too, it's really convinient, but then to deploy an app with this you could use the built in webview on Windows etc... right? Am I wrong about this? Make a C++ .dll for handling files and displaying the webview, it's not that difficult.
Same, as long as it isn't the worst of all worlds like Discord. I can stomach flatpak, I can stomach electron. Just... at least make it function man. Doesn't have to even be the latest, but at least make it close enough that expected functions works, the bugs get fixed, and gets some of the performance improvements. You're lucky you only have 400MB RAM use but mine with all the betterdiscord plugin I use is at 900MB and that's just brutal man.
Yeah, if people at least made sure the integration was working well...
Discord is practically a joke. Because if it notices a new version and your package manager is a little behind, it will lock you out completely. Since there is no option to skip an update your stuck with an unusable version until it gets updated to a matching version,
With the "Segway to our sponsor" you should call yourself the Linus experiment
This is why I develop with C. Write once, compile anywhere. As long as I don't use weirdo libraries most platforms have the same basic functionality and layout and things just work. Also, even though I'm a KDE user, I still use GTK to write GUI's because it's written in C and it just works everywhere. I can't recall ever writing something that took up 100mb of space, for just the program itself anyway.
C varies vastly on different machines. I don't understand how you get the write once compile everywhere idea. You'd have to write gigabytes of macros for that to happen.
My computer graphics class had a lot of fun figuring out why the C code provided by the professor wasn't running.
Spoiler, the code was written by some galaxy intellect that actually used "long" as a type.
@@user-he4ef9br7z No, you don't. Just write to the standard and it'll work.
@@isodoubIet Clearly that's not what was wrong with the code as `long` is a valid type in C. But I don't think TH-cam will send you a notification from my response, and you won't have a clue what the real problem was anyway. At least based on our past interactions you don't seem to have a brain.
ms teams on linux are pracictly not usable. just becouse they use older version of electron, which dont's support screen sharing on wayland. and it's browser version works perfectly fine.
I use Electron for various projects, thought I'd share a few thoughts.
Memory usage is one of the low points of Electron. However, you can reduce it by writing memory efficient code and not creating additional processes. Electron has 1 main process and any number of renderer processes. As you increase renderer processes the usage goes up drastically. I'd assume that each process is something akin to a browser window in chrome. The less of them the better! I have all of my code in 1 process and use less than 200mb.
The other way to reduce it is to avoid carelessly installing npm modules. I've seen projects with far too many third party dependencies. If what you want is simple its far better to build it yourself. Many modules have their own dependencies and this results in each module using its own instance of another dependency. This is more of a module/npm problem but it bleeds into electron as well. You really don't want 4 versions of jquery running at the same time...
One extra method is to package your app properly. I made the mistake of not doing so because I thought it was solely to protect your source code (I was creating an open source app). While that is a goal of ASAR packaging the real benefit is it can cut load times down a ton. My app loads in abt 2 seconds now.
Electron is easy to work with but its also easy to build poorly designed apps. However, if you put the time into it you can likely meet the constraints of your project.
I quite not agree about the cross-platform argument. Nowadays almost every GUI framework is cross platform. Let's take Qt for instance, with C++, QML and QtQuick you can develop an app either for android/IOS, Windows, Linux, OSX quite easily. GTK nor wxWidget or god only knows what framework does almost the same, they're just not as user-friendly as Qt. I personaly think that Qt is the best alternative to electron. It is dead easy to use, you only have to know C++ basics, the documentation is great and you can make something up and running in like 20 minutes with 10x less RAM usage and CPU overhead. And on the top of that, almost everything in Qt/C++ has a cross platform way to be done, using Qt toolkit or C++ STL.
It's a real shame that Firefox abandoned PWAs and that it isn't promoted more in browsers that do support it. The vast majority of Electron apps would be perfectly fine as a PWA.
At this point, Chromium just needs to be a new SDI web browser which will open applications found in a repository on local filesystem, and all installing an app should do is add the web assets for that application.
I don't have anything against electron apps other than the fact that if I open one, my computer is already on the knees...
Not necessarily "developers" but companies have basically no reason to not use electron since it saves them money.
Not sure about the package size but flutter seems better than electron as of now, for these reasons:
1. It is backed up by google and also incorporates their material design
2. It is compiled so theoretically it should be faster and take up less space
3. It supports Windows, Linux, Mac, Android, and IOS. It can also turn your code into Web
4. It is based on Skia, google’s 2D rendering engine. I saw some benchmarks the other day and the speed was extremely close to the native apps
I’m sure flutter still has its own flaws but a lot of developers are actually leaning towards it
Flutter along which language?
@@riganburnwal1012 flutter is based on dart
@@OmK-st2kk Can't we use flutter along other languages too? I'm sorry if I sound dumb I'm just curious, I thought it's just an UI toolkit/framework.
@@riganburnwal1012 I have searched along this topic myself and there doesn’t seem to be a direct way of using flutter with any other language than dart.
The only approach is to create a rest API with the unsupported language and then call it in your dart code.
@@OmK-st2kk Got it, thanks buddy!
7:45 "we already have ___ for that" what's that word? Couldn't catch it.
libadwaita
I had the displeasure of developing for and of using Electron. On the development side you have a mess they call "main processor" and "secondary processor" that turns sharing data between windows a nightmare. Anything other than a Single-Page Application is awful, hell, horrible or insert your worse curse here to develop. At the user side, at least on Microsoft Teams for macOS we don't have a good support either: I work as an iOS developer at a tech consultancy, and we use Teams for basically everything at the work. Some days it simply refuses to ring my calls, to send my message notifications, just works when it wants, and now I'm using iOS 16 Beta, even in my iPhone it isn't working well (the iOS version was the only one I was able to use properly). So for me, it's just ugly, heavy and lazy.
MS Teams is by far the worst, most bloated, slow and outright painful program I've ever had the misfortune of using.
@@wallyhackenslacker totally agree with that. It’s hard to believe Teams and VS Code (which I really like) come from the same company.
Thanks for covering this. The theming is a massive one for me. For accessibility reasons, I _need_ a black theme (grey doesn't cut it.) And accent colours matter just as much.
My main complaint about Electron? It uses Chromium, which has Google’s handprints alllllll over it.
Chromium is an open source project, which is very different from the Chrome web browser.
@@smileychess Not really "very" different, no. It's still controlled and maintained by google.
@@isodoubIet - It’s very different in regards to most of the fears and complaints about Google’s data privacy practices. The code is auditable and scrutinized. Besides that, it’s a good browser (if you ignore its memory footprint).
10:28 That's the Flatpak version. The native packages take up 60-100MB.
Edit: You addressed this very poorly. GIMP takes up close to 400MB when installed as a flatpak, which is "only" half the size of Discord. Still high, but I feel the core problem is with Flatpak in this particular case.
No, because out of the 400 MB for flatpak, more than half is reusable runtime that other apps will also use ;)
@@TheLinuxEXP This is true. However, you're comparing Discord's "installed size" number (which includes all reusable runtimes) to GIMP's "installed size" number on a traditional package, which won't. The traditional package number is only for GIMP and some core libraries.
I don’t know why, but my favorite part of every video is hearing you say the phrase “a lot.”
13:47 Except that apps written using any of those GUI toolkits will run under any GUI.
Title implying that devs aren't people
On debugging
Developer who works in a permissive language: Let's write the code quickly so we can debug it
Developer who works in a strict language: Make sure to write the code correct by design (using language features), so we do not have to debug it
this was really informative, could you do one on flutter?
I could!
People hate it because there is literally no reason to render an entire web engine to make a multiplatform application when we already have tools that make multiplatform applications in a more efficient, safe way like java or c#.
Devs use it because JS developers are everywhere (around 60% of developers use JS if I remember correctly) and most are too lazy to learn new, better tools.
13:00 Actually no, JavaScript doesn't leak memory.
It's just that by default you create global variables with JavaScript, "var my_variable = 5; var my_variable = 5;" works and guess what happens if one of these two have a typo.
Heavily disagree on JS being easier to debug. Compiled languages force you to fix the little errors before they even run and, despite how good Chrome and Firefox devtools are, it's always better to get the errors directly in your IDE. Means you can go directly to the malformed syntax instead of hunting through your code in two different applications.
a native app almost always looks feels alot better while using alot less resources, it's just the way it is.
the one good thing i will say is that i can instead of using an electron app, at least just use it in my browser most of the time, which is a good mercy for stuff like discord.
and although i get your point, the proton comparison is not perfect cause using proton VS a native game is way less of a difference than a native app VS electron, proton is like 85-100+% of the performance (sometimes better than windows and/or the native port) with tons of nice features, vs electron which is a pretty sizable downgrade no matter which way you slice it.
Proton also has another benefit over Electron: _It only installs once._ Games don't come with their own Proton distribution; they just use a Proton installation that's already on the user's machine.
People don't realize some of their most favorite applications are written in Electron. Such as Discord, Guilded, Team, Slack, What's App, Telegram, Signal, etc. ALL Electron.
I don't think Electron is as hated as you're making it seem.
Discord is write with C++ Qt ;)
*Telegram sorry
Only exception I would point out here is VS Code - yes it's an Electron app, but it still performs so good! (And of course, it's full of nice developer conviniences 🙂)
I disagree, ridiculous performance for what it does.
There's already a electron alternative which lets you write a backend in rust and you can use any JS framework on the frontend, it's called tauri, also the bundle is much smaller and it's much faster, it opens almost instantanously, and also it's a lot safer.
I have to be radically honest… I don’t care what an application is built with. I care about what it feels like and if it solves my problem. VS Code is the best non-commandline-editor in my book and I have wasted a thought about it being built with Electron while it was helping me finish an assignment.
Edit: and yes it sucks that some companies that distribute 3rd class products to lesser used platforms. But the thing is … why would the spend equal time on a lesser used version of their product when it’s not part of their vision?
@@Kuznet609 and I am very happy for the people that use it.
I actually don't hate electron.
I hate when developers use 5 year old versions (I'm looking at you, Discord!) that doesn't support modern Linux features like Wayland.
I never liked Electrons, they are so NEGATIVE 🤣
🤣
Guilty as charged. No matter what spin you put on it.
Proton should fix that..
qt is not only for linux, specifically developed to work on all operating systems. a simple google search gives you that
"cross platform" "devs can focus on making new features and improving the app"
Discord screen share audio on Linux: Hold my beer
As being a developer who uses electron, I think the new alternatives like tauri are getting better and better, so I think the future is bright both for devs and users
Tauri is same electron and has same problems.
Why not just write the app in Python+Qt and then you deploy to Linux, Mac and Windows? You don’t need Electron for easy cross-platform development.
From my experience
Most Electron devs don't know anything outside JS
Some guys that work close to me (not on the same company) don't even know what an interpreter is
@@talkysassis That would explain the terrible quality of so many Electron apps.
Because of Qt license
Free version has a GPL license
Not many people like gpl
@@amirrezai9612 LGPL
My biggest issue with Electron is the fact that I don't need another browser. Browsers generally work best when managed by a single instance, so I'm not a fan of Electron apps launching completely new instances of Chromium completely disconnected from the browser I'm already running. This has a very simple solution: _use the user's existing browser!_ Python apps usually expect users to have Python installed. Java apps usually expect users to have Java installed. As a result, they don't need to package the runtime environment with them. Just do with Python and Java already do. In fact, _this is already possible!_ They're called Progressive Web Apps. You install them through the browser itself, and when you open them they appear just like a standalone app, except that they use the browser that you installed them through.
mostly true, except JS debugging is in no way special; this is available in more or less identical form for every serious build system and language.
Big problem with all Electron apps is the bug that causes the display to "melt" on many screens. Takes a while to search for solution (turn off FXAA, either generally or for each app).
Problems go years back and apparently have never been fixed.
Inexpensive way to distribute multi-platform apps when companies like Discord can't be bothered to find other solutions.
It's mostly corporations that like it rather than developers, most enthusiast devs will usually just develop for their preferred platform but for corporations being able to basically make a single website and then port it as an app to every platform out there is a massive time and money saving. There aren't so many foss apps that use electron, I mean there are some (like Joplin) but they're by far a minority.
And like you said, they're so greedy and lazy they take it to the extreme and don't even bother updating the electron base, resulting in a total mess.
Flatpack version of Gnome Boxes does NOT support usb ports within the vm. Not sure if it's the same as mentioned in this video (as I have no clue about the technical things) but it sucks
If you need to create software that interfaces directly with the kernel or low-level system components like Blender does, Electron alone may not be the best choice. You may need integration Native Node.js Modules: Creating native Node.js modules using C/C++ bindings to access low-level functionality and then integrating them into your Electron application.
If it's all websites, would it be possible to extract the contents and run electron apps on Firefox or whatever is your engine of choice?
Electron (chromium) is good at rendering text boxes with a lot of text.
Most GTK text editors (gedit, pluma, xed, bluefish) just halt or have graphics bugs when scroll down (like black background) when displaying big text files.
Only GTK text editor that I know and can display big text files is CudaText (replace feature is slow tho).
Notepad++ and wine's notepad.exe running though wine are way better than gedit.
VSCodium was less laggy displaying large js file than gedit.
hahaha accurate messed up reality check. proof that native gui apps don't necessarily perform better. proof that runtimes don't necessarily add too much overhead. proof that is technically possible to have a better electron ecosystem.
@@knoopxelectron still has very much unused stuff loaded into ram like balenaEtcher doesn't need stuff like webgl, video decoders, MathML, WebRTC...
This highlights another issue, lack of good cross-platform UI frameworks
What would be cool is if you had multiple electron apps running on one system, it would use the same Chromium pool to save memory while running many electron apps.
Another thing that would be cool is if you could take any website and turn it into an electron app (I'd love to do this with my web games)
You can debug all popular languages line by line? You can also use portable UI libraries that don't use browsers.
Isn't it possible to recognize within the electron app to recognize if it's running on windows/mac/Linux and passed on that recognition change which css (look/style) to use?
The obvious answer is to take a page out of Flatpak's book: have the browser part of the app be shared by multiple apps (as long as they use the same browser version), in order to save space both in RAM and on disk.
I agree that having an Electron app than not having that app is much better. It might not be lightweight, but it works most of them time.
Some of the equipment I service has the user interface running in a chrome browser (Opera). I suppose this is using Electron?
So ,in theory, I could run the UI in Linux rather than having to boot Windows and having to put up with the itchiness and multiple showers afterwards?
I suspect the German developers for the equipment do all their work on Linux systems as the equipment itself is running embedded Ubuntu.
Nobody seems to have mentioned native Qt C++ apps (Qt being cross platform) or Qt + WebAssembly. Here you get a consistent UI and a single app that works on every platform.