> First, many sites do not need a mobile app — people who sell apps like to present that as a requirement

Yes, Testify! Also, I'd like to mention, so many of these upsold apps end up being a wrapper around the normal web view. I've seen this being advertised/proposed as a plus, as well "No need for your customers to learn a new interface, we specifically engineer your app experience to be just like the web experience". It's interesting to see heads nodding in reply to this.

Oh, yes — definitely saw those. My favorite were the ones in the pre-WKWebView era where the app was basically the website, except slower because it didn't have the JavaScript JIT enabled.

The idea is discoverability. Once, people looking to purchase Nespresso coffee online would go to Google. Now they go to their app store. If your app isn't there, they those people are going to install a competitor's app and buy your competitor's coffee.

Do they? Really?? I know some people who don't even go the the store for apps and do everything through the Google app that includes app results as well, but the other way around?

I just searched for "buy coffee" in G Play and not a single one of the top 15-ish results let me buy coffee apart from one coffee shop in New York, which is off by roughly one half globe circumference. If anyone ever did that, they'd quickly realise there's nothing there and go back to a search engine.

According to the guy who does metrics for my client - and his company does metrics for the largest e-retailers in my country - this is the case. Maybe he's pushing his own agenda or dream? Maybe it's market-dependent? But this is a company who can be trusted in the industry.

Wouldn't be the first time industry research results were conveniently aligned with profits, but I'm obviously not accusing anyone of anything as my evidence is 100% anecdotal and any research is better than none.

I guess it's just that users are stupid? Like, I know calling users stupid is a bad trope and all, but this is one of those cases where the behaviour just straight up wouldn't produce usable results. Like, if they're looking to buy a bike, will they just search for "bike buying apps"? I get looking for "apps to buy things with" (like amazon, wallmart, whatever) and then picking one and seeing if they offer bikes, but looking for the product directly??

This actually seems to also contradict the recent trend of people moving to big apps like DoorDash and Amazon replacing individual apps with different niches like the McDonald's app and apps from smaller retailers. If you're looking for "buying a bike" the Amazon app won't even be on the list...

Again, all of this is my logic, I have no evidence. This is just one of those situations where something goes so strongly against my intuition that I can't imagine how it could possibly be correct. I'll have to look for some real research on this, if any is available...

» This is just one of those situations where something goes so strongly against my intuition that I can't imagine how it could possibly be correct.

I think there are a few things at play here

1. Principal agent problem https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

2. Illusory truth effect https://en.wikipedia.org/wiki/Illusory_truth_effect

So like you said in the beginning, it makes sense that people selling something will highlight "evidence" that it works (principal agent problem).

Marketing is counterintuitive though. Please take a look at illusory truth effect and tell me what you think.

For what it's worth, I agree with you. But I don't know if that is because I was just trained to google everything.

I’d really want to check the sources on that to see the methodology. I’m in different spaces so it could be different here but that’s pretty much the polar opposite of what I’ve seen – people use social media or web searches, and hit the App Store only when pushed with a hefty drop-off rate. I’ve heard that this is very different for a few categories like games, which makes sense, and I think a key part is how well you can sell the benefits to the user: games, Uber, etc. have a pretty clear benefit but it seems like installing an app is seen as committing to some kind of ongoing relationship.

Is this really the case? It never occurred to me but I'm web native, not app native.

If it is, in most cases we can just release a webview-in-an-app and render the usual responsive website on the phone. This is the low cost route to apps.

However there are products that could genuinely need an app. A Nespresso machine could be one of them: control everything from your phone and if a machine has some kind of cup automation, also make coffee from remote and walk to the machine to get the cup whan it's ready.

I agree with the sibling comments, I've never actually seen anyone go to the app store before Google/Amazon for simple purchases.

When it comes to these companies selling apps though, it doesn't matter what the market thinks... What matters is what the suppliers think the market thinks.

I am open to HTMX. Seems refreshing but I am a little confused about how to structure the backend API returning small bits of HTML? Wouldn't that be a colossal nightmare to reason about?

I can think over time I'll have endpoints like this:

  POST https://foo.com/bar-section/baz-button

No? Haven't quite thought about it deeply but I can imagine logic mixed with UI bits in the backend.

Have a look at how Phoenix(Elixir) does it with LiveView. You simply write everything as a server rendered view and the framework pulls things apart and sends just what changed over a web socket. Its mind blowing how fast it is (can be. Latency is real)

I have no doubt that this style of front-end management is going to be a game changer in the next few years. Of course full-on SPA frameworks will still have their place. But if you aren’t writing the next Google Maps clone, maybe you don’t need all that. It’s made me love web dev again after hating the complexity explosion of recent years.

https://m.youtube.com/watch?v=8xJzHq8ru0M

What worries me (I write Django, Rails, Phoenix web apps - different customers at the same time) is that I'll have to learn yet another three different ways to do the same thing. What I'm doing now is either creating HTML pages (the 3 ways are pretty much the same, Django a little bit more set apart) or a JSON backend (basically the same everywhere.)

But to be fair it's fear of the unknown: I read about all of these approaches but the only new project started with a SPA and the other ones will never move from backend generated HTML.

The concept is absolutely fantastic, I am very intrigued, thanks.

> API returning [...] HTML

The endpoints that return endpoints are not API endpoints, they are UI endpoints like `/index.html` or `/login` or `/Results.aspx?id=3984272`. Now you can have `/login/email` or `/login/google` and switch between them like <https://htmx.org/examples/tabs-hateoas/>.

As for the machine-consumed API, you have quite a few options. e.g.: The server that serves these resources may serve JSON to the same URLs through content negotiation, or the API may be separate, or you can have a generic API that is consumed by mobile app, desktop app and HTML-producing server (as opposed to JS app delivered by static file server or framework SSR).

