[osrec]

One of the wonderful things about a PWA is that it is so freeing (no app store gods to appease for approval etc etc). I'm a little afraid that putting PWAs in an app store may actually reduce the flexibility they offer by restricting what PWAs can and can't do. Then again, an app store may be a necessary to allow PWAs to diffuse into mainstream usage.

Personally, I am looking forward to the day PWAs are considered on par with native apps by the general populace. I think we're getting there in terms of functionality and flexibility - I run https://usebx.com/app which is a PWA, and my users are pretty happy with the functionality it delivers on all platforms. It also helped me launch with a smaller budget, since it's a single code base that runs on desktop, mobile or tablet.

The one thing I will add is that building a high-quality, performant PWA is significantly harder than building a native app - why? because you really need to understand the workings of modern browsers to squeeze native like performance, and unfortunately, in my experience, very few web developers have that depth of understanding. I have been building web apps for 20 years (I started young), but when I decided to build Bx as a PWA, I had to learn a lot to achieve the quality I desired.

[sandGorgon]

That's not the issue. The TWA has been created specifically on the request of app creators (including me).

The problem is that users find PWA very difficult to install. Like massively hard. They are used to the "app Store installation model" - they search for stuff, they click install, they check for permissions and then apps are available in their dock.

This model breaks down in a PWA "add to homescreen" kind of experience. In fact, it is hard to explain what a "homescreen" is in vernacular languages.

The TWA is a massive jump in usability - publishers can now work using web technologies and users can still get the same experience. This is what will unlock web use on mobile phones.

[CraftThatBlock]

I think app stores are a great discovery tool for PWA. Searching for PWA in a centralize marketplace will most likely be one the tipping points of PWA, and putting amd emphasis on the "app" point.

If their goal is to be the same as native apps, putting them together makes them even closer to that objective

[pasta]

Well I find myself not using the app store anymore because it's useless to find apps.

There are no filters and no way to order results.

Top downloads sometimes have worse scores than indy apps that only have a hundred downloads but work much better.

[criddell]

I don't understand the love that PWAs get around here. All things being equal, as a user I'll chose a native app every time.

As a developer, I'd much rather be working in a native toolkit as well. There's less to learn to get going and the foundations are more stable than the browser and billion lines of javascript from 40 different parties.

I also think it's a lot harder to reason about security with a web app. I might be able to satisfy myself that the app I load today isn't doing anything nefarious, but you could sell your business and tomorrow I might be running a significantly different app.

[nicoburns]

> There's less to learn to get going

There are thousands of pre-existing web developers for whom this is not true because they've already put the effort in to learn the web platform. For these people, PWAs represent significant new functionality which they can now use without having to learn a whole new toolkit.

You may be dramatically underestimating just how many web developers there are.

> I also think it's a lot harder to reason about security with a web app.

