Ask HN: If you started making a web app today which tool would you choose? | Hacker News Reader

Ask HN: If you started making a web app today which tool would you choose?

17 pointskarimdag29 comments

There is not one tool I would use/recommend before knowing the actual requirements.

In one of our latest projects we decided on following stack:

Backend/API: PHP, Symfony3, Mysql

We choose this because the following reasons:

The team is already familiar with symfony/php We had to integrate with existing stack/business logic in php ( or port parts of it )

Frontend: Angular.js

We needed a single page app that we could easily port parts of to a mobile app later on We wanted to decouple our frontend from the backend by doing only api calls so we avoid having backend code responsible for generating html/etc

Real-time component: Node.js, Redis

We needed a component that processes events as they come in, and a lot of them. We decided against PHP so we could lower our memory footprint and also because it is a bit more convenient to deal with state.

This component checks each incoming data packet with a set of rules and reports on violations.

This component gets it's configuration from the backend api and reports back to the api whenever a violation occurs which needs to be logged.

That depends so heavily on your requirements that every general answer is incomplete. There are lots of different kinds of web apps with very different requirements. There are tools for solving certain problems in frontends and other tools for certain problems in backends. There are tools for small projects and others for large scale products... As long as there is no specific problem you can't say what's the right tool.

As always, the right tools for the job.

And those tools today are often a mix of my own code and some SaaS.

Depending on how much data management there is, I will ususally start with Django, specifically Django Cookie Cutter [1].

This bootstraps a lot of the basics for me like user auth, testing, front-end assets, etc.

For error console, I will use Sentry[2]. There are self-hosted and paid versions.

If I want some real-time type functionality, I will use Pubnub [3]

I am lazy and will always play to my strengths. That happens to be Python, Postgres, and constantly hunting tools that make me an even lazier developer.

[1] - https://github.com/pydanny/cookiecutter-django

[2] - https://getsentry.com

[3] - https://pubnub.com

Situation dictates: Any kind of business website/ blog/ landing page is probably going to be Wordpress. Not because I really like Wordpress, but because it's fast. These are "good enough" pages. For anything else, I'm likely to choose Flask if I can. I think Flask strikes the right balance for me between having all of the features I want without bogging me down. For the front end, I normally just stick with html/css and Bootstrap or another css library.

Right now, if tasked with building another service of the same type as the one I am currently creating (kind of a CRM integrated with various 3-rd party payments and messaging) I'd use the most recent version of my current stack.

My current stack is JavaEE on TomEE.

I'd probably happily sacrifice verified stack compliance for the latest TomEE 7 milestone build as I understand the verification issue is just Oracle being Oracle again, throwing a wrench in the gears just because 'why not'? Or rather to see if they can somehow extort some money from an open source project. </rant>

Java back end, HTTP/2, everything tuned for small transfer size and high speed, no CDN, no extra DNS lookups, as little JavaScript as possible, but maybe d3.js or something else which adds a lot of value.

I would use Scala with Play framework. Mongo or Maria DB depending on type of data. Angular 2 for front end. Hosted in Google cloud.

This is stack I use. We use different database MySQL or Postgres -- depending on what you like and need. Hosting on AWS.

Vim. :)

If it's just you, and a first outing, then a minimal set of whatever you're most familiar with. For me that would be nginx -> wsgi -> flask/bottle or similar -> postgresql, because python. Similar if you're more comfortable with ruby, js, whatever. Build out from there if it becomes worthwhile.

If you're a group, whatever allows the group to make best progress.

This long weekend (US) I started a project hosted in Linode running Debian. I am writing code in Go, HTML, JS, CSS using jEdit on Gentoo desktop (4 monitors). The backend stuffs are Redis and Solr. I used Bower to add web components. I still use Makefile rather than grunt or other newish things

Front-end: React.js(if fancy interactive stuff needed), Bootstrap with Flexbox for styling Backend: Django, PostgreSQL, Redis, Elasticsearch, Nginx

Haven't used but wish-list to try next: Docker, GraphQL, and probably try hosting it on google cloud platform

If the use-case fits, even wanna try a Firebase-backend only app as well

Am I really going to be the first?

I would use Rails. Rails has everything I need to build a web app and API back end should I require a native mobile app. As a ruby guy I can't really comment on the frontend, but my go to JS framework that lets me build shit quickly is knockoutjs.

Server: Nginx

Backend: PHP (Yii2), Mysql, Redis

Frontend: React (if I can't get away with just JQuery), Bootstrap 3

Realtime components: Node.js, Socket.io

Like everyone else: my personal preference.

In the future I want to use the following setup: ASP.NET Core with Angular 2 and Typescript. And then host it on Azure. Sounds like a golden combi.

Server: Flask (or possibly Django) behind Nginix

Database: Postgres and possibly Redis

Frontend: Not much of a front-end person so I avoid all the complicated stuff and stick with Bootstrap. I also tend to prefer coffescript

Surprised at the lack of Rails usage...

Personally, I would go for Flask just because it's so easy to build up momentum due to the minimal setup required.

Would love comments, questions, and criticism on my choices.

Hosting: Lambda via Serverless for API, S3 for HTML/assets

API: Node/JS via TypeScript, Postgres RDS, GraphQL

Front end: React

The only problem about Typescript is locking-in your script into a framework, I don't like lockins, I would recommend leaving your code in NodeJS only.

React is a nice piece of technology, but you need to understand it very well. Otherwise you might loose performance instead of obtaining performance.

Lambda (Serverless API) - I've used a lot and it's awesome.

Most of my processing is on the back end, so my front-end code rarely benefits much from being highly optimized.

As for TypeScript, I'm not sure I understand what you mean. How is it locking me in any more than React or something?

If TypeScript dies as a project, I would still be able to transpile my latest code and then continue writing pure JS...

Also, whatever risk there is of that happening, the productivity boost of TypeScript far outweighs it for me.

Ok, but if it's react it's a web or mobile web project. Then you'll still need to render DOM in the browser and it doesn't matter if you have more or less processing in the backend, you'll always need to care about your frontend.

If you think TypeScript has a lot more benefits then fine, you may go forward with it. I'm just conservative in this perspective. I understand you may transpile (build process), that's fine, I don't like working in Visual Studio, I prefer Atom and having my code without transpiling, not sure how it will work out with your build process when creating a zip to upload to Lambda, but best of luck.

I disagree that performance always matters. I don't pre-optimize. If I can create better UX by focusing on performance, I will. Currently my front ends are so light that a human can't tell the difference.

I don't use Visual Studio either. VS Code is based on Atom, and it has great TypeScript support. I use WebStorm, which is a better IDE overall right now.

I understand people not wanting to transpile, and it does suck that JS forces so many of us to do it.

@smt88 that's fine, but when I talk about performance I'm not talking about what a human eye can see, but rather what Google wants in terms of performance.

Best Regards,

If the app is mostly a tool that doesn't need SEO I would use Phoenix with jsonapi.org compliant api + EmberJS.

AWS S3, Lambda (NodeJS). You'll get one year for free, then you'll pay very little on that configuration.

Do you use nodejs for everything? Real-time, CRUD heavy apps, etc..?

Yes, because it's the easiest codebase to manage and maintain. Everything new is in NodeJS. Build process is all in NodeJS as well, creating build processes in other tecnologies used to be a headache. Only if it's something very specific and focused I would use the API's language which is "Java" ou ".NET".

ASP.NET webforms because it is what I understand best. YMMV.

C# asp.net and knockout for money

Haskell yesod and elm for fun

php, mysql, angular, laravel/symphony, nginx, linux, node.js and socket.io for long polling

Reply on news.ycombinator.com