Comment by pelagicAustral | Hacker News Reader

Comment by pelagicAustral | Hacker News Reader

No one in here is going to agree with me because I'm not cool, but I don't care, "I've seen it all!!"

I have an employer, and we work with a particular stack, but if I was doing my own thing I would work native each an every time... If you work with apps, xcode and Swift, Android? Android Studio and Kotlin/Java, Windows desktop? Windows Forms and .NET %CURRENT_DOTNET_ITERATION%... Web? pick a solid framework with tons of support and libraries, django, rails, phoenix, et al. Minimize the use of JS libraries/frameworks or remove altogether, forget about fads that mix markup with javascript and logic, and even style (these days). Do not build stuff based on a web browser just so you can call it multi-platform, you will end up shipping a crappy abstraction with a poor UI and even worse performance, because remember, you are playing solo, cant afford the optimizations of large product teams, be pragmatic... deployments/CICD/devops DIY, don't trust services that advertise themselves as a panacea for deployments, remember Heroku f* everyone sideways... learn and use stuff like Dokku or Kamal...

You're going to make cross-platform native apps for the local pizza shop who wants to display opening hours and the menu on some kind of webpage? No one here is going to agree with you because the question is specifically about building websites as a freelancer, and you're replying something akin to "don't make websites, trust me I'm not a freelancer." Well okay then?

Native apps certainly do have their plus points, but for use cases like small local business that customers will order from pretty infrequently, a website is the way to go. I don't want another app on my phone that I'll use once and then never again for a year or so. And of course, websites are still the way to go when you just want to put some information up publicly for people to access without any interactivity involved. You wouldn't have an app just to display your store services and timings.

> Do not build stuff based on a web browser just so you can call it multi-platform, you will end up shipping a crappy abstraction with a poor UI and even worse performance (...)

In many cases this sounds better than shipping for only one platform - or not shipping at all.

Plus, if your app idea is basically served by the features that a web app or a PWA offers, then you can write it more or less once (might need a few standalone browser checks in specific places) and deploy on multiple devices, for example, with https://www.pwabuilder.com/

I'm doing that right now. I'm having enough troubles with payment integration and proper auth and back end stuff, there's no way I could ship for web and two different mobile platforms at all without cutting too many corners.

> remember Heroku f* everyone sideways

Can you elaborate please? I hosted an API on heroku recently. I have no problem so far. Should I be concerned?

They used to have a free tier that they killed out of the blue [0]. The cautionary tale is that you cannot just trust these services, they might change the rules at any given time... You can however learn to deploy your own servers and manage your deployments with FOSS tools like the ones I reference.

0: https://help.heroku.com/RSBRUH58/removal-of-heroku-free-prod...

no, Heroku is fine, as long as you have a basic understanding. If your service becomes a runaway hit, your heroku bill may get big, I assume that's what OP is referring to.

It's just expensive and is less of a value add than it was when deployment tools were painful (especially for Rails applications)

I think you are basically correct: the answer is usually boring technology. That should be everybody's default, and you should have to demonstrate why that is inappropriate on a case-by-case basis. But you should have to demonstrate it to a very skeptical and knowledgeable audience, who will probably roll their eyes when you talk about all the advantages of whatever eight month old technology you are excited to use. If the argument relies on phrases like "look at how many stars it has on github", or "here's a blog post about how great it works", or "big companies use it ... on some brochure sites" then it should not pass the filter.

Reply on news.ycombinator.com