Hacker News Reader

Look, I love Qt; I worked with it a ton, I contributed back to it, I even still work on LXQt sometimes.

But the rise of web apps, and Electron along with it, have turned the Linux desktop from a "you need to dual boot or use wine" machine into one where all my tools and apps are Linux compatible and have feature parity with Windows and macOS.

I also wish Qt would see more use, I also wish more people would write desktop apps using desktop frameworks when it's meant to be a desktop app, and I really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies. But truth be told, I'm happy to live in a world where I can do 100% of what I do on Linux without feeling like a second class citizen.

I think the "Web on desktop" paradigm is the future, even if it's currently a bleak one. Ten years ago, it was becoming pretty clear that Javascript would be the future, and at the time that was a bleak prospect -- but tooling improved and today, things like Typescript, React, the plethora of incredible development tooling and excellent cross-platform compatibility have turned what used to be bleak into an excellent environment.

There's a lot of improvements that can happen with Electron, if rather than fight it we actually embrace it. Running 10 different web browser engines for 10 different apps may be silly, but what if Electron was global to the desktop instead of included in every fat app?

You'll note that Google has been dipping their toe in that water for years with ChromeOS; Mozilla also tried their version of it with FirefoxOS, which failed for a plethora of reasons that don't undermine the concept at its core.

Basically, JS on the desktop is in the same uncanny valley as it was on the web a decade ago. It's ugly, slow, overwhelming and changing too fast. But there's an end goal there, which doesn't have to suck.

The thing is, with the desktop Web in the end what we get is ChromeOS, a browser window manager that makes the actual kernel completely irrelevant.

The adoration of Electron apps among Linux users will be the final nail on the year of desktop Linux.

> “really wish people would start writing tiny CLI apps in nodejs and include 70 dependencies”

did you mean /s/start/stop/ above?

Uh, yeah. People have definitely started.

"Web on desktop" Reminds me of Win98 and how Microsoft tried to push that back then. It's just a bad security model. Technologies were different, but the security implications that lead to exploits stayed the same.

theres very litle reason today to make an electron app instead of a web app. especially if its just a client.

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream.

There really is no competition and any claim to the contrary would need to offer more than a cross platform desktop app.

Electron is not really fast, nor does it generate great GUIs. It's much younger than Qt, only four years old. It's not frequently updated, it uses an insecure version of the Chromium browser. So... not all positives can be applied.

In fact none can be applied except ease of use and it's about the same, until the app grows and one realizes that the typical JS architecture is as easy to structure as a pile of mush.

Electron supporters are really taking the piss in this thread. Slapping together a bunch of statements which can be easily disproved doesn't qualify as an argument.

I absolutely disagree with all of your statements and think they are equally unjustified.

You have your unshakable opinions and I’ll leave you alone with them.

It's not a developers dream if that developer loathes Javascript, like I do. Even Typescript just feels like lipstick on a pig.

There are many viable compile-to-js languages out there to pick from:

* clojurescript

* f# via fable

* c# via different means(even an MSIL compiler)

* Golang

* etc

I mean, clojurescript and F# are bomber if you want functional. Typescript may give the best interop with existing packages, but I've read good things about F#'s .d.ts file support for creating type providers. In any case, if the lang you pick creates a bit of extra work that's probably small beans compared to the work required to get all of what parent described with completely separate languages and platforms.

Adding Reason(which is Ocaml with bucklescript backend) and Purescript to the list.

Adding this[0] list of languages that compile to JavaScript to the list. There seem so many that no matter your taste in syntactical sugar there should be something for you.

[0] https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

Would like to clarify that it's not about "syntactical sugar" more like different semantics and/or safety(they treat js as machine code), hardly anyone would claim they are using these languages because of js syntax.

f# is the future

As clearly evidenced by how hard MS has been working to bring C# up to par these last few years :)

Naturally there are limits to how well you can retrofit something into a language compared to having that feature there from the start...

And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI?

Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.

It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.

> It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.

You might wanna read that back to yourself. Now replace it with any language you hate, and then tell me how that statement makes any form of argument at all (it doesn't...).

"It is all a matter of actually knowing how to write proper JavaScript, or just using TypeScript to compile code that looks like JavaScript."

Sure, you can hate a programming language. It changes absolutely nothing, except your potential revenue streams.

It's like saying "I loathe Linux!!" and knowing nothing about it; sure, but in this industry, you're going to have a tough time :)

