Hacker News Reader

Comment by trey-jones | Hacker News Reader

Using web technology to build "native" mobile apps has been around almost as long as mobile apps themselves. I used Appcelerator Titanium and Phonegap to do this beginning in 2012 (maybe even 2011) before eventually trying Native development later after finding these options underwhelming.

I have a reasonable amount of experience doing both, and my opinion is that development tools aren't really the problem. The biggest pain point is the platform specific deployment and maintenance requirements (including legal and technical documentation) that will be needed regardless of what technology you use to actually build the product. Because of this I always advise clients that they don't really need a mobile app. Just build it on the web.

If you absolutely must have a mobile app, you need to fully commit and hire an internal development team and be prepared to keep paying them as long as the app is going to be in use.

View on HN

> Just build it on the web.

It takes a very insignificantly small amount of JavaScript to make a website a Progressive Web App, which iirc can be listed on app stores.

If you dont use React or any fancy frameworks, I believe last time I ever did such a project our JS was under 50 lines of code to have our PWA working fully offline. There were some odd hacks, like detecting network connectivity.

Not on iOS. You gave to use this WebKit hack https://blog.pwabuilder.com/posts/publish-your-pwa-to-the-io....

That's specifically to be listed right? I mean I guess that's fair. Thanks for the link, saving that.

Is there a super simple tool for turning statically served websites into PWAs?

Last time I looked all of the simple tools had been deprecated in favour of complex tools that do way more than I need.

If I had a site in a directory that works fine from

    >cd MyWebApp
    >python3 -m http.server

I would like a command line tool That worked like

    >becomepwa MyWebApp

Which produced a PWA that downloaded everything on install and could be run henceforth offline.

I thought this would be a common use case, but I failed to find anything that supported it without intruding on my workflow.

Three things you need:

* Manifest file

* HTTPS - for localhost I dont remember the workaround, browsers have made this increasingly more complicated from recent experiences

* Service Worker - This is where I said I had maybe 60 lines of JavaScript.

If you have these three things, a browser should pick up that your sites a PWA and server running it should be irrelevant... So you MUST have a minimal amount of JavaScript, but I did it using pure vanilla JS, you dont need a fancy framework.

On that same note, there might be a tool that could inject the bare JS necessary for this, but I dont think it exists, certainly could be built.

The service worker thing is a weird amount of boilerplate. Every time I go back to making a PWA, I skip through 10 search results explaining what a service worker is (idc) until I just find whatever .js code I have to copy. And it's not some trivial one-liner.

I get that in theory a PWA can do offline stuff and whatever, but 99% of the time someone is only making a PWA to make the app installable on a phone home screen.

It is not a trivial one liner no, but you need 3 events implemented in your service-worker file, then in your main.js file you register it.

Service workers are just JavaScript that runs in the background in their own process in a browser. Could think of them as separate threads. Anyway, all of that can be done in less than 20 lines of JS?

I consider it simple compared to people building React apps and making the process more complicated than it needs to be just to build a PWA.

I was able to build a PWA out of a bootstrap HTML5 web app, with minimal JS for REST calls and ag-grid population.

Yeah, it's no big deal, I just find it odd that it's even a requirement. And using React doesn't get you out of making a service worker either.

You can't run native ads or handle payment via store with pwa

HTTPS isn't an issue, dropping whatever the command generates onto a HTTPS supporting server isn't an issue.

I want the manifest to be automatically generated from whatever is in the directory. The service worker should download everything from the manifest at first launch. I'm ok with a download-on-demand build option, but by default it should grab everything needed. If a user installs something, it should be assumed that they can use it offline.

I feel like the tool should already exist. If it does not yet exist, it seems like there must be a reason for that that I am not aware of.

What I have learned after all these years, is either do a Web site that is mobile friendly, or go native, anything else is a kludge in the search of holy grail of cross platform development without costs.

However this is a lie, because after going after the dream of cross platform, one lands on the (N + 1) reality, with team having anyway to master the leaky abstractions of the underlying platforms.

This * 100. I have a lot of experience with these types of apps and the biggest issue I've encountered is the platform keeping up with native technologies and OS updates.

Reply on news.ycombinator.com