no, having 8 gigs of RAM doesn't change my policy on web / Electron apps.

which is: screw Electron.

note: i will not be taking suggestions about Electron in the replies. i've heard every Electron apologist argument.

· brutaldon · 9 · 15 · 35

@grainloom 8gb of RAM, that's at least 1.5 electron apps runnings at once.

@grainloom I have 32 gigabytes of RAM on my desktop and Electron can go eat a brick:
- It's a binary of chromium that doesn't works on my main install (probably missing librairies)
- Getting logs as to why it doesn't works looks painful as fuck
- It's a complete waste of storage, RAM, CPU, bandwidth, …
- I already have a web browser, I don't need yours
- Programs written in it are likely not going to last in even short-term
@lanodan @grainloom while I agree with this mostly, there is at least 1 example of a really well-thought, well-working app that doesn't frustrate users. And, surprise, it's from Microsoft - It's VSC.
On the other hand if you are about to write an app and consider Electron - forget about it, for god's sake
@roman @grainloom Maybe VS Code is great but it doesn't need Electron and one thing that I quite like with vi-derived or even emacs is that it's very fast.
@lanodan @grainloom unfortunately neither (n)vim nor emacs are really fast enough (with all the plugins you need to work, we're not talking plain installations, right?) to cover the difference. And I still have most of vim stuff in there, along with full-featured ElixirLS :)
And the reason why they initially started using Electron is because it was based on Monaco iirc, which was a web-editor. Of course I'd vote for native rather than electron, but I don't think that is coming anytime soon since that will essentially mean dropping cross-platform support and need to significantly increase the team to bring it back.
@roman @grainloom Why would you drop cross-platform? Qt for example supports more platforms than Electron.

And by fast I meant response-time, like typing text or loading a file.
Sure stuff like plugins are going to be faster than to the huge optimisations on V8 but in my experience they're rarely needed and could be done with tools provided by the language (like renaming variables in Go is really nice). And an appropriate code-style.
And If we really need plugins for a language maybe it's time to consider it a blob.
@lanodan @grainloom I was talking about writing native apps, not another multi-platform wrapper (that also sucks in it's own ways) - only that would make significant change imo.
and plugins: ElixirLS is the best example of what I want, but in Vim I could only get parts of it (like poor code completion via ctags) for double the price of performance. Btw, Go plugin in VSC is something I was absolutely amazed by, though never worked with Go from Vim and never worked with Go for serious at all.
@roman @grainloom Well I hope they're going to enjoy debugging chromium if VS Code doesn't works anymore, I stopped using IDEs here because they tend to be a single-point of failure with almost no proper recovery/fallback, or just a pain when using multiple devices.

@roman @lanodan @grainloom I used to run a cluster that served an entire university on a smaller system than what electron in vscode consumes. It’s highly optimised massive bloatware let’s not kid ourselves the emperor has no clothes.

@lanodan @grainloom Same for me. With 32 GB of RAM it's sometimes possible to use Electron applications, but "being able to use" an application should not be something to celebrate.

@loke @grainloom Well ram of not I can't launch any electron app and I have no idea why, just some guesses.
An application should report it's errors, that's the absolute minimum.

@grainloom what would a sane Electron-like environment look like?

@kragen @grainloom A sane app is developed in C/++, Ada, Java, or any other reasonable language of choice (not j/s), and it possibly uses something #cURL bindings to connect to the web-based service.

As a C++ dev, I take umbrage on it being called reasonable. There is a reason GNOME has #Vala (it must have been a difficult choice to maintain a language too).

#D ? now an official part of GCC (and an unofficial part for ages before that).

#OCaml ?

#CommonLisp ? Shipping the compiler with the app doesn't seem onerous compared to putting up with Electron.

@kragen @grainloom

Common Lisp programmer here.

Shipping the compiler with the app doesn't seem onerous compared to putting up with Electron.

@wyatwerp "The compiler" makes it often sound like it's something huge. On Steel Bank Common Lisp, it weighs several megabytes of disk space and up to twenty megabytes or so of RAM when uncompressed; if an application does not use the compiler at all, it can be easily swapped out to hard disk by the OS.

@aktivismoEstasMiaLuo @grainloom @kragen


Common Lisp fan here. I didn't intend to make SBCL packaging look like overhead, rather point out that its relatively small and quite justifiable overhead is complained about by the bog-standard dev while Electron has acceptance.

BTW, how does one get over paran-phobia if years of Emacs hasn't done the job? Also lack of pattern-matching (on values, not just types).

@aktivismoEstasMiaLuo @grainloom @kragen

@wyatwerp Agreed. Almost everything is small and bloat-free compared to Electron. Including SBCL.

I just recently blogged about parentheses! See

@aktivismoEstasMiaLuo @grainloom @kragen

@phoe @kragen @grainloom @wyatwerp #Ada with AWS would surely yield something lean, performant, and the code would be readable. Although I say that w/out having tried AWS.

@phoe @wyatwerp @grainloom @kragen @phoe We neglected to stress the importance of finding a good HTML parser. Most HTML is non-compliant garbage, which makes it very difficult to produce a usable HTML parser. If you find a good parser & build the app around that, you're ahead of the game. Electron probably spares developers of that need.

@kragen @grainloom @wyatwerp @phoe So, does anyone know of a forgiving #HTML parser library which creates a structure that can be easily queried w/an XPATH-like input? I've used the html parser lib for Tcl & I can say that's not it (it just dumps you in a callback for each tag).

@phoe @grainloom @kragen @aktivismoEstasMiaLuo @wyatwerp #movim user spotted!

I went back the other day to check my Movim account, but all my stuff (not a whole lot) was gone, probably due to ~2 years of inactivity.

@wyatwerp @aktivismoEstasMiaLuo @phoe @kragen idk about CL, but Scheme can match on builtin types.
in Guile it's the (ice-9 match) module.
but i do miss having proper algebraic data types and pattern matching for everything.

@grainloom Whence the question of matching on types? Common Lisp has a TYPECASE, too, but I don't know if that's relevant in the current context.

@wyatwerp @aktivismoEstasMiaLuo @kragen

@phoe @wyatwerp @aktivismoEstasMiaLuo @kragen i mean, it can match values of the builtin types.
maybe it can match more, but i'm a noob and don't know much more.

@grainloom @phoe

Erlang pattern-matching is very seductive (apart from its platform properties). That is what I feel I would miss in Common Lisp if I got used to the parantheses. Not thinking of anything near OCaml-like type handling, and not in a dynamic language with multiple dispatch.

@aktivismoEstasMiaLuo @kragen

@wyatwerp Trivia and Optima, the CL pattern-matching libraries, should work well if you decide to take a dive into Lisp.

@aktivismoEstasMiaLuo @grainloom @kragen

@wyatwerp @kragen @aktivismoEstasMiaLuo @grainloom @phoe How different is CLOS pattern matching from Erlang pattern matching? I don't know either by heart, so I don't know.

I don't know much. The basic little feature I was talking about was Erlang's overloaded definitions of a function where the overloads can have the same type-level function signature if they match different constant values.

@grainloom @aktivismoEstasMiaLuo @kragen @phoe

@wyatwerp Correct, Erlang is capable of having functions with the same name but different arity, e.g. foo/1, foo/2, foo/3, foo/5, foo/8, et cetera. Common Lisp cannot easily achieve the same.

@aktivismoEstasMiaLuo @grainloom @clacke @kragen


What I was saying was that Erlang goes further. Say, where 2 definitions have the same type signature (arity and types), but with different value constraints.

Anyway, this is far off-topic already, without even mentioning Erlang's concurrency handling.

@aktivismoEstasMiaLuo @grainloom @clacke @kragen
@wyatwerp @grainloom @kragen @aktivismoEstasMiaLuo @phoe Ah. Yeah, CLOS doesn't do variadic, and while it does specialize on values with the eql form, I don't think it does ranges.

@clacke @grainloom @phoe @wyatwerp @aktivismoEstasMiaLuo I think a big part of what Electron contributes is being able to write DHTML for your GUI rather than the clumsier, less composable toolkits like GTK+ and wxWindows and Tk and fltk. I'd say "and Qt" but now Qt has adopted HTML. But HTML still leaves a LOT to be desired, and the DOM is a shitshow. It's just less bad than the alternatives. What would a *better* alternative look like?

@clacke @grainloom @phoe @wyatwerp @aktivismoEstasMiaLuo I mean having a good programming language like Erlang or CL or JS is nice, but by itself it doesn't solve the problems of user interface toolkit design. It might make them a little easier.


Stand-alone JS engines were going in an encouraging direction, towards a "system DOM" like with node.js seems to have subverted that (so easy to drop protocols for API"s).

A GUI DOM may not be a bad idea if the HTML way has appeal.

@clacke @grainloom @phoe @aktivismoEstasMiaLuo

@clacke @grainloom @phoe @wyatwerp @aktivismoEstasMiaLuo Erlang pattern matching is more or less the kind of pattern matching you have in Prolog or ML; CLOS's dispatch is not really similar. But I haven't tried Trivia or Optima, so I don't know what their capabilities are. You *can* build the same capabilities in CL with defmacro.

@kragen maybe something built around a browser engine like Netsurf's.
no JS, just C bindings, usable from any language.


That's an idea. Does netsurf have capable layout of elements?

Another way might be SVG? Embedding librsvg into Common Lisp or Erlang?


@grainloom in case the facepalm above is too subtle, I'm all with you on rejecting Electron

@steko @grainloom

> Electron is gaining adoption by new and established startups alike

If you're "established", are you a "startup"?

I guess github considered themself a startup until MD bought the VCs out, but for how many years can you be starting up, really? As long as you're not making profit?

griping about Electron 

re: griping about Electron 

re: griping about Electron 

While one app bringing entire browser with it might be tolerable, if everyone start using it even 128Gb won't be enough.


Electron is shit. Every package contains a full web browser copy, which is very heavy (because of Chrome).

Unlike libraries such as Sciter, which are only for UI, not for full logic, Electron uses Javascript for everything, which causes memory leaks and high memory consumption.

So fuck Electron.

Sorry for my shitty English.

@grainloom I have 32Gb of RAM on my new PC, but I support you with all my limbs! :)))

@Revertron @grainloom yes, it's completely ok to use resources to actually do something, and it's terribly wrong to use resources for.... just use it.
Sign in to participate in the conversation

cybrespace: the social hub of the information superhighway jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal support us on patreon or liberapay!