To be fair, JavaScript hardly deserves being compared to Linux. People don't loathe JavaScript for no reason. The language itself is pretty rough around the edges.

Not just the edges!

I not a fan of javascript either, although I write js almost evey day and use Atom mainly because I could not find a better open source desktop editor that looks and works like Sublime Text. If anyone cares to write one in C++, D, Rust or Go, I'll happily use it.

> I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers

Look, let's not kid ourselves, we all hate JavaScript like it's the plague, but no other framework comes even close to the ease of CSS/HTML and a drop of JavaScript for interactivity (transpiled from a sensible language), when it comes to GUI development. It's such a fucking embarrassment working with Gtk, Qt, Tk whatever have you, it's not even funny. Even native mobile dev (Swift/Java) is easier through a web interface, because nobody wants to have to remember that you had to "drag click from here to your source code" or "add this to your xml file to make it accessible".

Honestly, Electron is a shitty resource hog, but it is a trillion miles better than what the current offerings are.

I'm really surprised we haven't seen the functional style of elm, react and friends backported into modern gui frameworks. A react-like framework for native apps written entirely in swift would be killer - swift is a much better language than JS, and the resulting apps would be much smaller and snappier than what we get with electron or react native.

C#/F# would be a great candidate for this kind of thing too.

Qt QML is JS with a declarative UI language and C++ when you need it.

On the other hand you have JS with a document markup language combined with style sheets.

And the first one is embarassing you say. And declaring UIs in HTML and CSS is easier than in QML.

Why do you even post this. I mean... it's trivial to disprove it. Do you subscribe to the idea that if one makes enough noise their arguments will win out?

>the ease of CSS/HTML

Is this a joke? I can't use either of those for more than 5 minutes without wanting to commit self-harm.

welcome to the history loop!

it is a very known fact for all unix grey beards (insert more inclusive analogy if you can think any) that containers and fat binaries lead to way more code rot than anything else. and consequently more bugs and security bugs.

I blame this fad coming back on apple. linux and even Microsoft were happy with shared libraries, until osx adopted the bait and switch tactics of Microsoft and got the whole industry by playing the "but I am unix" tune. and with it the whole (webdev) industry was back to fat binaries.

then people started to realize they dont have to find out the source code to patch that old application just because they have to patch openssl or something. they can just release an entire image! and they have no idea they will make it even harder to have a legacy build when that other openssl bug hit. but for now, everyone can be agile and live serverless! and users now have to update the OS, the few shared libraries, and every and each one of their fat binary applications and container images!

good luck with that

> a very known fact for all unix grey beards

The co-inventor of Unix, Ken Thompson, and the Unix team engineer and author of The Unix Programming Environment, Rob Pike, are both big advocates of static linking. They designed Go and made a big point of emphasising static linking. Pike: "Shared libraries are obviously a good idea until you've actually used them. Whether it's obvious or not that they're a bad idea is mostly a matter of how close you are to trying to get them to work." He wrote the first windowing system for Unix, which surely qualifies him as a greybeard.

It's a shame they didn't roll a proper package manager with the language toolkit. Having your executable depend on having some lib installed is quite a pain. But how do you share libraries properly then? Especially without a proper way of bundling deps in your code...

Using cargo always makes me feel at ease when writing Rust. Haven't dabbled with linkers though.

And rust binaries all link the rust libs statically(you can change linking), maybe because it is easier to distribute static binaries that work everywhere than to distribute a bunch of libraries without official channel(your os distributions).

The same Rob Pike also stated that UNIX is past its due date.

> it is a very known fact for all unix grey beards ...

It doesn't get more "unix greybeard" than Ken Thompson, the original bearded creator of Unix. And his latest project suggests he is pro static linking.

Go packaging philosophy goes against that. but go is also released in a good enough state and things are being done right on the fly.

As a developer, I find containers much easier to update, especially in scenarios where you need to update to a new patch with a fix for OpenSSL.

The solution, is to bump the version in the dockerfile, rebuild, and deploy.

This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines.

Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs.

Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.

when it works for containers, it would have worked just the same for shared lib, but with one less step.

containers: update the lib, rebuild.

sane software: update the lib.

now, to the complicated case which containers claim to solve, when the lib update breaks compatibility.

container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways.

sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.

Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers.

I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good

with shared libraries containers are an option just fine

Everything is easy when you are one person caring for your own software. That's not a problem that needs solving.

On what basis do you think a complex c++ app would be more immune to security issues as compared to one written in a higher level language? Witness all the security exploits with Microsoft Word over the years.