Live data from Hacker News

Ask HN: Go-to web stack today?

news.ycombinator.com

91–100 of 453 posts

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

#91

Here's an interesting stack: https://github.com/ornicar/lila It's the server/client for https://lichess.org/ which is a powerful online chess server. Scalla with Akka actors is used to provide realtime multiplayer chess (bullet chess games, where each player only has a minute or two to play an entire game, are very popular there). The client-side is written in TypeScript, and rather than use React for the vdom, they'…

I'm a regular HN reader, yet I've never heard of half of these. This doesn't sound like the kind of stack you'd want to adopt if you ever want anybody else to work on the code.

It's interesting that your view works on paper but in practice lichess has many contributors and this has never really been a problem.

This is probably not the go-to stack but not for the reasons you've stated.

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

#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).

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

#94
* Statically-typed languages like Typescripts, Kotlin, Scala, or even Java. Avoid dynamic-typed language in general

* Single-page application, which means complete separation between frontend and backend. When developing locally, you have to run two servers. I prefer the traditional way but it's hard to make JS build tools (e.g. webpack) to work well.

My choice is Playframework (because I know Scala well). The frontend is Vue in Typescripts.

I am not using the single-page application and have developed a Playframework plugin to make it work seamlessly (e.g. hot reloading) with Vue/webpack (https://github.com/GIVESocialMovement/sbt-vuefy). It wasn't easy to do.

I imagine other web frameworks would encounter the same issue, so I can't recommend the not-single-page-application way.

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

#95

- 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…

A lot of people say that you'll know when you need it about flux implementations (redux, mobx, vuex, etc). I have a react native project that I resisted using flux (in my case, mobx) as long as possible to try this theory out. The situation I ran into that instantly told me I needed global state management was when I had an index screen for list of resources, and a edit screen for a single resource. I knew I needed g…

There are simpler ways to do global state management than redux. The scenario you described is nothing new. Redux is new. How do you think people solved this problem before Redux? Does redux have a better way of solving this old problem? How would you solve this problem in an ASP.NET or JSP application that has server-side rendering? How would you solve it in an iOS app? My point is that this is a pedestrian, every-day problem that doesn't need a complicated solution. Redux is unnecessarily verbose and makes you jump through hoops without giving enough in return. Yeah, I know about time-travel state debugging, but YAGNI.

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

#96

- 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…

> - 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 using "unstated" for client store. What a breeze of fresh air!

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

#97

Earlier quoted context omitted.

how is django "running" on lambda these days? -- been meaning to check that out

I'd say that Django is not a great fit for lambda. Lambda works best when you architect you code around it, with lots of tiny methods. Django does not encourage this way of coding (just like the other frameworks).

> Lambda works best when you architect you code around it, with lots of tiny methods

as a total hobbyist: why?

deploying a django app with zappa is extremely painless... its only issue is that you still need an SQL backend, as DynamoDB isn't really an option unless you want to kiss most of djangos values goodbye.

that would've been my take why you'd want to use flask... because there is very little value in django if you remove models, caching, authentication, permissions and more (that can't be used without external infrastructure) from the equation.

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

#98
post #94

* Statically-typed languages like Typescripts, Kotlin, Scala, or even Java. Avoid dynamic-typed language in general * Single-page application, which means complete separation between frontend and backend. When developing locally, you have to run two servers. I prefer the traditional way but it's hard to make JS build tools (e.g. webpack) to work well. My choice is Playframework (because I know Scala well). The fronte…

Same here: Playframework for backend - but using Java instead of Scala.

Using it for many years already, that's probably why I am most productive in it. However I try to look at other frameworks every now and then (Spring, Django) but I always come back to Play, because it just feels more "right" to me.

BTW: You can use Play without Scala, but Java only. No problem. There seems to be this wrong assumption that Play is a Scala only framework - which is wrong. Yes, Play is written mainly is Scala (69% according to GitHub stats) however as a framework user you can choose between Java or Scala. Or even mix both languages. Back in the early Play 2.x days some features/components of the framework where usable only via Scala, meaning you had to write Scala code to make use of them, however these days are long gone. We run major projects in production written entirely in Play Java.

Play 2.7 will be released soon, containing many nice enhancements and fixing many hickups (for Java users at least). It will be a really great release!

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

#99
post #89

- 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…

You talk about using Django and React together. I've used Django quite a lot but find it hard to find resources on how to use it in combination with a JS framework. Could someone recommend learning resources? Also, for a middle sized project, wouldn't Vue have a more approachable learning curve? Finally, since vscode is too slow on my chromebook, is it sensible to use sublime text 3 (of which I've bought a licence),…

I think that what they mean is not to use Django's templates, but to use it as an API server. Django's DRF is one of the easiest ways to create and maintain resource endpoints.

Nginx would serve the index.html with the scripts and the React components would request their data to the API.

This of course doesn't consider SSR'd React as it is just to get started, but the community is working on it (see pipy's projects)

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

#100
post #31

Earlier quoted context omitted.

You can avoid flux longer by simply making a component which stores that shared state, passes it down via props to children, and along with some callback functions to update that state. It is almost exactly what is needed most times and it prevents a problem we’ve dug our selves into before which is making everything via the store because we didn’t want to pass so many props.

Even better: https://reactjs.org/docs/context.html

Why do so many people forget about context?
Post reply on HN