[AboutTheWhisles]

No it isn't, flash was the best way to do many things for the years it was popular. Video, vector animation, simple interactivity.

Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language. Maybe a case could be made for severe misconceptions also helping electron like 'a custom native app has to be made for each platform', even though C++ and Qt and many other combinations can be written once with 99% of the source being the same for every platform.

[SquareWheel]

>Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language.

Why is there always someone ready to jump in with this elitist nonsense? There's plenty of reasons to use a web stack even if you know other languages. It's inherently crossplatform, has an extensive library, and is extremely quick to iterate on.

Slack and Discord building in Electron means they only need to maintain one codebase across web, desktop, and mobile. They don't need separate teams for building in Java, Swift, and C#. They only need to write a new feature once. Crazy, right?

This "web programmers are dumb" attitude is nothing but elitist rhetoric. Cut it out.

[sixstringtheory]

I keep seeing this "extremely quick to iterate on" point being brought up in defense of Electron. Slack released threads 2 years ago and we still can't post snippets, images, or use many slash commands inside them. Their last genuinely new features in the last year were synced DM drafts and the little lock badge on workspaces you're signed out of. Where's the iteration?

Meanwhile, almost daily I hit so many issues with the macOS application that I have to walk away from my computer in frustration. It makes my working life miserable due to its poor performance and bugs, and it encourages awful organizational and communication habits.

[SquareWheel]

It's a bit anecdotal, but I imagine Slack is being careful because they are targeting businesses. Discord is a similar platform which iterates new features extremely quickly.

[asdff]

If that is the case, Slack should want to maximize features, even to the point of excess redundancy, so users can tailor their business product to the specific needs of their business. People don't work productively being boxed into one way of doing something, people work best if they are free to find their own ideal way of doing that thing or are able to tailor the product to the unique tasks they work on.

Think of all the different code editors developers use. Some are straightforward, some have a steep learning curve, yet the good ones are good because users can customize them toward their own personal preferences.

[derefr]

> There's plenty of reasons to use a web stack even if you know other languages. It's inherently crossplatform, has an extensive library, and is extremely quick to iterate on.

The GP's point was that, in the year 2019, none of these features are unique to the web.

• For "frameworks", there's Silverlight, Adobe Air, Haxe, and—strangely enough—Flash itself, which still works just fine if your goal is to ship a standalone "projector" app rather than something that runs in a browser.

• Or you can use a cross-platform scripting language (e.g. Python) with a cross-platform GUI toolkit (e.g. QT, WxWidgets.)

