I spoke to the boss of a major music software company a few years ago. He told me that if they were going to start again from the ground up, they might look at WebKit for their UI. This totally surprised me. But I'm wondering if other folks are thinking and acting this way. Is webkit working its way in to truly non-web software?
RealPlayer, iTunes, and many other applications are using it, so are some non-"web" apps such as desktop widget programs:
http://trac.webkit.org/wiki/Applications%20using%20WebKit
Designing "web-apps" with HTML/Webkit UI is beneficial for Mobile users, since many devices have Webkit built in. Even if it is currently only used on a PC, you would have the possibility of hosting it on the web or local network later, with less work to convert it.
Gwibber, a Gnome twitter client that ships with Ubuntu, uses WebKit for displaying timelines (although it uses normal GTK+ widgets for the surrounding UI).
I would consider WebKit a viable option for many pieces of UI, particularly if the program shell exposes appropriate hooks into the surrounding platform to do things like launch a real browser or hook in to system notifications. You run the serious risk, however, of building an application that doesn't fit well in the UI conventions of the user's operating system.
It's not WebKit, but building a UI on a rendering engine is essentially what Mozilla does - Firefox, Thunderbird, etc. are built in XUL rendered with Gecko.
Anything you can do on webkit can be wrapped as an application easily with PhoneGap or other tools.
For example, store.sonyentertainmentnetwork.com could be wrapped as an OSX app, an Android app, and still act as a regular website very easily.
Also: https://products.sel.sony.com/opensource/source_webkit.shtml
Related
I am trying to build a desktop app.
I am thinking of using electron on the recommendation of a web-developer friend of mine, but as I am the only sole developer, I don't have the means to test the software on different platforms(OS, hardware etc.).So I am anticipating that this will cause a problem later, in the end, to test/debug software on different platforms and different OS.
I have ruled out web-apps because of some privacy concerns of the users for the remote data hosting.
Software is pretty lightweight and is almost equivalent to the image viewer apps with some slight modifications.
How to solve the problem of variations of different platforms?
Any literature suggestions pointing me in the general direction are also welcome.
Sometimes it helps to think of Electron as two processes.
The renderer vs the main processes. Generally the renderer process which runs the HTML/CSS/JS is it's own isolated component, and you communicate to the main process using IPC.
So generally for the UI, you can use mostly any web based testing framework to test reliability. At Amna, for example, we use Cypress as our E2E testing platform. You an also use something like QAWolf. Both should work with localhost. In general, most website testing tools should work fine, and consistently across platforms.
Where this gets tricky is when a UI functionality makes a call to the OS or the main process. For example, saving to the disk, or launching a program.
The general flow is this, and I've yet to find radically simpler options:
Set-Up a VM or buy a machine with the corresponding OS. I used Spot VMs in Azure for this.
Manually test the scenarios you care about in each VM before you ship
If you have a lot of cases that rely on the OS, then you should be able to further optimize this by using an automated test runner like Spectron.
From experience, what I've realized is that most of the iterations I do happen more on the UI than the underlying functions with the cross-platform capabilities. And if your code has good separation (e.g. contextIsolation:true, nodeIntegration:false), it should be pretty obvious when you need to do an entire "cross-platform" test vs just UI tests.
I'm not familiar with a lot of large-scale electron testing frameworks, I do know that ToDesktop handles package building and generating binaries to perform a smoke test and verify things open across different operating systems.
It depends.
The answer depends on what you are building, so it makes sense to figure out what you actually want to build. Some questions you might ask yourself:
Do I need a database?
Do I need authentication?
Do I need portability?
Do I need speed to market?
Do I want to pick a language I'm familiar in?
These are all good questions and there are dozens more we all ask ourselves. However, back to your original question.
Electron is a fine choice
Yes, there are alternatives. But Electron is used for Visual Studio Code, Facebook Messenger, Microsoft Teams and Figma. Choosing Electron means there are other developers making apps and there are proven apps in the market so you don't have to worry about a dead ecosystem.
Electron is easy to onboard if you know web technologies, think js, html and css. If you know these, you can transfer your web dev knowledge and make a cross-platform app. You don't have to worry about learning each OS since the UI is the webpage which will look mostly* the same between each OS. (*some very minor differences, but essentially the same).
Cross-platform deployment is easy
There are a few ways of bringing your app to multiple platforms, I happen to be most familiar with electron-builder, but the other two solutions work as well.
Many templates to start with
I am biased, since I'm the author of secure-electron-template which is one of the many templates you can choose from when starting an app. However, I recently reviewed all Electron templates and found that only 4 do not have serious security vulnerabilities.
The Electron framework frequently is updated, and over the course of the past few years there has been a shift in the way Electron apps are made. Some earlier frameworks didn't have good secure defaults which some of the older Electron templates inherited and thus, aren't as secure as new frameworks that follow security guidelines.
If you decide on Electron, give my template a try. It's got a number of features I'm building out in order to help the community with features they might want (ie. internationalization (i18n), saving local data, custom context menus, page routing, e2e unit testing, and how one can use license key validation, to name a few things).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are planning to built cross platform desktop application. We found that Node-Webkit is a perfect choice for us. But GitHub developed their own framework called Electron instead of using Node-Webkit.
What is the difference between them?
Electron has a page explaining the differences with nwjs.
Like NW.js, Electron provides a platform to write desktop applications
with web technologies. Both platforms enable developers to utilize
HTML, JavaScript, and Node.js. On the surface, they seem very similar.
There are however fundamental differences between the two projects
that make Electron a completely separate product from NW.js.
Entry of Application In NW.js, the main entry point of an
application can be an HTML web page. In that case, NW.js will open the
given entry point in a browser window.
In Electron, the entry point is always a JavaScript script. Instead of
providing a URL directly, you manually create a browser window and
load an HTML file using the API. You also need to listen to window
events to decide when to quit the application.
Electron works more like the Node.js runtime. Electron's APIs are
lower level so you can use it for browser testing in place of
PhantomJS.
Node Integration In NW.js, the Node integration in web pages
requires patching Chromium to work, while in Electron we chose a
different way to integrate the libuv loop with each platform's message
loop to avoid hacking Chromium. See the node_bindings code for how
that was done.
JavaScript Contexts If you are an experienced NW.js user, you
should be familiar with the concept of Node context and web context.
These concepts were invented because of how NW.js was implemented.
By using the multi-context feature of Node, Electron doesn't introduce
a new JavaScript context in web pages.
Note: NW.js has optionally supported multi-context since 0.13.
Legacy Support NW.js still offers a "legacy release" that supports
Windows XP. It doesn't receive security updates.
Given that hardware manufacturers, Microsoft, Chromium, and Node.js
haven't released even critical security updates for that system, we
have to warn you that using Windows XP is wildly insecure and outright
irresponsible.
However, we understand that requirements outside our wildest
imagination may exist, so if you're looking for something like
Electron that runs on Windows XP, the NW.js legacy release might be
the right fit for you.
Features There are numerous differences in the amount of supported
features. Electron has a bigger community, more production apps using
it, and a large amount of userland modules available on npm.
As an example, Electron has built-in support for automatic updates and
countless tools that make the creation of installers easier. As an
example in favor of NW.js, NW.js supports more Chrome.* APIs for the
development of Chrome Apps.
Naturally, we believe that Electron is the better platform for
polished production applications built with web technologies (like
Visual Studio Code, Slack, or Facebook Messenger); however, we want to
be fair to our web technology friends. If you have feature needs that
Electron does not meet, you might want to try NW.js.
Keep in mind this may be biased- it is from Electron's wiki page.
Electron doesn't introduce
a new JavaScript context in web pages.
Source code protection
Electron is packaging its applications with asar, which contains the applications' unprotected source code. This makes it possible for application 1 to extract application 2 and inject vulnerable scripts, without the user knowing it. You can checkout this project on GitHub to see an example of how to manipulate the Slack app for an example. As for now, the Electron team don't have any plans to implement support for source code protection.
NW.js has built in support for compiling your source code to protected binaries.
I've downloaded and installed the windows 8 consumer preview, and I'd like to figure out how to use the UI Automation API's to get data from metro style applications.
Background: I have a lot of automated tests which use the Microsoft UI Automation API's to interact with applications. The scripts are written in IronRuby against .NET 4
Initially, I'd simply like to check if the start menu is visible (and if so, close it)
According to Microsoft, the normal UI Automation API's should be able to access and control metro style applications, but the problem is, I can't figure out how my code can actually access the UI of metro applications? Our normal way of viewing UI automation data is using UISpy, however when I run UI spy under windows 8 and bring up a metro app, there is no mention of it... it seems like metro apps (including the start screen) are walled off from the desktop.
If I can't find the metro apps in UISpy, how can I find what their automation ID's are, and how could I find them from my automated test scripts?
A few resources on UI automation which works in Metro style apps:
Here is a sample demonstrating it.
Here is a blog post explaining it.
This is a forum thread on the subject.
There is nothing about the app that stops traditional UI automation from working correctly. You may have to get updated tools to view the Metro style apps. Some ship with the Consumer Preview. Look for inspect.exe.
UI Automation tools can automate Metro applications. Check RIATest for example.
Stating from version 6.0 a number of features in RIATest are specifically targeted at Metro style application automation, particularly:
Ability to stay on top of Metro UI to allow you to simultaneously see your Metro application and RIATest IDE and minimize switching from Desktop to Metro screens when automating a Metro application.
Recording of actions performed on native Windows GUI elements (including Metro GUI). The recorder analyses your script code and reuses your variable names to generate cleaner recorded scripts similar to how you would hand-code an automation script.
Seamless workaround for bugs like this in Windows UI Automation implementation in Metro UI.
Disclaimer: I work for Cogitek, the RIATest company.
WinRT (aka "Metro Style") applications run in an sandbox. You cannot pierce the walls between applications, including to Desktop applications. This includes network isolation (you cannot refer back to localhost for example except in a development environment). There are a couple of exceptions to this such as the Share and Search contacts which allow for very specific types of interactions between apps.
It is this sandbox that is preventing UISpy from seeing the executing WinRT application in the background. I'm not sure how UISpy could work around this issue without some kind of development environment exception to the sandbox (similar to the network isolation exception) that isn't available in the consumer preview.
I'm also unaware of any announcements regarding when/if the UI Automation API will be supported for WinRT applications at this time.
How can I develop an installable desktop application on top of the Mozilla Engine or the Webkit engine.
We want to have best of both worlds, ease of development with DOM+Javascript+RenderingEngine+ContinuedImprovements in a Browser and user's control as in a desktop app
I looked at using C++ XPCOM for Mozilla but it seems to be quite complicated, Is there any other way to code like a WebApp using Javascript but burn it into the browser and dress it to give a feel of a desktop app. Also I require that javascript is compiled into native so that one cannot sneak into the source code
Are there any examples of desktop applications done this way ?
Web apps are fine but there are concerns of piracy, privacy, security and version control. The moot point is that in a web app the control lies with the software vendor, moreover the data is also with the vendor. Not only these, any changes to the application may also necessitate another around of training. What we want is that once the customer buys a version he is sure of what he owns and that he is in total control of it and we as software developer do not exposed our source code.
The issue is we have expertise in Web App development and we want to utilize that to develop a Desktop App
Your last point is that :
The issue is we have expertise in Web App development and we want to utilize that to develop a Desktop App
Well then BowLine can be an option though it requires Ruby, so you need to consider that. You can also take a look at WebKitDotNet if you are with .net Background.
Use XUL for the user interface and code your functions using JavaScript. You problably only need C++ to expose native functionality not yet available in Gecko. Examples of software that works this way: Komodo IDE, Songbird, Firefox and Thunderbird.
The Adobe Air introductory documentation and samples seem to separate Air development into 3 different categories:
HTML/Ajax
Flash
Flex
I've read the tutorials and examined some of the code, but I'm not totally clear what the differences between them are, and more importantly why you would choose one approach over the other. Sorry for asking such a basic question (please bear in mind I come from a Windows development background).
I will answer this myself since I've done the research. Here's a summary:
HTML/Ajax, Flash, and Flex are
different approaches to developing
web apps. These technologies can be
combined in a single web app.
Adobe AIR is a runtime which allows you to take those web technologies and run them as a desktop app instead of in the browser. You can combine them in the same app.
Flash is a runtime that was originally created to provide a rich UI to browser based apps. AIR brings the Flash runtime to desktop apps.
Flash runs compiled SWF files and is scripted via ActionScript. Flex is a tool
(SDK, MXML schema for defining UI, etc), which makes it easier to create apps that run on the Flash runtime (it generates SWF files).
Further details see: Adobe AIR FAQ, Adobe AIR (Wikipedia), Adobe Flash (Wikipedia), Adobe Flex (Wikipedia).
As for deciding which approach(es) should be used when developing for AIR, I think that should be based on the experience and preferences of the developers working on it. I don't think Adobe gives any guidance here, because their goal is simply to provide the same options for desktop developers that web developers already have.
I haven't used Flex myself, but I know that you can use it to interact with HTML elements, rather than providing the interface itself via Flash. I'm not clear on what Flash vs. Flex is though.