blog.over-update.download

Electron was first open-sourced in 2014, and gained immediate popularity as a way to build desktop apps using web technologies (HTML+CSS+JS). At the core of its design is the idea of bundling a predictable environment:

Best bible software for mac 2018. Peter Pellerin.

1. Mac Ui For Electron Applications
2. Mac Ui For Electron App Free
3. Electron App Store
4. Electron Desktop Apps
5. Electron Desktop Ui
6. Electron Ui Apps

Nov 01, 2019 Blazor on Electron. We’ve had a lot of interest in using Blazor to build cross-platform desktop apps. It’s not surprising: combining the performance and productivity of C#/.NET with the familiarity of HTML/CSS UI rendering is powerful and appealing. So, we published a sample and an experimental package for hosting Blazor on Electron. Aug 12, 2015 Desktop Apps With Electron And Kendo UI is out. Stay connected to Telerik Blogs for.NET, JavaScript, cross-platform app development (and beyond) news and tutorials. Compatible with Mac, Windows, and Linux, Electron apps build and run on three platforms. The hard parts made easy. Automatic updates Native menus & notifications Crash reporting Debugging & profiling Windows installers Get started. To get started with Electron, check out the resources below.

• It bundles its own copy of Chromium, so you know for sure how your HTML/CSS will be rendered and don’t have to worry about random old versions of IE (etc.)
• It bundles its own copy of Node.js, so you have a known version of a portable programming platform that goes beyond the browser sandbox and can interact with the host OS directly

These choices offered a lot of value five years ago, but in late 2019 you might choose differently. And these choices are also key to why Electron has a reputation for being unusually resource-hungry. A default blank Electron 8.0.0 application is 164MB to download (66MB compressed), and runs as 4 separate processes consuming 150MB RAM in total.

It’s completely possible that these numbers look fine to you and are satisfactory for your scenario. If that’s the case, good for you! This post is not an attempt to bash Electron, which is a well-run project that people are clearly using successfully. In this post, I simply want to consider what other options we might have.

How light could it get?

What if…

• …we didn’t bundle Chromium, but instead used whatever webview already exists in the OS? In 2019, just about any desktop OS is going to have a sufficiently modern, usually Chromium-based browser, ready to go. For your app, it likely doesn’t matter whether it’s Chromium from last week or last year.

• …we didn’t bundle Node, but instead made use of the programming environment already in the OS, or optionally brought a different one? A framework-dependent .NET Core app can easily be under 1MB, and a standalone one (i.e., bundling its own copy of .NET Core) can get down to ~20MB linked and compressed.

Mac Ui For Electron Applications

Various Electron-lite alternative projects have already sprung up [1]. Of course, there are also PWAs, but that’s not what this post is about, since PWAs don’t have native access to the underlying OS.

Blazor on Electron

We’ve had a lot of interest in using Blazor to build cross-platform desktop apps. It’s not surprising: combining the performance and productivity of C#/.NET with the familiarity of HTML/CSS UI rendering is powerful and appealing.

So, we published a sample and an experimental package for hosting Blazor on Electron. The key innovation here is that it’s not running on WebAssembly, but rather uses the normal cross-platform .NET Core runtime to achieve full native .NET performance and enable full access to the host OS without any browser sandbox limitations.

Mac Ui For Electron App Free

You can try this out today. Just note that it’s only an “asplabs” project, as we haven’t yet made any commitment to ship and support this technology.

Blazor on pure webview

It’s not hard to imagine how a Blazor hybrid desktop app could be slimmed down dramatically further. We could swap out Electron for a pure OS-native web view, reasoning that in 2019, there’s virtually always a good enough one available on your target machine. Plus we don’t really need Node as a cross-platform programming environment, since .NET Core already plays that role for us.

To verify this, I built an experiment called BlazorDesktop. This is very similar to BlazorElectron, and in fact most of the code is a copy-paste from it. Again, it runs on native .NET Core (so not on WebAssembly), but now it’s running on a much smaller rendering stack, without any bundled Chromium or Node.js.

It’s a fully-functional Blazor application into which you can add any native .NET Core-based functionality, and runs as an extremely lightweight desktop app - see below for numbers. Unlike a PWA, it’s not limited to the browser sandbox.

If you’re interested in trying this out, please note that it’s purely a quick proof-of-concept, and currently is Windows only. Expanding it to be cross-platform wouldn’t be too hard (I’d use something like webview to add Mac+Linux support) but is not something I’m actively doing right now. Send a PR if you’re interested.

The stats

Not surprisingly, this minimal Blazor + webview application is significantly smaller and less memory-hungry than one built on the whole Chromium + Node stack:

One of the neat things about .NET Core apps is that, with a simple switch, you can control whether the publish output bundles its own copy of the .NET Core runtime (a.k.a. standalone), or whether it assumes the runtime will already be installed on the target OS (a.k.a. framework-dependent). This is captured in the first graph above, and you can see it makes a huge difference to the output size, since the Blazor libraries themselves are very compact.

In corporate environments where you know that certain software is already installed, you can safely distribute tiny < 1MB framework-dependent apps, where the same binaries run on any supported OS. But for public distribution, you’d most likely publish a standalone app - generating different binaries for each of Windows, Mac, and Linux users.

Note that about 200KB of the compressed Blazor webview app above consists of Bootstrap styling, so you could drop that if you’re using something else.

