3 ms·
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,
by pelagicAustral 3y ago
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...
- thih9 3y ago> 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.
- KronisLV 3y agoPlus, 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/ 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.
- fourside 3y ago[dead]
- robofanatic 3y ago> 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?
- pelagicAustral 3y agoThey 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-product-plans-faq https://help.heroku.com/RSBRUH58/removal-of-heroku-free-prod...
- slices 3y agono, 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.
- bdcravens 3y agoIt's just expensive and is less of a value add than it was when deployment tools were painful (especially for Rails applications)
- yau8edq12i 3y agoYou'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?
- seafoamteal 3y agoNative 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.
- karaterobot 3y agoI 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.