• Or you can use a not-cross-platform language (e.g. C#) but just use the (pretty large) subset of that language that is compatible with a third-party cross-platform runtime (e.g. Mono). Before you laugh, this is exactly how many companies code games to be cross-platform: they just write them for Win32 but constantly test them under Wine to ensure they aren't breaking Wine compatibility. Then they ship one native version and two virtualization-layer-wrapped versions.

• Or—horror of horrors—you can just use Java, and use the various Java-to-native-X compilers to target mobile platforms like iOS. (It worked well enough for Minecraft!)

[Pfhreak]

> none of these features are unique to the web.

The web has all of them, I have yet to find another platform/language that meets all the same criteria.

Combine all of the above with a rich toolchain and extreme dev tools portability -- I can be up and running on basically any machine in minutes. As well as ease of deployment (at least for hobby projects).

All of those other platforms are, for me, less in one of the axes I care about. I've developed extensively in Python, C#, and Java for both personal and professional projects and while I like developing in them for many, many reasons, when I need to start a new project I nearly always find myself reaching for Javascript as the starting point.

[SquareWheel]

>For "frameworks", there's Silverlight, Adobe Air, Haxe, and—strangely enough—Flash itself...

With the exception of Haxe (and maybe Air), these are all dead or dying technologies.

Options 2 (Python/QT) works great, but is certainly more development hours and still requires platform-specific code.

>It worked well enough for Minecraft!

Minecraft was rewritten in C++ for mobile. It doesn't use Java.

[tyteen4a03]

Minecraft (Bedrock, the engine used by Android, iOS and modern console versions) is written in C++ with custom renderers for different platforms it target. They don't compile their Java code to native code.

[saagarjha]

> Slack and Discord building in Electron means they only need to maintain one codebase across web, desktop, and mobile. They don't need separate teams for building in Java, Swift, and C#.

Did you know that Slack has native iOS and Android apps, as well as a cross-platform C++ "LibSlack" run by another separate team?

[SquareWheel]

I didn't. Are you saying they're not simple containers?

[saagarjha]

Not quite sure what you mean by "simple containers", but yes, they're native apps written in Objective-C and Java IIRC. And here's some more information on LibSlack: https://slack.engineering/libslack-the-c-library-at-the-foun...

[nv-vn]

Qt is also cross-platform, easy to use, and has a giant library to work with. You can use it with virtually any language you want. Plus it runs on mobile.

[wesammikhail]

and lets not forget, it looks like this:

https://doc.qt.io/qt-5/qtwidgets-mainwindows-application-exa...

You didn´t really counter the parent´s post with an argument. You just pretended to do so by suggesting an alternative that is incompatible with the requirements he had in mind because you think you know better...

[nv-vn]

Qt is really trivial to style. That's like showing a blank HTML page without any CSS and discounting HTML because of that default appearance.

[ahartmetz]

"It looks like this"

That just shows how little you know. One style in one configuration looks like that.

[pjmlp]

Yep, when all that one has is programmer art.

Doing web apps without CSS skills won't look much better.

[saagarjha]

> and lets not forget, it looks like this

What are you trying to show here?

[sime2009]

> You can use it with virtually any language you want.

huh!? When did this happen?

Spoiler Alert: It didn't.

[dtech]

Qt is not suitable for building web pages/apps.

[bdcravens]

> This "web programmers are dumb" attitude is nothing but elitist rhetoric.

I don't think that's the attitude. The attitude is that they are lazy/stubborn, not dumb. I personally believe most developers are smart enough to keep learning. Whether or not they are willing to put in the work is the question.

[Gibbon1]

> Why is there always someone ready to jump in with this elitist nonsense?

Because it's absolutely true. You'll know it once you watch a web dev try and work on desktop app.

[SquareWheel]

People working outside of their comfort zones generally don't know all the answers. That goes both ways. I recently watched a desktop developer reach for a Java servlet because they didn't know Javascript.

[Gibbon1]

I think thee is also definitely a problem where if you don't use the right/current fad/popular stack you'll have a lot of trouble hiring people to work on your stuff.

Especially true since front and back end web stuff is so huge and high paying. problem comes when those stacks are a very poor fit for the problem at hand. But sure you could get an old neck beard to write that in C++ instead of java/Ruby or Node.js. Great you only need a single core embedded processor and it doen't even get hot! And yeah then who's going to maintain it?

[happy_man]

"They only need to write a new feature once. Crazy, right?"

Yeah!, why you old farts want me to learn about the stack, the heap and all of that OS architecture crap?, I don't need or want that #$@&*, I barely can keep up with all the JavaScript frameworks/libraries/toolkits that came out last week!

[JustSomeNobody]

Wait a minute. I have seen the argument for Electron because devs "get" to use one language they already know. So, let's just take a step back and reset...

[sime2009]

> Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language.

What toolkit or library would you propose instead? Seriously, what are these great alternatives? Doesn't necessarily have to support JS.

[nv-vn]

There's a ton of really popular, well-supported options

* GTK

* Qt

* WPF for Windows

* JavaFX

* Tk

* LibUI

I'm rooting for https://github.com/revery-ui/revery/ right now too, but it's still early in development

[sime2009]

> GTK

GTK hasn't been well maintained or developed for ages and has always had poor docs. I wouldn't feel confident trying it on any platform which isn't its home (i.e. Linux).

> Qt

Qt is probably the best option in the list but it's language support is poor, only C++ and Python are practical. It is a big fully featured and mature library, but developing with QML is a poor experience compared to the tooling available on Chrome/Electron. Packaging and distributing Python and/or C++ Qt apps is a huge PITA too.

> WPF for Windows

not cross platform

> JavaFX

JavaFX looked interesting but just didn't seem to take off and develop a reasonable ecosystem around it. Certainly nothing that could rival the web ecosystem. I do love the language support that the JVM delivers. Regarding deployment size it isn't likely to be much better than Electron as most apps have to ship the whole JVM anyway. The stench of Oracle does taint it these days too.

> Tk

be serious

> LibUI

This isn't mature yet and it looks like another optimistic adventure in "write once, debug everywhere" like WxWidgets.

None of the options here can compete with Electron in terms of ecosystem or developer experience (often Chrome's dev tools). Nor are they built on open standards. Also JS is up there with the JVM and .Net platform in terms of languages which target and can run on it.

[munchbunny]

As someone who used to develop with some of those options, I'm frankly glad that I can use HTML/CSS and Electron + React. It's much easier on the developer, even if it's less performant for the end user.

[doodpants]

That's exactly the problem: the developer prioritizing their own convenience over the end user experience.

[munchbunny]

I can also just not write the software.

It's not like I don't get the pain of slow tooling. I cut my teeth on C++. However, it's not a laziness issue, it's trading performance in one place for functionality in another. Case in point, at the time I chose C++ because I was trying to do game development in the pre-unity days. These days I'd choose Unity in a heartbeat because it's fast enough and saves me a lot of busywork. I could write more performant code from scratch, but it's really not worth the extra months spent wrangling polygons because the game never gets made.

[nv-vn]

Which options in particular? I'm guessing Gtk or Tk might be pretty annoying to work with.

[faissaloo]

Gtk is mostly annoying to work with because the documentation is poor.

[Pfhreak]

How many of those run on the web as a platform? (A cursory search suggests 'not many' or 'not without some effort'?)

There are some components I'd ideally like to avoid rewriting for my web and desktop applications. (E.g. why should I have to write render code for my friends list component more than once?)

[nv-vn]

I'm sure Revery does, don't know about the others.

[8draco8]

1% difference is a lot in software development. Electron is like Flash, it allows cross platform apps with one codebase. By the way Flash used ActionScript which have a lot in common with JS so that’s another similarity.

[derefr]

Electron is the best way for a third-party to wrap someone else's web-app into a more-fully-featured desktop app when that someone else doesn't want to ship a native app.

For example, there are a number of desktop Facebook Messenger "clients", that can pop OS notifications and so forth. They're all based on Electron. None of them are built by Facebook.

Similarly, there are a number of desktop Gmail "clients", not built by Google. They're all Electron, too.

The only alternative to this approach, would involve reverse-engineering the company's web-app's (proprietary, undocumented) API to write a native client library for it, and then constantly fighting the company as they try to block your native client library from being able to access their backend service. Some projects do that (there are at least two "native Gmail clients" that are actually native and are built on a reverse-engineering of the Gmail web-app backend API) but it's really not worth it if you're just a dev trying to scratch your own itch of wanting better desktop integration from these web-apps.

[reificator]

I have never seen Qt be proposed without immediately being shot down for the licensing.

[michaelmrose]

I was under the impression that it was available under the lgpl and only had to open source changes to the actual library that you aren't likely to need to make not your application.

[reificator]

It doesn't matter what the actual requirements are, the issue is that it gets dismissed out of hand for the perceived requirements.

[emilsedgh]

Which is usually based on just misunderstanding LGPL.

You "can" write a proprietary app with Qt and you wouldn't have to pay for it.

[reificator]

Misunderstanding or not, that's the reason.

With most software developers and most managers not moonlighting as lawyers, misunderstandings are to be expected.

[jakelazaroff]

Why did you put "can" in quotes?

[dx87]

You have to ensure you keep your business code separate from the Qt code. It's extra work that people might not want to deal with when they are more comfortable with other options that don't require special care.

[camgunz]

To be specific, if you modify actual Qt code--which you shouldn't be doing generally--then you have to release those modifications.

But if you dynamically link your app with Qt you're fine; you don't have to open source anything.

[Buttons840]

You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.

You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.

You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.

There's certainly a reason people worry about Qt licensing.

Source: https://www.qt.io/faq/

(And despite all this, let's remember how great it is that one of the best widget toolkits in the world is open source.)

[seba_dos1]

No, you don't. You just need to provide a way to replace or relink Qt libraries. Unless of course you modify Qt itself, but then you only have to publish those modifications. Absolutely nothing requires you to "keep you business code separate from the Qt code".

[simion314]

I am wondering what is the issue with dynamically linking Qt, are developers statically linking with MS c/c++ runtime or GUI libs ? From my experience you must install c++ runtimes on windows or if you use C# you need to ask your user to make sure to have it installed, where with Qt you ship the dlls.

[dwaite]

My understanding is that Windows has an odd memory allocation system where each DLL has its own allocator. Qt historically wasn't designed for that; it will allocate and return objects on the heap with the understanding that user code will free them.

They may have solved this since by using a custom allocator on windows for Qt types.

[simion314]

Is this related to statically linking? HOW are alternatives like Electron? can you bundle your Electron app into a big binary file ? From my experience in year back when doing desktop apps there was never a pressure to combine your dependencies into 1 big binary

[beamatronic]

Isn’t Gnome/GTK supposed to be kind of close?

[faissaloo]

>Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language. More like Electron is only the best way to do something when you're a business that's in dire need of developers and needs a cross-platform solution.

[jrs95]

Even if you were equally proficient in C++ and JavaScript, you can't tell me that Electron isn't significantly more productive.

[seba_dos1]

It really isn't. Even the multiplatform aspect of Electron is PITA - abstraction layers are so poor you usually have to support every platform separately by yourself if you want to reliably use stuff like systray icons or notifications.

Well, there's one exception - it sure is more productive if you already have a webapp to reuse.

[AnIdiotOnTheNet]

Add up all the time and resources wasted by an Electron application for all users over the lifetime of the application, then compare that to the amount of developer time supposedly saved.

[scottlu2]

It’s about time to market and iteration speed being important success factors, coupled with users accepting the costs in exchange for the benefits.

[AnIdiotOnTheNet]

So it is ok because money? I don't accept that reasoning. Computers today are orders of magnitude faster than they were in the past yet this concept of developer time being so much more important than everyone else's has them still feeling slow and unresponsive on essentially the same tasks we were performing 30 years ago.

This is why I hate this industry.

[jrs95]

It might feel like this, but if you boot up an old Windows XP machine and edit some text, it's still going to feel slow as hell in comparison to Atom on a modern machine. We get used to what's "fast" to do on our computers, and anything significantly slower than that feels "slow". And sure, the software is much less efficient. But compare it on hardware from the time it was developed, and it's not as bad as it seems.

And it's not just about money. With Discord as an example, they are able to quickly develop and deliver a great product, iterate on new features and integrations, and support all major platforms including web browsers. Their choice to use a web based stack helps A LOT with this.

[scottlu2]

I think it’s an economic reality for for-profit companies that make apps. If company A doesn’t go the html app route, and company B does for the same effective product, company B will have an advantage. It’s almost to the point where if your company app can be developed this way, you must do it this way to stay competitive.

[gammateam]

> Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language

and when you want to fire all the obsolete specialists while making a product with one person that works for everyone. I mean, you can keep one specialist, since they know javascript too

[x0x0]

electron also allows sharing code between web and mobile, plus the cross platform. afaik qt doesn't address that.