HN Explorer

Ask HN: What tech stack would you recommend for a single-page web application?

10 points by bsldld ↗ HN
I am developing a web application. The users of this application will be mostly from well-to-do background. So the devices they will be using, to access the application, will be latest. Hence old browser compatibility is not the requirement. What tech stack would you recommend for a single-page web application in this case?

14 comments

[ 3.1 ms ] story [ 46.8 ms ] thread
subrat_rout
I'd suggest go for the tech stack with which you are the most familiar with.
bsldld
C and C++ :)

I am evaluating using Wt, Bootstrap, jQuery and PostgreSQL. But that may not be the best option both to scale the app and the team going forward.

el_dev_hell
Since there's not much of a spec (past users on newish devices), I would default to:

* Next.js - React on the frontend with endpoints handled by Next.js.

* Postgres for the DB

* Hosted on Vercel (unless otherwise specified).

* S3 for binary files.

If the project scope was anything past what Next.js APIs can reasonable handle (heavy DB migrations required, an admin panel, etc), I'd go with:

* Django Rest (or Django Graphene for GraphQL if it's a better fit) on the backend.

* React on the frontend (possibly still with Next.js if server-side rendering is high priority).

* Postgres for the DB.

* Frontend hosted on Netlify or Vercel.

* Backend hosted on Elastic Beanstalk, DB hosted on AWS Aurora, and S3 for binary files.

randomchars
> Next.js APIs can reasonable handle (heavy DB migrations required, an admin panel, etc),

You can reasonably handle those in next.js as well!

For backend, I use hasura: https://hasura.io/opensource/

It's a GraphQL backend, that wraps a postgresql database, and handles the heavy lifting. GraphQL is very easy to work with in the javascript/typescript ecosystem.

For admin UI, they're very easy to build with react-admin: https://github.com/marmelab/react-admin

Wrapping them inside next.js is actually doable too, if that's a requirement (or it can be it's own react app, and you can share components between them).

Jugurtha
>The users of this application will be mostly from well-to-do background. So the devices they will be using, to access the application, will be latest.

How did you check that assumption?

>What tech stack would you recommend for a single-page web application in this case?

Does the stack to be used represent the innovation itself? Are you doing this in order to learn a new stack (i.e: a fun project where the objective is learning about single page application stacks)? If not, I'd disregard that and go with the stack I'm most productive with to solve the actual problem at hand and deliver value.

bsldld
> How did you check that assumption?

This is a guesstimate. Most well-to-do individuals will not stick to old phones that do not match their outward looking status.

> Does the stack to be used represent the innovation itself?

No. But the stack should help easily build web app that look and feel like mobile app. The users of the app will be on-the-move individuals. They may not like visiting a website everytime they want some information. But building a mobile app(iOS and/or Android) is not affordable at this juncture.

> Are you doing this in order to learn a new stack (i.e: a fun project where the objective is learning about single page application stacks)? If not, I'd disregard that and go with the stack I'm most productive with to solve the actual problem at hand and deliver value.

No, it is not to learn new stack. The original question I posed stems from the requirement that the web app should be as easy to use as mobile app, and should not put off the users from using the app regularly and also should not drain their device battery.

codingdave
Use whichever stack you know best. This is always the answer. Learning a new stack for a new app is a great learning experience, but not the most effective way to launch a product.

Likewise, if you are concerned about mobile usage, that has nothing to do with the stack - you can code responsive design and accessible markup on any stack.

bsldld
> if you are concerned about mobile usage, that has nothing to do with the stack - you can code responsive design and accessible markup on any stack.

The requirement here is that the web app should look and feel like mobile app so that the user is not put off from using it regularly. Also, the web app should not drain the user's device battery. Not all stacks can handle that efficiently.

bsldld
> Use whichever stack you know best. This is always the answer.

C and C++ :)

I am evaluating using Wt, Bootstrap, jQuery and PostgreSQL. But that may not be the best option both to scale the app and the team going forward.

> Learning a new stack for a new app is a great learning experience, but not the most effective way to launch a product.

Initial pain may provide better dividends afterwards, that is my line of thought at this moment. But I may bite the bullet and just go with Wt as I am comfortable using it.

giantg2
Depends on what it has to do.

If it's a simple static site just use S3 static hosting and the language of your choice (maybe Angular).