This is amazing. I work in digital publishing at an art museum, and we are creating digital books as static HTML/CSS/JS files which rely on client-side interactivity for most features.
Some people have asked about getting a desktop version of these books which they could download locally (scholars doing fieldwork, etc). I knew something like this was possible using Electron, but I figured I'd have to build it from scratch if I wanted it.
Instead I just pointed this script at the beta version of our latest project[1] and the project built flawlessly in under a minute.
Nice work! I know that the web as a platform has its problems, but it is the only truly universal runtime we have right now, and tools like this help realize this potential more fully.
One question: is there a way to package pre-built copies as .dmg or .exe files so that non-technical users can download an app that is ready to go, without having to run the build script themselves?
I'm glad you like it! I think such an installer feature could be added in by integrating with https://github.com/loopline-systems/electron-builder, I'll see if I have time in the next few days to add this in before school starts.
This doesn't seem to create offline copies of the webapps, at least assuming by the examples given (maps.google.com and medium.com), which would be quite useless as static apps.
Hey, cool, it opens external links in my default browser. That's all I've ever wanted in a web-page-to-app tool. It's surprising no one has gotten this right before. Both Mozilla's Prism and Chrome's webbapp-izer functionality get this wrong.
Edit: It doesn't support HTTP authentication, though. Any page that is supposed to present an HTTP auth dialog just goes straight to a 401. This means I can't wrap my personal Transmission/Syncthing servers using nativefier. Edit 2: Looks like this will be fixed soon[1].
I had originally mis-read this: I read it as a super-simple wrapper that converts web pages/apps into a native mobile app. But it seems it actually creates a desktop application. I understand the use-case: avoiding bouncing between web browser tabs, but I guess I don't see that as annoying enough. I'm sure there are other use-cases that I'm not thinking of.
My main driver is Firefox, but Google Docs etc. won't work properly in it. I also wouldn't want it to use the same cookies (home vs. multiple work Google accounts, etc.).
`google-chrome --user-data-dir=$XDG_CONFIG_HOME/gdocs/ --app=https://docs.google.com/` launches Chrome with a dedicated profile and in "app" mode (no browser UI, favicon as program icon, etc.), which works well for cases like this. Apparently this tool in particular works slightly differently, but the intent is comparable.
As someone who spends most of the time in the browser, I'd actually prefer as much as possible to be in browser tabs that I can easily jump to via ctrl+[tab position] instead of having to cycle between external programs with alt-tab.
Ha, I'm the exact opposite. Not for everything, but when I'm developing I find it easier to switch between, say, Trello, Github and Slack using alt-tab.
When I am working on projects, I would often have hundreds of tabs open (figuratively speaking) with reference material and whatnot, and my browser tab bar would end up being a gigantic mess. I just thought it would be handy if I could keep certain web pages that are important (such as Facebook Messenger / Whatsapp etc.) separately from the mess to facilitate easier navigation when switching between windows.
Performance and experience is so much better from an actual native app, though.
This trend toward building a parred-down version of a browser into link-rich apps is actually really troublesome, from both the broken user experience (different buttons for different common tasks, back and return functions not working consistently) and from a security standpoint.
How can Fluid be using an old version of Safari? Does it bundle its own build of WebKit? Or are all Mac apps that use the public WebKit framework using an older version of WebKit than Safari itself?
I'm also using Fluid, and I even purchased a license for it, but it seems like it's no longer being maintained, to the point where sites refuse to work with it due to the outdated User Agent Identifier (which you can change, but still...).
Fluid refuses to create a wrapper for a site using a self-signed SSL certificate (or at least, it did the last time I tried it).
This was annoying, because I wanted to use it with an app I was self-hosting, and it wasn't worth the effort of getting an SSL certifiate it would accept.
I'm not convinced that this process qualifies as making a web page "native". After all, this just seems to spawn a new browser instance with some UI stripped away.
None of the normal qualities of native applications (native performance, hardware access, exposure to system interfaces/toolkits) apply.
I'd say if your GUI layer is based on the HTML DOM then you're certainly not "native", for any useful definition of "native". Except maybe on ChromeOS, I suppose.
Honest question: Are Chrome apps "File->Create Application Shortcuts" not available on Mac OS X?
Because on Linux you can create such apps very easily with this Chrome feature, and I'm pretty sure even cookies/history is separate from the main Chrome instance.
I tried doing the same thing using Electron. CPU usage isn't ideal, context menus wouldn't work, keyboard focus was an issue. Eventually I dropped it and have been using MacPin[1] for a while. There is also WebShell[2]
I use Fluid (http://fluidapp.com) for a similar purpose as Nativfier... it's because my brain is hard-wired from years of use to equate Cmd-Tab (or Alt-Tab) with "task switch." My brain thinks of e-mail as a separate thing from my work (editor and browser), and I personally don't like conflating my browser with different tasks like e-mail.
I know I could just learn Ctrl-Tab or Alt-{ or whatever to cycle through dozens of tabs, but Cmd-Tab works for me. Different strokes for different folks.
I'll probably check Nativfier out because Fluid hasn't been updated significantly in a while and uses an old renderer, and it's a bit laggy w/ HuBoard (the front-end to GitHub issues that we use at work - it's pretty JS-intensive)
IMO for web apps that you have open all the time (maybe Asana, Google Docs), native OS navigation and window management is significantly better than tab navigation. Of course it doesn't have as much of a benefit if you do it for every tab you have open.
Google Maps, like most web apps, incorrectly determines my language based on IP address. I can't find a way to change it from the UI, but you can force it to English with this:
If you use Chrome, and are not logged in to a Google account, Google Maps respects the Chrome language setting (just tested). Go to settings, "Show advanced settings" at the bottom and search for "Languages".
If you are logged in to a Google account, the language settings on your Google account takes preference.
That isn't the case for me. I have my OS and Chrome set to English [0], but when, in Incognito mode, I go to http://maps.google.com/ it redirects me to https://www.google.it/maps/ and displays everything in Italian (I'm in Italy at the moment).
That's really nice actually. I couldn't try it out but if it works I think it's really cool. I just don't know what to think about my Apps being more and more simply websites instead of Native.
What does native even mean here? It is just making a standalone browser that will only talk to the website and whatever resources it references or somehow make it all work locally, natively?
This project and the projects I see linked in the comments thus far (MacPin, WebShell) are AWESOME. I really wish Python had a better story here, but I digress.
Also, these types of projects are puzzling at the same time. I have been under the impression (right or wrong), that people didn't like/want/need desktop apps. With these types of projects I wonder if people don't know that they want desktop apps...
Really useful! I actually started to build a similar utility as a side project with NW.js, but I never finished it because of lack of time... You should also add the ability to add chromium flags...
What am I missing by having a simple web link on a desktop to any frequently accessed web page I want?
Launch it, and there I am, in Google Maps or whatever.
Does this natifier actually suck down some of the JavaScript so that it is locally hosted? If so, is there some check if the upstream software has changed and needs to be re-natified?
I liked it. Reading Medium posts on your app was better than in a chrome browser. Congratulations. Side note: on Ubuntu there is no icon when I open the app. If it could get the favicon would be great, as well as the back button rather than pressing backspace.
Actually, I originally intended this mainly to wrap single page web apps that tend to avoid using the back button and instead providing their own navigational controls on the page itself, so I did not include them in the UI. However, if desired, these basic navigational controls (back, forward, reload etc.) can be found in the application menu.
Thanks for the feedback about the icon issue, I'll take note of that!
Yeah, that was one of the main concerns I had when I was developing this, it would be lovely if the app itself could automatically source and add them in automatically. It's really a hassle to manually add teh images, but I'm not really familiar with how to convert them into the appropriate format in Node.js in a quick and easy way. Will look into this in a future update!
Wonder if the executable file will work in other systems. For example if I create an app for google.com and move that app to another system, will it work? given that is the same OS.
Yeap, you can specify different build options such as OS (osx, windows, linux) and processor architecture and pass it to a friend, but the main idea is that it simplifies the process for you and automatically detects your current platform.
Cookies are isolated to the app it is built for, and right now the application name is the unique identifier for the app. You're right in that the application data should be segregated, and I'll look into a more robust method of uniquely identifying each app that is built.
This trend of a hundred desktop applications all bundling their own copy of Chromium really bothers me. I know the situation sucks on Windows, but on Mac, why not use the system WebKit framework? I know the decision was made upstream of this project, in Electron, but this project will increase the proliferation of app-private copies of Chromium.
For the past year or so, when thinking about software bloat, I always come back to this sad bit of dialog from the novel _Off to Be the Wizard_:
Phillip (time traveler from 1984): What on earth can a person do with 4 gigabytes of RAM?
Martin (from 2012): Upgrade it immediately.
Do we really want to make that situation even worse?
Same reason people often like to statically link. The system is guaranteed to be a moving target sooner or later, so new bugs may appear or disappear depending on a user-controlled action that's tedious to track if it's possible at all.
Bundled code, on the other hand, is a fixed, known quality against which bugs can be tested, or source inspected, or otherwise debugged in a way system libraries typically cannot.
It sucks on Linux even more. On Windows, at least everyone (including the build tools) is used to shipping dependencies, on Linux not so much.
You have all sorts of crazy dependencies on (system) libraries (not to mention libc versions), and you probably don't want to fool around with dozens of package managers (apt-get, rpm, whatever Gentoo is using, hand-rolled distros), and you pretty much don't want to store stuff in /usr/local because you might overwrite stuff already present there.
> but on Mac, why not use the system WebKit framework?
Because Chrome is far faster to pick up new stuff than Safari. Also, most people these days prefix and test only for Chrome, which disqualifies embedding a Firefox runtime.
I do agree with you on that, and there should be some form of Chromium that can be shared across applications to reduce the bloat of such packaged apps. Perhaps this is an issue with the architecture of Electron itself, which requires all such apps to contain their own version of Chromium?
I wanted easy cross platform compatibility with minimal code, and Electron seemed like a good choice across for apps across Windows, OSX and Linux.
On OS X, a little Cocoa application in Objective-C using the system WebKit framework would probably do the trick.
On Linux, a little GTK application in C using WebKitGTK would probably work.
On Windows... I don't know. I know from firsthand that embedding the IE engine via the WebBrowser ActiveX control really sucks. I'm going to see if the WebKit WinCairo port is any good these days.
If we must use CHromium, then the Chromium Embedded Framework is worth a look. It's a DLL, so in principle, it can be shared between applications. You'd still need some platform-specific code to create the window containing CEF, though.
All these "little native applications" require lots of work. If I want to share these "little applications" with people that do not share my OS, I am forced to make at least 2 different versions of the "little application"... then maintain them.
Good enough, is good enough. Yes, the web is not as performant as native... the question becomes; is it good enough? The bonus in wrapping Chrome is that I don't have to dive into 3 or more system level API's to get a "little application" up and running.
You are missing that saving a bookmark to the desktop does not provide a different instance of the browser when spinning up. It will just open a tab in the first browser it finds.
Which is horrible if you consider something to be a core piece of software and you are unable to effectively cmd-tab to it. This is more of an OSX issue than windows, since windows will happily alt-tab amongst browser windows. OSX uses a less intuitive cmd-` for tabbing through program instances and still requires that the webapp is running in it's own window, in the same OSX window "Space", it cannot be minimized, and which will crash with the browser itself, irrespective of which tab is truly responsible [taking all your current state data with it].
I'm all for webapps supplanting native apps. But even presenting them as such requires something like Electron, and is completely counter to the trend of managing all tabs [webapps] as crony components of a master "WebBrowser" process.
Some people have asked about getting a desktop version of these books which they could download locally (scholars doing fieldwork, etc). I knew something like this was possible using Electron, but I figured I'd have to build it from scratch if I wanted it.
Instead I just pointed this script at the beta version of our latest project[1] and the project built flawlessly in under a minute.
Nice work! I know that the web as a platform has its problems, but it is the only truly universal runtime we have right now, and tools like this help realize this potential more fully.
One question: is there a way to package pre-built copies as .dmg or .exe files so that non-technical users can download an app that is ready to go, without having to run the build script themselves?
[1]: http://gettypubs.github.io/Terracottas/