Live data from Hacker News

Your 'app' could have been a webpage (so I fixed it for you)

danq.me

211–220 of 571 posts

Re: Your 'app' could have been a webpage (so I fixed it for you)

#212

Earlier quoted context omitted.

> I have no interest in installing a web app that could look innocuous today and be entirely different every time I hit F5. That's been the case with native apps for a long time now too.

Not really, no. Not that it doesn’t occasionally happen, but at that point you’re trying to dodge the police… as compared to there being no police in the first place.

In this case the police are not watching. Apple does a cursory review during the approval process but they are not proactively firing up your app to see if anything changed post-review.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#214

Booking a flight on the website and then being told I need the app just to see my boarding pass drives me nuts.

If it's frontier, as much as they want to make you think you need the app, if you lookup the trip manually on the site (using your confirmation code), you can download it from the web

Re: Your 'app' could have been a webpage (so I fixed it for you)

#215

Earlier quoted context omitted.

Unlock Origin doesn't enable all filters by default, you can go in the extension settings and enable more filters which removes the cookie banners etc.

Does it remove them by automatically consenting to the cookies, rejecting them or just hiding the banner?

It blocks the cookies and the banner. Ideal solution.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#218
post #46

Wait, the users password is part of the URL? What happens if the password contains a forward slash or a question mark? Wouldn't that break the whole endpoint?

Original author here. Upon inspection, these passwords are clearly not chosen by the user and, as far as I can tell, consist only of numbers and uppercase letters.

More of an ugly authToken then.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#219

The question is: Why would anybody prefer a web-app over a native app in any kind of system or on any kind of device? I think the answer is "only when there is no native app for the system I use", ie Linux. So FOSS people want for apps to become much worse for everybody else, so that they can have the apps also through a web browser. Remembering that everybody else is who pays for the apps and all development, while…

I invite down voters to make a reply explaining why users would prefer web apps to native apps, given the choice.

At least with web app I have a browser sandbox to protect my system.

Re: Your 'app' could have been a webpage (so I fixed it for you)

#220
post #192

Earlier quoted context omitted.

I like making maps, and I wanted to do a certain bend on a very specific kind of online map, filling a gap I noticed in existing maps. The idea of an app really appealed to me (at first), but the more I thought about it the more I didn't want to deal with iOS and then Android and then maintaining parallel functionality on the web and all that mess just for a fairly-local hobby project that I make no money off of. So,…

So i've done similar things in the past - and my justification for 'app' over website has been offline. Does the PWA state of things resolve that in the modern days? If it did, yeah I'd agree, no need for an app at all. In my case the app was being used in rural Ontario. I cant even make a phone call here without wifi.

This actually handles that, at least for my use case. Specifically, on first load of the page (in a browser, or the stripped-down browser that runs the app-like PWA install) a service worker gets installed, that caches the entire site/app/map locally, and runs it from there. Then every 24 hours, or on new page load, it checks the live site for content changes and pulls down the changes if they exist. If there's no network connectivity it just silently runs the map.

Each map is 16MB - 20MB in total, so this is all nice and simple to do. Even on a slow 3G connection it's only a minute or so for a full map update to stream in.

The whole point of this system was to take a snapshot of data (mostly OSM), add on some local things that can't really be represented in OSM (like WHICH parking lots are most appropriate, stylistic overrides, system descriptions, etc) and display them. Because of issues I've had in the past with well-meaning-but-misguided OSM mappers wrongly editing trail systems I did not want anything that pulls live.

And then by having purely static content the hosting is very cheap and easy, there's no security concerns around... well... anything dynamic on the site. And each map is portable were I to want someone else to host them. And literally in a couple of years if I haven't updated the map it won't change yet still will work, and that's fine and accepted for this use. Sort-of like a mobile version of a traditional print map. Kinda like the print workflow of editing/design/etc and then rendering the PDF, but web.

This all aligned nicely for me to have a tool that works this way, with each map generated by a tool.

(Sort-of disclaimer: It was also a big personal project in learning to work with AI stuff for development. I knew and understood the inputs and outputs, was able to design the UI, handled/managed all the testing... But I didn't have to worry about the actual-code part. I was able to make pretty quick progress and iterate nicely on my ideas.)

Happy to talk, etc, more about it too. Either here, or contact info is on the site.

Post reply on HN