Show HN: DeskGap – Like Electron, but uses the system webview
deskgap.com
deskgap.com
The ideal application:
- uses almost no memory
- uses almost no disk space
- is extremely fast
- costs (next to) nothing
- and has all the features in the world
- presented in a manner that automatically shows the user only the exact features (s)he cares about
In the real world, we have to balance the project/product requirements. In the end, only these things matter:
- It yields a net profit (monetary or otherwise) for the company or owner
- It has (and keeps) added value in comparison to similar software
- It's fun to design and develop in/for
- It has bugfixes and new features in a timely manner, without taking up too much development time
- It has a pretty, easy to use interface
- It's quick and snappy enough to run
Adding that all up, and developing in something like Electron is a no-brainer: mean time between iterations is faster, design and development is more fun and the end user has a product that is fast enough for their needs packed with features. Try that in any low level language or without control over the engine and you'll have to severely hamper one of these goals.
Disclaimer: I hate Electron. (but really appreciate and admire its developers)
Not everyone on earth is a dev/gamer/video-editor. For regular people, electron is a cancer that needs to be nipped in the bud. Remember, 91% of the desktop on earth is Windows (meaning regular USD 300 machines). And of them I'd wager less than 10% fit have machines where electron is snappy (1.2K Thinkpads).
What the earth needs is a better cross platform native GUI framework. NOT electron.
That's not how I expected that sentence to end. I don't think regular people are nearly as concerned with performance as the groups you listed are. Regular people are probably using Electron via Slack for work and if it's slow and bloated it's ultimately not their problem. Even a few seconds delay won't cost them anything when it's still a faster replacement for email.
You also don't need to focus on Slack. Skype is an electron app. How many people use Skype to connect with their family?
"Regular people" are likely to encounter electron by using Telegram or Whatsapp on the desktop, or some recent MS product like Skype. Whether they care or not about bloat, I don't know. I know those chat programs used to have annoying problems with cut & paste and not supporting basic assistive technology (i.e. the "emoji keyboard"), but I have to admit they got better with time; if those fixes have made it upstream to Electron, then things are improving. They are still horribly opaque to native OS services like sharing facilities and whatnot, but it looks like OS developers themselves are throwing all that away these days, so...
I expect the real issue Electron might never solve is real support for more advanced assistive tech for the visually-impaired and other disabled people. That stuff barely works with traditional desktop tech as it is. Obviously that has never been an obstacle in the market at large, it mostly plays a part in public-procurement processes.
Now, in practice? Yeah, not so good right now.
Telegram is written in C++ and uses Qt. Maybe you're thinking of Discord?
If the regular people expect anything modern to be snappy on those machines then they have been mis-sold to[1] and that isn't our fault as devs.
> What the earth needs is...
Then why don't you put a team together and make it, and gain the fame and fortune that comes from solving the matter?
> NOT electron
Nobody is forcing you to use Electron based apps. If you find them, or anything else, too slow then find an alternative that is in a native toolset or entirely browser based, or what-ever.
A key problem is that people want what the want, they want it now, they want it to work on their platform without needing specific version of anything else (i.e. a browser), and they want it free. If Electron allows the thing to be delivered now, in a cross-platform manner, and people aren't willing to wait or pay for the dev time to develop in something smaller/nippier, then Electron is what devs are going to use.
I remember similar arguments regarding VB way back when: people wanting something that started faster and used less RAM bitterly complaining, but not wanting to use alternatives that were available because they cost more. To my mind Electron has a very similar feel to VB back then: great for prototyping, but can be used to produce fuller solutions too if you are willing to accept the cost in speed and weight.
[1] Oh how I love having to explain that 32GB total storage isn't really enough for Win10, especially when that is slow eMMC and the machine is swapping to it on account of only having 2GB RAM, when the sales person[2] said otherwise.
[2] People don't seem to accept "well go ask the salesman to make Office fit and make it go fast for you, you obviously think he knows more than I do"[3] as a valid response...
[3] Heck, those diminutive laptops/tablets/black-boxes-to-plug-into-your-tv, that are still being actively sold as Win10 compatible, can't even install the latest Win10 updates without some technical jiggery-pokery.
I always like to use VSCode as an example. It's a tool a use on a daily basis, and I like almost everything about it. It's also a poster-child for a good Electron application, maybe one of the best around. Add to that I completely understand why it was made using Electron, and why it might not have existed in this form (available, up-to-date, and feature-complete on all platforms, regularly improved, etc) at all if it wasn't because of Electron.
But it's not.snappy.enough.
Even though large performance-sensitive parts of it like the editor buffer data structures etc are (AFAIK) implemented natively, the whole user experience is actually quite bad. It's sluggish, inconsistent, it's full of random glitches, and everything feels like an insane amount of effort went into putting more and more lipstick on various parts of a pig to hide that the whole thing is like a house of cards and sluggishness and instability hides around every corner.
I feel a little sad that so many developers defend Electron so vehemently, pretending that it's 'ok', 'fine' or even 'very good' for end users, because it's not. I fully agree it's great for the people (and mostly the companies making money off the people) who develop commercial stuff with it, because it obviously saves a shit-ton of money if you want to deploy something across the 3 major platforms.
All of this is completely unrelated to the end-user experience though, who typically uses just one platform at a time and couldn't care less if the application they are using is also on some other platform. Or if they use it across multiple platforms, how many extra UI devs where needed to make native UI's for each of them.
Any developer who knows how freaking fast modern computers are and why should, when completely honest, should feel ashamed that something like Slack or VSCode is made in a way that makes it so sluggish and memory-hungry, and that we now all accept this because it's cheaper to develop that way, and the applications are (supposedly) 'snappy enough to run'
Agreed, it's a great example of why Electron exists, but also a great example of an Electron app done well - I've used other Electron apps that have far fewer features, yet feel sluggish and/or are incredible memory hogs.
> But it's not.snappy.enough.
I also use VSCode on a daily basis (on Windows), and TBH I don't find it any less snappy than native IDEs such as Visual Studio or Rider, or indeed native text editors such as Notepad2.
> the whole user experience is actually quite bad. It's sluggish, inconsistent, it's full of random glitches
Similarly, I just don't have this experience - I find it both consistent and performant.
Do you use it on Windows, or another platform?
I would rather compare VS code to a regular editor with syntax highlighting, autocomplete and a few bindings to quickly kick off tasks, because that's essentially what it is. Could be Emacs, Vim, Sublime, etc. That's how I use VS Code, so that's what I compare it to. That said, for example XCode or CLion also feel faster, and I consider those way more feature-heavy than VS code.
>> Do you use it on Windows, or another platform?
I'm using VSCode on Linux, on a moderately sized C++ code base with the Microsoft IntelliSense LSP extension. I realize that some of the annoyances I experience are because of the C++ LSP stuff, which is still in preview, but it definitely isn't contained to just that. I sometimes also use VS code on macOS for JavaScript and Python projects, and even though it's a little better there, it's still nowhere near a good native editor. The weird glitches I experience are present on both platforms, and I've had a fair share of them. Keyboard input freezing for some seconds, buffers not updating when files changes, shortcuts not firing, drawing/refresh errors, just to name a few.
So, Visual Studio is somewhat sluggish, but Rider is not. I also mentioned Notepad2, which is a native text editor - I find VSCode just as snappy as that.
> I'm using VSCode on Linux, on a moderately sized C++ code base with the Microsoft IntelliSense LSP extension
I haven't used it on Linux, or at all with C++. I've used it on Windows and MacOS, for Typescript, JavaScript and Cordova projects, as well as for note taking (because I find it as fast as a text editor, yet much more fully featured).
Honestly, I've been using VSCode for a long time now, and I've never encountered any of the glitches you mentioned. Just did a totally scientific straw poll of co-workers, who say the same. You sound unsure, but I wonder if it is due to an extension you have installed?
I was following you until this line... In general I agree about Electron though probably not to the same degree as you. But for me VSCode runs amazingly well; I think the only thing that tops it is Sublime (and I vastly prefer VSCode's interface and features). Not saying that what you said isn't your experience, but you should know it's not everyone's experience.
A good example being opening a new window. This is something I do semi-often to edit something out-of-context that shouldn't taint my current workspace. Under anything from Notepad to Gedit or Sublime Text, this task has no perceivable latency. Under VSCode, however, it is so uncomfortably slow that I actively try to avoid it, and instead use Gedit for these editing tasks. This is a significant downgrade in workflow compared to Sublime Text.
So, why do I use it? Well, features. However, what must be made very clear is that none of the features I use in VSCode exist as a result of Electron. Terminal panes and the better Go/Rust integration has nothing to do with Electron, and are within areas of difficulty that I could have added it myself over a weekend had Sublime Text been open source. But it's not, so I can't.
Electron is cancer.
I find the term to be quite fitting here. The use has spread to an absurd degree, meaning that there is a large change that everyone is running one or more instances of this framework at any given time, and use of this framework not only harms UX, but also brings down the machine it runs on through resource consumption. Well, maybe "pandemic disease" is better than "cancer".
When everything uses something like Electron, you the ability to simple chose to avoid it. Like a disease, Electron is that you involuntarily get subjected to, and as such, would prefer to see eradicated.
(And yes, yes, we should improve the experience of making cross-platform native apps, but due to Electron, no one is even trying anymore outside of mobile.)
Intel Core i7-8700 @ 3.2GHz (12 threads, Coffee Lake)
64 GB 2666MHz DDR4 RAM (4x Kingston KHX2666C16/16G)
SAMSUNG MZVLB512HAJQ 512GB NVMe PCIe SSD
GPU is just the built-in UHD Graphics 630
Opening a new window takes presents a blank, black window that has more and more UI glitch in over a 2 second period. This is very frustrating for as a file-open delay when doing quick small edits. Gedit, on the other hand, does it in the time it takes to make the "fwoosh" opening animation (which can supposedly be disabled for faster start).
And for the record, there are no specs bad enough that a text editor should have a noticeable delay to open.
The only time vs code got unbearable to use for me was on this iMac late 2013 with an HDD drive I got on Craigslist a month ago but once I upgraded to SSD it was like a whole new computer, even running VMs and Kubernetes, VScode runs real nice working on large scale enterprise apps.
But yeah your computer sounds strong enough to handle any IDE so specs not the problem.
Actually they are not. The search in VSCode uses an external exe writing in Rust, but that is about it as far as custom native code goes.
Atom though did add some native code data structures.
Claims that VSCode is "inconsistent, it's full of random glitches" doesn't match my experience at all. It's solid. Maybe it could be faster, but I find its speed acceptable and regularly run it on a laptop with an Intel i3 CPU.
My 10 year old netbook runs RStudio? Discord works great on my 10 year old Dell 2nd screen computer. What doesn't run VSCode?
Last week was the first time my 2015 XPS laptop started swapping too hard to get any meaningful work done, and that was because I jumped onto a project with a vscode workflow.
Technically it can run vscode fine. But only if it's exclusively vscode.
So now I'm working in my editor of choice most of the time, and then closing all my open applications whenever I need to use the vscode extensions.
Example of that "avoid Javascript" advice:
deep link: https://youtu.be/vzs5VPTf4QQ?t=30m55s
Out of experience can tell you 32 GB is a space that can be killed rather fast.
There have always been questions of adoption, stability, fidelity of the user experience and others.
Meanwhile web apps have kept chugging along and browsers have gotten better and better.
> What the earth needs is a better cross platform native GUI framework.
I contend that "native" is irrelevant. People are "native" web users. They use web based interfaces daily. A browser based UI is the "cross platform native" (whatever that means) GUI.
It can be fast (if you do the work, which may involve firing up external processes) it can be beautiful it can look native and it can deliver great user experiences.
It's not the GUI framework we wanted, but it's the one we deserve :)
> cancer that needs to be nipped in the bud.
Come on with the hyperbole. Electron is effectively (nipped) as it is most usually just the shortest path to giving apps a persistent offline option outside of the browser sandbox. I don't know of _any_ electron app that isn't also a dedicated web app. VSCode is embedded as an editor in a few online code sandboxes.
Electron apps will almost certainly be replaced with PWA akin to the MS strategy. Shared run time, distributed via a 'store' of some kind, etc. It's an arc that we are in the middle of.
I get it, the world needs a better solution. However there isn't one. There isn't even a #2 best option. Electron's success is just the industry's continued failure.
You'd think Google would be close with Flutter, but Flutter doesn't run in the browser. So, fail.
Are there any options you'd suggest using _over_ Electron?
Every couple months an electron thread pops up and gets the same bashing.
The world very much needs electron and that's why it exists. jQuery was the same way forever. People just complained _constantly_ that we should be advancing the spec and using built in calls. That jQuery was some sort of bloated misstep. Well, we're still waiting for web components to be standardized more than 15 years later.
So as I understand it, people that don't like electron would rather us use _nothing_. Thus providing _no_ stepping stone to what should rightfully come next.
I see the same thing with electric cars. They aren't perfect _now_ so why invest in them at all? Why even explore an avenue that could lead to other innovations if it isn't _perfect_ out of the gate? 91% of the world population don't even own cars!
QT is what i would suggest over electron
>- and has all the features in the world
In this case it's okay if it uses up all disc and memory. Actually it can even cost something in this case because only one application is needed.
It should be open source though so users can audit it and fix bugs if required. You see, just by requiring consistency in the requirements, one can get very far. Optimizing for typical startup metrics is just one way to do things but not the only valid one.
The ideal application:
- uses no memory
- uses no disk space
- is instant
- costs nothing
- and has all the features in the world
- presented in a manner that automatically shows the user only the exact features (s)he cares about
The real-world application, when the developers work for the customer and not for themselves:
- uses almost no memory
- uses almost no disk space
- is extremely fast
- costs next to nothing
- and has almost all the features in the world
- presented in a manner that automatically shows the user only the exact features (s)he cares about
Sadly, we need to balance features, performance and expectations with our own expectations about what kind of software we want to deliver.
I sincerely hate Electron and the whole ecosystem of bloated apps it enables BUT having matured a bit i can understand why it exists. People that hold the money want software out and want it fast and they don't care if the customer now needs almost 4 gigs of ram in their phone just to play music or browse the odd website.
A depressing state of affairs imho, specially for us "old folks" which enjoyed our software native and optimized as much as we could.
DeskGap is another try to build an lightweight alternative to Electron. Compared to the existing attempts [0, 1], I choose not to go that far and bundle a real Node.js with it[2].
And to battle test the framework, I wrapped squoosh[3] into a desktop app[4] with DeskGap, and successfully submitted it to the app stores.
[0] https://github.com/pojala/electrino
EDIT: Appears the latter [0]. Great work. I wonder how this affects bundling...does this make it a UWP app?
0 - https://github.com/patr0nus/DeskGap/blob/master/core/src/win...
[0]https://docs.microsoft.com/en-us/windows/communitytoolkit/co...
This is just reusing a DLL and saving disk space thanks to it.
And then there's disk memory, which isn't as important IMO but still it will of course be smaller since you don't ship the whole browser stack for each application.
https://docs.microsoft.com/en-us/windows/desktop/dlls/advant...
If not, why are you appealing to iOS to help make your case?
The webpage mentions the app size, but no mention of RAM usage, which is a bigger concern with Electron apps to me. Can you comment on how it compares?
So for now I consider DeskGap a good place for simple apps. But if you start to build something like VS Code, the RAM usage can’t be good, either.
I have been watching these types of tools (desktop js frameworks) and I'm glad the DeskGap docs[0] explain the difference between existing tools like Electrino and Quark although the most notable difference is that those two projects are no longer maintained.
I just added DeskGap to my list of Awesome Desktop JS frameworks[1].
[0]: https://deskgap.com/#there-are-already-similar-attempts-elec...
- webkit-gtk2 - webkit-gtk3 - qtwebkit - qtwebengine
Additionally I have two Geckos for Firefox and Thunderbird. All of them use skia, which then also gets compiled 6 times in total.
Using Gentoo, I'm a bit sensitive to this sort of thing ;)
I absolutely hated how slow and buggy the app was, until I realised it was down to it attempting to index music locally all the time
my app speed increased massively by going to settings > local files, and turning off all of the options of where to show songs from
Apparently the debate has matured from focusing on technical downsides to making unfalsifiable claims about technical downsides.
- 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.
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.
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 ...).
(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.
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...
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
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.
- 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.
Nobody does. CSS is pretty mature, a difference in rendering between modern engines is extremely rare
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.
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.
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).
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Also electron doesn't 'just work'. A simple program being 300MB with a laggy sluggish interface is not 'just working'.
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..
Of course not.
Just because people are still having the conversation it doesn't mean the conversation is worthwhile.
So yeah, it's pretty black and white. ;P
Soon they'll all be WebKit or Chromium.
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?
Monopoly != multiple large vendors contributing to Chrome/Webkit/etc.
You mean like when building websites?
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.
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.
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.
From the webview project page: It supports two-way JavaScript bindings (to call JavaScript from C/C++/Go and to call C/C++/Go from JavaScript). It uses Cocoa/WebKit on macOS, gtk-webkit2 on Linux and MSHTML (IE10/11) on Windows.
[0]https://github.com/zserge/lorca
[1]https://github.com/zserge/webview
edit: the link to the video https://video.fosdem.org/2019/UD2.120/godesktopapps.webm
and the presentation slides https://fosdem.org/2019/schedule/event/godesktopapps/attachm...
As a developer, I can appreciate Electron's utility in targeting multiple platforms, but one has to wonder:
Why isn't there a good, open, cross-platform UI library already, that compiles to the native UI of each OS?
Has there even been an initiative to make one?
You'd think the global developer community would have come together to tackle this problem by now, consider how it's such a pain point for all of us and users as well.
It is either "good native" or cross-platform. But not both in reality.
In principle can do something very basic using stock platform widgets - some application that uses only basic widgets: buttons and plain text textareas - all others are too different on different platforms.
If your app is slightly more than that you will have problems even with basic stuff. Consider this native UI example (Notepad++) : https://i.kinja-img.com/gawker-media/image/upload/c_lfill,w_... and something like Sublime Text
Notepad++ is a disaster even native platform API. Sublime Text uses custom non-native renderer - consistent UI styling.
I guess the downside is that that would be just a new .Net Framework, where an app requires you to install the Whatever Webview 2.5 in order to run, but it'd be neat to dodge Safari, while still having leaner Electron apps.
It could possibly be solved by specifying supported webviews in the application.
But it does use HTML/CSS in the same way as WPF uses XAML for UI definitions.
Sciter allows to use best parts of two worlds: flexibility of HTML/CSS/script for UI definitions and richness, power and compactness of native code as Sciter is designed to be embeddable from the very beginning.
In what UI engine you can create your own HTML element with native C++ (Rust, Go, etc) controller when you need to?
And on all Windows versions starting from XP, Mac OS from 10.7, all Linuxes with GTK3 including Raspberry Pi...
https://www.theverge.com/2018/12/6/18128648/microsoft-edge-c...
...as if that's an excuse.
https://deskgap.com/#why-is-the-supported-version-of-windows...
IE has been available as a COM component in Windows applications for ages -- at least as far back as XP -- so it could be done.
Simple, stable, good compatibility.