Hacker News Reader

Hacker News

Comment by koolba | Hacker News Reader

Parent Full thread

koolba

Why an app rather than a static site deployed to something free like GitHub pages?

Could even have the data in a repo to accept pull requests for new names.

View on HN

Ultimately because I wanted an app.

* I make enough web-based things for my job, and I enjoy developing in Flutter / Dart (what this was built in).

* I’m never realistically going to be looking through names on a desktop; I use the app when I have a few minutes to kill in line or something where I can pull out my phone, decide on a few names, and then go back to what I was doing. I could build it as an offline web-app that gets saved to my device but then why not just build an app in the first place?

* I like using SQL for retrieving data, and I don’t want to have to jump through hoops to do so.

Projects like this one are excellent for scratching an itch or learning a new platform. Low-pressure / "oh well" failure mode, fairly constrained scope, nothing too fancy, but enough of a "product" with utility to push you through the boring parts to the end.

It's also interesting how this question shifted over time! It used to be that people would ask why you made a Perl CGI or PHP app when you could've just made a desktop app.

ps: congrats on the new baby!

Exactly! The development actually languished for many months and I almost scrapped it. Only in the past week or two did I decide to revive it when I once again felt the need for it (9 months go by fast).

Thanks!

9 months go by fast

For the father at least...

Congrats!

> I use the app when I have a few minutes to kill in line

You could track whether specific locations, or time of day/week, result in liking certain types of names. Version 2.

It's a baby name generator, there's no need to track everything!

You're not thinking of the potential here. Just imagine a baby name generator that tracks its users preferences and automatically registers domains and social media accounts which it then tries to sell you.

...it sounds horrific, I'm glad OP went with this model.

They could also stand with their decision, to stick it to all the user apps, that track you to oblivion ;)

It is possible to collect information, use it locally, and not upload it to a server.

of what relevance would such data be to the user who generated it?

curiosity!

Might be nice to deploy the Flutter app on the web too. Flutter web support is pretty decent now. SQLite on the web is probably going to be tricky though (sqflite doesn't support it).

"Why isn't this a text file so that everybody can simply use their Unix shells to shuf -n 1 /usr/share/dict/baby-names".

this is hilarious

Because you can already `shuf -n 1 /usr/share/rig/fnames.idx` (or mnames for male ones) or `vis-menu /usr/share/rig/fnames.idx >> momlikednames.list`, and `cat {mom,dad}likednames.list | sort | uniq -d` to find names both parents like.

`shuf /usr/share/dict/words` was how I picked my HN username.

Why not... `head -c8 /dev/random | base64`

That's exactly what we did, albeit the final list was filtered by grandma as well, non digitally

Because everybody knows how trivial it is to curl/wget the list from https://www.ssa.gov/oact/babynames/limits.html, unzip it, etc.

The list is biased. Not only does it only have U.S. births, but also only those where the individual has a Social Security Number. I wonder how many the latter rules out.

For privacy, it also drops names that are rare, with fewer than 5 births in a given year.

(App is open source, so it’s easy to discover that’s where the names come from. See https://github.com/hamaluik/nomdebebe/blob/main/app/NAMES.md)

You joke, but I see this as "why is this implemented as software that potentially violates the security of my device?"

I trust the browser sandbox a million times more than I trust the phone app sandbox.

People have different skill sets. I bet there are engineers out there feeling more comfortable building a mobile app than a webapp.

A static site would remove many of the features that OP built (favourites, matching with partner, sorting).

"Static site" is a bit of a misnomer, it refers to the webserver's view not the clients view. The client can still dynamically request chunks of information, favorite things, sorts things, save things between sessions, and form dynamic connections (though you'd need to point to a 3rd party signaling server for the WebRTC connection to come up).

I.e. it's not the web page that is static rather the files to host the web page are static vs say being a php site dynamically generating responses based on user/session/request information.

You could do everything but collaboration using a static site and localStorage though Apple's support of localStorage is iffy now.

You just gave two reasons why it wouldn’t work as a static site

That is indeed what I said

I assume that the app keeps track of names that you've already rejected.

This. Please don't create apps that shouldn't be apps.

Please do whatever the hell you want. There's a difference between asking a question, making a suggestion and shoving ideals down somebody's throat.

> Please do whatever the hell you want.

Indeed. Especially if you want to piss off potensial users/customers.

> There's a difference between asking a question, making a suggestion and shoving ideals down somebody's throat.

Unfortunately, the "ideal" for many is to have an app for their - well - app, or service, whatever it might be. Usually it's just a perfectly functioning responsive web service that is turned to a native app instead of just going for a hybrid app (at least to start with).

In this specific case, there's is _absolutely no reason_ it should be provided as an app, at least not a native one.

Because:

The user already has everything installed on his phone to use the service; a browser.

To me, _as a (potential) user_, having to install this app would have been showing something down my throat. To solve that problem, the developer could have created it as a responsive web application first, and maybe made an hybrid app, and then decided if it is worthwhile creating a native app.

Why the desparate need to create native apps and have to maintain two totally different projects when there's no need to?

Well, it was done in flutter so a web app might be something easy to do from that.

All your arguments hold if this was something the developper was trying to grow (commercially or not). Given this is clearly just an app made for their own use and scratch an itch... Taking about pleasing potential users/customers and how you'd have to be forced to install this app is more or less off-topic.

> Taking about pleasing potential users/customers and how you'd have to be forced to install this app is more or less off-topic.

Then why make an app out of something that would work just as well with something I have already installed on my phone?

But how do you know if it should be an app? It seems like we need a ShouldThisBeAnApp app where you can upload screenshots, descriptions, API diagrams, etc. and allow AI + community input to make the determination.

No more apps! Only websites!

There should be a ShouldThisBeAnApp website, and a ShouldThisBeAWebsite app :D

Make it a ShouldThisBeAMobileAppOrWebAppOrNativeApp service that has a native implementation on all these platforms.

What if you don't want an app and you just want to consume an API? I'm thinking a better name would be ShouldThisBeAMobileAppOrWebAppOrNativeAppOrAWebService.

We'll see how this comment ages, in the VR meta future

> But how do you know if it should be an app?

In this case it's very easy: if all the functionality can be run in the browser, which already is an app installed on my computer, don't make it an app. At least not a native one.

Don't use apps you think shouldn't be apps? Making normative statements about something OP did for fun and shared with us is a bit odd.

> Don't use apps you think shouldn't be apps?

I said: don't _create_ apps that shouldn't be apps.

Reply on news.ycombinator.com