What?
Every C++ application, he said, implements pretty much its own networking stack and UI framework.
This talk must be from some alternate reality where Berkeley Sockets and Qt don't exist.
About 150 developers gathered at the headquarters of Slack on Friday to learn about Electron.js, the open-source, cross-platform desktop app framework upon which the IRC-for-hipsters client is built. Felix Rieseberg, senior staff engineer at Slack, a maintainer of Electron, and organizer of the Covalence conference, opened the …
Word. If you have an electron app port to webkit in QT.
Port JS to C++. Port dev skills.
Still quite heavy till you get rid of webkit, but not 20gig of spyware monitoring your every move.
Cross platform. Actually native.
GTK has something similar if you prefer webkit & C.
_Chrome_ has a complete ui toolkit embeded in it and its own network stack, but thta is so they can add "metrics" hooks. No one uses the toolkit (except Chrome itself) because its so bad, lots of chrome itself uses html/js to avoid using its own toolkit.
Chrome is a mess compared to QT. Riduclous base for a development platform. It was never designed for that. Its unstable. Changes on the whim of Google. Stupidly large. No dev tools. Its just not a platform.
Shame Mozilla canned XUL. Seems there was a market.
Just wait, and WASM-based framework will come - including UI frameworks. I didn't look at the details yet, but if WASM brings a language-independent ABI enough usable for complex calls, you can have WASM compiled libraries to be called from different higher-level languages.
At least you won't need to install a Google-controlled run-time because WASM application will run on your browser WASM VM - or your operating system one.
Why you should ever run a WASM application on Electron? High-level language -> WASM -> Javascript??? WASM has been designed exactly to take JavaScript out of the equation and have a low-level "machine" language to be executed directly.
WASM runs below Javascript, not above. You can implement it in Javascript virtual machine, but its code is not Javascript - and doesn't tie you to a specific engine - so Electron could run WASM application, but won't be required to run them. And why you should bloat your system with all the Electron code when your browser or even OS will be enough to run them?
"And why you should bloat your system with all the Electron code when your browser or even OS will be enough to run them?"
Exactly... exactly what wasm is for. What I think some people are forgetting is that wasm can and is also used to draw.... wan't fancy FX like sprites or smoother transitions? Electron will slowly become the new jquery, but with way less uptake and far less longevity. Electron's only option is to become a IDE for wasm with that Frontpage/Dreamweaver feel.
Not sure why you're downvoted, but it very well could as it's bringing a huge grey area of APIs that merit a whole new IDE. Which kind of leads into why I came to post....
"...feel confident the software isn't a fly-by-night whim"
But it's not software! It's about as much as software as considering GCC software. Want some strange looks? Ask somebody if they have "the latest GCC... GCC". But then again that's a bad simile, as Erectron is basically an interpreted-interpreted-runtime. So it's that script you wrote to emulate FreeDOS to run .bat files... no, nothing wrong with that at all :-/.
Is that possible at all with Electron? Microsoft claim to have been "working on it" since 2016, so that's not exactly rapid development.
It also rips apart the security model of the host OS, creating holes large enough to drive several double decker buses through. Sideways.
Can we introduce some sort of carbon tax to offset the massive bloated waste of CPU cycles and RAM that things like Electron represent? To try and make the devs actually consider what they are doing for a change.
It's true that for a lot of people they won't notice if the app they use is electron or not. In the same way that most people won't notice if their petrol uses lead or aerosols use CFCs. But enough people using them because the suppliers can get away with it adds up to disaster and forces the user to unknowlingly be complicit in it.
I have lost count of the number of times I have been told that processing cycles and memory are cheap, so bloat is perfectly acceptable.
I would like to see them try their hand at deep embedded where those things are not cheap because there isn't enough space to put a lot of memory and a very fast processor (because you can't get the heat out).
Sure, UIs can take up a fair amount of memory but the amount the current ones take is ridiculous (I can hear them writing it..."Oooo! Shiny!") and a simpler interface might well be better anyway (and use fewer resources).
Icon for the processing required.
Electron appears to be a problem in search of a solution (yes, I know which way round I put those :)
Funny that a Slack engineer 'fesses up about bad quality software. A quick comparison: HexChat (for the youngsters, a client for a predecessor of Slack called "IRC") uses 57M real, 600M virtual after having ran for a couple of days. I just launched Slack (that hipsterware to keep you off work at work) - 300M real, 2.4G virtual. And I know that HexChat will stay the same and Slack will probably at least quadruple. That's progress for you. And I'm not even touching on the vast difference in usability - one of them I can extend in a bunch of different programming languages and has nifty things like custom hotkeys.
The whole "multiplatform is hard" thing is bollocks anyway. There are only three platforms left, and I think all of them have decent Qt bindings (at the least; I think Gtk is available as well and I once did a cross-platform thing in Wx that looked surprisingly better than I anticipated). It's sheer laziness that Slack refuses to make a decent client; that, and - of course - being enterprise-directed the CIO, not the user, is the customer. CIOs don't sign cheques for optimized code (so in that sense they're rationally right to sling Eletron crap at their users). So it's a bit more work, would never impact Slack's bottom line but nobody who matters complains loudly enough. And I think that _that_ is the real thing wrong in our industry.
"Electron/Chrome is bloated and slow"
"why don't you use native c++"
"Qt looks just as good"
I wonder, have the people who say this ever developed an actual app and faced the issues for any modern UI app that needs to be cross platform? Can you point to any cross platform QT apps that are mainstream?
Look at https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt - nothing big there at all.
The simple fact is that HTML+Js is such a vast ecosystem it allows you to build amazing UI in a fraction of the time it'd take with any other tech. The browser and JS engine (V8) have had billions of dollars invested to make them fast and feature rich. Native code just cannot approach that level of richness, and certainly not in a cross platform way.
Why do you think we have React Native/Xamarin/Flutter etc? Its because devs don't want to write the same app, same UI multiple times in different languages. Qt just covers the desktop. What about the web? Slack's website and desktop apps run the same code.
No one is going to learn QML. Why should they when we have CSS/HTML? Microsoft had to abandon the vastly superior WPF precisely because no one was using it. Flutter faces the same uphill battle, but it has Google behind it.
Like it o not, Electron is here to stay. The browser is already shipped with every desktop/mobile OS as a system component. The fact that its a bit expensive to launch and runs in a separate process/tab is an optimization problem. In a few years this will be optimized. There's a very good chance V8 or some JS engine will be part of the OS too. Look at Gnome.
Standardized apps are a good thing, esp wjhen built on such a flexible stack that is evolving faster than anything. Improving the web helps everyone, and its open.
> The simple fact is that HTML+Js is such a vast ecosystem it allows you to build amazing UI in a fraction of the time it'd take with any other tech.
Take "amazing" out of that, and I'd agree with you.
But HTML+JS simply cannot make applications that are as good as native apps are. They are necessarily full of compromises to the user experience, not to mention being bloated and wasteful.
> Like it o not, Electron is here to stay.
That's likely true (if not Electron specifically, then something like it), but because of economics, not because it's a great way to create applications. In any case, I won't be using them, personally.
And may I also add that "Standardised" is their standard. This godforsaken framework which has everything including the kitchen sink and can happily fill gigabytes of memory because it also needs a browser, a JavaScript engine, and whatever JavaScript libraries are du jour all because web developers like the idea of writing actual desktop software but haven't got the patience to learn anything new and think slapping together some HTML and JavaScript in Electron makes them Real Programmers Now is in no way a definition of a standard but just stuff slapped together that happens to work and is just yet another giant albatross around the neck of modern-day IT.