Show HN: Nativefier – Wrap any web page natively

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.

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.

If you want a framework to turn a web application into a mobile app, try Crosswalk: https://crosswalk-project.org/

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.

> I read it as a super-simple wrapper that converts web pages/apps into a native mobile app.

I would love that. Just one command and you're done.

I'm a big fan of fluid as well. But it's always annoyed me because it's a older version of safari. Electron uses Chrome!

I was a user of it, but it's closed source and Electron uses Chrome and is heavily maintained.

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'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.

Not available on Mac OS X

I believe this uses Electron under the hood.

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.

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.

Yeap, it's just an easy way to create a browser that only talks to one website in a separate and isolated environment from your default browser.

> I really wish Python had a better story here, but I digress.

I know it's a digression, but I'm curious. What do you not like about packaging of Python apps on desktop platforms?

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!

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.

> why not use the system WebKit framework?

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.

> I know the situation sucks on Windows,

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.

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.

"Yet"? We should be moving away from Flash, not towards it.

No but it does seem possible to add it by hacking the Electron files post-creation.

https://github.com/atom/electron/blob/master/docs/tutorial/u...

Haven't tried it but I have some sites that use flash (mostly music streaming) that aren't playing well with Electron-based apps.

I tried using this with play.spotify.com (for linux) and had the same problem, it needs flash to work...