What would have to be built to make this viable

As I’ve said, Blazor Desktop is currently just a quick proof-of-concept, built entirely during the waking part of my return journey from NDC Sydney. It would have a long way to go to turn into a viable product.

It would need:

• Cross-platform support, e.g., using webview
• Edge (Chromium) support, so that on Windows 10 we’re using the OS’s own Chromium-based browser instead of the Edge-based webview used in my prototype. This would also enable access to Chrome-style browser dev tools automatically.
• Handling the scenario where a suitable webview can’t be found. In the rare case where a user’s OS doesn’t supply an acceptable webview technology, we could prompt the user and download a standalone Chromium distribution (likely via CEF).
• Desktop APIs - this is the big one that would be expensive to achieve from scratch. Electron doesn’t just use Node as a general-purpose programming environment; it also ships a set of cross-platform APIs for interacting with the desktop OS for tasks like copying to clipboard, changing the taskbar/dock icon, displaying native dropdown menus, showing native prompts/dialogs, and many more such things. .NET Core itself supplies a huge proportion of the APIs that applications need, but today it doesn’t address many of the desktop-focused ones, since there isn’t today any standard cross-platform .NET Core-based UI technology. Any realistic app needs these capabilities. Conceivably it might be worth bundling Node just to get cross-platform implementations for these APIs (though still without bundling Chromium).
• Publishing and downloading updates automatically

Feedback requested

My reason for writing this is mainly to learn more about how the developer community feels about these technologies. Do you have scenarios for building hybrid desktop apps with .NET+HTML+CSS? Would you be happy to use Blazor with Electron, or do you feel it’s necessary to have something more bare-metal?

Footnote: existing Electron alternatives

Many people have thought about building lighter alternatives to Electron over the years. Various open-source projects now exist, though it’s not clear that any really have the critical momentum for mass adoption. Some of them, like Chromely, eliminate Node and only bundle Chromium. Others, like Neutralino, eliminate Chromium and only bundle a Node-based programming model combined with the host OS’s browser technology. At the ultra-minimal end, webview is simply an abstraction over the idea of a webview: it shows your HTML/CSS in whatever browser technology is built into the host OS, and doesn’t provide any cross-platform programming model of its own.

Taking the time to learn the flashprint advance settings you can get some very good results using it. I have over 1500 hours on my creator pro so far using flashprint. Flashforge creator pro software update. Flashprint has produce very reliable and high quality miniature gaming tiles and props for me. I have only used flashprint with my creator pro, I have thought about Simplify3D but I can't justify the cost.

Developers of apps built with the cross-platform Electron framework say that Apple has started rejecting their applications during its Mac App Store review process, and has threatened cancellation of Apple Developer Accounts for repeated rules violations.

The issue was first raised in August and only affects Electron apps seeking Mac App Store Distribution. The problem received widespread attention following a developer blog post on Sunday.

Electron App Store

Apple's App Store Review Guidelines have long specified that applications may use only public APIs. The phone-and-computer maker maintains private APIs for its own usage, but it doesn't support them for third-parties.

The off-limits APIs singled out by Apple include: CAContext, CALayerHost, NSAccessibilityRemoteUIElement, NSNextStepFrame, NSThemeFrame, and NSURLFileTypeMappings, among others.

Despite Apple's warning, those making macOS apps sometimes risk crafting code that interacts with private APIs because they can distribute such apps themselves, outside of the Mac App Store.

The Chromium project, the open source foundation of Google's Chrome browser, is one prominent code base that talks to Apple's private APIs. And Electron apps include Chromium as a runtime library.

Electron has a number of drawbacks – builds tend to be large and memory-hungry, for instance – but the advantage of being able to use familiar web technology to create a single code base that can generate builds for macOS, Linux, and Windows outweighs the downsides in many cases.

Apple hasn't previously rejected Electron-based applications for private API usage – at least not on a consistent basis – so presumably something has changed in Apple's review process.

The Register asked Apple to explain what's going on but the Cupertino crew did not respond to a request for comment. Whatever prompted the change, a rule long ignored is now being enforced, at least for Electron apps.

We also asked Google whether it intends to move away from private APIs in Chromium. Again, no response.

Electron Desktop Apps

Here's how we made a no-fuss RSS vulture app using trendy Electron

Electron Desktop Ui

Electron Ui Apps

What makes this particularly alarming for developers is that some have received a warning threatening excommunication from Apple's walled garden if rules violations persist in subsequent app submissions: 'Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.'

The API clampdown recalls several months in 2010 when a draft of Apple's iOS 4.0 rules disallowed iOS apps that relied on programming languages other than Objective-C, C, C++, or JavaScript. Following criticism from the developer community, Apple adopted more flexible requirements. But the way things have been going in terms of security concerns – e.g. app notarization – it seems doubtful that Apple will relent.

The iPhone maker's heightened concern about Electron raises questions about whether future updates to widely used Electron-based desktop apps, such as Slack, will get flagged by Apple's reviewers.

Developers reporting rejections have indicated that Apple has recommended specific outdated Electron builds that it finds acceptable. These include versions 3.0.0-beta.7, 2.0.8, 1.8.8, or 1.7.16 of the Electron SDK, which is presently at version 7.0.1.

Contributors to the open source Electron project have been working to disable calls to the offending APIs, so a forthcoming Electron update may address Apple's requirements. ®