...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.
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.
- Someone
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").
"The perfect race car crosses the finish line first and then completely disintegrates"
- Ferdinand Porsche
(I took some liberty with the translation - the idea is that everything breaks at the same time.)
* https://quotefancy.com/quote/1791488/Ferdinand-Porsche-The-p...
[edit] Achshually "An engineer can do for a dollar what any fool can do for two" - Arthur C. Wellington
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.
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.
...That's because (unless something has changed in Wordpress relatively recently) what the browser receives is, in fact, "flat HTML".
Wordpress is written in PHP, and all the processing happens server-side.
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.
Engineering without constraints is easy, but it's not engineering.
- "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?"
Imagine a world where our currency is decentralized and the user owns their own data!
kek.
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.
Science fiction.
Somebody designs user interfaces for use in Hollywood movies. They don't have to be practical or even feasible, they just have to look cool.
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".
Magic.
“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.
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/
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.
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.
I am really just trying to emphasize that there are tradeoffs lurking everywhere and they are often hidden by assumptions.
Example of such apps ? There should be plenty since it easily built.
Or did you mean good desktop apps in general in which case where do I start...? There are thousands.
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.
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.
You can give any number of examples where time has a loose constraint.
This is wasting the time as well of the end user, because its slower to load, and lower performant on the device itself
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…
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 :-)
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.
I knew it! Ha!
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.
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...
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.
If it reduces cost, it is really a net negative? A lot of effort went into making the Apple II cheaper. Was that a "net negative" for the customer?
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.
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.
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!
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.
That one of the reasons I don’t use the Google Chats PWA , when the browser misbehave, it will affact PWAs as well.
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.
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!
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.
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).
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.
Standards are good. IETF is the reason for some sanity in IT.
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).
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.
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 :)
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.
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.
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.
But maybe it should be.
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.
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.
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.
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.
> 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.
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.
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.
Have some respect for your users; they might be developers too.
There are tradeoffs to be made; being absolutist about it isn't helpful.
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.
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.
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 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 [email protected] and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
This mindset is why
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.
But is modern Apple smart enough to do that?
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.
Hmm, I don't think this is true.
Also this is kind of different beast - WASM has some limitations that need to be overcome
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.
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.
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 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.
Originally it wrapped the IE/trident engine and then transitioned to chromium.
You've never used Delphi, FP/Lazarus, or even Visual Basic, have you?
___
[Edited to add (equally erroneous) Apple quote.]
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.
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.
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.
[0]: https://www.businessofapps.com/data/slack-statistics/
[1]: https://www.businessofapps.com/data/discord-statistics/
[2]: https://www.businessofapps.com/data/microsoft-teams-statisti...
There are no major native chat apps left to use as a reference.
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 makes you think that Slack's loading times is due to Electron, not shitty backend?
This is genuine question
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:
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.
...
>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.
.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.
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)
And for locked down corporate machines life was even easier. Same base image, same libraries installed.
Also DLL hell had been solved by the Windows XP timeframe with side by side installs of multiple dll versions.
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!
Oh, and we did it without Visual Studio as well. Kids today.
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?
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".
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.
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.
But apart from that, not many changes.:)
WDDM was a huge one though.
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.
Same story with Adobe Flash.
Nothing available today matches.
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. :/
Alrighty, BRB while I finish my dropdown for converting from metric to "donkeyhooves per camelpower."
That is the keyword here, website, no need to package it, I already have plenty of browsers installed.
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.
React Native and similar options allow us to do so much more than we otherwise would.
1. I avoid both Electron and React. I like UNIX. Runs on many platforms.
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'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."
"Hello World" shouldn't take 115 mb and trillion computer cycles, period.
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.
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.
Its a race to mediocrity on every platform
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.
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.
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.
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.
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.