Honest question, when solutions like https://github.com/tauri-apps/tauri exist out there that promise smaller build sizes and similar developer experiences, are folks still using Electron to build new apps?
I’ll reply to your question with a question: once VSCode has proved one could build hyperscale complex apps that perform well, would you be fast to bet for less proven tech?
I’ve had a great experience using VSCode on occasion (I’m a JetBrains guy), and loads of other people, including some great programmers, rave about it. I’ve similarly had a fairly solid experience with Spotify desktop across different platforms.
I’m asking genuinely, is it such a subpar choice when there’s such proven success cases?
I don't think you realize how slow those are, how slow they make your entire machine (eating the RAM for no good reason) and how insanely fast similar apps could be if written in something that doesn't involve massive bloat.
Electron is also how Microsoft essentially broke Skype (on purpose?) IMO.
For me Electron just stands for lazy companies/devs who are not interested in producing something elegant that runs as fast as possible.
> I don't think you realize how slow those are, how slow they make your entire machine (eating the RAM for no good reason)
You're on a forum full of software developers, I think you can give us credit for knowing exactly how much resources the apps we use take up.
Personally, I frequently run VSCode, Slack, Zoom, Chrome, and occasionally Loom at the same time on a machine with 8gb ram and it's fine. Until one of these new platforms like Tauri or Socket.sh catches up, the trade off for developers being able to develop once and run on multiple platforms is entirely understandable and clearly acceptable to most people.
Cool. I'm a single developer releasing software for free which is only made possible by Electron and wouldn't exist without it but I guess I'm just lazy.
Honest question: where does all the RAM go? If a chrome tab eats about 200 MB ram, shouldn’t an electron app consume about the same? After all Electron is just an SPA with all the assets packaged with the browser engine. Like the zip’d web archives of yore
Chrome engine is build for browsing the web multiple windows multiple tabs etc.
If you drive with a empty truck with trailer it uses more oil than a car.
Chrome is not designed for this. There are other engines like https://sciter.com that are work for single apps, but probably scale bad if they are misused as a browser.
I just opened Chrome to a news website and got 400MB of usage on the "GPU Process", 150MB on the "tab" process, and 100MB on the "browser" process. In Electron the webpage doesn't have access to native APIs like the system tray, so that's done by exchanging messages with an extra process.
The ones of these I've actually used like Slack are doggie doo. Aside from using way more resources than a chat app should, last I checked basic UX was not close to on par with native, like right mouse clicks didn't do anything but bring up the built in browser menus.
I don't mind using an Electron app. The problem is, they are multiplying too fast. I currently use: 1Password, VS Code, Discord and / or Element, Obsidian, and Postman. They use most of the machine's resources doing nothing at all.
You can also see the pains the Evernote team took from the initial Electron-based 10 release until it became usable again. But you could also feel the product moving again after stagnation on a gazillion native clients. It was the right albeit mostly final engineering decision they took.
"Powers" being a relevant word here. People love to call out various tech/choices for needlessly sending our energy into a black hole, has anyone run the numbers for Electron's negative impact versus a non-wasteful solution?
> VSCode has proved one could build hyperscale complex apps that perform well
did it though? It might perform "good enough", but its still an order of magnitude worse than native solutions. the only reason to ever use Electron or similar is for rapid prototyping. once you have an MVP, you should immediately work towards a native solution. people seem to forget that part, out of laziness or ignorance.
I use VS Code daily and I have never had performance issues. That obviously doesn’t apply to all folks.
Also, it seems presumptuous to prescribe what appropriate solutions are for all people of all time. There are many, many places where an electronjs would be just fine.
> Also, it seems presumptuous to prescribe what appropriate solutions are for all people of all time. There are many, many places where an electronjs would be just fine.
And many where it wouldn't. It seems more presumptuous to me to demand that users have machines with that much memory and CPU to spare.
You have to define ‘worse’ because raw performance isn’t really everything and vscode’s popularity proves it.
Feature set and extensibility have clearly won here. At a certain performance point, it’s good enough and what you can do with it matters more.
I’m not sure you could achieve the sane flexibility in a more native, “bare-metal”, development environment. Possible, yes, but it would probably not be as successful as developing for it would be somewhat harder.
Vscode is “fast” enough. Its extensibility and its ecosystem are what makes it so popular and successful.
I’m not sure you can build the same without trade offs.
> once you have an MVP, you should immediately work towards a native solution.
All of the chat apps that worked towards a native solution have died. Most of the other apps too, but all of the chat apps. Going native, despite being satisfying for the user, carries a maximum cost in terms of internal organization (several departments in the company for each target OS), HR (developers that can’t be recycled in other departments), marketing: “Wait, does HipChat MacOS has the same features as HipChat-on-the-mac-but-in-browser? Wait it doesn’t matter, HipChat is dead.”
Telegram, which is easily the best chat app by software quality, has native apps on all platforms (well, QT on desktop, but that’s close enough). iMessage is native as well, and widely used, though it has admittedly fewer target devices. Those are the two I use daily, so I definitely don’t live in your Electron world, and I’m happy for it.
They do have a native solution you might be familiar with, "Visual Studio". It took them a solid decade to port it even from 32->64 bit (finally released last year). Hard to blame them for some institutional PTSD around the whole idea of native apps.
- Not everyone wants to learn Rust but want to use the same language throughout their stack
- Tauri is still new which means it is not considered "tried and true"
- More developers know how to use Electron or at least know enough Javascript to learn which means larger talent pool = cheaper and easier to replace developers if need be
- Last I checked (was not recently I admit), the build time for Tauri was abysmal
- I would argue very few gives a damn about smaller build sizes unless the problem space actually requires size to matter
In short, Electron is established tech and "good enough" while Tauri is the new kid in the block. It takes time for it to carve a space for itself. With all the Rust hype going on, I don't doubt it will happen.
Fun fact: I actually embarked on a project recently where my plan is to build the app in Electron first and once I had a change to learn Rust, I'll probably try to migrate the Electron app to something like Tauri.
A reason to keep using Electron rather than Tauri is when you need to make sure the UI is going to be displayed the same way on each platform.
Tauri uses the OS's native webview which means that there can be differences in how the DOM is displayed. It's not the same browser engine being used for each platform.
One problem with Tauri is that it doesn't bundle Node runtime, meaning that you can't take advantage of the npm packages that works outside of a browser environment. It does allow you to use Rust packages, but that's another story than Javascript.
Yes. As a user, I’m rooting for Tauri, but as a developer, I could probably build my app faster using Electron. Unfortunately, past experience tells me that companies usually optimize for ease of development instead of performance, most of the time :(
It was just open sourced, if your pointing out how few stars it has. It also hasn't been officially announced. But HTML, CSS, and JS are far less niche than Rust.
Electron is very well known & has a large footprint - lots of existing tutorials, extensions/plugins/libraries, regular bug fixes. There are also lots of existing large Apps that can serve as reference. If you Google - building cross-platform desktop Apps, most of the results will point to electron.
If you already know JavaScript (lots of people do) & are trying to quickly get your App up & running, then it can make sense to just go with Electron rather than trying to learn a new language like Rust.
Yes, Electron Apps are big but in the grand scheme of things, they might not matter so much for now (laptops are being built with bigger memories, Apps are being improved to manage memory).
It's not really the same developer experience. Because it's a browser JS engine it's much less powerful than electron, and you need to write more rust as a result. For many people that's probably not a demerit but for others it will be.
There is something to be said for a unified frontend and backend that closely mirror the existing browser API just extended. It comes with it's downsides too, where Tauri obviously shines, but really I see Tauri and Electron as two different approaches not direct competition. Last I checked Rust was still the only native backend too, that changing may help its story. Of course there is always the ecosystem size difference too but that normally sorts itself out with time.
I tried using Tauri (about 6 months ago, so things maybe have improved), and found lots of inconsistencies and issues between platforms. It did work well on my "dev platform", but then things often misbehaved on other platforms.
I'm not sure many people are refusing electron apps due to the size, but they would definitely reject a buggy app that didn't work on their platform.
Unfortunately despite Tauri being very performant, small, and having good UX it looks like most projects are still using Electron. I've built a prime number calculator which draws a graph in the webview using Tauri [0], this has was part of a series of projects of mine that calculated prime numbers and displayed them to compare performance of browsers and backend languages. The application does all the calculation in Rust and I got to say I will never ever go back to even considering Electron again.
I believe the reason why people look to still be using Electron is simillar to why people use React. Sure it's a bit bloated, a bit hard to master, it has some design flaws, but it's well adopted, and hundreds of successful companies use it in production. Meanwhile Tauri is rust the new kid in the block.
Tauri and similar are only as good as the webviews on the system. My trials with webview based alternatives showed they use slightly less ram as electron at startup, but later use more memory and perform worse in FPS. (Linux)
Not really seeing an advantage other than a smaller binary.
Using fzf to power ^R (reverse history search) is such a huge productivity win. Also it has the side effect of showing you the last 10 commands without any other config or setup.
By default that doesn't seem to pay attention to the current directory or the directories commands were run in. Is that a configuration option or something?
No but it would be very straightforward to do something like what the OP does, and then instead of using tail you just pipe the grep result for PWD into fzf. Which has some advantages: all commands instead of last n, plus of course the killer feature which is fuzzy matching.
Thank you! Our backend server is an Elixir (Phoenix) server. It has a separate Elixir process for every current live room, we store all state in Redis. So in case we do a rolling deploy we won't drop any connections and continue where we stopped.
The server is mostly responsible for keeping all room state (the editors, the owner, operations per module) and transforming operations. When an operation comes in at the server, like an insertion, the server will check what revision that operation is at and transform it accordingly if the sent operation is based on outdated code. Then that operation will be broadcasted to the clients and again transformed on the clients to handle any inconsistency.
The library we use for doing the transformations is called ot_ex.
I hope this quick view is clearly written, let me know if there are any other questions!
Congrats on shipping something so awesome in so little time!
Also thanks for this writeup. You recently migrated your servers to Kubernetes, right? What learning resources would you recommend for deploying a Phoenix app to k8?
If it is too time consuming to answer my questions, don't worry. The most important part of this message is thank you for building codesandbox. It makes the web a better place.
I learned most from the official Kubernetes tutorials (https://kubernetes.io/docs/tutorials/). I also used mix_docker (https://github.com/Recruitee/mix_docker) as a reference on how to build the image. The advantage of Kubernetes is that you can have the same way to deploy for all servers, so if you learn how Kubernetes deploys you automatically know how to deploy Phoenix applications.
reply