Gatsby > Create React App in my experience. Routing is so convenient with pages
Ask HN: Go-to web stack today?
111–120 of 453 posts
Re: Ask HN: Go-to web stack today?
#112- 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…
We've been following this stalk for quite a while and are super happy with it. But there's huge downside: It's really hard to find Django/ Python engineers - let alone phoenix devs. Right now I'm considering a move to JVM. But the frameworks i've seen are all far behind Django. Any thoughts?
Spring Boot is pretty good actually. It doesn’t match some of Django’s features, but if I were to use JVM now, either Spring Boot or a standard Clojure stack with Ring (coupled with Honeywell) would be good enough. (Of course finding Clojure devs is harder, I have spent a lot of time evangelizing it in my country with little success.) I have used both last year in production without issues.
Still, Django and Rails makes many things a breeze.
Re: Ask HN: Go-to web stack today?
#113I'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).
No. You're not the only one.
Re: Ask HN: Go-to web stack today?
#114I don't believe there is a good answer to this as details are missing. What scale are you trying to get to? What level of concurrency? How much state and how often is it accessed? And what are the skill of your engineers. You could write a rails monolithic app on postgres if you're building an internal application 100 people will use. Or you could use Akka and Scala with all state in memory backed by an event journal…
May I ask, what is it that you don't like about Elixir?
Deployments are a nightmare.
Re: Ask HN: Go-to web stack today?
#115Web "sites" or web "apps"? The optimal solution for one end of that spectrum is very suboptimal at the other.
Re: Ask HN: Go-to web stack today?
#116In the pattern of LAMP/MEAN/etc:
- Linux
- Nginx
- Postgres
- Ruby (when I want all the Rails stuff) or Nodejs (when I don't)
- Elm (for anything app-like or Ajaxy in a browser)
- Utility classes for CSS (Tachyons or similar)
Re: Ask HN: Go-to web stack today?
#117I'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.
Re: Ask HN: Go-to web stack today?
#118Professionally and for personal projects I go with Elixir. Having 99% transparent parallelization of any task is irreplaceable in our multi-core CPU era (especially having in mind that CPUs seem to have more and more cores lately -- see AMD). Functional programming improves the way you reason about your tasks as well. Having a simple language living inside a 30-year old runtime and being able to reach for pretty adva…
Elixir/Erlang is concurrent, not parallel though.
Not to pile on with the rebuttals, but Elixir/Erlang are actually truly parallel. There wouldn't be much point to all the interest into it unless they were. You should go to the phoenix framework website for statistics on how it handles many connections and processes.
Of course, true parallelism only comes with multicore CPUs anyways, and this is what the Erlang VM ("BEAM") is geared to. The processes are not threads in the C++ sense and there is no shared memory, but there are separate BEAMs for each CPU core and the processes are scheduled to them. Message passing in the Actor style takes the place of shared memory.
Re: Ask HN: Go-to web stack today?
#119- 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 us…
Ah, it's poor design because you don't understand it? Right.
Re: Ask HN: Go-to web stack today?
#120- 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…
All of this is great.
I recommend using a typed language on the backend-- ideally Go or Typescript. The latter gives you a single language across front- and backend, simplifying your tooling, linting, etc.
I have had only great experiences with styled-components. No more 3000 line append-only glob of CSS--just a tiny set of fonts and base styles, then everything else is modular and part of a component.
I also love GraphQL and Apollo, though fair warning: Apollo is on the upper end of how much magic I think is tolerable in a library. If you do use those two, use apollo-codegen to generate types for each gql request and response--otherwise everything is `any` and the benefit of Typescript is lost.