This is like claiming nobody wants to write C because no one wants to manage their own memory in 2019, or miss out on all the cool new packages in the JS ecosystem.
Evidently _some people_ do. I can assure you there's at least number _n > 1_ of people who care more about app size than either of your points.
I personally wrote a side project in system web-view, because I don't want my macOS-only system-tray application to weigh 115+MB to make sure I have APIs I don't need in platforms I don't support.
While this route is probably not for quick app deployment, but boy can it kick ass when properly done in C++ with custom GUI framework.
I love Sublime Text and Sublime Merge. I love their philosophy towards software design. I love how they value user experience above everything else.
There are very few pieces of software that give you so much pleasure and joy in using them on a day to day basis.
I get the point you’re making, but you might be in the minority here.
And I highly doubt that many users switching from Sublime to VS Code. They use one or the other for a specific reason, like a blazing fast and distraction free editing experience in Sublime - something you do not have in VS Code or any other IDE, imo.
Plenty of former sublime users are on VS code now.
I really don't get your point.
I was disagreeing with his distinction between advanced text editors and lightweight IDEs.
Really hope they can keep being profitable.
A few weeks ago my non-technical neighbours told me that their computer was "a bit slow" and if I could "install a new antivirus". Here's what "a bit slow" meant :
- windows took 7 minutes to boot
- IE took more than a minute to open
And of course it wasn't always like that, but the proverbial frog was boiled long enough that it took a lot of time for them to be pissed enough to look for help (the poor guys had 4 antivirus programs running concurrently - on a machine with 2 gigs of ram).
In contrast, if my browser takes more than 3 or so seconds to open I start looking for what's wrong.
That makes me think of what school and uni digital illiteracy should look like.
Non-programmers assume this is normal and now they are used to slow apps. Also, they don't know that the reason their whole system is very slow is slack.
"Apps" like Slack are on my hate list even above desktop Java apps. Seriously, I can't understand how come it's acceptable to use >1GB of RAM to display 10 lines of text.
There is no native UI toolkit that can do this properly, nor is there a cross platform way for 3rd parties to integrate even if there was. So web it is, with a runtime designed for being able to rapidly page in/out the entire UI from one screen to the next, even if that is entirely unnecessary for a single app.
Grouches have been shitting on the web, not entirely for bad reasons, but it's made them miss the fact that web has been stealing their lunch for a reason. If you live inside a terminal, your needs have diverged from the majority, and you're likely relying on crutches that are considered impossibly clunky by most.
The only ray of hope here is what FB has done with React and React Native, but I imagine it will take another 10 years before the unix geeks will want to admit there is something in that "webshit" worth looking at.
The problem isn't that the text part is rendered using HTML. That actually makes sense - multiple desktop applications that compose/render user generated rich content rely on HTML (or something converted to HTML) and a web view of some description to render that content: mail, chat, etc.
The problem is rendering the entire application's chrome using Web technologies, and then running all of that inside a web view from a browser that is known to have the resource usage of a porcine creature with an eating disorder.
> The only ray of hope here is what FB has done with React and React Native
No. The ray of hope is that people realise web technologies are not the best choice, and the way they're used in Electron is fucking atrocious.
Keep in mind that the OS and the hardware it runs on comes from the same company that does iMessages. You shouldn't discount the amount of control that brings.
Contrast that to people who have to work with different OS platforms and hardware specifications.
The hard work of optimisation has been done by apple, any app can embed a web view for content and take advantage of the optimisations in the system html renderer.
I refuse to use Electron apps - they clearly work in JS so the web version will work fine, and I get to keep the sandbox protections, content blocking etc of Safari.
And I use IDEA Ultimate almost daily. Yes, it uses a ton of RAM - but it uses a ton of RAM and is powerful.
I've not yet seen another IDE with the same capabilities (i.e. built in static analysis of dynamic languages like PHP, with refactoring support, etc).
I have oodles of memory (64GB) so I could of course run Slack and not "run out". But the key thing here is that Slack doesn't just use memory, it wastes it.
IDEA uses memory to make me more productive
And besides, of that 5% of people who hate it, a large percentage of them use it anyway because they have to.
Overengineered products for the minority don't do well unless you charge a huge premium for it, something my field unfortunately does a lot of and I have to deal with.
Yes, lots of projects want multiple, competitive rendering engines.
It used to be that Windows was the only viable target OS for commercial software. Firefox and Safari gave IE competition and gave developers who wanted to target Mac and Linux a way to get a foot in the door. That kicked off the whole generation of web apps we’ve just lived through. If developers give up on Gecko and WebKit, then they allow a monopoly again. And since Electron is made by GitHub and is now owned by Microsoft, Microsoft will again have the monopoly (with the caveat that Google has primary influence over Blink).
Render engine competition keeps web standards relevant, which keeps the web open. Take away competition & we’ll be back in a world where people build to IE6 for a decade instead of targeting standard HTML/CSS/JS.
Maybe having multiple engines is good (although maybe the benefits are overstated since nowadays most engines align with the spec instead of implementing non-standard extensions like ActiveX), but it's not good for people for who want to quickly, and with low effort, develop desktop applications.
The point of the parent comment was that developers chose Electron over other frameworks for reasons such as speed of development, and DeskGap does not align with those reasons.
I'm sick of sluggish "native" apps on my i7 PC with fast SSDs and 32GB of RAM. I don't even want to imagine how those apps perform on low-end devices.
Only developers and very tech-savvy people bitch about Slack. Your average person working in Sales, HR, or operations cares not for the memory footprint of Slack.
It's also not nearly as bad as people make it out to be. Yeah, it's slower than mIRC, fair enough. But IRC is dead to almost everyone and Slack took over, so it is what it is.
Maybe the circle I am in simply has great computers. But who knows.
Software used to be both fast and "feature rich" (relatively speaking), designed so users could "grow" and learn increasingly more of it. Now almost everything seems to have idiotically dumbed-down "flat" UIs that look simpler yet still manage to consume more resources than before.
The new Skype is a great example. Compare to something like this: https://www.microsip.org/ Yes, I know they're different protocols, but the point is that IM and audio/video call functionality doesn't need to take as much resources as Skype does.
The real reason MS and IE were not so good is because they were a closed source monopoly! And moreover the copyright was enforced by the government.
Now even M$ switched over to WebKit / Blink.
Collaboration beats competition in the end.
Wikipedia beat Britannica quite handily. And it beat Encarta, too.
Open source beat closed source over time.
The Web beat AOL and Compuserve.
Science beat secret cults and alchemy.
Today Pharma is using patents and competition. People are prevented from building on each other’s work in microbiology but not in other sciences. Isn’t that wild?
I would rather have lots of people adding to one snowball platform, than having competing platforms. AS LONG AS that platform is open source and anyone can use it for any purpose. If your commits don’t make it into the core, just market them until they get popular enough. Compatibility is the goal, though.
It has nothing to do with the point that trying to make your code work in multiple browsers/rendering engines is painful.
Wanting a project to work with multiple rendering engines just because is an idealogical decision.
That's certainly _one_ reason why.
I would posit that the main reason is that web developers would like to reuse their webapp skillset for building desktop apps. This seems like it accomplishes the goal.
Re: testing against multiple browsers, frankly this is _mostly_ a solved problem. The big gaps between rendering engines is on the real fringe of css at this point, which most of us aren't bothering to use. Also, many people builting on top of electron (and presumably this platform) are using css toolkits like blueprint, and most of those take care of most of your cross browser issues anyway. So, largely not a concern.
The people behind Slack, Spotify, and so on have actually commented on these threads explaining the exact line of reasoning. This stuff isn't limited to just CSS, and it makes total business sense to avoid it.
(This is like the obviously silly quote "we lose money on every sale, but we'll make it up in volume!" translated into "this rich environment and set of libraries enables such amazing developer productivity that we can create much better optimized user experiences!" while the laggyness and flakyness and huge memory use are just never optimized away with that productivity.)
I dunno, Discord might be gunning for that prize.
Which 99% of users never care about. The idea that large memory usage is a negative business driver is almost laughable at this point, yet for some reason it is a huge pet peeve among lots of technologists.
I partly manage a team of end-user support people, and the number of tickets they get with "my computer is slow!" is astonishing.
The number of times it's found that they have Slack eating over half the RAM of their corporate-issued laptop (read: wimpy specs) is huge.
The number of people who understand that Slack being an insane resource hog is a large part of what is making their daily computing business painful is the inverse.
The only debatable question is whether the exact memory overhead (of electron for example) on the specific user machines existing out there today will make a noticeable loading time or lag difference. For many users it seems it does, not everyone has the lastest hardware.
People quite obviously care about speed and latency issues, but they might not be able to pinpoint slack or discord, etc as the root cause.
The desire to use new features as soon as possible is driver enough I feel. Imagine having to wait years for parity between 6 different operating systems before being able to use classes, a language feature introduced years ago and that still isn't fully supported today.
What they really want to do is make that web app installable in the OS, no? I use WebPin to "install" websites (until this works natively in Firefox with PWAs) a lot of the time, even when they offer electron bundles (with the browser I already have, nodejs I already have ...).
- Nobody bothers to be testing against multiple operating systems in 2019.
- Everybody gets to wait for Slack to get around to it while the system webview gets the compatibility update almost immediately.
Great for the authors, shit for the users. On the bright side, it was the straw that broke the camel's back, and my org doesn't pay Slack any more.
But size and speed matter (you don’t see much elektron based games..). We as a humanity can’t just always build faster and more powerful computers and then let developers throw these gains away by building more elaborate Rube-Goldberg-machines, that take 100 times the space they need, running more things taking the same old time we are used to wait, with dependencies no single human ever checked at once.
Many of same people who waste tremendous amounts of energy and collective human time writing ineffective applications might end up to be really pro-environmentalists outside their job, but when it comes to computers suddenly we don’t care. As long as it is acceptable on a new machine, who cares, right?
It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together.
This is such a privileged thing to say. I would guess there are far more important environmental problems to worry about. There are also more things that can be done that have more impact.
> It would be entirely possible to write perfectly fast and efficient GUI applications using HTML and CSS as layout engines without dragging whole browsers into this. Using system webview might not be the solution. But maybe something that doesn’t feel like it has been taped together with duct tape would help. A fully fleged browser engine for a desktop app is overkill in most common usecases and while I understand why one decides for Elektron, I’d rather see a really thought out solution than one that has been duct taped together.
Convince platform owners to agree on a common spec for GUI that's implemented consistently. Otherwise, what you want will ever remain a pipe dream.
That's why DeskGap uses EdgeHTML on Windows. With toolchains such as webpack and babel, building an app that runs on WebKit and EdgeHTML (which is going to be replaced by Chromium[0]) can't be that hard.
> Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately.
DeskGap doesn't mean to be a complete replacement for Electron. But after a glance of Electron Apps[1], I suppose many simple apps do not require start-of-art features.
[0] https://blogs.windows.com/windowsexperience/2018/12/06/micro...
Strangely, that would likely make it most conformant on Windows. I can't imagine that KHTML is up to date in terms of specifications (but I could easily be completely wrong about that) and Apple/Safari is taking tips from Microsoft during their IE days.
It would seem that the platform differences would be quite large, but at least the JS engine would be consistent.
As I noted in an above comment...
https://news.ycombinator.com/item?id=18763449
Projects like DeskGap make this out to be a simpler problem than it actually is. ;P
What really blows my mind is that we’ve reached a point in computing where the developers laziness now outranks the customers needs.
> Since I can already see the litany of armchair-quarterback-desktop-app-authors
I think you’ll find those who are offering counter arguments aren’t just armchair critics. Eg I’ve been writing software since the 80s. This includes a considerable amount of desktop software. So I’d like to think my opinion is just as valid as your own. ;)
It's not developer laziness. This is 100% a business decision, and if you've been doing this since the 80s, I'd expect you to know this by now.
Do you really think Slack & co chose Electron because it's making developers lives easier? Companies and people choose it because it. just. works. across platforms. This has a direct translation to money, no matter how much you stick your head in the sand about it. Less resources, less platform-specific wizardry, more focus on core features with faster turnaround time. _That_ is all that matters here at the end of the day, because programming is not - nor has been, for the majority of roles, for some time - been about coding and tinkering with bits. It's about increasing revenue for the company/product/whatever.
When you (the general you, not you specifically) rant about reimplementing everything Electron gives you on three platforms, you gloss over the wealth of shit a web browser provides for free. I have actually implemented some of this stuff outside of a browser, and I wouldn't do it again if you were paying me.
_Furthermore_, very rarely does anyone compare implementing something via Electron to native... but native is a landmine-filled problem area of it's own. macOS alone is horrendously undocumented these days for a good portion of stuff, and you'll end up with a litany of platform specific hacks for the most basic things.
Hell, the easiest response to this comment is this: neither of our opinions needs to be valid, because the market's opinion is that Electron is the better choice.
Take mobile app development: half the products that run on Electron on the desktop will still have native apps on mobiles. And even those that don’t would still have to use the native renderer on iOS and Windows Phone thus you’d be testing your common code base across multiple rendering engines anyway (which was the argument against the tool in this discussion).... and I’ve not even meantioned the slew of cross-platform applications that exist which have successfully avoided using Electron.
There are quite a few cross platform frameworks out there these days and different languages that can leverage them, however the next point I think is the real crux of the problem:
I will grant you that Electron does lower the barrier for entry (which is ironic because I personally find the web stack more awkward to develop in than native widgets - but each to their own). And maybe that’s where the biggest cost saving comes for the business; you can hire cheaper engineers to build and support your desktop software?
In any case, I’m not blind to the appeal of Electron; I just don’t agree with how important it is in the same way as the GP does.
Multiple rendering engines in this case also makes sense because the form factor you're designing for is inherently different. As a result, the usability factor comes into play... you're never writing one UI at that point anyway. The point of Electron is that you turn building and testing 3 rendering engines into testing 1.
Where can I request the "core features" of performance and usability?
One I just complained about the other day is Electron apparently doesn’t handle font fallback properly, so if I type an emoji that Slack doesn’t support, such as [frozen face], it just renders as a placeholder square in desktop Slack even though it renders as the emoji on both the website and in the iOS app.
Edit: Apparently HN strips the emoji from the comment [facepalm]
Wouldn’t have this problem with a native app.
...which is exactly the kind of thing that nobody wants to deal with when trying to ship a product. ;P
This myth that you get these things for free with native apps is just that: a myth.
As have I :)
> you actually might! macOS, for instance, has a few race conditions that can (easily) occur when using the built-in spell/grammar-checking functionality on text field/view instances.
That forces it to load the wrong dictionary (one which differs from the system dic) and do so repeatedly each and every time you use the application? That doesn't sound much like a race condition to me...
> This myth that you get these things for free with native apps is just that: a myth.
Is that actually a myth though? Because I've never heard anyone suggest that - least of all uttered that nonsense myself.
There are bugs for NSSpellChecker going back as far as 2009 regarding automatic language detection (they're, however, now annoying as piss to link to... because all the old mailing lists/archives have been seemingly nuked. Thanks, Cocoa community!). This in turn hits Electron apps, since they're just passing back to the native API anyway.
https://github.com/electron-userland/electron-spellchecker/i...
For reference I was referring to Linux where Chromium and my DE all have their dictionaries set up correctly. I only ever seem to have this problem with Electron apps too. It's very annoying though.
Monopoly != multiple large vendors contributing to Chrome/Webkit/etc.
The next time I ran it, it worked on release mode, but panicked on debug mode.
I've just tried again from master and it works, which is an improvement!
You hands-down could not build Slack, Spotify and so forth in a solution like this. You would end up refactoring it very quickly when users start walking away because you can't have a feature they want (playing video, gifs, etc).
Maybe you should consider that a sign that it's not as black&white as you tout it to be? I mean, what a way to just dismiss everything..
So yeah, it's pretty black and white. ;P
Of course not.
Just because people are still having the conversation it doesn't mean the conversation is worthwhile.
You mean like when building websites?
Speak for yourself.
I hate to break it to you, but in the real world there are multiple browsers.
Not testing in more than one is lazy, standards ignorant and an insult to your users.
Let’s not repeat the MSIE-fiasco again. We know better. We can do better.
Slack et al are more successful with users, and have delivered more value to them, than 99% of the work people who post here are doing. Pretty sure this isn't insulting them.
And for the last time, this isn't the MSIE-fiasco all over again. The primary engines used today are all open sourced, it's not vendor lock in on the level it used to be.
I'm so very sorry our 20 years of experience that causes us to reject the subpar monstrosities you like to call "dektop apps" rubs you the wrong way.
So yeah, it does rub me the wrong way. The people who argue against Electron are the programmer's programmer: they like tinkering, they care about the code, and so on. Most businesses don't. Users never see the code. If you want better, you need to beat Electron and stop ignoring or decrying why people opt for it.
Soon they'll all be WebKit or Chromium.
Also electron doesn't 'just work'. A simple program being 300MB with a laggy sluggish interface is not 'just working'.
Nobody does. CSS is pretty mature, a difference in rendering between modern engines is extremely rare
That’s true with any platform. But if you stick with tried and true stuff, it’s hassle free.
I don’t remember the last time I had a layout rendering issue and I write this stuff everyday all day.
I'm also unsure how it is even supposed to solve that specific issue considering my laptop is currently running at least two versions of electron for different apps, both of which render text as their primary directive.
The reply was that it isn't because there are lots of features that are not available to all browsers.
A mature platform would be one where the features are consistent in whatever environment it is in. So in that regard, CSS is not mature.
"Just don't use new stuff" is not an excuse.
My issue isn't really with that my issue is that the issues with CSS and the valid workarounds are not painful enough to validate electron as a solution.
If electron did what it promised I wouldn't have a problem.
- Nobody wants to be testing against multiple browser/rendering engines in 2019.
- Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately.
Edit: Since I can already see the litany of armchair-quarterback-desktop-app-authors, I'm just going to link to the comment from the guy who actually migrated Slack away from WKWebView.
https://news.ycombinator.com/item?id=18763449
Blows my mind we're still debating this.