But on the whole, I don’t think the armchair critics truly appreciate how Electron reduces the cost by at least an order of magnitude. It’s a brilliant tool for shipping early and fast. My only criticism with these start-up use cases is that these Electron apps can often just be websites.
Also: all of these “shitty” Electron apps work just as well on Linux as they do everywhere else. That is a huge advantage. I’ve got a significant amount of software that is realistically only on Linux because of electron.
Contained within a tab Slack can only use a set amount of resources allotted by the browser.
Whereas installing the app means it can go full hog.
If the code is based on HTML/js/CSS and not Swift/Obj-C/C++ (etc) then you're really creating a web app running in a native microbrowser.
Which is very much not the same thing as writing OS and system calls directly - not least because it will be much slower.
In the Chrome menu, select More Tools / Create Shortcut... and edit the title and check the Open as Window box.
In Edge, select Apps / Install this site as an app. Edge has a lot more options here than Chrome. You can pin it to the Taskbar or Start, create a desktop shortcut, and set it to auto-start. (You can do those manually with a Chrome shortcut if you know your way around the Start menu and Startup folder, but it's easier in Edge.)
I don't see a similar option in Firefox. No idea about Safari. If anyone knows about those browsers, please comment.
And having posted this comment, I am now wondering why I am still running the Slack app. I think I will try making it an Edge app!
That one of the reasons I don’t use the Google Chats PWA , when the browser misbehave, it will affact PWAs as well.
The comment I replied to described a preference for the app because of OS navigation, e.g. Alt+Tab, a separate taskbar icon, etc.
This Chrome shortcut or Edge app trick lets you combine these approaches, running the website in your browser but giving the site its own main window that you can pin to the taskbar, set to auto-run, and navigate to like a native app.
did they fix multi-stream video yet? last time I checked in the browser version you could only see one video stream (ie. webcam), whereas on the desktop app you could see multiple.
The main reason I was using the browser was so I could use Stylus to make it compact just like Slack. That’s another benefit of the browser approach, but ideally it would not be so obviously inferior to competitors.
My GP surgery uses a fantastic website for streamlining comms where you'd never want to install an app that would be rarely used. It's so well integrated that they could ping me the link during a call and I had details back to them seconds later so I got a decision there and then as we spoke rather than breaking flow state and delaying it by days as they used to.
Funnily enough my dentist has a similar kind of app relating to pre-appt preparation - perhaps there's a fight back for common sense in these slightly more serious fields?
There are plenty of native mobile apps out there that are better off as web apps.
If it's a service that people use constantly, then there may be some merits in using an app.
But more often that not there are plenty of things people use once-in-a-long-while that should probably be just a website.
For instance I know a place (outside the US, not naming the place because that's not relevant) that has a mobile app just to highlight the local tourist spots. It just shows pictures and text description. There's no AR/VR stuff or anything. Neither can it reserve tickets for any of those places. In my opinion that should just have been a static website!
Of course, there will be angry PMs and designers that will be upset that their website looks like it was spat out of a desktop GUI framework instead of looking exactly how they want it to look. I remember people whining about how desktop-looking ExtJS was back in the day... this was for an inventory-management application, shouldn't it look like a desktop productivity app?
Not if the native controls are strongly opinionated as to style language, such that there is limited themability, unless you go to the level that your “native GUI” is doing the equivalent of drawing and reading mouse touches from a canvas to implement a custom UI rather than using more specific native controls.
Spotify buck the trend, Spot is a fantastic app
We need regulations around platforms, protocols are inherently more powerful and from the perspective of humanity almost always preferable over platforms, so the incentives of companies should reflect that, but it isn't right now.
Stuff like email, http etc is what makes computers great. I doubt anything like that could get invented today, companies would just create their own proprietary protocols and there would be no web browsers. Imagine if we just continued along that route and made protocols for everything instead of having big companies lock down computing habits via platforms.
Allowing platforms to innovate but somehow incentivizingnor requiring opening up what they've built seems like it would be the best of both worlds, but I'm not sure how that could be done well.
If people actually paid for usage, that would be one thing, because then it would be all about getting people to use your platform so you made more money, and having others innovate on too of it that you could fold into it would be cost effective. In the world of free APIs and services, it's all about keeping control of every bit.
Maybe all it needs is a nudge to make the decision to hoard all data no longer worth while. Make companies liable for PII that's lost and make someone's PII their own property only to be used with their agreement and maybe the rest will start to fall out of it.
The problem is the intersection of extreme profits at stake and the public's lack of understanding of the underlying causes. That's not a recipe for good political outcomes.
In the case of the UK open banking regulations I suspect tech lobbying (powerful) might have trumped high street bank lobbying (not as powerful).
Standards are good. IETF is the reason for some sanity in IT.
I concur with this. I've gotten into IRC recently, and have started reading RFC's/specs for various protocols instead of ducking "How to do X", and it's both greatly increased my enjoyment of computing, and my knowledge.
I guess that's also kinda Docker or QEMU or V8, but also https://github.com/solo-io/unik if you think about it differently.
In other words: hey, Lisp Machines were an excellent idea back then, but they still are. Maybe someday we'll have a V8 co-processor. More fun reading: https://lobste.rs/s/2poahh/what_i_could_not_undiscover_about
Postscript as a UI language? Fine as long as they all do it.
HTML5+ as a UI language? (E.G. like the failed HP Fire or Firefox) Fine as long as they all do it.
Some new thing that isn't a complete dumpster-fire but is included everywhere and a free for anyone to implement interface? Fine as long as they all do it.
We have NO shortage of programming languages that can be cross compiled to different operating systems. Filesystem differences can be annoying but you can work around those. Entirely different user interaction paths? That's the sticking point.
One really obvious example (maybe no longer current - it's been a while since I spent any time on Windows) is that OS X windows are responsive even without focus. So you can scroll around background windows just by hovering without having to click first. Windows doesn't support this.
The bigger problem is that the data structures for menus, chrome, and the rest are completely different. An OS X menu is nothing like a Windows menu is nothing like a Linux menu.
There are systems like Tcl/Tk and Qt which act as middleware between GUI descriptions and specific OS bindings, and they kind of work. But they force devs to learn a separate intermediate language and (IMO) they look crude compared to real native apps.
Of course there are also business reasons why GUI convergence won't happen.
Scrolling non-focused windows works just fine (ex. can type text into notepad while simultaneously scrolling a browser window).
It isn't? I use it daily and haven't noticed anything missing, except that voice calls don't work on Firefox, which is fine, because I never use them.
But same, I haven't noticed any missing features from the web version.
The exception is the list of domains that allow auto-play video with sound by default (like YouTube) but I think there are very few instances of this.
On the flip side, when you use them as websites, you gain the benefit of extending them through browser add-ons and extensions. An example where I work is that everyone uses Asana’s website because our Everhour extension works in Chrome but there’s no equivalent for Asana’s desktop app.
open.spotify.com##section[aria-label="Episodes for you"]
open.spotify.com##section[aria-label="Shows you might like"]
open.spotify.com##section[aria-label="Shows to try"]
open.spotify.com##section[aria-label="Funny LGBTQ+ Podcasters"]
VSCode is also appreciably different both in capability and implementation, https://franz-ajit.medium.com/understanding-visual-studio-co... but interesting that V8 debug protocol is becoming more common, so maybe that will come to a browser some day :)
Slack is great; it's like "hey, we took IRC and added inline images, now it's three orders of magnitude slower". Google Sheets is great in the same way: "hey, we took Excel and removed half the features plus now it's a few orders of magnitude slower BUT EASIER TO SHARE THINGS". Spotify is similar: "Like WinAmp, but slow, but with a subscription you can listen to most of what you want immediately and share things easily." These are in ascending order of their actual value compared to their predecessors, I guess.
Distributing the load of webapps makes sense if you've ever had to run a few thousand web servers running PHP apps, but yeah, running a framework server-side to render the page again and calling it modern is just kinda...the same thing we had before with a fresh coat of paint and more levels of abstraction.
Back in the day, we had CPAN, PEAR, and PECL. Now we have NPM and approximately 18 trillion modules. You can get stuff that does all kinds of useful types of manipulation, but under the hood some of it is still just a wrapper around some combination of zlib, FFmpeg, OpenSSL, and maybe Boost, plus TensorFlow or OpenCV (which can use FFmpeg) these days.
The amount of truly novel problems we're solving still seems low. "what Andy giveth, Bill taketh away", or I guess these days, "What Lisa giveth, Sundar taketh away"?
In the thread chain I was just curious why people think IRC could not be a Slack replacement.
Related to your question about these integration services.
Running an IRC server is definitely not complicated. Bots which implement authentication/authorization already exist (NickServ/ChanServ/X). History saving is also common, and for in-client message history a bouncer is a pretty good tool to have. Document downloading, you have DCC, or yet other bots you can query/download from (pretty common in the mp3 download era).
If there was incentive someone could create a bundled package that unifies all these different components + a more modern client interface and people would not have any issue using.
It's not in the problem space I'm interested to work on, but functionally even the more restricted existing IRC offering would be something I'd rather use than the gif meme filled, emoji overdosed chats I've had on Slack.
On the other hand, I've been an independent contractor for a couple of years now and I had the pleasure of not being part of large team slack channels anymore anyway.
Humour on HN is generally frowned upon.
Hahaha, bravo, that's a funny one!
It's not a matter of finding resources, it's a matter of finding that to be the best use of resources. Obviously they could have native apps for major desktop platforms with the energy put into the Electron app, and performance would probably be better, but would they have feature parity? And if you increase the resources, would the best use of that increase be into maintaining native apps for each platform of Electron?
I believe feature parity is less important than the basic HCU of a responsive interface for the most basic features. Some of the most recent features they've added, like the "WYSIWYG"ification of the input box were arguably more disruptive to my use of Slack than any benefit it offered. If a good baseline performance for basic features like chat, image sharing and calls are achieved, then later into the lives of these clients the kinds of features that would lose out on parity ought to be more niche. Things like the presence of huddles (arguably just a different kind of call), bot command interface tooltips, and the ability to draw on shared screen.
Maintenance is a real challenge, but one that delivers the value of good HCU and performance on dev machines; a worthwhile operating cost to provide a product that is harder to unseat. Better performing programs also save memory for the rest of the user's programs like containers and IDEs, which can get pretty resource-hungry.
I think with the recent chip shortage, supply chain issues and potential catastrophes in the future with Taiwan, there's a pinch that will force us to be more resource efficient on a per-machine basis at least for a while. And we may find out that there are miraculous things we can do on the individual machines we have, with what felt like very little processing power, once we're forced to adapt away from overvirtualized, shallow quick-to-market apps.
EDIT: on further consideration, I'm wondering if it's not possible within things like electron, to have some kind of "just in time" style hybrid infrastructure where the most basic features are augmented to run native code quickly for the most heavily used parts on the most common platforms? I don't know enough to say.
The problem is more recruitment and internal mobility I guess. If you have 4 teams, experts in their domains, you will have 4 teams 'fighting' each other over the UI, working in their silo's, harder to maintain feature parity... But thats organisational.
I can guarantee you whatever is causing Slack to take 3 seconds to load a channel has nothing to do with it being built on Electron and, all else being equal, would probably have the same problem if it was built as a native app.
I think they could, but they've decided it wouldn't be a good use of that time and those resources. The Electron app was probably written when Slack was a much smaller company, with less time and fewer resources. Now that they have more time and resources, they can choose to spend that on adding features and acquiring more users, or they can spend it on rewriting their entire app three times (ok, two times; I assume if they decided to go native they wouldn't spend the time on a Linux app). And remember this entire app isn't the app they started with; it has a lot more features than that one did.
It frustrates me too; with the exception of Signal Desktop, I've banished Electron-based apps from my machine (if I had more time on my hands, I would write -- and then spend a ton of tedious, thankless time maintaining and updating -- a native Signal Linux app). I use the Slack webapp in my browser, and it works just fine. And that's also the weird thing: I don't get why so many people use the Electron-based desktop apps, when the webapp has all the same features.
But on the whole, I don’t think the armchair critics truly appreciate how Electron reduces the cost by at least an order of magnitude.
To me, I look at electron and I would put it roughly on par with QT. Although, like the vb vs delphi argument, i think electron gives you a good initial boostrap and makes you feel productive, but then when you start to hit problems they are very difficult to solve. Vs QT which is harder to get started in, but once you have the core up an running its possible to bolt things on fairly rapidly.
I've not written anything in lazurus other than toys, but many of the problems I had with it just a couple years ago seems to be mostly fixed. AKA, its been quietly getting more robust everytime I install a new version..
So, I would be interested in a fair electron vs lazurus comparison from someone who has spent significant time in both.
But maybe it should be.
I was employed doing what we called client server development in the 1990's, where we wrote the frontends the users interacted with in vb and later delphi. I would put the visual and operational complexity of some of those applications far beyond any slack/etc type application (one actually had a chat function built in). They were also distributed, but instead used proprietary protocols over proprietary wireless networks (until later when we were some of the first customers for cellular data). And I say it not to brag, but there were two of us working on the front end, both part time over the span of maybe 5 years. And we could do large logs/chat histories where the scrollbar reflected where in the data set the user was viewing and they could smoothly scroll or jump to any arbitrary location. I can't remember the last web application that could do something even that basic. Slack definitely cant. I'm pretty sure there are more developers working more hours on the slack front-end than we worked on those applications. So, I'm not sure where the claims of developer efficiency comes from.
People make a lot of claims about developer efficiency, but just about none of them are backed up by more than their gut instincts, which I would claim from the end user/3rd party viewpoint seem to be completely invalid. The apps are overwhelmingly poor on any number of fronts, and apparently have a lot of man hours poured into them.
I would worry about hidpi support with Lazarus, and how well the android/ios/mac bindings actually work. Maybe a few other things too, basically things that are going to be so large a work item that fixing them is going to outweigh any advantages of picking the tool. I think electron has at least a dozen of these, and that would push me away from it. From where I stand, electron is closer to java in the long term results.
I wrote my first pieces of shitty Turbo C code before autocomplete was a thing, in a DOS editor. There was no discovery of language syntax or features, you had to have a paper manual open on your desk. So I got frustrated, didn't stick around (dumb decision in retrospective), turned to webdev, at least the turnaround from code to result was quicker. For some time I thought it couldn't get any better than syntax highlighting, but it did. And now I just don't want to work with languages that don't have good lsp support. Been there, done that, nope, not going back.
Sigh... "Does [Product X] even have [solution for Product Y problem]?"
A "package/dependency manager" is only necessary in languages based on using umpteen million unvetted modules downloaded from the net. Not all languages work like JavaScript in that respect.
Seems quite mad considering the use/value of the tools and the absolutely enormous user base they have.
https://techcommunity.microsoft.com/t5/microsoft-teams/teams...
It's also worth remembering that HTML UI is technically "native" on Windows since Win8, where HTML/JS was one of the three stacks supported by all the new WinRT stuff - and, indeed, the one most heavily pushed.
But they didn't migrate because isn't critical for their business, Teams is just a bonus, but Outlook is 100% native app in Mac and works great, because they can't afford to lose customers with an electron version of Outlook.
It's kind of a shame that chrome apps didn't become a thing and electron app installers would detect if you have chrome and just install themselves as chrome apps vs an electron app. That would've been another legit alternatives.