Live data from Hacker News

Ask HN: Go-to web stack today?

news.ycombinator.com

151–160 of 453 posts

Re: Ask HN: Go-to web stack today?

#151
post #92

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top? When I need a more dynamic page, I create a react app specifically for this one page. Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).

Easy there tiger, React and others are compatible with server side rendering. They’re capable of being the “little bit of JS” on top. Everything will be ok.

Let's see - one could have both server and client jumping through hoops rendering a client-side framework on the server and then hydrating it again on the client (including having to pull in all the tooling that would require)...or one could just use regular old templates.

There certainly is nothing wrong with going with simplicity over a solution that's overengineered for one's case, tiger.

Re: Ask HN: Go-to web stack today?

#152
post #130

Scala for backend and Scala.js for front end. Use terms SPA and SSR like the cool kids do. Only you can share the same code between the two and in a strong statically typed way.

> use the terms SPA and SSR like the cool kids do

and how are you doing this in Scala.js? As far as I can tell, outside of rolling your own, there's Binding.scala, Monadic-Html, Scala.rx, and a handful of other, perhaps maintained, in-house libraries for building SPAs (i.e. not dependent on the "cool kids" libraries, like scalajs-react).

Just curious what your approach is as I had a great time doing a project in Scala.js a year or so ago, and am looking to possibly build a Scala/Scala.js SPA for the next project (instead of the default: Angular/React + TypeScript on the frontend).

Re: Ask HN: Go-to web stack today?

#153
my go to is java/Scala/kotlin in the backend (Spring Boot when appropriate). Angular 6 with typescript on the frontend. Stack is stateless, immutable (no ssh keys or any secrets, only IAM roles). Lambda, API Gateway and DynamoDB with on demand billing. Costs pennies when idle and can auto scale fast to millions of requests. Static files on S3. Automatic CI/CD with Code*. All the infrastructure is in code as well. AppSync for WebSockets and GraphQL. (Recently started using Amplify as well)

Re: Ask HN: Go-to web stack today?

#154
post #103

Earlier quoted context omitted.

> - Do not use redux until you know React well. You might not need it. Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app.. I'm now us…

[deleted]

> not creating own modular framework instead of using the marketing-driven library/bloat that is called React.

> calling others noobs.

Re: Ask HN: Go-to web stack today?

#155
post #92

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top? When I need a more dynamic page, I create a react app specifically for this one page. Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).

In my experience, the problem with a lot of those solutions is that at some point you still need to handle data and some significant dynamic content. Of course, this depends on what you do, but even a simple e-commerce site is fairly dynamic nowadays. What happens if you go the I'll-do-it-myself is that you still get a significant amount of code, and lots more bugs since you'll have to redevelop significant pieces of…

I totally agree with you! I've used react and redux in almost every project last year, but that doesn't mean the entire web app was written using react and redux. 50 ~80% was plain old static content rendered on the server.

A dynamic client side UI is more expensive to build compared to static html rendered on the server. Our software usually aims to solve a business problem for as little money as possible so we only build these dynamic ui's when they're absolutely required.

Re: Ask HN: Go-to web stack today?

#156
Me, personally:

Vue on the front end, Django on the back end. That’s mostly because I know these frameworks quite well. And in the beginning of a project, all I want is an MVP as quickly as possible while maintaining some clean code standards.

I use firebase static hosting for the front end and a dockerized deployment on Heroku for the back end.

Later on, if the project grows and when I break components out into microservices, I may start to worry about other considerations such as performance and resource usage.

Re: Ask HN: Go-to web stack today?

#157
post #133
post #86

Frontend: (vanilla) React with TypeScript. - TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes. - Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff. Backend: Kotlin on the JVM. Kotlin is a really nice lang…

At this point this would prolly be my advice as well. From React/TS, to Kotlin, to PG, to the JOOQ shout out. I hoped a strongly(ish) language that spans from BE to FE, like ReasonML, would be ready by now, but it isn't. Kotlin to JS is not there I'm afraid: https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-j...

What's not there about Kotlin/JS for you, out of curiosity?

Re: Ask HN: Go-to web stack today?

#159

Idea: Might be a good time to play around with full-stack in a serverless environment. (Sounds odd, but it's doable) I've been pioneering an AVA stack, Airtable, Vue.js, and AWS to create pluggable blogging components. I think you could mix-in GraphQL and end up with just about anything you'd need in an app for pennies a day, including switching out back-ends.

Yep, I’m doing full stack serverless for a few years now.

Re: Ask HN: Go-to web stack today?

#160
post #23

- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…

I would go with NestJS and TypeORM on the backend with node..

Nest has a bus factor of one[1]. Django[2] and Rails[3] don't have this problem.

[1] https://github.com/nestjs/nest/graphs/contributors

[2] https://github.com/django/django/graphs/contributors

[3] https://github.com/rails/rails/graphs/contributors

Post reply on HN