Point taken – 'issue' is not the correct term here. Perhaps 'cause' is better.

Lowering the barrier to entry is great, I agree. It's awesome that Electron and web technologies can be used to quickly launch proof-of-concept desktop apps. I find it significantly less awesome that companies with hundreds or thousands of engineers continue to use it after the concept has been proven, however!

But these apps aren't "proof-of-concept" apps - they are fully functioning, working cross-platform applications.

So are you saying that these companies which have implemented these apps should instead say "You know what, we have this app developed, and working on the major platforms - but let's instead devote three new teams, one each for Windows, Mac, and Linux - to re-implement this app natively! I'm sure upper management will agree!"

That's not going to work. That's going to be shot down and laughed at. No company is going to re-implement a working cross-platform application over to three separate native contexts, and maintain all three. That just won't happen. It works already. The users probably like it just fine. What benefit to the company will this get them? Nothing - just more costs for maintenance across three platforms.

If native is wanted by the users, likely what would happen - if it happens at all - will be the company says "Ok - we'll make it native for Windows, maybe even Mac - maybe. Linux? Forget it!"

It's not the developers. Developers would love to make native apps, for all the platforms. But developers are limited by the companies they work for, and by the economic realities that all the platforms can't be supported natively; at most, only one or two can - because at that point, with the number of users on those platforms, the additional costs of maintenance and support are pretty much saturated. Adding additional native platforms doesn't just add onto those costs, it actually (in theory) multiply them - because a single person might use the application across multiple platforms. So if they have problems on two or three different native platforms, now there are three different support issues (needing more people to support) - instead of a single complaint for a single platform.

I get it, though - it would be great if these apps were native, and worked on every platform, from now and into the future (even on platforms that don't exist yet!). That's just not going to happen; if native is wanted, then only the most widely used platforms will be supported, and even then, one of those will likely be dropped, and it won't be the one from Redmond.

So - what can be done? I dunno. The concept the author brings up ("use React Native") might be the solution. Or some other interface that abstracts a platform's OS and other native functionality out to an API that is the same for all platforms. But now you have issues with security and other access - which you still have with Electron, but it is more contained and constrained, since it has to go thru the Chrome engine and the various rules/settings browsers have for sandboxing bad actors. Or - you leave it to the user and their operating system (and slim it all down - maybe that's what React Native does; I don't know, I've never used it).

Or - you (that is, the company) just says "Sure - we'll do a native only implementation - for Windows only." - because that's how it usually goes.

> It's not the developers. Developers would love to make native apps, for all the platforms.

I don't think that's true in the case of Slack. They only have JS "hacker" webdevs, and those are notoriously resistant to any change to their comfort zone. C++? WPF? Swift? Cocoa? Scary stuff.

"The easier we can make it for people to get started, the better, isn't it?"

Would you like to use an application that would not have been written without a low barrier of entry? Powerfull and easy tools are not necessarily the same thing.

"the easier we can make it for electricians to wire up my house, the better, isn't it?"

Unfortunately, no. Just as a trained electrician will wire up your house so as to not set it on fire as soon as you turn on a lamp, a trained developer will make apps that use a minimal amount of resources.

Especially more hilarious if someone writing Electron apps call him/herself an engineer.

I write Electron apps and call myself an engineer, because I am an engineer. Could you please explain why am I being hilarious?

Some engineers take exception with software developers using term, given that the disciplines are somewhat different.

As computer programmer in the web field, I find it awfully pretentious when web developers or any other programmers call themselves engineers when they are not legally licensed engineers.

It says "Software Engineering" on my graduation certificate. I wouldn't be able to get licensed even if I wanted to.

Have you been trained as an engineer, in a country where "engineer" is a very specific thing and is held to higher expectations, including the possibility of having your title taken away by your peers if you do not respect your duty to, first and foremost, your users and/or society, like every country that takes the title of engineer seriously?

If yes, what in earth makes you think writing Electron apps is a good idea? If no, back to my point.

To quickly answer JetJaguar below you, yes, I am an utter cunt, but being called a typical hackernews one hurts, considering how I can't stand most HNers.

> Have you been trained as an engineer, in a country where "engineer" is a very specific thing and is held to higher expectations, including the possibility of having your title taken away by your peers if you do not respect your duty to, first and foremost, your users and/or society, like every country that takes the title of engineer seriously?

I have been trained as a Software Engineer in Istanbul. I am very sorry that my country doesn't fulfill your expectations.

> If yes, what in earth makes you think writing Electron apps is a good idea?

Engineering is about making trade-offs. There's enough discussion here about what those are for writing Electron apps.

> If no, back to my point.

What, "no"? What was your point? ...that I'm not an engineer? As I said, I am one.

> yes, I am an utter cunt, but being called a typical hackernews one hurts, considering how I can't stand most HNers

I don't think you are a cunt. I think you are uninformed and have concrete opinions based on limited or self-fulfilling-prophecy-boosting experience.

> Have you been trained as an engineer, in a country where "engineer" is a very specific thing and is held to higher expectations, including the possibility of having your title taken away by your peers if you do not respect your duty to, first and foremost, your users and/or society, like every country that takes the title of engineer seriously?

No country trains software engineers in the way you describe.

I think Germany was the country described in the post. Whether it's true to the fullest extent is hard to say, but having worked and socialized with them for years it seems mostly true. Engineering is the country's actual official religion. And I mean that as the highest compliment.

(No offense to any other country's engineers -- the engineer mindset is the same everywhere, but the mindset of the non-engineer in other countries is the distinction. That is, Germany grants engineers a degree of respect, almost reverence, that I've never seen in the US.)

Our company recently purchased some Hardware I/O devices that came with software (both made in Germany). Lets just say, I'd much rather buy their cars than their software.

So they should not call themselves engineers - any more than they call themselves doctors or lawyers. They are programmers or software developers. Or potentially software engineers - but certainly not engineers.

All of Europe, also parts of Canada.

No place in the US does, indeed.

Are there standardized licensing bodies for software developers in the EU and Canada? I'd be really interesting in learning more about them if so.

I sympathize your argument and I think the field is doing a great job right now demonstrating some of the upsides of a licensing authority, but actually getting one would be bad IMO.

Most software is not life and death, and licensing authorities, like unions, quickly become gatekeepers that work to prevent competition whilst simultaneously enriching themselves through extortionary means (today, these are mostly indirect because everyone is on the look out for them, but they are nevertheless still there). There are good arguments that the AMA and ABA have both seriously contributed to the astronomical expense of their respective services.

>Are there standardized licensing bodies for software developers in the EU and Canada?

For engineers, absolutely. For software engineers, absolutely, because they're still engineers. Software development? Go wild, anyone can do it. >licensing authorities, like unions, quickly become gatekeepers that work to prevent competition whilst simultaneously enriching themselves through extortionary means

That seems like a terribly US centric that I keep seeing online. Unions in France, as it's the one example I can be certain of, are in no way gatekeepers, and we are a country where they've been immensely powerful when it comes to influencing the state (whether talking about worker's unions or CEO unions). But you can get any job without being in an union, all they're doing is bringing everyone on an equal footing when it comes to negotiations.

Licensing authorities are purely a society thing. Either you have a numerus closus, because the end goal is for everyone that passed the selection to have a guaranteed job, with good living conditions, or anyone can pass, and good luck everyone. It works in some cases, doesn't in others.

I've never heard of some governing body in France or England taking away the title of "software engineer" for someone who wrote faulty code. What are these governing bodies?