HN Explorer

Ask HN: What tech stack would you choose for building your next app?

39 points by roadbeats ↗ HN
Hi all,

I feel like I'm behind the trends in building apps. I see lots of new stuff-as-a-service, and need to refresh my knowledge.

Could you tell what would you choose for your next app ?

Backend / frontend does not matter.

Thanks in advance.

53 comments

[ 9.6 ms ] story [ 379 ms ] thread
tboyd47
Web:

If I'm paying: Wordpress, LAMP, vanilla JS, MySQL, and PHP

If I'm maintaining: Ruby on Rails, PostgreSQL, JQuery, ReactJS

If I'm building a resume: Either C# or Python, SQL, and Javascript, hosted on either AWS or Azure.

Mobile: Swift/iOS and Java/Android both.

cmehdy
You're more likely to get somewhere with Kotlin on Android now, although knowing your way around Java constructs will definitely remain useful for a long time.
brailsafe
As a web guy and spmetimes hobbyist Android person, has Kotlin surpassed Java in terms of support or some other quality on Android?
suyash
That won’t happen anytime soon, 90% of libraries and majority of Google’s own sample projects are in Java.
Porthos9K
I'd like to use BCHS[1] next time around.

https://learnbchs.org/

I want something that's simple, and reasonably secure by default so that if the crap I build turns out to be insecure, it's my own damn fault.

non-entity
So I'm assuming you'd write the application as a a collection of CGI programs? Either that or does OpenBSD's websercer support developing handlers as sort-of extensions like ISAPI with IIS?
Porthos9K
Yep. I'd use CGI.
non-entity
I'm actually intrigued, I might try this stack out.
fortytw2
Go, Postgres and a dirt simple React/Typescript/Parcel app as the frontend. 99% of the time you won’t need anything else.
arkanciscan
+1 Parcel. It really is a breath of fresh air after dealing with Webpack.
ng12
That's good to hear. I've been on the hunt for a replacement for create-react-app -- in my experience it's problematic in an enterprise environment. I love Webpack but I don't want to recommend it to junior developers. I'm hoping Parcel is a better candidate.
arkanciscan
I wouldn't go that far. Parcel is fine for small stuff, but it doesn't allow nearly as much control as Webpack. In enterprise you're likely to run into limitations. Parcel 2 is supposed to get plugin support, but who knows if that'll be any better than Webpack.
hiccuphippo
There's a bunch of new python web frameworks built for asyncio that I'd like to try.
[dead] arkanciscan
JamStack is "so hot right now"

I like zeit/now, but Netlify is also very good. Whatever you use for hosting, it should have GitHub integration to auto-deploy branches. If you don't want to deal with a middleman at least use a framework like SAM, Serverless, or ant.codes.