I'm not sure that's true, because the web runtime itself tends to provide quite good security (partly because it doesn't allow access to a lot of device APIs in the first place). Native apps are often granted quite wide permissions, and auto-update by default too.

[gammateam]

> All things being equal, as a user I'll chose a native app every time.

The reality is that most potential users don't install native apps, and will use a PWA without knowing it. Its just a URL.

Numbers are still as high as 20% don't install due to lack of space. Thats a ridiculously dumb bounce rate.

"Solutions" were presented already 3-4 years ago, for android. Native apps that don't install! And hey look, nobody cares!

[ksec]

I don't like Web Apps, but there are a huge class of Apps that doesn't require a Native App to work. Services Sector which already has their Web Platform sorted out, and are only providing an "App" in the App Store. Paying for App Development is expensive, when majority of the functions in these Apps are exactly the same as online. Having PWA meant they could offer an "App" at a ( relatively speaking ) much lower cost.

Example, why would every Restaurant wants to have an Apps of its own?

That is of course assuming PWA for these kind of Apps work close to Native App in performance and usability. Time will tell.

[criddell]

> Example, why would every Restaurant wants to have an Apps of its own?

Why would any restaurant have an app?

> close to Native App in performance and usability

Javascript in the browser will never be close to a native app as far as CPU, battery, memory, and bandwidth utilization goes. I don't think they will ever work as well with assistive technologies either.

[arendtio]

Well, from a user perspective you might enjoy having an app on every platform. So no need to wait until the developer rebuilds some app on a new platform. No need to bother the dev to port his app to Mac/Linux/BSD/(other non-mainstream OS).

In my opinion, the single most reason not to use a PWA from a user perspective is the performance. But I still use my Samsung S3 and when I look at the current flagship smartphones... They have more RAM and CPU cores than many laptops nowadays.

So I think the performance issue is going to be much less relevant. Others might say that usability is an issue too, but with the upcoming component libraries, that is going away too. After all, projects like framework7 [1] support quite good components already.

[1]: https://framework7.io

[pier25]

> As a developer, I'd much rather be working in a native toolkit as well.

Across multiple OS?

[criddell]

Definitely. The last thing anybody wants is to run an application on a Mac that looks and acts like a Windows application. How could you be proud of that?

[pier25]

I don't think that's even remotely true.

For example: Photoshop, Autodesk Maya, Da Vinci Resolve, Premiere, Ableton Live, and a very long etc. Those are not your crappy Electron apps, but industry standards.

[osrec]

I find people generally overplay the "all apps must look native on my OS" card as an argument against PWAs. Yet they are often very happy using Google docs for most of their day to day work... I personally like the fact that a web app looks the same across all OSes. I find that is a better type of consistency to aim for, in that if someone changes their OS, they don't need to relearn your app's UI.

[la_fayette]

In terms of the web one could use different stylesheets for the different platforms... the business logic can stay the same. OnsenUI and ionic are providing just that.

[criddell]

So on Windows it feels like a Windows app and on Mac it feels like a macOS app? All of the widgets work the same as native controls with accessibility devices like screen readers?

[GrzegorzWidla]

It's only about expectations.

When you open your web browser you suddenly expect apps you access there to be the same across all OS, and you certainly don't mind them all being different from each other - it's actually a good thing.

So why shouldn't we expect the same of native OS? I know I care only about few details - like native notifications instead of custom ones, native close, minimize, maximize buttons etc.

[osrec]

I wrote an article on why I think PWAs are the future in my opinion: https://osrec.co.uk/publication/3/Why_PWAs_may_be_the_Future

Maybe it'll help you see things from another perspective :)

[criddell]

I've read this before and I get what you are saying. From a business point of view it makes a lot of sense. I'm saying from every other point of view, it doesn't.

> I'm sure you'll agree that having a standardised platform that runs on any machine, while being unlimited in the variety and nature of things it can conjure is the utopia we are all working towards.

Are you talking about Java + Swing? :)

I like that macOS feels different from Windows and that I can load up a Linux with many more variations that all have their own personality. I don't like how web apps use my bandwidth (I pay $10 / GB on Google Fi), how they use my battery, or my CPU.

[tluyben2]

> I pay $10 / GB on Google Fi

Wait, what? That is insanely expensive. I pay far less even on just 4g. Is that a normal price there?

[criddell]

I don't use a lot of data so my monthly phone bill is usually under $35. That doesn't seem unreasonable to me.

[tluyben2]

But is that something normal in the US? I live in a remote location in Europe, I pay 19 euros and download/upload well over 100gb per month.

[wincy]

Any good resources on developing that kind of understanding? What sorts of things would a web developer need to learn?

[osrec]

I don't have a list of resources, but here is a not-so-comprehensive list of things I find important:

  1) Understand how requestAnimationFrame() works
  2) Understand how setTimeout() works
  3) Know how to minimise the number of DIVs you have in the DOM at any one time
  4) Understand the touchstart, touchmove and touchend events properly.
  5) Understand the browser viewport model and the vw, vh CSS units. These units can even be used to scale text, which, if done well can allow for truly responsive text scaling.
  6) Understand the various layout engines. Grid is good for static layouts, Flex is great when you want to animate things.
  7) Understand the different element positioning modes. I'm amazed how little most web devs understand absolute and relative positioning. Understanding this is super useful.
  8) Understand promises properly. Understand async/await and try/catch. Understand Promise.all() and Promise.race().
  9) Understand what 'this' means and how func.call() works in Javascript
  10) Understand indexedDB and localStorage
  11) Be aware that any Javascript on a page executes in a single thread
  12) Understand which JS likely to trigger a "recalc" and "repaint" in a browser
  13) Become a master of your browser's dev tools and be comfortable debugging asynchronous code.

