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.
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.
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.
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!)
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.
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.
Did you know that Slack has native iOS and Android apps, as well as a cross-platform C++ "LibSlack" run by another separate team?
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...
That just shows how little you know. One style in one configuration looks like that.
Doing web apps without CSS skills won't look much better.
What are you trying to show here?
huh!? When did this happen?
Spoiler Alert: It didn't.
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.
Because it's absolutely true. You'll know it once you watch a web dev try and work on desktop app.
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?
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!
What toolkit or library would you propose instead? Seriously, what are these great alternatives? Doesn't necessarily have to support JS.
* 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
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.
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.
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?)
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.
You "can" write a proprietary app with Qt and you wouldn't have to pay for it.
With most software developers and most managers not moonlighting as lawyers, misunderstandings are to be expected.
But if you dynamically link your app with Qt you're fine; you don't have to open source anything.
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.)
> You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
This isn't true [1].
> 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.
If I'm distributing a game written with SDLv1 on mobile, I don't have to do anything at all differently than if I distribute the exact same game on desktop. Many, many games did this.
> 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.
This is also not at all true [2], in fact they couldn't release Qt under the LGPL if it were. That would be LGPL with a non-commercial-use clause, which would be incompatible.
> There's certainly a reason people worry about Qt licensing.
Yeah and honestly, it's because there's a lot of bad information out there. GPL and LGPL are subject to so much FUD. We as developers have a responsibility to know the facts.
[1] https://copyleft.org/guide/comprehensive-gpl-guidech10.html#...
[2] https://www.qt.io/faq/ (section 3.7)
They may have solved this since by using a custom allocator on windows for Qt types.
Well, there's one exception - it sure is more productive if you already have a webapp to reuse.
This is why I hate this industry.
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.
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
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.