I’m thinking of making an app and I am jumping between making a dedicated web and mobile app, but with PWAs as a thing, I’m wondering if I should only consider that.
What considerations should I have while developing?
Relatedly, I have absolutely no webdev experience at all. For my particular project in mind, I have a friend who’s willing to help me out, but I’m curious as to the direction we should look into.
PWAs have been a thing for 18 years.
If you want to build a web app, make it responsive by default. If you want a dedicated mobile app, build one.
In other words, you don’t need a dedicated PWA and for most, it’s overkill.
@Stevie
I would think that marketability and reach would be better overall if I have a mobile app; however, I don’t want that to detract from having a website/app, which I think is necessary. This is why I was considering a PWA, as maybe it would be easiest for developing as a 2-person team, although surely not without sacrifice.
I can definitely see that it may be overkill for the user, as it’s not as direct of an installation method. I’m not sure what else may be involved in its being overkill though. Is there anything you can share that I may read up on?
@Jessie
Protip: forget about “marketability and reach”. Just make it work. Once it works then you can worry about marketing it. Cart before the horse and all that.
@Jessie
Here’s the thing, PWAs provide marginally more functionality over a regular website, and if most of your users (or all) have a constant connection, a PWA is useless.
PWAs are best for those that need to work without an internet connection but still be updated via a website.
Emerson said:
@Stevie
Why is a PWA overkill?
Today, most of the user base has a reliable, always on, fast enough connection that it’s better to just talk directly to a server vs having a worker poll for data and still function without a connection.
Most websites require that constant connection anyways so there is no point in the extra work for a feature that adds minimal value.
For applications that have all data client side and only occasionally need updates are a better use of PWAs.
Bret said:
@Stevie
I’d argue that more often it’s overkill to build a mobile app instead of just a PWA.
You missed the point of the comment.
If you want a dedicated mobile app, build one.
and
If you want to build a web app, make it responsive by default.
Not every site needs a dedicated mobile app. Most sites would NOT benefit from a PWA.
Something like tauri would work well to let you build any combo of web app, desktop, or mobile apps.
Jules said:
Something like tauri would work well to let you build any combo of web app, desktop, or mobile apps.
Thank you for sharing this. I took a quick look at it and something that popped out is “Tauri does not natively support server based alternatives (such as SSR).”
The idea I had in mind is for a user to request data from a server based on certain values in their profile/query. It seems like this wouldn’t work for that?
I’m not really familiar with app development at all - please forgive the naïveté!
@Jessie
That’s not what SSR means.
A static site is HTML that never changes. You don’t need any kind of “backend”, everyone sees the same thing.
For dynamic content, like a user’s profile page, the HTML gets built on the fly. One way to do that is to have a bunch of JavaScript that manipulates all the elements on the page to customize. That’s called client-side rendering.
Server-side rendering (SSR) is when the backend builds the HTML, and usually minimizes the amount of JavaScript needed, and then serves the customized page. The browser has to do very little.
Tauri builds “apps” which are then “installed”. Because all of the assets are stored on the device, it’s obviously client-side. But I am sure they get the question “How do I use this with Next.js” all the time.
@Jessie
It just means that you won’t be able to use the device itself as a server (which you shouldn’t anyway in most cases). You can still make a separate server and host it somewhere and make requests to it from the app.
Do you need SEO?
PWAs only differ by just adding a few metadata of the web app itself. This allows users to operate the app offline as well. If making an SPA seems tedious to you, do not look into PWA right now. You should try making a simple SPA, then iterate to add the features you want.
@Ridge
I would want SEO, but I genuinely don’t know how a PWA affects that. May you elaborate?
So, your recommendation is an SPA + SSR over an MPA (+ SSR)?
I personally may not be making the front-end of this much per se, and would have a 1-/2-person team to work on this with me. Is that the direction I should push for?
@Jessie
You got to understand how SEO works. I’ll try to brief it. So basically, there are crawler bots that go to different websites on the internet and index the pages in it.
In case where you send the whole app in JavaScript, the crawler bot is not able to see the nodes of your DOM fully as it is constructed using JS. This will give you poor SEO; the crawler bot cannot interpret the full content of your site, thus the search engine cannot point or read the data in the site.
When you send the app as just HTML, the crawler bot can now infer the DOM tree and see all nodes, which also contains text and images as well. Thus, now the crawler bot can now index these pages with contents with keywords. Now when a user searches (for example, a hair dryer that you sell on your website would show up when a user searches up). SEO is not just limited to this; the process of making small previews like the one you get in Twitter or Discord when you paste a link is also part of SEO.
Every app requirement differs from one another. If you are unfamiliar with all this, simply make an SPA that has poor SEO. You do NOT have to use SSR unless you really care about SEO. It’s very struggling to understand SSR without understanding the traditional way of delivering content using a frontend and a backend (if needed) hosted separately.
MPAs are now kind of a bad choice as it reloads the whole page when jumping around the site. Also, MPA + SSR is not a thing. SPAs are efficient in that it only reloads what has actually changed.
@Ridge
Hmm, so it seems that my understanding of SEO was a bit off. I would definitely hope that this shows up in a search engine, but I wouldn’t necessarily have a lot of specific content that I would want to appear on a search engine. I definitely have one or two things, but they aren’t the bulk of the app and UX per se.
The idea I have in mind is to pretty much provide a dashboard of some cuts of data as served by my database, filtered by parameters on the user’s profile/query. I wouldn’t want users to spoof access to other/all data, so I was planning on dynamic generation/querying. I feel like this may not require SSR, then.
After many years of watching lots of companies waste a ton of money chasing PWAs: they can work, but it takes a lot of investment and dedication. A lot more than you’d think. They’re fragile and the wins are overhyped, especially because of all of the issues with iOS and PWAs.
You are likely better off building a high-quality API that can be easily shared between your website and your app, and then building relatively thin clients that rely heavily on server-side logic.