Hacker News Reader

Comment by onion2k | Hacker News Reader

Web app with complex data = website that can be done very well with html, css and a server-side language.

Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb.

My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage.

Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.

View on HN

I think that when one is developing a web-based product, a working internet connection is a very reasonable assumption.

If that's not the case, it's pointless to create a web-based product. Just offer the full thing as an app and a simple web UI.

I looked at the WaPo link that you posted and it seems to be exactly this type of product with an identity crysis - my browser already allows me to save pages for later reading and if that won't work, there are a multitude of offline reading apps to choose from, I don't need a WaPo "progressively enhanced" app for that.

I keep seeing this use case of JS heavy web apps but have yet to come across one in production that adds any value when offline. Can you provide an example?

https://www.washingtonpost.com/pwa/

Assuming all the required data is reachable offline, which would make the choice of a web app very questionable.

What work is required to make an app fulfill it's need is mostly very similar regardless of what delivery mechanism you use to get it to the user. Native has a few advantages (performance, build tools, layout libraries, etc), but if all you need is available on a web app platform and the performance is good enough then a web app can still be a very good choice, namely because the code assets easily can be shared with other web offerings and there's vastly more available developers to do the job so hiring someone to write it is much, much easier (assuming you're not outsourcing it).

There are a lot of things that you have to do regardless of how the app is delivered - you need to work out what the app actually needs to do, you need to design the business logic, you need to design the look and feel, you need to get the UX right, you have to throughly test it. On a decent size app, the job of actually writing the code is about 25% of the work required. In my opinion, something that represents a quarter of the project probably shouldn't drive the entire process.

The apis and libraries for an offline app are very different to an online one. If you build an offline app as a html/js app then good like finding libraries for common tasks, like file system access.

When I'm talking about offline-first progressive web apps I'm not referring to something that would load data from a file system.

https://developers.google.com/web/fundamentals/getting-start...

As it is though, the API for file system access in JS might not be standard yet (and might never be) but it works well in Chrome: https://developer.mozilla.org/en-US/docs/Web/API/File_System...

Reply on news.ycombinator.com