The MDN pages for a lot of the above are pretty good - all the best :)

[matgessel]

Don't know how much of this still applies (2011), but it's a good starting point:

How Browsers Work: Behind the scenes of modern web browsers https://www.html5rocks.com/en/tutorials/internals/howbrowser...

[SCdF]

> I think we're getting there in terms of functionality and flexibility

One big thing that is missing IMO is getting out from under the 5% quota. If you want to write a "serious" app that might store large amounts of data locally you are under constant threat of your data being arbitrarily deleted from the device.

[osrec]

This should help alleviate the issue somewhat: https://developers.google.com/web/updates/2018/11/writable-f...

[blumomo]

Your demo login is broken. I don't want to sign up for understanding your product.

[osrec]

Apologies - there was a subtle race condition in our code which meant that if you try to log in to the demo at the instant we're resetting our demo's data, you end up using stale demo credentials. This has now been fixed :)

[oneeyedpigeon]

Also want to report this. Running safari on an iPad, fwiw, but it looks like the username/password for the demo user are just wrong.

[osrec]

Sorry about that - we have a cron job that resets the demo user data every few hours. Sometimes if you happen to catch it just at the moment we're resetting, a bug in our code means the demo credentials used by the frontend to log in to the app are stale. If you refresh, you should be okay now :)

Edit: my dev has just issued a fix for this bug, so it will not be a problem going forward!

[oneeyedpigeon]

Thanks — much appreciated!

[pjmlp]

You application looks quite nice.

I do prefer native to Web, but also have spend the large majority of project assignments on the Web side.

If PWAs everywhere get the same capabilities as in UWP, then I really admit defeat on my preferences. :)

On my specific case, it would be so nice to finally have WebGL catch up with ES 3.2 at very least.

[osrec]

What's UWP?

[pjmlp]

The future of Windows APIs, aka COM Runtime.

[osrec]

Ah, thank you!

[fefb]

Nice work. How many users? Are using some cloud services for the backend? Thanks in advance

[osrec]

Just over 100k users. All of the backend is managed by ourselves - no cloud services, apart from the servers/hosting.

[fefb]

Wow. This is big.

Do you have some blog? Explaining technologies, knowledges and etc about this app? How did you grow to reach 100K users?

Thanks in advance, and congratulations.

[saulrh]

  I'm a little afraid that putting PWAs in an app store
  may actually reduce the flexibility they offer by
  restricting what PWAs can and can't do

Not sure what you're saying here. Are you afraid that app store policies (privacy requirements etc) will be stricter than what you can do with browser APIs, or that the app store will ban API abuses that're currently necessary for acceptable performance/usability?

[osrec]

The web is analogous to an untamed forest. It's got a bit of everything in it, and you can choose which parts of the forest you wish to go to. Don't like app XYZ because it locks up your CPU? Don't visit its URL. If you like and trust app ABC, use it regularly. It's like when you visit a restaurant - if the food's good, you go back. Otherwise you don't. I feel people are smart enough to work this out on their own without needing a corporate app store to set out rules for everyone.

If we start to restrict the web, I feel it takes away from what makes it great; the fact that it's a platform for untamed creativity and choice.

[jayd16]

I think its a good change. There are a fair bit of apps that should have been web pages but the owner wanted something on the app store.

[dddw]

wow you're app is really nice! superfast too

[osrec]

Thank you! We've got version 2 coming out at the end of the month which aims to make it a bit quicker with more functionality :)

[WA]

Is the UI entirely custom-made or do you use any framework for that?

[osrec]

We built our own framework, but do make use of d3 for charts and jQuery for cross browser events. We modified d3 a bit to make the animations more performant.

[pier25]

Apparently he/she used jQuery, jQuery UI, and D3.