The author is fighting a strawman. Rather than engage with the specific problems these solutions were built to solve they dismissively regard them as just flavor of the week trends purely for the sake of chasing newness. This is true of the entire post, but I'll tackle just one since it's emblematic of my issues with all the rest:
The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper". Hiring experienced desktop application devs to build a quality native app for each platform is going to be expensive, hiring a few JS bootcampers to build one react UI that works on every platform is extremely cheap - shittier performance is the tradeoff to instantly have access to every platform. It's not a coincidence that Electron apps like e.g. Slack, Spotify, Discord are massively dominant players in their markets, I doubt you'd look the engineering leads of these companies in the face and tell them that you believe they put no thought into the tradeoffs of Electron and that they're just following trends.
I think that's what's offensive to the purist engineer mind. These aren't engineering decisions, they're business decisions (or maybe the closest thing you could call them would be "financial engineering" decisions). The best thing, by pure engineering criteria, is not what gets built. The best thing for the business is what gets built. In that context it's a complaint as old as the hills.
...and not specific to computers either, or even the private sector. In a past career I was a civil engineer, and I learned about how traffic light green times (how many seconds a signal stays green for one direction vs. the cross street) usually have a "right answer" from an engineering standpoint, which as you can imagine, has to do with maximizing traffic throughput and/or minimizing delays to each individual vehicle. And then the mayor of the town shows up out of the blue and says no, this direction is going to have a longer wait, I'm going to delay people intentionally, so that when they're stuck in traffic, sitting there, they'll have more of a chance to see signs/placards of, and contemplate patronizing, nearby businesses, whose owners are my political backers. That made a big impression on me... must have, because I feel like I've told that story in an HN comment before... but anyway... yep.
> These aren't engineering decisions, they're business decisions
All engineering (including "real" ones like civil or mechanical) is about fitting your requirements within budgets. When one's building a skyscraper, you try to build it in a way that minimizes the cost while satisfying all requirements (it shouldn't fall down given such and such conditions, etc.)
Engineering is largely the art of solving problems that fit in real-world constraints and one such [major] constraint it cost. When you build software, you're not given 10 years, a research team and infinite money. You're given just enough resources to build something that satisfies requirements and is the lowest cost (financially and temporally). There's always a way to build things "better" but that's not the point.
Your quote is better, but for people that have a hard time with that analogy, I like using the example of building a 4-story concrete/brick building - anyone can make a building stand strong by filling it with concrete / bricks. It takes precise engineering to know how thin you can make the walls/supports to make that building worth building.
If you just mindlessly fill everything with bricks and concrete, you likely need to make the lower walls thicker than the upper ones to support the weight...
The whole engineering process can be done without ever looking at the budget as long as the framework is given ("use these materials", "you have this much space").
Feels like everyone is very disinterested in the cost to the user with most "modern ways" of doing things. Many webpages use far too much resource to just communicate text. Web adverts are especially awful for this. I could browse the web with dialup and a machine a thousandth as powerful as my phone. So as a consumer why do I need to "upgrade" what was the added value above Google scale is delivering computationally intense adverts I then waste cycles blocking?
Of course they are, because the user does not reward them for being sparing of resources that are, frankly, insignificant on modern devices. Might be different in you were operating in a market where people were largely relying on very low-powered devices, though.
That's a circular argument, because "on modern devices" moves the goalposts every year. I still have a Galaxy Note II, which I would definitively classify as a modern device. But some webpages have terrible performance on it, because anything older than 3 years is not worth optimizing for.
Same thing with old iPhones: the only reason they don't work reliably today is because each piece of "modern software" is less efficient than yesteryear's equivalent, and the constant redefining of what constitutes a "modern device" is what perpetuates the problem.
This isn't an engineering problem, it's a consumerist dystopia. The computing market is encouraging wastefulness in all dimensions: useful device lifetime, computing costs (bitcoin farming anyone?), software efficiency, framework longevity (jquery, angular, meteor, react), dependency management (NodeJS). None of those problems are new, but every new entrant seems hell-bent on outdoing the wastefulness of its previous incarnation.
Perhaps a circular process. Not a circular argument. It's just reality that users reward optimization they can't really notice less than features. In places where it does matter to the bottom line, like how fast a shopping page loads, the optimization is prioritized.
But the cost to the user is not considered, even in the real world. For example, transportation decisions are made in the airline industry, and they rarely consider how much this will financially impact the lives of passengers. The same pattern is replicated everywhere: companies work to maximize their profits, while their clients have to deal with possible financial losses.
Desktop OS's are not appreciably faster now than they were 30 years ago, despite exponential rises in memory, storage and processor capacity. Better looking, yes, but not faster.
Games have maintained roughly the same performance for 20 years. However, the number of polygons has risen exponentially.
There's a minimum acceptable performance for most systems. If you exceed that, no-one cares (the extra performance is wasted). So every system hits that minimum performance level and spends the rest of the budget on appearance (or configurability, or ease of editing, or whatever).
Wordpress is slower than flat HTML. But the average web browser and connection is fast enough to serve Wordpress content in an acceptable time for the user. The "extra" budget was spent on making it easier to create the content.
> Feels like everyone is very disinterested in the cost to the user with most "modern ways" of doing things.
The only time a decision maker actually cares about the cost to the user is when they are trying to calculate how much money (or savings) they could capture from the user.
Proper engineering also takes into account the end users, even the ones that aren't paying for it. If other engineering disciplines were as hell-bent on cutting corners as SWE, these situations would be common-place:
- "cars older than 5 years are not supported on this bridge"
- "Sure, we can perform maintenance on this bridge, but with every round of maintenance work, the maximum speed across the bridge will be lowered by 5mph"
- "No, I'm sorry, you can't call our office from a landline. We only accept support calls from a Sprint mobile device, and the contract must be less than a year old"
- "What do you mean, you need to replace a fuse? You can't do that, they're built-in. Please contact our office to buy a new house".
- "Sure, our new Model T does 5 gallons to the mile, but look at its color! It's not just black, it's Vanta Black (tm)! And look at these rounded bumpers, aren't they a marvel of engineering?"
I wouldn’t be surprised if solving the problem with the Mayors constraints increased costs though.
I have a few stories where senior management, or a preferred developer had some pet project. Or crazy ideology. So we adopted that dispute protests. If we picked a standard way we would have been done faster, cheaper and with fewer bugs.
But you can do this satisfying requirements with different interpretations: here in HN we cry and whine when database queries are not efficient, when code is suboptimal, when sites are hacked and leak info and many more things. These things were all probably fine within the requirements. Just like this crap experience for the user with Electron. So where do I draw the line? And why?
Ok. What is the art of building things that are good, but violate some constraints of the real world? I’d like to use the products from that discipline.
Jokes aside, do you really not understand what GP means? "Real-world constraints" are the things like having to make money or having to do something with only 2 other programmers to help you. Nobody's claiming that, for example, academics (who don't need to have products that money) don't have other problems (like grant writing or juggling academic responsibilities), but that isn't what people mean by "real-world constraints".
> What is the art of building things that are good, but violate some constraints of the real world?
“The romans were so much better at building stuff”.
You could make buildings matching those, they’d be massively over-engineered and overpriced compared to the modern equivalent, and significantly more limited in suitable locations.
also within time constraints, building an electron app in the scenario outlined is probably a lot quicker. Normally building something quicker implies that later maintainability is adversely affected, but in this case the tradeoff is not time vs. maintainability, but time vs. performance.
Performance has generally been getting the short end of the stick since early Windows days anyway when Gates had people build not for what a computer could handle when the application was built, but rather what it could handle a year down the road.
>When you build software, you're not given 10 years, a research team and infinite money.
So actually you don't need all that to identify when there is a bird in the picture anymore, what's the new bird in a picture requirement? https://xkcd.com/1425/
> also within time constraints, building an electron app in the scenario outlined is probably a lot quicker.
But building it in Free Pascal/ Lazarus is (almost?) as portable across systems, probably at least as quick, and comes without all the horrendous overhead bloat.
Its best to understand early that an Engineer deals in two commodities: money and time. Their job is not to create ivory-tower ideal solutions. The whole problem, the reason Engineers exists, is to manage technology such that the constraints of money and time can be met.
You know, I hear this argument a lot for e.g. why Slack is a dog slow electron beast.
The thing is, slack has not been short of time OR money for at least the last 5 years. They could have easily built leaner, faster native apps and customers would have appreciated it.
This "ivory tower" stuff smacks of just world/just market fallacy.
I suspect there are deeper issues here. For example, vendor lock-in inhibiting competition paired with the "electron app team" being a powerful fiefdom within the company.
IME the concealed undercurrent of politics tends to provide a better explanation for many hard to understand decisions at large companies than unexpected technical prudence. Why does Uber's app require 150 developers? Why is Facebook's app such a beast? Why did they create a whole new "lite" app rather than slimming it? Why does Google have 13 messengers?
Reaching for a calm, rational engineering decision to explain each case is tempting, but wrong.
So once you have an app up and running, with millions of satisfied users you would hire another team of more expensive developers to build a native app.. for each platform? so make that 2 more teams or rather 4 more teams? (iOS, Mac, Android, Windows)
Telegram already does this with a rather small team. Hell, there are even third-party Telegram clients that, while a bit behind the features, eventually catch up with every single one.
You don't get to be a billion dollar company by spending money unnecessarily. The question is never the total size of the company the cost relative to other options.
See, this is interesting to me, because I come from a different engineering background and was taught that the constraints were safety first, then cost. Time to build was a part but not as important as those other two.
Obviously safety is a bit less important in the software world, but hearing time be a key part of an engineer’s focus makes me uneasy for some reason, even though it makes a lot of sense from a business perspective.
The saying about optimization goes, "Time, Cost, Quality: Choose two." You've chosen the two that most profit-minded entities choose, but they are not the only choices.
Optimizing for quality and time can be a winning solution, particularly if you can achieve novelty as well. Countless corporations and founders have had success with the strategy (Apple under Jobs comes to mind.) Optimizing for quality and cost is also viable: Deming preached it, and e.g., Japanese car manufacturers have showed it to be a highly successful strategy.
yeah but the problem is: which budget are you optimizing? That of the company of course. You offload a lot of bullcrap onto the end user. Like the author said, wasting electricity and battery life and thousands of devices just because you cant be bothered to generate html on the server to serve simple text is a common thing for news sites.
This is wasting the time as well of the end user, because its slower to load, and lower performant on the device itself
> yeah but the problem is: which budget are you optimizing? That of the company of course.
The budget of the company is predicated upon what the user will be willing to pay for the service.
You’re wasting electricity and battery life of thousands of devices of users who don’t care or want to “vote with their feet”.
Now obviously users are also constrained by what is made available to them, but time and again the shiny and early to market wins out even if it’s a literal trash fire…
Let's not pretend that such business decisions are following rules written down on stone tablets passed from above. They're nothing more than going with the flow and following the path of least resistance in a market that painted itself into a corner of inefficiency and technical inferiority. Chiefly because of Google's empire building, VC money and the quest for millions of users.
Those two facets of quality, or the lack thereof in the applications which are being discussed are undeniable and the offence will continue to be perceived until the underlying problems are resolved.
Watching the rhetoric of the web dev community over the years, I have the impression that previously they thought that the one big technical improvement will come and that will allow them to compete on equal footing with native applications. Now they've given up and just mumble something about Electron being cheaper - an improvement, even if far from the ideal :-)
> And then the mayor of the town shows up out of the blue and says no, this direction is going to have a longer wait, I'm going to delay people intentionally, so that when they're stuck in traffic, sitting there, they'll have more of a chance to see signs/placards of, and contemplate patronizing, nearby businesses, whose owners are my political backers.
You gotta be kidding me! Not only are we subjected to this constant visual pollution in the form of advertising but these politicians deliberately make traffic less efficient in order to force us to "contemplate" this garbage?
That's extremely offensive and not just in the purist engineer sense. The audacity of these people to think they can literally hold you down and force their little commercial interests into you.
> the mayor of the town shows up out of the blue and says no, this direction is going to have a longer wait, I'm going to delay people intentionally, so that when they're stuck in traffic, sitting there, they'll have more of a chance to see signs/placards of, and contemplate patronizing, nearby businesses,
> [...] usually have a "right answer" from an engineering standpoint, which as you can imagine, has to do with maximizing traffic throughput and/or minimizing delays to each individual vehicle [...]
Another common problem is when an Engineer is told to maximise a specific variable, rather than apply their wisdom to determine _which_ variable to optimise.
Optimising for more cars usually means that public transport can't improve, and moving around gets worse for pedestrian/bikes. Ultimately, mobility does not improve, and you just need more cars and more car lanes. Car flow improves, but nobody stops to think if that's really the most important thing to improve.
> "The best thing, by pure engineering criteria, is not what gets built."
How do you define the "best thing, by pure engineering criteria"?
The least memory/CPU? Or the smallest download size?
These are somewhat irrelevant vanity metrics in most cases... they're especially vain, if optimising them loses you potential clients and makes the project a failure...
Well it's a net negative for the end user, which should have been the priority for everyone involved, and what you're describing sounds like a corruption of this system. So I wouldn't call it an engineering thing, it seems far more general than that.
>> Well it's a net negative for the end user, which should have been the priority for everyone involved
I feel like you're missing the point. Let's say you are a product manager. Here are your options;
A) increase the product price so the budget can be bigger. Understand that increasing the price will lower customer numbers, but net inflows may be larger. (does this option prioritise the end user?)
B) spend all your budget on platforms with the most usage. Ignore less-used platforms completely, but deliver the best possible for your selected platforms. So 100% spend on the Windows client - - and of course ignore Apple and Linux desktop. (does this prioritise the end user?)
C) build a cross-platform solution that is sub-optimal on all platforms, but targets multiple platforms on a limited budget. This reaches the most people, but the experience from an engineering point of view is less than ideal for all of them. (does this prioritise the end user?)
How you answer depends on who you consider the end user to be.
If you see them as "people who have bought our system on our preferred platform" then option B makes the most sense.
If you see them as "people who could use our system to improve their lives" then option C makes the most senses.
If you see them as people who can afford fine engineering then go with option A.
On the up side, no matter which one you choose you are prioritising the end user, so it fulfills your premise.
I don't consider it a "net negative" that I can use a bunch of stuff on every device I own rather than just one or two. And frankly, if you happened to be involved in the sysadmin world during the long, slow death of Windows XP, you might even appreciate the benefits of Web apps even from the technical standpoint.
I'm sure COBOL programmers thought the same. Some day all the existing QT programs will need people to convert them to something else. Keep those skills sharp.
Indeed it is, however the end user is probably not the customer of the business. The business is serving its customers. Sometimes end user = customer. But often they are different sets of stakeholders with their own priorities. I'm not saying businesses go out of their way to piss off end users, but customer needs trump end user needs.
I’m very critical when a company like Slack cannot find the time and resources to make native clients. I’m so #%^*ing tired of it taking three Mississippis to show a channel I click on.
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.
I can’t think of any reason not to use Slack exclusively as a website. I’ve been doing it for years now, and it’s a better experience IMO. For Teams, the only disadvantage is you can’t share your screen and video simultaneously when running as a tab; but I find the screen sharing experience to be better otherwise when running as a browser tab.
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.
Ii run Slack outside of a tab and in its app format because it's easier to navigate to using keyboard shortcuts and OS level features. That may not be enough for you, but it's plenty reason for me, and I imagine many others.
With Chrome or Edge, you can take any web page and turn it into a standalone "app" that lives in the start menu and can be pinned to the taskbar and Alt-Tabbed to, etc.
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!
Some people in the thread said they preferred running Slack in a browser tab instead of the Electron app, perhaps to avoid the memory overhead of a separate browser instance.
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.
I would have guessed the memory consumption would be similar given the sandboxed tab model of Chrome. Anyway... even if not, do any of you guys really find that the memory consumption of Slack is a problem for you in practice?
Not a Slack user here. Is the app version _slower_ than the website? I assumed that since Electron is only a little bit more than a Chromium wrapper that they would have identical performance.
One Chromium runtime managing five tabs is more efficient than five Chromium runtimes running one site each (because those instances aren't able to share anything with one another).
Long time slack app user here, I don’t know how you guys organize your slack but performance has never been an issue for our organization, I don’t think it would run any better then it currently does if it were an os native app, of course my machine isn’t a toaster.
Lots of tools are better as websites - however underhand motives often mean mobile apps get pushed more and have done for years. Inevitably someone pops up to say "but what about essential feature X that you can't do well on the web" even though it's rarely genuinely essential or it's a worthwhile trade-off.
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!
>For Teams, the only disadvantage is you can’t share your screen and video simultaneously when running as a tab; but I find the screen sharing experience to be better otherwise when running as a browser tab.
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.
Last I used it I could see multiple people simultaneously. I could even do Together Mode, but it seemed to be rendered on a server somewhere and streamed, rather than done locally. Maybe they were doing that with webcams and I just didn’t notice.
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.
I disagree, Teams in Linux (it might be on purpose) the app is way cut out, you can't request control (or was a few months ago), you can see less simultaneous videos at the same time (iirc was 2 or 4), so no, with the app you have almost zero advantages in Linux over the browser version.
Maybe desktop Linux should get its act together to make a target that everyone else actually feels like targeting instead of grasping to the relevance of someone dropping Electron bombs as the true path to happiness, or emulating Windows games for that matter.
Usually they are websites. That's kinda the whole point... Spotify's desktop app is the same as open.spotify.com, Discord's is the same as discord.com, VS Code's is the same as vscode.dev, Slack is the same as.. something. But yeah, instead of those companies all needing 5 separate engineering teams (Web, Mac, Windows, iOS, Android, and you're joking if you think they'll make a Linux native app), they just make a website. You're welcome to use the websites instead of the desktop apps for any of those, though you'll lose some OS integration capability.
I think it's a huge pity that we're so reliant on platforms instead of protocols - there would be native Slack clients for every platform. Few companies even allow proper API access.
Small companies loves protocols, but as they become big and dominant they start pivoting to platforms to exert control and extract more profits from the ecosystem.
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.
There are tradeoffs beyond just the company making more money, as Moxie's recent web3 assessment covered. Protocols take much longer to evolve, platforms are quick to evolve.
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 UK open banking regulations are a good model to follow.
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).
> Stuff like email, http etc is what makes computers great.
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.
Crazy idea that I'm sure isn't an original thought: instead of adapting the languages to deal with abstracting the idiosyncrasies of each OS, change the OSes to expose a universal API to make everything else lighter.
Cross platform 'windowing toolkit' APIs are what's missing. At this point I'd be happy even if Microsoft, Apple, and UNIX likes (who would probably just implement any free open standard anyway) could agree on even ONE such interface.
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.
That would be ideal, but there are huge differences between the window implementations on different platforms.
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.
If those don't go altogether stagnant then usually what happens is there are a bunch of features that only work in the "official" implementation so it's a degraded experience anyway.
I'm kinda hopeful that Maui+Blazor will eventually let us have our cake and eat it too - instead of "everything is web", do "everything is a desktop-style gui framework" including the web. Although AFAIK they don't even have a web renderer on the horizon right now - purely desktop+mobile.
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?
> Should it not be possible to style a native GUI application with the same framework language as for a website?
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.
Isn't that basically what Flutter does? In my experience, it works well enough for mobile, although you still have people saying it's not "native enough." It's less stable on web and desktop though but it works.
Flutter on web is basically unusable for anything that involves text or links. The browser has so much native functionality here that trying to reimplement it is futile.
> You're welcome to use the websites instead of the desktop apps for any of those, though you'll lose some OS integration capability.
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.
This gave me the idea to use uBlock Origin to hide Spotify's "Episodes for you" section... a simple `open.spotify.com##section[aria-label="Episodes for you"]` and I don't have to deal with their spam ever again!
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"]
This may not end up being the cakewalk I was expecting.
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 isn't feature complete in their webapp if they even still have it. vscode.dev is new, the app existed for a long time. In practice, its the reverse; it allows you to turn an app into a website and add yet another supported platform.
This is something I think many HN'ers don't understand. For a good amount of modern web functionality, being supported in Firefox is less a matter of "do testing in firefox and make sure things work there" as much as it is "have a very popular product and good marketing team so that you can convince the firefox team to whitelist your domain in their internal maps of `what cool things should X domain be allowed to do`". People see that Slack works in Firefox, but Joe's Voice Calls.Com doesn't, and blame Joe for not supporting firefox. In reality it's firefox that doesn't support Joe.
You misunderstand, you have the situation exactly backwards. The problem isn't that Firefox doesn't support these APIs, it does support them and the problem isn't that they are limited to specific domains, they aren't. The problem is that the Slack code is `if isChrome() { enableCalls() }`. Mozilla has to spoof the user-agent to bypass this check. Joe's Voice Calls.com will just do no conditional or do feature-detection rather than user-agent checks and everything will work fine.
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.
Ah, indeed I misunderstood. Though to be fair, at $DAY_JOB we had to do exactly the process I described above to access some API (not auto-play) without a litany of obnoxious prompts. If anyone at a smaller company tried to do what we were doing, they'd be 100% unable to provide a usable experience for Firefox users.
Hey, look, it's simple: just spend $5k on a new top-of-the-line M1 Max MacBook, then it'll be as fast as IRC was on a 133Mhz MMX Pentium 1.
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"?
IRC isn’t even remotely competitive vs Slack for 99% of its users. It’s the same ignorant take you hear from people who complain about Excel files. The overwhelming majority of users do not experience the cosmos at all like you do.
One thing about Sheets vs. Excel: Appscript for automation is a lot easier to get set up with than VBA ever was to the point where my org has a ton of things that we just throw a small amount of Appscript at (E.G. generating performance reports) because it just works and it doesn't require a lot of processing power (yay, cloud!)
Are you suggesting that a massive company should run their own IRC server, complete with bots that handle OAuth and access control, history saving, document downloading?
I'm not suggesting anything really. If anything I'd be happier for even more asynchronous collaboration via email, and realtime chat available as an exception.
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.
> I’m very critical when a company like Slack cannot find the time and resources to make native clients.
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.
I agree Electron is a great way to serve tons of end users. But lets not exaggerate, there are 4 main systems to target: iOS, Android, Windows and Mac. Its not that insane to have 4 well optimized applications, instead of 1 mediocre-fits-all approach.
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’m so #%^*ing tired of it taking three Mississippis to show a channel I click on.
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’m very critical when a company like Slack cannot find the time and resources to make native clients.
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.
Compared to what? Java? Have you used c#.net, or for that matter Delphi or VB6 in their heydays?
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.
There's still a huge advantage for Electron - it's still fundamentally the same tech underneath - HTML, CSS, JS. Any semi-competent web developer can use Electron and ship cross-platform apps with it, and heck, lots of code can be shared between Electron apps and the web "app". None of the other options provide these facilities.
But, you then have all the problems with JS/HTML/CSS that web developers have. Like for example being able to support scroll bars and the like in a reasonable way. We accept certain poor behaviors from web apps because they are bound by a technology stack that is in many way sub optimal for the needs of the user.
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.
It's not that I don't appreciate it. It's that I _don't care_. I've only got 16gb of ram, and much of that is used by things I actually care about, like airsonic, a Linux VM, fb2k, etc (yes, my PC is my home sever). Even if I were to dump all this, there's a limited number of electron apps I'm willing to use, and none of them are things I leave open all the time. Authy particularly annoys me, since I have no choice if I wish to use their authenticator (humble bundle doesn't support totp, only Authy 2fa)
Last time I looked at Lazarus its autocomplete/suggestion was not on par that I've become to expect from VSC/Intellij and modern languages. Also, who wants to write things in FP nowadays? I was toying with the idea, but I don't want to end up abandoning my project midway just because FP happens to miss an important library or db driver or something else.
The pascal thing has its own advantages/disadvantages. Finding people with pascal experience is going to be difficult, but i'm not sure this is really any worse than some of the web/framework wars. Pick a framework and likely in 5 years your going to have problems finding people who are experts in it because they have all moved to something else (although maybe that is settling down angular/react are still around). OTOH, Pascal is a far simpler language than JS, for sure it has fewer gochas than JS does at this point, and it supports proper threading if you happen to need that among other things. Its definitely stagnated, but that's probably a good thing if you plan on building a long term business around it. I'm not sure I would consider editor features like auto completion very high on my technology selection, particularly since you can 1. fix it, 2. use a different editor.
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.
Autocomplete was one example, but I wouldn't underestimate the importance of tooling when you want to onboard people new to the language. Does fp even have package/dependency manager? How good are linters?
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.
I'm actually surprised either Microsoft, Slack or a new startup in the space haven't made a native app yet. Wouldn't even need to be all of them; Teams could be a native Windows app and keep the electron one for mac/linux/mobile. Or Slack could make a native Mac one first.
Seems quite mad considering the use/value of the tools and the absolutely enormous user base they have.
Considering that in Mac you have universal app (so in theory your iOS app can easily become a Mac app), but they don't want, even they opt-out from the universal app program so you can't install the mobile app in the desktop.
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.
Because they already have a codebase that uses HTML for UI, and a team that's proficient in it?
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.
IMO OS vendors could create an electron detection mechanism and start making electron instances use shared libraries and memory for their browser instances as part of a swap in the kernel. When you remove the "virtual OS container" that come with every electron app (their browser instance), you remove a significant amount of resource waste they have. Then they're pretty much QT apps written in python in the level of performance and memory they use.
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.
If the OS doesn't get updated, then some of those electron apps might stop working properly as they are expecting to target a particular version of Chromium.
It would be a bit smarter and generalized than that, it would detect new chromium 'version bases' and differentiate based on that. Eventually it will stop working, but if you don't update your OS after a certain point, new app versions wouldn't work anyway, or they would fall back into standard mode.
The whole “newness” idea seems odd anyway considering electron must be coming on ten years old now.
> The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper".
This is spot on. I’ve worked on a big electron project before for a massive firm and a lot of work was done before picking that direction. Proof of concept was done for a couple of alternatives but electron ended up better on balance.
I mean, this isn't the first time in history that quality and performance got thrown under the bus for the sake of cost. When developer salaries are your highest cost, and you have to make more and more money, eventually everything will get (and has gotten) sacrificed at the altar of "developer cost".
Historically, commercial software development has never been the place for perfectionist "software craftsmanship". If you want to make the world's fastest performing, native, bug-free, warning-and-lint-free, most beautiful and elegant software project, you're going to have your lunch eaten by the competitor who throws together a barely-working, bloated JavaScript mess in 1/10 the time. The people who take pride and "sand the back of the cabinet" go out of business. At the end of the day, customers (broad generalization) don't seem to care about performance or quality. So, purely by survival of the fittest, these frameworks are going to take over every software project they possibly can. Sad if you care about native/performance, but inevitable as the tide.
It's not (just) about money or profits. As a solo web dev, building for desktop with electron is faster. It saves me time, the most valuable resource. How I choose to spend that extra time - on more features or on vacation - is up to me. I don't want to spend it on learning yet another way (or several) to build UIs and apps, when I already know enough to make a good enough product for my goals. It would be great if Electron was less resource intensive, yes. There's Tauri and other alternatives that will eventually replace it and solve the performance problem.
You can blame OS vendors for trying to build a moat with OS-specific, not web-compatible UI toolkits. Don't want to touch that, don't have to, thankfully.
You are saving your own time and resources, in exchange for those of every one of your users. That insanely selfish attitude is why we are so incensed by this crap --- especially when it's developers making the lives of other developers worse.
Have some respect for your users; they might be developers too.
You're presuming that these users would have a product, even if it took several times longer for the developers to build. That isn't always (or maybe even often) true.
There are tradeoffs to be made; being absolutist about it isn't helpful.
> I think there's already more than enough quantity
That's just not true though. People need so much software, I've written more than one mediocre electron app for niche use cases that saved users multiple hours a week of mind-numbing work. That software that they're so happy to have in their lives would still not exist if it weren't for electron.
Almost none of those users are willing to pay 4x the price for native iOS, Android, Windows, Macos, and Linux apps (on top of the web version).
Also, I do not, in fact, have 4x the time to implement all that, vacation or not, nor do I have enough revenue to justify hiring a team of specialized developers.
It's about as selfish of me to be building on Electron as it is of you to not be working full time on Tauri or some other secure and high performance solution to this problem. Which is - not at all. Nobody is entitled to our dev time for free or against our will.
Realistically, the alternative to an Electron app is not native apps for multiple platforms. It is either a web app or a native app for a single platform.
Fully agree. I have a background in C/C++ and a bunch of other languages, I'm probably in a better position to write native apps, and am no Electron fan, but I never got into native GUI's for a reason. Certainly if they have to be portable, it's an absolute mess. I already did throw together basic VueJS web apps for management interfaces for another projects, and now I need a similar interface, but with some OS-level access. My choice right now is not between a native app or an electron (or something similar) app, it's between having an actual viable project/product or having nothing at all.
I can't afford to waste time and money on native apps for multiple platforms. And I know that once my thing would bring in money, I could easily find someone not too expensive to take over the work on that UI.
Native apps cost a LOT more money, not to mention organisational overhead to bring feature parity to all. Bringing something native to 4 platforms is nowhere near an x4 cost, optimistically it would be more like x8.
I thought it was that it was the browser as part of the OS which was the issue from being priveledged in performance (regardless of security concerns).
I conjecture that if the alt-universe Microsoft could have dodged that bullet via different code structuring. If there was a "HTMLReader.dll" available which handled the HTML page display rendering If Internet Explorer, its help file reader, and any other implementer of the API could use it there would be no antitrust issue because it doesn't technically priveledge their own applications. Not a lawyer but it would be interesting to know if I am right or where I went wrong.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
I learn plenty of technologies - those that I want or need. I neither want nor need to learn any desktop GUI frameworks for my purposes, so I don't. Certainly not going to do anything just because some troll told me to.
If you want to make the world's fastest performing, native, bug-free, warning-and-lint-free, most beautiful and elegant software project, you're going to have your lunch eaten by the competitor who throws together a barely-working, bloated JavaScript mess in 1/10 the time.
On the other hand, things like kdb+ and the like show that there is a market for excellence. It's unfortunately rare, but it's there.
There are multiple platforms and nobody wants to write a separate app for each one. So now you need a framework to make apps multi-platform.
Microsoft has resources but no incentive to do this. They have the most market share. Before Electron existed, people would just write native apps for Windows and nothing else, locking people into Microsoft.
Apple has resources, they have the right incentive because they don't have dominant market share on desktop, but they're obsessed with native look and feel. Cross platform frameworks are antithetical to that, so they don't do it.
That leaves the Linux people. So we get Qt. Finally something that works. Except that this is the opposite of what the Linux people are good at. It's not "do one thing do it well," it's reimplementing the equivalent of an entire operating system's APIs on at least three different operating systems. That's a lot of work, it's hard to do right and easy to get wrong, and they don't have a mountain of cash behind them. So it works but it's full of sharp edges.
Enter Electron. Browsers had to deal with the same multi-platform nonsense but Google does have a mountain of cash so it's easier to use. Winner, efficiency be damned.
What might have worked if anybody there thought of it would be for Apple to port their native APIs to Windows (because it has the most market share) and Linux (because it's a fellow Unix-like so that should be pretty easy). Then you could easily compile native macOS applications for other platforms but they would still be native on macOS. That solves their problem because now everybody is going to target their native API, and if they run less well on Windows, that's fine as long as they run at least as well as Electron does. Big win for them because now that becomes the target and they're the only ones with true native applications.
From my experience, these Microsoft frameworks never really get picked up by larger parts of the community.
I feel like Microsoft's approach is to create a framework for everything and hope it sticks - though they appear to repeatedly fail. Nobody really used Xamarin. Nobody is using Blazor.
This very minimal documentation of Maui doesn't really scream confidence in their own product, either. I predict this one will die as well.
This so much. Google gets a lot of critique for killing of its products, but Microsoft does the same in the developer community. Except they don't even have the decency to properly announce it when they consider something abandonware
Such web solutions are cheaper because the software market is really sick. There is almost no point in competing on quality and performance for consumer software, because some start-up with hundreds of millions of VC funding or some SW megacorp will enter the market and give their mediocre product away for free while paying engineers N times more than what you can offer. Bonus points if the software is at least partly open source or integrates with some standard (which will get nixed once they have enough market share).
And those VCs and that CEO won't be particularly concerned with technical excellence, they'll focus on their metrics regarding user acquisitions, market share, etc.
Since technical excellence is of at best secondary importance, it makes sense to commoditise the technology and make it as easy as possible to build such applications. Build some framework, give it away for free, ideally open source. Brag about how you're enriching the world through your open source contributions. Optionally snicker at the fact that you're in fact controlling how things get built on the so-called open web.
Relax on your yacht while drinking a good champagne. Don't explain to the poor sods still worrying their brains about technology why "the economics" prevent building quality software, because you don't give a fuck anyway. One of your employees or the employee of some other web company will surely set aside some time to clarify this, like the good little employee that they are.
I think the underlying explanation for this is that the world sucks. Most of the companies that are commonly thought of as tech companies aren't.
My definition of a tech company is a company that lives and dies by the quality of technology they make. For example Nvidia is a tech company. If someone made GPUs that are half the price, but twice as fast, Nvidia would be out of business in a jiffy.
Spotify isn't a tech company - if someone made a better music player, they wouldn't be able to disrupt Spotify, unless they somehow managed to make a deal with every record label under the sun.
In the 2000s, I had a 20GB Music folder full of music I liked, and I played them using Winamp, which supported searching my library as fast as I could type. It didn't have all of Spotify's features, but the it did the core value proposition of playing music better than Spotify does today imo.
The problem is that Spotify is a package deal - if you like the service, then you must use the client - and they are under no competitive pressure to make a better one.
The 'it's much cheaper' argument is ridiculous - it's not that hard to create a native app that plays music - I doubt the people who wrote Winamp commanded the salaries FAANG people writing Electron apps do today.
'Tech' companies make much more money today than when they were making when they were writing native stuff.
> hiring a few JS bootcampers to build one react UI that works on every platform is extremely cheap
But this is the point: Technological development could go in one of two directions: Allow skilled people to build increasingly bigger and better things, or allow increasingly low-skilled people to displace the skilled people by creating things that are worse but still vaguely fit-for-purpose. -- The industry is going the latter path, which is highly offensive to those skilled people.
The thing with Electron et al is that the GUI dev tools on it are the best thing humanity's come up with, by a country mile. It's vastly, vastly easier to develop a really good, clean app, with a great UI in it — especially a UI that needs lots of unique, new components that aren't in an OS-level GUI api's standard set. You compare really well-built electron apps (VSCode, Discord) with their competition, and it's such a staggering, one-sided comparison in "fit and finish", attention to detail, and not having weird little bugs that never get fixed. I say this as a former OS partisan, but even Apple, previously the trophy-holder for "best gui-builder tools", is way behind the curve. Steam, too, is now an electron app.
The thing that's just the brutal nail in the coffin is — if it just had the attributes mentioned above, it'd be a huge win. But to have "nearly perfect cross-platform support out of the box with no effort?" Jesus.
The thing about electron is — some 5 years from now, we're likely to start shipping electron apps that run on WebASM rather than JS, and at that point, there won't be any valid counterargument. They'll have all the benefits, and run just as fast and lean. Game over.
I'd argue that Steam isn't 'now' an electron app but was the OG 'electron' app. The store and community interface have always been web UI from day one.
Originally it wrapped the IE/trident engine and then transitioned to chromium.
> The thing with Electron et al is that the GUI dev tools on it are the best thing humanity's come up with, by a country mile. [...] even Apple, previously the trophy-holder for "best gui-builder tools
You've never used Delphi, FP/Lazarus, or even Visual Basic, have you?
A bit of a digression, but iMessages is supposed to be a native app and it sucks ass on macOS. buggy, slow to load previous messages, and have to force quite from time to time.
From my experience, many native apps suck. But a lot of them are good. Same goes for electron apps.
Also, native app development process is way worse than solutions like electron and react native in terms of feedback loop and DX. Ofc they have downsides as well since they're abstraction layers.
> The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper".
I'd argue it's not cheaper overall, just for the company choosing to do the development.
What I mean is, the lost productivity of waiting around for slack to load a channel is essentially outsourcing this cost difference via poor performance.
And yet the market (the users) choose to use Slack over alternatives. If this lost productivity was a problem for the general market, Slack wouldn't have the market share it has.
From what I can see Slack's market share is dwarfed by Teams'[0][1] and similar to Discord's[2]. This is not strictly an argument against your broader point as I believe all these apps are essentially the same in technology stack.
Regardless, it's hard to look at that one feature and determine that conclusion from it. There's a of other pros and cons to be weighed when making any kind of decision like this. I'd suggest hosting, overall UX, and corporate support probably make up far more of the critical success factors for these kinds of apps than their older competitors. The lost productivity and poor performance are the cost of these other features, apparently. Perhaps in the future there will be a new disruptor to the market that will do this same thing but with a fully-native client application that is stabler and more performant than their competitors.
I personally consider IRC (or I guess more precisely, IRC clients like Weechat (Not to be confused with China's WeChat)) a contender, as it provides chat functionality as well as the ability to create channels for themed discussions.
No, it doesn't have emojis or inline multimedia, but IMO it delivers the important part of chat and leaves the unimportant parts for other applications (like opening a hyperlink from IRC chat to see the clever meme someone posted). It also doesn't do video or voice, but there are other applications for that as well. For purely text chat, IRC is a lightweight (and self-hostable FOSS) solution.
>What I mean is, the lost productivity of waiting around for slack to load a channel is essentially outsourcing this cost difference via poor performance.
What makes you think that Slack's loading times is due to Electron, not shitty backend?
If it were the backend, I would not expect the load times to improve when loading Slack into a browser tab where its resources are constrained.
Separately, if it were strictly a Slack problem and not Electron, you wouldn't expect to see these kinds of issues crop up across the spectrum of Electron apps. Scroll through this thread and you can see a variety of people running into these problems in all kinds of different electron-based apps:
> The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper".
Expecations have changed.
It is 2004, your company needs a simple CRUD app so your employees can work with some structured data in a DB somewhere, let's say so sales can check inventory levels in an existing database.
A single developer can start up a Winforms project and throw something together in a matter of days to weeks. It can only be used by people on desktops running Windows while they are at the office, but that is fine because that is the world of 2004.
2022, your sales team needs to access inventory levels in a database. Assuming you haven't already been sold some multi-million dollar solution to do this (and you likely have, multiple times, and at least some of the implementations have failed), you now have the following requirements:
1. Some of your employees use Apple laptops, some use Windows.
2. People want to be able to access the data on their phones as well, which adds another 2 OSes to the mix.
3. Restricting the app to being onsite in the office doesn't cut it.
So, you can write 4 (!!) native apps. The ugly WinForms one is still simple, but you can either adopt a proprietary "simple app building" solution for the other 3 OSes (or just use it for all 4 OSes), and have serious issues finding devs who know the niche tech you've picked, or you can make a website.
Now, native apps on smart phones are a constant maintenance headache. Major OS releases break things on mobile all the time, and entire APIs get deprecated. (Another reason why writing against Windows is good, that Winforms app from 2004 probably runs just fine with 0 changes in 2022) It is easier to maintain 1 website than 2 mobile apps and 2 desktop apps.
So, website it is.
What framework are you going to use? Whatever one is stable, easy to hire for, and has the best tooling. OK so I wouldn't call React "stable", hopefully it has undergone its last major redesign for awhile (LOL), but there is tons of tooling for it. Of course the docs suck compared to what Microsoft had in 2004, because it turns out part of that $500 per seat license for Visual Studio went towards amazing documentation and example code. And because Web you'll get breaking changes now and then, but it still is easier than maintaining 4 native apps.
People underestimate how simple Windows everywhere made life for developers. Amazing documentation, stupid good tooling, and an obscenely stable platform to develop against. A major OS version came out what, once every 3 or 4 years? And unless you were writing drivers, that major OS version wasn't going to break anything.
>A single developer can start up a Winforms project and throw something together in a matter of days to weeks. It can only be used by people on desktops running Windows while they are at the office, but that is fine because that is the world of 2004.
...
>People underestimate how simple Windows everywhere made life for developers. Amazing documentation, stupid good tooling, and an obscenely stable platform to develop against. A major OS version came out what, once every 3 or 4 years? And unless you were writing drivers, that major OS version wasn't going to break anything.
I was doing this exact work during this time and things weren't that easy back then either. Does anyone remember DLL Hell[1]? Even if everyone was running Windows on an corporate machine, it was still more difficult to deploy new code than it is today. Being able to deploy the same code to a wide variety of different machines is a huge cost saver today.
I was doing that exact work back then, as well, and DLL hell was mostly gone by then. If you had a dependency, you simply packaged it alongside your main binary, and it wouldn't affect any other app on the system. DLL hell only arose when apps would try to install their dependencies globally (i.e. into \WINDOWS or \WINDOWS\SYSTEM32), but it was already rather uncommon by early 2000s, except for the most foundational runtimes like the C++ one.
.NET pretty much solved the problem even for globally deployed dependencies by imposing physical versioning, and added file signatures for good measure, so that your dependency would literally be on that exact copy of the DLL.
I had direct experience with some apps in VB6, some in Delphi, some in .NET/WinForms, and even one in C++/wxWindows. None of them had any DLL hell issues. Not as in I dealt with them, but as in they simply never arose in the first place.
> Even if everyone was running Windows on an corporate machine, it was still more difficult to deploy new code than it is today
Is that true? As someone who was also doing native Windows desktop applications back then (C# and VB in .net from 2006-2010), ClickOnce handled everything pretty reliably for Windows XP/Vista/Server (even with weird DLL requirements -- for example, I had to ship a QuickBooks Desktop API wrapper and propritary Epson drivers in our .net desktop app)
Yes, it's not quite as reliable as "go to my-app.com". But it was way more reliable than Electron's current self-updating (.net ClickOnce loaded in a tiny fraction of the time that Slack and Discord's Electron apps take to check for updates on every launch)
Well that Wikipedia page exists so I wasn't the only one running into the issue. I will note that the time period you listed is a few years after this problem peaked. These issues were a lot more pronounced in the VB Classic era and were greatly improved in the first few releases of the .Net Framework. Your timeframe is just after that.
I cut my teeth during that era and the level of complexity asked for from those apps was minor compared to what people will demand today. Your native app will also require every machine to install a bunch of extra libraries before they can even run your little CRUD app.
At some point you maybe wrote a cute little auto-update function that let you update the application automatically... until IT slapped your hand and told you never to do that ever again.
You could write a similar web app in any modern framework in just a few days as well, and have it work on any device with a browser. It updates automatically and IT doesn't give a shit. Yay!
I have a pet theory that one of the big things that drove SaaS adoption was that people didn't need to deal with IT gatekeeping. You could get the latest software RIGHT AWAY! As soon as the devs finished it! Incredible!
Wow! I remember working for a company having to deal with your 2022 scenario way back in 1997! Only back then we didn't have npm, react, or any other of a dozen Javascript frameworks I've forgotten the name of.
Oh, and we did it without Visual Studio as well. Kids today.
> So, you can write 4 (!!) native apps. The ugly WinForms one is still simple, but you can either adopt a proprietary "simple app building" solution for the other 3 OSes (or just use it for all 4 OSes), and have serious issues finding devs who know the niche tech you've picked, or you can make a website.
Or you can adopt a free software / open source simple app building solution for all four OSes (or, hm, at least three of them -- not quite sure about iOS) that compiles natively on these and many other OSes. Sure, the UI would preferably be designed differently for desktop vs small-screen mobile, but you have that problem with Electron too, don't you?
> OK so I wouldn't call React "stable", hopefully it has undergone its last major redesign for awhile (LOL), but there is tons of tooling for it.
I'm not sure what you're talking about. The last major feature addition to React was Hooks in 2018. But that didn't break stability at all - you can still use all of the old React APIs and ignore that Hooks exist entirely. The React team has actually been incredibly thoughtful about introducing new APIs, rarely break backwards compatibility, and it's a library I generally trust _not_ to break anything on updates.
If you work somewhere that insists on flavor of the month development using the shiniest libraries and the newest features, yeah, there's a lot of churn, but that's a very different complaint from "I wouldn't call React stable".
> The last major feature addition to React was Hooks in 2018. But that didn't break stability at all - you can still use all of the old React APIs and ignore that Hooks exist entirely.
Yes, except that hooks completely changed how React is written, and most libraries and code samples now days use hooks. You basically had to learn a brand new way of writing React. I learned react pre-2018 (tens of thousands of LOC written) and I basically "don't know React" now.
Then there is the ecosystem churn. I got tired of my routers breaking, all the bloody time. In 2 years I had to rewrite the routing for my code twice, each time took multiple days of frustration[1].
There has been the rise and fall of Redux, which again, massive churn in the ecosystem.
[1] In defense of React I was using React Native Web which, at least at the time, was a pile of many small disasters combined into a single code base. Also it wasn't as well documented as I'd like, and eventually I had to scrap it and move to regular React, which solved many of my issues.
> And unless you were writing drivers, that major OS version wasn't going to break anything.
Just a minor nitpick, but the NT device driver API has in fact stayed largely the same since Windows 2000 and in comparison to the various technologies that came and went in userland.
And then MS got pissed at Creative for having drivers so bad that crashes from Creative sound card drivers accounted for a non-trivial % of all Windows crashes. The result was MS changing the entire Windows audio stack and eliminating Creatives most lucrative product line.
I don't have much to add, except that WinForms was an absolute dream to work with. I was literally illiterate in any kind of programming and I was able to build stupid little apps that actually did things.
I remember writing one utility that would turn off the monitor with a global key shortcut. It had a little window with just one button, and would minimize to tray.
I was able to build it just by downloading the free version of Visual Studio and reading the docs. The extent of my programming knowledge at that time was doing some silly LOGO stuff in school.
And internal websites are a direct competitor to Winforms.
Every year someone telling me Xamarine forms is better now, but every year someone tells me that they tried Xamarine forms the year prior and it still wasn't any good. My one experience with Xamarine forms was watching 3 apps teams (WinPhone, Android, and iOS) all struggle to write an app. Given that it took 3 teams, and it was a large effort, I wasn't impressed, but this was 6 or so years ago. I hope things have improved since then!
Fun fact, for awhile Silverlight was huge in the internal website world, and Microsoft could have easily had another decade of lock-in going on, but then MS killed Silverlight due to internal politics, and even the most loyal MS customers saw the writing on the wall and redirected their internal development efforts elsewhere.
90s Microsoft would never have abandoned a technology stack that had wide spread internal corporate adoption. :/
> The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper".
Cheaper sounds like something that is always the right thing to aim at, but it also constrains the product and the business around it to a model that has shrinking margins. That might be the best bet to make. It rarely results in durable businesses. Unless there's some other sort of moat in play.
Comment fails to account for user perspective. As a user I do not want Electron nor React. It does not solve a problem for me, it creates a new one.^1 I would rather someone like UNIXSheikh make the "engineering" decisions.
1. I avoid both Electron and React. I like UNIX. Runs on many platforms.
I definitely empathise with the author. The web space is particularly prone to fashion driven development (FDD). Despite that I think he's a bit off the mark. Most consumer facing development isnt and has never been "engineering" outside of safety critical applications. It's more akin to domestic plumbing. You're connecting existing components together and while there's a skill to it, the skill ceiling isn't that high. Programming however (as opposed to development), even where software engineering does take place, is a craft. It's something that you learn by doing and it takes time to learn to do it well.
Modern frameworks and software development techniques are often the equivalent to handing a complete amateur the keys to a fully equipped wood working shop, complete with laser cutters, CNC routers and a load of power tools and letting them have at it with only a few YouTube videos for guidance. Sure they'll be able to make things, and larger and more impressive things than if they could only use hand tools, but the resulting creations will be over engineered, or rickety, or just plain badly designed compared to furniture created by someone who's spent a few years apprenticed to a master craftsman.
And you know what, that's fine. 99% of web development is still teenagers desperate to be the next Elon Musk hawking Tinder for marmosets to VCs, WordPress sites and e-commerce. It doesn't matter if it's a bit shit and is developed by people who learned their craft on Udemy and by watching 10 ways to turn yourself into a l33t programmer videos. The concerning thing is when that philosophy starts to infect areas where actual safety critical software engineering is done. No one wants a l33t programmer with massive scrum skillz designing the control system for a nuclear reactor...
to be fair though, isn't "it's cheaper" just the same thing the article laments from the consumer side? It just extends the argument from "devs are cheap" to "users are cheap as well"
the overriding concern seems to be that if we continue to stack crappy tech on top of crappy tech and accept it as consumers for twenty years we've built the tower of Babel (some might argue we're there already) and that this is terrible long term engineering.
If we treated semiconductors or aerospace engineering the same way we wouldn't have any chips to run electron software on and the planes would keep falling out of the sky.
I mean, you named the precious few that don't suck, and two of them do essentially the same thing, and the other is a music player with a very questionable business model.
I'm with the op. I'm deeply unimpressed with the last decade or so of software development; and that's not just blowing smoke -- this is day to day practice. With the exception of Discord, I deliberately take pains to use old software because it's better.
Moreover, I find when I show non-tech folk "how I do things with old software," most want to learn more, and nearly none are satisfied with what they are "given."
> perhaps with the only exception that now a 2 year old baby can make something shiny that you can click on with your mouse.
True, and the author highlights the benefit himself.
Maybe there is an underlying truth here as the number of users isn't indicative of quality and they might be successful if implemented differently.
Apps like Teams are a severe resource hog, software is getting slower even if machines improve. I use electron myself for visualization, but I know it is not the optimal choice.
and thats exactly his problem. Its about dumbifying the development cycle, with often terrible results for the end-user. Its a race to the bottom about 'how low can we go' and 'what will our users tolerate'.
Not all Electron apps are bad, but thats because they are still doing a ton of work to actually make it a little bit smoother. But this is in spite of Electron, not thanks to Electron.
To be fair, Discord is only as popular as it is because Microsoft was insistent upon alienating its Skype user base to the maximum extent of its ability.
> Hiring experienced desktop application devs to build a quality native app for each platform is going to be expensive,
So it looks like software would vastly improve if silicon valley companies moved to india or russia or some other place with abundant supply of capable developers.
Regardless, what you said doesnt show that it was a strawman, it was still a valid conclusion, but you re offering the real reason behind it.
Depends what you're writing. People aren't going to write performance-sensitive apps in Electron, like FPS games where customers demand 4K 120 FPS with full graphics enabled. But for Image burners (balena), Drone software (Betaflight), and Sophisticated code editors (VSCode), it's hardly a concern.
Yeah, it's worth pointing out that people are blaming electron for what's wrong with Slack. When, perhaps, it's just Slack itself that sucks?
I use Discord all the time, which is one hell of an oranges-to-oranges comparison (with Slack), and not only does it have none of the perf problems of Slack, it's also faster and snappier than any NATIVE chat app I've used.
There's a lot that can be done wrong in any framework; as recently as windows xp, there were a few atrocious algorithmic-complexity gaffes in basic file viewing (directories with more than a few hundred files would slow to a crawl in the GUI, taking multiple minutes to display). It wasn't the fault of the framework it was written in; it's just that someone at MS had written something that had to scan the directory in a hurry, and ended up accidentally writing an exponential-time algorithm. Slack likely has a few deep-seated goofs in their architecture that are just too big to extract and fix.
If nearly every single professionally written and quality vetted code created on JS is so slow that it takes several seconds to do things that software used to do instantly 60 years ago, is this really not a problem with the language?
Yes, JS can be much faster than every single piece of it you will find people using. It's just that every developer that has some main focus different from execution performance is holding it wrong.
Totally agree. And I'd argue it's not even a new trend. Consider Infocom's Z-machine. What was that if not the Electron of its day? And the right decision from both a technical and business perspective.
What is it about building "web-related technology" that makes it so cheap? Is it actually that much cheaper? And if so, why? Why isn't there a platform for making apps that compares?
> What is it about building "web-related technology" that makes it so cheap?
Mainly a huge existing (and ongoing) investment from Google.
> Why isn't there a platform for making apps that compares?
Not enough money in it for a company that would make something properly polished, and the open-source stuff works well enough for its own developers and gets bikeshedded to death whenever anyone tries to add good defaults and provide an easy onramp (if anyone even cares enough to try). Like, in theory you could glue together something with Python, Qt, PySide and Freeze where someone can write two lines of Python, push a button, and get GUI executables for all major platforms. But good luck getting anyone to accept your patches or commit to not breaking compatibility with what you're doing.
A huge pipeline of labor who understands it and mature tooling that creates a much lower skill floor for labor to be productive. Bootcamps, tutorials, freelancers, contractors, there's a _lot_ of resources in all sorts of languages about web development. Many fewer resources on trading packets over TCP, or making a desktop GUI, and even fewer on cross-platform GUIs.
The argument for Electron and React Native isn't "it's modern", it's "it's much cheaper". Hiring experienced desktop application devs to build a quality native app for each platform is going to be expensive, hiring a few JS bootcampers to build one react UI that works on every platform is extremely cheap - shittier performance is the tradeoff to instantly have access to every platform. It's not a coincidence that Electron apps like e.g. Slack, Spotify, Discord are massively dominant players in their markets, I doubt you'd look the engineering leads of these companies in the face and tell them that you believe they put no thought into the tradeoffs of Electron and that they're just following trends.