The UI runs on the server, using REST to change client state over a stateless protocol similarly to how a React app may use Redux.

Not really, as long as you keep your HTML-driven interactions from becoming too fine grained.

For example, if you have a search page that provides management of contacts + active search & click to load functionality, it might look like this:

  GET /contacts - get a list of contacts + search & click-to-load functionality
  POST /contacts - create new
  GET /contacts/:id - get the details for the contact
  PATCH /contacts/:id - update the contact
  PUT /contacts/:id/archived - archive the contact
  DELETE /contacts/:id - remove the contact
  

All pretty reasonable and all can reuse the same few templates and sub-templates for rendering responses.

Thank you. To continue this conversation, how would one implement searching and filtering? My use case is an online ecommerce store (think amazon.com or newegg) where you sell multiple different categories of items. For example, if someone searches for SSD, we should show a list of checkboxes to filter by capacity such as 1 GB or below, up to 127GB, ... (based on inventory and other business requirements). How would I do that?

In your example, we can say something like if you could grab lists of by contacts by some common trait such as employer or domain of email address?

You'd have category pages with different filters. E.g. for the 'Storage' category you'd have, among others, the 'capacity' filter. HTMX doesn't take over your entire render like a SPA. It affects targeted areas of the page. E.g. when you would select the '<1GB' checkbox and click 'Filter' on the left panel, that's where HTMX would step in, to swap in the response of calling the 'search' endpoint with the current filter params, e.g. '/search/storage?capacity=<1GB'.

I think you can get pretty far by having good conventions and not over-thinking it, but remember also that this is all about being pragmatic instead of taking a one-size-fits-all approach — if you found yourself doing a _ton_ of highly-granular requests, that might be a clue that you're not in the sweet spot and an API client might be a better fit.

The trade-offs in terms of how granular to go will always exist -somewhere-, whether here, or in terms of react/etc. components, or template include directives.

I suspect 'template include directives, except with some client smarts' may be a good (approximate) model to use to initially get a mental feel for how stuff like htmx plays out in practice.

You can also render a full page and htmx to will intelligently update the current page where things match up.

Unless we are speaking about games (WebGL/GPU are never going to compete with GL ES 3.2/Vulkan/Metal capabilities), or hardware access not exposed as Web APIs, all CRUD apps and magazine/newspapers content can be delivered as mobile Web.

Can you name one, that the group would know, that wouldn't be improved by a convergent phone or tablet offering?

When was the last time you used an application from a gallery, archive, museum or library? How many people use https://apps.apple.com/us/app/wikipedia/id324715238 instead of visiting wikipedia.org? I'm not naming names but this came up a number of times at meetings I was involved with in the GLAM community where people mentioned having spent considerable amounts of money on apps, even winning design awards or getting featured in the Apple AppStore, and then seeing that their daily active users never came within 4 orders of magnitude of their web traffic.

What they generally had in common is that they're content-heavy (i.e. solidly in what the web was designed for), might not require authentication, and most importantly aren't something most of the users wanted to use all of the time. If you are trying to get the hours for a tourist destination or even a restaurant, look at public information, etc. the time needed to login to the app store, authenticate to approve the purchase, wait for a large file to download, open the app and complete any mandatory enrollment, wait for it to retrieve content, etc. was often orders of magnitude slower than using the website. Restaurants and bars are a great example of this: if it's your hangout and they have something like integrated ordering, maybe a trivia night or something like that, the app can be useful. For most people, however, a webpage with the contact info and a menu with Apple/Google/Stripe buttons to pay is going to be better than an app they use a couple of times a year.

The other key thing to understand is that this is a question of priorities and budgets. It wasn't that there is no possibility of doing anything useful for these organizations in a mobile app but rather than the cost wasn't worthwhile for the incremental benefit to the users, especially when you considered the opportunity cost of not spending that much money on something else, especially since most of the cool things you could do in an app could also be done on the web with very similar quality but with the difference that you only had to build one version rather than 2+ and the web version required much less ongoing maintenance.

Yes, I think we're in agreement: fuck apps, use webapps.

Progressive web apps with proper manifests so that I can put them onto my home screen.

Hn would be worse as an app, but more notably Twitter, and reddit would be better as pure web pages if they didn't purposely cripple them to funnel people into the app.

Well, i usually read HN on my mobile with Materialistic. It is one of the apps i use the most often.

There's no way to be notified of comment replies, or see votes, though. But otherwise I love it as well.

Dumb question time… How do you get notifications on comment replies? I thought this missing feature was “by design” to limit bickering.

Edit: I won’t (eventually) see your reply because I just hit the comment depth limit. Reach out by email if you want to answer. :P

There's a handy site if you see this: https://hnreplies.com/

There is no comment depth limit per se; to continue replying, you must click the timestamp of the comment you wish to reply to.

Same, it works offline, loads faster with bad mobile connection, better gestures & UX overall.

I use twitter's PWA. Not planning to ever use the proper app.

Even twitter is a PWA now — the app is redundant.

I for one will never download an app when I can just use the mobile website instead. That's what modern websites are — they're single-use disposable applications. Why would I throw that away for a native app that eats up disk space and has much greater access to my device?

  > Why would I throw that away for a native app that ... has much greater access to my device?

You wouldn't, because you understand. But for every one of you there are 99 other who will install such a app if it is pushed to them. Apps are almost like bookmarks now.

Bookmarks with access to your location, contacts, and camera.

> Bookmarks with access to your location, contacts, and camera.

Also bookmarks that usually point to an obsolete and/or inferior version of the web site.

In the same way a mobile-first website can be done poorly—or non-existent—so too can a native app not add any value.