The frontend should be React (preferably wrapped with a convenience layer like Create React App, or Next.js so you don't have to handle Webpack yourself). The more interesting question is how to manage state. Use something like Apollo or AWS Amplify for this because mapping REST-JSON to state is so 2014.

Redux is a waste of time.

TypeScript can die in a fire, and if you disagree you should join it.

gubsz
I can't tell if you're being sarcastic or not, but I'm really curious about the TypeScript hate. Besides some odd type mapping here and there, I've really enjoyed using it over plain old JS.
arkanciscan
TypeErrors are just not a problem that I need a compiler to solve for me.
odyssey7
I used to feel that way — and in some situations I still do, like for a short script that I think won’t change much over time. But for a lot of situations I realized that I had so many things to keep track of myself. If there was an easy way for me to be looking back over my shoulder less, like with static typing, I was all for it.

Static typing lets me front-load the effort of making sure many different buggy cases won’t happen. The alternative is for me to think really hard proving to myself that those cases won’t happen each time I come back to the code in the future to add a feature or make a change.

arkanciscan
More like front load all the effort of every error that may or may not happen.
rvz
> TypeScript can die in a fire, and if you disagree you should join it.

This is probably a poor attempt at satire, but I'll bite. Actually yes, I'd rather disagree and jump in the fire to use TypeScript than to plod along using JavaScript with its clumsy type-system, designed by a team of clapping seals and to watch all the hell it truly brings.

If you think TypeScript should die in a fire then perhaps I'll see all companies using JavaScript in Dante's Inferno.

arkanciscan
I don't dislike TS because I love JS so insult it all you like. Besides TS is just a superset of JS so it's still got all of JS's warts. It's just a glorified linter.

I dislike TS because it provides no benefit to me. I already have a type checker, it's called a browser. I dislike TS because a bunch of people who wasted their time learning Java or C# are forcing me to deal with it because they can't do their job without a compiler to tell them how.

You need types, that's your problem, not mine.

JamesBarney
It's great that you always write bug free code, but then typescript was not written for you, it was written for the rest of us who write the occasional bug, refactor an API that we didn't realize another developer was using, or can't quite remember the order or shape of args that a library call takes that we only use once every 6 months.
[deleted]
(comment deleted)
arkanciscan
Why don't your tests catch your TypeErrors? You do have tests don't you?
Can_Not
Tests aren't an alternative to types. They're better together.
stevenwliao
Why would you write a test instead of a type declaration if you had the choice?
arkanciscan
TS checks at buildtime. It can't guard against runtime TypeErrors because JavaScript is a dynamic language (despite all the effort to "fix" that). Tests can catch all TypeErrors, TS can't. Why use two tools to do the job that one can do alone?
ng12
I agree that the type checker isn't that useful but I still use TypeScript for two reasons:

1. Accurate autocomplete.

2. Typing my domain models so they play well with autocomplete.

arkanciscan
The first thing I do when I install an editor is turn all auto-completion off. Especially the auto-closing brackets. Drives me NUTS!
dang
Please don't do this here.
arkanciscan
Do what exactly? Participate in discussion? Voice my frustrations? Contradict the popular opinion?

You know, I think I agree. Commenting on this site is a huge waste of time.

dang
I thought it was obvious, but in case not: please don't post flamebait like "$language can die in a fire". We're trying to avoid programming language flamewars (or any flamewars) here. They get repetitive very quickly, and nasty too.

Also, can you please not post unsubstantive comments like https://news.ycombinator.com/item?id=21822655? We're trying for more thoughtful conversation here. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the spirit of this site to heart, we'd be grateful.

Btw, I tend to agree with you on https://news.ycombinator.com/item?id=21810266 and thought that was well put.

rocketpastsix
Laravel, Vue, Tailwind, MySQL, OpenAPI, JSON:API.
mschaef
It really depends on the target platform, who will wind up maintaining the code (and for how long!), and how the build will be done.

But the short version is that I would (and do) favor Clojure for personal projects. These are cases where I have limited time to invest, a high desire for tangible results, and no other developers to worry about. For that set of tradeoffs (and my skillset), this has generally been the best way for me to achieve my goals. (I also have some code that abstract out some patterns I find useful or importatn.)

In these sorts of projects, if I need client side code, I'll tend to favor straight JavaScript (with markup rendered by Hiccup) if I can get away with it, and ClojureScript/Reagent if I have a requirement that implies a need for client side logic. (Tolerance of lost network connections, incremental page update, and the like.)

For more commercial projects, I'd be thinking TypeScript/React with a Java (JVM?) backend for starters. I'd also be open to Node or Python for the back end, but it really depends on the skillset of the team and where the best libraries are.

And all of this would be done with an eye towards the exit. Any codebase that has a reasonable life expectancy will likely have to at least interoperate with other language ecosystems, if not incorporate them bodily. Being mindful of how that might happen is important. (Which practically speaking, means decent interface definitions, testing, and the like.)

codegeek
frontend: Vue Backend: Golang/Laravel PostgresQL database

No SPA. I use server side templates and just call the vue components in them as needed.

brailsafe
Mind expanding on that last bit? I'm working with a fairly convoluted Flask/Pylons based framework which I'd love to use Vue in but don't want to lose server rendering. Are you just piecing small components together that individually call apis or what's your setup?
codegeek
Basically, on server side, I have templates like this:

users.page.tmpl (in Golang):

    {{template "admin" .}}

    {{define "title"}}Users{{end}}

    {{define "main"}}
    <users></users>
    {{end}}
Then I have a Users.vue that does the heavy lifting with API calls on loading existing data when component mounts etc.

Using this, I can use server side routing as needed and no need for client side routers or SPA etc.

riter
For quick proof of concepts

Backend: Flask -> MySQL -> Docker -> Digital Ocean

Frontend: Vanilla JS + Bootstrap or VueJS + Template

Have yet to fail me. It makes for easy transition once things get serious and I want to migrate over to GCP/AWS

noodle
My current swiss army knife is Rails+Vue for web/api, plus React Native for mobile if necessary.

Of course, I'd use something different if the project necessitated anything in particular.

nyxtom
Web/services and keeping it boring and basic:

Aurelia, Mongo, HAProxy, Nginx, Express, Redis, ELK, Ansible

Depends on the dependencies, some things I need have very great implementations and support in golang (network traffic, routing).

rsinger87
Postgres, Django (with Rest Framework) and TypeScript/Angular.
hpliferaft
React/AWS lambda/AWS DynamoDb+S3 for prototyping CRUD variations.

Anything else would depend on the app's features.

gitgud
Front-end = Nuxt (vue) + Vuetify.

- Simple, great abstractions, many enterprise grade components

Back-end = Firebase (Firestore db and Cloud Functions)

- Simple, cheap/free, scalable

wishinghand
For the frontend I always use Nuxt, which is a server side rendered flavor of Vue. Vue just makes sense to me with how it handles markup, styling, and code in a single component’s scope. The only time I really make use of Vuex, the Vue solution for Redux, is if there’s user data that I need to share into other views.

For backend I’d want something either rock solid and fault tolerant like Elixir, or very speedy like Rust or even Go. Kind of depends if I’m doing this in my own or with others.

semireg
After 5 years on iOS/Android I wanted to build a cross platform desktop app. I came up with an idea (make thermal label printers a joy to use) and started hacking a proof of concept using https://github.com/electron-react-boilerplate/electron-react....

It’s been an incredible learning process, super laborious and an absolute joy to see people buying my app and emailing with questions and ideas.

I’ve had to learn React, modern JS development, semantic UI, redux, native node modules, maintaining a cross platform build system, publishing on app stores, selling direct and building my own license system using react/express/graphql/jwt not to mention auth, and other APIs, deployment to Heroku... the list goes on and on.

Check out my app at https://label.live

maxharris
I'm working on a new frontend framework, as well as a couple of applications that make use of it: https://github.com/maxharris9/layout

One of my goals is for my framework to compete with Flutter. So why not just use Flutter? Two reasons: Flutter's API is object-oriented, and Layout's is functional. I also prefer a declarative style for specifying views, but can't stand Babel's bigness/slowness, so I built a JSX transformer (https://github.com/maxharris9/jsx-layout).

mijkal
My side project is React + Firebase (Node functions + NoSQL database + websockets) — love it!
suyash
Java, Node.JS and JavaScript.

For Mobile - Android ; Java, iOS - Swift

mc3
Getting it done:

Frontend - Typescript/React + miscellaneous libraries. Maybe CSS compiler, maybe raw CSS.

Backend - I'd use C# and .NET but that is for reasons of familiarity. I would also be comfy using NodeJS but I prefer the comparative sanity of C#.NET.

For Fun:

https://safe-stack.github.io/docs/overview/