
Ask HN: Go-to web stack today? - capkutay
As a long time software developer who hasn&#x27;t done full stack in awhile (since 2013), what&#x27;s everyone&#x27;s go to web hosting stack today? Wanted to quickly put together a simple website with react&#x2F;node.
======
ludwigvan
\- 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/await has made things much
easier on the node side though. Express doesn't still have async support by
default, but there are middlewares and native support is coming with express
v5.

\- Use relational databases (postgres) by default.

\- For authentication on the web, just use cookies (Do not use jwt). Put nginx
in front of django and your static files (react etc) from the same domain so
that you do not have to use CORS, JWT etc etc. So, an easy choice is
myapp.com/static serves your React bundle while the cookies are on myapp.com

Some tooling tips:

\- Use VS Code if using JS

\- Use prettier (for js, css, html, and relevant VS Code extension) and black
(Python) for automated code formatting

\- Use jest and VS Code's jest extension (Orta's) for automated tests within
the editor

\- For deployment, I roll my own, but zeit's offerings are exciting.

\- codesandbox.io, repl.it etc are amazing for testing out various stuff
without downloading stuff. You can get a React/Angular/whatever environment
within seconds that will give you a public url for your app.

\- json-server in npm will get you a mock REST API with GET/POST/etc support
within seconds from a json file.

~~~
sebslomski
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?

~~~
ludwigvan
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.

~~~
emidln
What is Honeywell?

~~~
ludwigvan
I meant honeysql, but iPhone corrected it. :)

[https://github.com/jkk/honeysql/blob/master/README.md](https://github.com/jkk/honeysql/blob/master/README.md)

------
shapath
Backend: Django w/ Django Rest Framework

Frontend: Vue

Prefer Django, because it has so many things built in (authentication, other
protections to build things super fast and not worry), many people call it
magic but if you read the code, it's very easy to follow. [1] & [2] sites
helped me a lot to remove the "magic" as well.

Prefer Vue because it is strongly opinionated, unlike other JS frameworks
(i.e. React). Again, learning Vue allowed me to build things super fast and
other having to worry about things like Gulp, Webpack and many more things
that I don't understand in the JS community. Personally for me the JS
community moves too fast for my liking and Vue has been a god send, especially
with the help of Vue Cli [3]

Database of choice: PostgreSQL, because it is used by several developers
rather than MySQL when building anything with Django.

Building realtime: I use a external service like Pusher or Pubnub, because
they have generous free plans to get you up and running. But there is Django
Channels if you don't want external dependency.

[1] [http://ccbv.co.uk](http://ccbv.co.uk)

[2] [http://www.cdrf.co](http://www.cdrf.co)

[3] [https://cli.vuejs.org](https://cli.vuejs.org)

~~~
reindeerer
Seconded on Django. It's excellent, especially if you get it out of the box
with cookiecutter-django and DRF ( rest framework )

Plus, with things like Zappa it's easy to go entirely serverless

Django + NewRelic for APM is plain magic

EDIT: Oh, and Celery if your use case needs it. Brillant

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

~~~
EmilStenstrom
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).

~~~
y4mi
> 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.

~~~
EmilStenstrom
As a non-expert on lambda... Django encourages one function per view, and
adding database calls, celery functions, maybe API calls, to your views make
them quite big, and potentially slow to run. Running slow functions is not how
lambdas are supposed to work (as I've understood them). Rather, you'd want
smaller ones that call out to other smaller lambdas. That coding style is not
something lambda encourages.

~~~
reindeerer
That's a very confused take on how things work. Celery functions run async,
and Django frontend view responses are normally lighting fast

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

~~~
virtualwhys
For a long time I was in the server-side html + js for ajax/validation/effects
camp, but I'm starting to gravitate to the SPA side of the fence.

Why? While server-side based web sites can load quickly, there's something
dissatisfying (to me) about clicking around a site, waiting for server
responses, when _nothing has changed_.

Sure, js, css, img, etc. assets are likely cached in the browser, and you're
just downloading a blob of gzip'd html, but wouldn't it be better to flip the
script and notify the client, rather than the client clicking around,
uselessly consuming resources?

A SPA combined with websocket connections allows you to implement the, "don't
call us, we'll call you pattern". Granted, for mostly static sites this isn't
particularly useful, but still, in principle, only consuming server-side
resources when state has changed is a "natural" goal I'd argue.

There are tradeoffs with both approaches, but I'm leaning toward SPAs more and
more.

~~~
peteforde
I urgently encourage you and anyone else reading this to check out Turbolinks
5, ideally in tandem with Stimulus.

[https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s](https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s)

[https://github.com/turbolinks/turbolinks](https://github.com/turbolinks/turbolinks)

[https://stimulusjs.org/](https://stimulusjs.org/)

You can get all of the benefits of server-generated pages with the speed of an
SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks
and Stimulus.

~~~
pklee
Just looked at stimulus. Really cool framework. circa 2008 or so there was
this concept of non-intrusive javascript where you bind js to elements. So you
could wysiwyg html and then inject js where you need it. Thought that was a
neat idea and like what stimulus does it. Any real life experience from anyone
?

~~~
TomK32
Yes, I'm using it in the budgeting webapp that I develop and here's one little
component that I shared, a calculator for input boxes
[https://tomk32.de/2018/08/04/stimulus-component-
calculator.h...](https://tomk32.de/2018/08/04/stimulus-component-
calculator.html)

Really should add a gif or something.

~~~
pklee
pretty cool.. thanks for sharing... I could not work on the app itself, but
that is ok.

------
therealmarv
If you want to be fast and flexible:

Frontend: Vue.js on top of Nuxt.js (reactive web programming cannot be easier
than this and you get SSR or SPA or PWA or static page generation out of the
box easily, you can decide later on that). There is not only React out there
(which is like a jungle and more complicated in comparison to vue)...

Frontend styling and components: Vuetify or Bulma (you can also go with some
vue bootstrap) + Stylus or SASS

Database: PostgreSQL (it's so stable, flexible e.g. with JSON, extendable and
scalable in so many ways).

Backend: Whatever suits you to build a RESTful or GraphQL web API.
Python+Flask, Go, Django, Ruby on Rails, Java Play Framework, PHP (e.g.
Laravel) etc. etc.. Whatever you are most productive in. It does not matter
really.

CI/CD and source control: Gitlab.com and the CI you get for free there is
unbelievable good.

~~~
dakshmiglani
All of your points are great. Imo vue / nuxt is a much simpler and complete
set compared to react and Gitlab CI is an amazing tool, you can literally use
docker in docker to build the container right from it and even deploy to
kubernetes.

------
luord
First, be entirely sure that you actually need an SPA.

So, in stages:

\- Database: Postgres (you could start with any relational DB, Postgres is
just one of the best). It's very, very likely that your model is gonna be
relational so better pay that debt upfront. Don't even consider NoSQL this
early; we're paying a heavy price on my current job because the initial
developers bought that non-relational databases were better at prototyping.
Worry about NoSQL and consider switching to any of those if you see, once you
release, that the type of data you're handling is more of a stream of mostly
independent records than an actual model.

\- Like I said, make sure that you actually need an SPA. It's likely that you
don't and in that case you can get away with using Django; it gives you pretty
much everything you could possibly need.

\- If you're dead set on a SPA, go for a more lightweight framework geared
towards creating REST APIs. The usual recommendation is flask with any of the
rest extensions, but there are other options such as falcon or molten (which
is recent, but really well designed).

\- Since this is a SPA, use Vue. I find it to be leagues ahead of the js
frameworks when it comes to striking a balance between power, expressiveness
and ease of use. Much like Flask in the backend, for that matter.

\- Dockerize. I don't like promoting a specific tool in this area but docker
will make it very easy to develop and deploy your application (also makes it
easier to implement the usual suspects like a reverse proxy, a queue, a cache,
etc) without having to rely --and thus essentially marry-- any specific tool
provided by a given cloud platform.

\- Use gitlab for version control. They give continuous integration and
private repos for free out of the box.

~~~
Fre_d
At least briefly consider whether or not you actually need a relational
database when starting a project. I work with some rather complex data access
using Postgres, JPA, Hibernate, HikariCP, and a second level cache, all within
a separate microservice exposed via a REST API. To make matters worse, the
responsible developer has since left the project to me.

We don't even use relations, so this essentially means that we are paying a
hefty price for something that we don't actually need. A much simpler solution
would be to have used MongoDB together with Spring Data, where we can still
have caching and object mapping.

~~~
owens99
I would personally never use MongoDB again. Broke one too many times. Postgres
on the other hand has never failed me.

~~~
Fre_d
MongoDB was released nearly 10 years ago. Do you believe those issues are
still relevant today?

~~~
aeonflux
If that’s the argumentation then Postgres is over 22 years old which makes it
over two times better? On the other hand Windows is over 30 years old and it
still hasn’t fixed many issues which for me are the reasons why I don’t want
to have anything to do with it.

~~~
Fre_d
I'm not saying MongoDB is better because it is old, and I was rather hoping
you would elaborate. For all I know, you could have had issues with it
yesterday or 9 years ago.

~~~
owens99
I haven't tried it in 4 years myself. But I invested in a company that just
launched their product two months ago and already regrets building it on
Mongo.

------
Retozi
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 language for either functional or object oriented
programming. Static typing with strict null checks are again a huge
productivity boost. Standard library is very complete

Beeing on the JVM without beeing stuck with Java is a big win:

\- unlocks a huge ecosystem and Java interoperability of Kotlin is
superb.There are a lot of lightweight frameworks for stuff around here,
enterprise Java is a myth if you are free to choose what to use.

\- special shoutout to the JOOQ library, the golden middleground between an
ORM and raw SQL Strings.

\- JVM is fast

\- fat jars are somewhat like containers, can be run everywhere with minimal
setup (yeah I'm looking at you python-uwsgi black magic)

Database: Postgresql. Everything you need (relational, JSON), fast, rocksolid

~~~
AsyncAwait
Wanted to look into Kotlin on the backend for a while now. Do you use any
framework or do you just assemble individual libraries for whatever you need?

I am not sure I find Spring an attractive proposition and Ktor seems rather
young, slow and not that well documented.

What do you think is the best option?

~~~
Retozi
I'm personally in the "functional handler" way of doing HTTP Request camp.

We have a very small Ktor service in Production, and it works nice, for legacy
reasons, we're using [http://sparkjava.com/](http://sparkjava.com/) for the
heavy lifting. An alternative would be
[https://javalin.io/](https://javalin.io/)

I would not start with Sparkjava anymore. The way you write handlers is quite
okey (compared to other frameworks), but there are issues with how it's
connected to Jetty and relies on singletons that will be painful if you would
like to do advanced stuff. It's on our todolist to swap Sparkjava with Ktor
somewhere down the road.

To be honest, Ktor seems to have come a long way, the docs improved a lot last
year and it seems well thought out. I would give it a try. It's quite easy do
decouple your application Handlers from the underlying framework via
functional composition, so there is no big lock-in Risk.

In my experience, all three Frameworks are way better than the regular Java-
like approach with annotating classes. Request-Context specific information
("The user making the request") is very hard to get to this way and it's
usually untyped. On top of it, you are locked in HARD to the Framework.
Swapping out a Framework that just mounts Functional Handlers is way easier...

~~~
AsyncAwait
Thanks for the writeup, Javalin looks like what I was looking for honestly,
but I'd check out Ktor again as well.

EDIT: Ktor does look a lot better today and now that Kotlin coroutines are
actually stable, I'd definitely check it out.

------
pdimitar
Professionally 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 advanced tools if you need them, is heaven. Not everything is
ideal though; there are still holes to be filled in the ecosystem.

If you do something more serious and need compiler help as much as possible,
I'd say go for OCaml. Its multi-core parallelism story is still not good but
there are ways around that. I hear from some people Idris is good as well.

~~~
dragosmocrii
Elixir/Erlang is concurrent, not parallel though.

~~~
dragosmocrii
To best of my knowledge, Erlang was not built for parallelism, but
concurrency. When the language was created, multicore CPU where not yet
available. The following article can explain better the point.

[http://jlouisramblings.blogspot.com/2011/07/erlangs-
parallel...](http://jlouisramblings.blogspot.com/2011/07/erlangs-parallelism-
is-not-parallelism.html?m=1)

~~~
nathan_long
It's true that when Erlang was first made, machines were single-core, so
parallel execution was not possible on one machine. However, the "no shared
memory" process model made transitioning to true parallelism much simpler. The
ability to run one scheduler per core was added around 2005 I think. See
[https://hamidreza-s.github.io/erlang/scheduling/real-
time/pr...](https://hamidreza-s.github.io/erlang/scheduling/real-
time/preemptive/migration/2016/02/09/erlang-scheduler-details.html)

Also:

> Erlang achieves concurrency by interleaving the execution of processes on
> the Erlang virtual machine, the BEAM. On a multi-core processor the BEAM can
> also achieve parallelism by running one scheduler per core and executing one
> Erlang process per scheduler. The designer of an Erlang system can achieve
> further parallelism by distributing the system on several computers. >
> [https://happi.github.io/theBeamBook/](https://happi.github.io/theBeamBook/)

My understanding is that the BEAM will also do "work stealing" among
schedulers to take better advantage of the available CPUs.

------
hamaluik
For static websites, [https://getstatik.com/](https://getstatik.com/)

For “dynamic” websites, Mithril
([https://mithril.js.org/](https://mithril.js.org/)) and Redux written in Haxe
([https://haxe.org/](https://haxe.org/)) on the front end with Rocket
([https://rocket.rs/](https://rocket.rs/)) and SQLite on the backend, proxied
behind nginx with Let’s Encrypt on the backend.

Personal projects hosted on a VM at Linode, company projects hosted on VMs at
Google Cloud.

It’s a somewhat unique stack but I love it and can be exceedingly productive
with it.

~~~
markoman
Its an interesting stack, for sure. I'm only surprised by the sqlite choice.
With such a concurrent and speedy backend, what do you do about concurrent
writes and the lack of row/page level locking in sqlite?

~~~
EmilStenstrom
SQLite is great when there are few writes, such as for a personal blog. For
lots of writes, you probably need another database.

------
slifin
Backend:

    
    
      Clojure
      Datomic
      Luminus
    

Frontend:

    
    
      ClojureScript
      Regent
      Datascript
      Datsync
    

Some advantages:

    
    
      Immutability down to the database
      Database reads scale horizontally
      Impossible SQL injection from reading API
      Cache TTLs can be set to infinity
      Can ask for data at any point in time or do speculative writes
      Same programming language front and back
      Running queries within loops are performant due to data locality 
      Query results can be returned with nested results
      The database can be queried with Clojure functions
      Data shape is defined at query time, not at schema time
      Specs can enforce stronger safety than types
      Specs can help generatively test your application
      Prolog -> Datalog many things from SQL can be expressed easier in datalog i.e. recursion, nesting, joins etc
    

This kind of stack is just getting started, see hyperfiddle as a real-time app
builder that leverages these primitives that thing is off the chain powerful
it can render itself inside its self, can express blogs, tables, crud
applications very easily, once that gets deps support no reason it couldn't
support much more complex apps

The equivalent would be a site were you could write SQL client side, to define
your data for your application then add react code to complete your app

~~~
snazz
This is very cool and certainly unique compared to some of the other
responses. How much have you used this in production? Have you worked at
companies that do?

------
marcus_holmes
Storage: Postgresql

Backend: Go (no framework, just the standard library)

Frontend: Vue

Working great so far. A little longer to get things up than using
Rails/Django, but the extra speed and control is really nice.

Using Go's templating engine to assemble Vue components into HTML <script>
tags works well.

~~~
no1youknowz
What are you using for SSR?

I haven't yet seen any concrete tutorials for getting this up and running with
Vue and Go. All I've been able to google is augustoroman/V8 and dop251/jago
and other derivatives.

~~~
marcus_holmes
to be honest, at this point I don't bother.

My only dependency is Vue (and vuex), and I only send the components that the
current page needs (packed into a single <script> by the template engine). I
also send the initial data inlined in that script as js objects. So there's 1
fetch to get the the HTML (usually around 200-300Kb), then 4 fetches (vuejs,
vuex, css, logo file) totalling around 500Kb (and all cached, so that only
happens on the first load).

So far, no speed problem and no rendering lag worth worrying about. If that
changes I'll look at methods of fixing it, but I'm learning to not solve
problems that I don't have yet.

------
yakshaving_jgt
If it's a brochure site, use a static site generator and put your generated
stuff on S3. I happen to use Hakyll, but they're all more or less the same and
nobody cares what software generated your files.

If it's a web app, my weapon of choice is Haskell/Yesod because I have
opinions about how complexity grows over time and how that should be managed.
Dynamic languages fall short of my needs.

If I need a complex UI (lots of state and interactivity), I use Elm. It works,
and in my experience it works better than dynamic alternatives (JavaScript,
ClojureScript, etc). TypeScript and Flow are not alternatives to Elm.

For storage I just use Postgres, and sometimes Redis if I need it.

For infrastructure, I do just about everything with Nix/NixOS/NixOps (although
I develop on an Apple Macintosh Book Air).

------
vemv
Clojure + ClojureScript

* One language across the whole stack

* Its approach for React makes it both easier to grasp and more correct/maintainable than its ES6 counterpart

* Gradual typing for the parts that matter

* The overall experience is the opposite of "Javascript fatigue"

Needs some investment, cannot be denied but it pays off over the years.

~~~
swah
* Feels lonely

~~~
harperlee
That is true, at least from here. But it sure is a pity, as the technology is
fun and technically awesome, and the stack is not so esoteric - it is actually
used by a lot of people.

Part of the reason is that libraries can be “finished” (as in, so stable that
they don’t need frequent updates), so there is way less busywork and noise in
the open.

Another reason is that clojure is open source but not free software, and this
has affected the community. There was a big discussion lately about this,
where some vocal leaders of the community complained about it:
[https://news.ycombinator.com/item?id=18538123](https://news.ycombinator.com/item?id=18538123)

~~~
pushtheenvelope
thanks for sharing your thoughts.

Could you elaborate on why or how libraries feel "finished" in Clojure versus
in other languages?

Also, curious about the gradual typing bit. How sophisticated is Clojure's
type system once applied, compared to one found in (say) Typescript, or as
another extreme Scala?

------
interfixus
JS has its uses. Once in a while I see a site which actually needs it and
makes proper use of it. Much rarer, I have to develop such a site myself. But
generally, I hark back to ancient times when websites meant html and css. When
I do need a dose of JS, I usually go with something raw, or the unfashinable
jQuery. I _abhor_ the thought of JS in the backend.

Html and css always via Pug and Sass.

Out back, I really, really like minimalism, usually in the form of a single
executable made with Nim. Static link whenever possible, so I can just bang
the thing unto anything linuxish. For a reasonably low-volume site (meaning
99.9% of all sites), I go with SQLite for data. Yes, there'll be shouts of
outrage that I shouldn't do it. These I know I can safely ignore, but keep my
code clean and simple and easily portable to Postgresql if the should
occasionally arise.

Sometimes I need easy access to every library function ever written, so I'll
drop the purity and go Python. Bottle or Cherrypy is what like to build on,
then.

No matter what, these days run the whole thing behind a Caddy server and be
done with any headaches over configs and https.

I realise, of course, that I am completely out of whack with current general
consensus. So be it. My stuff works, and works fast, and I can cram amazing
amount of it into a fairly low-end VPS.

~~~
alain_gilbert
I use the exact same setup using Go instead of Nim.

It works marvellously well. I use VueJS when I have a page which requires more
intensive JS.

For dead simple use case (no subdomains), I was even able to embed caddy
within my static binary file.

Serving hundreds of users on a $5 VPS.

~~~
interfixus
Hundreds of users, exactly.

And yes of course, Go. Solid language, good tools, and a much richer set of
libraries than Nim. First rate solution, and I have tried. Several times. But
for some reason, Go and I always end up in a shouting match, and one of us
inevitably slams a door. It's a purely personal thing.

------
nzoschke
Static content served from S3 / CloudFront / ACM / Route 53.

Lambda functions for APIs.

I favor Vue for frontend and Go for backend but React and Node work just the
same.

[https://github.com/nzoschke/gofaas/blob/master/docs/static-s...](https://github.com/nzoschke/gofaas/blob/master/docs/static-
sites.md)

------
tanin
* 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](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.

~~~
mkurz
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!

------
honopu
You can go really far with node. I'm a node js and Vue dev these days, but I
think we will end up switching over to React for public facing stuff due to
ease of hiring and getting devs to work in it. I like sticking to one
language, it performs pretty well, and is fairly easy to hire for and get help
with.

I am looking at React on the front-end instead of vue, due to how much easier
it is to hire for react.

The isomorphic/universal rendering is really awesome for node on the server,
one set of templates vs two, plus it seems like the GraphQL stuff is way more
mature on node. We're not currently using GraphQL, but having that option open
to us is nice.

Combined with all the success stories from Linkedin, Paypal and even Walmart
around moving stuff to node, it's also an easy decision to defend.

I'm not a huge fan of debugging node, that could be a bit improved, but
overall I am happy with the choice to try to build everything in node unless
there's a compelling reason not to.

~~~
christophilus
I prefer React to Vue, and MithrilJS over anything else. But I don’t think
that hiring should be difficult for any of those. If you find someone who
knows React, they can easily pick up MithrilJS or Vue, no?

------
pragmatic
Use what you know.

The technology fashion show continues on at full tilt.

PHP, asp.net, node, go, etc.

Angular, react, Vue, etc

MySQL, sqlserver, postgres, nosql, etc.

I've used all of these and more to build systems.

I'd stick with what you know and look at what your requirements are, SEO,
massive scaling, needs to be cheap, needs to run on multiple platforms, et.

~~~
snazz
Your username matches the suggestion in your comment (which I agree with
wholeheartedly)

------
butterfi
The problem I have with most, if not all, of these answers is that they seem
to be good choices for orgs that have a dedicated development team. If its a
small org, or a company that basically just has a brochure site, all of these
answers are huge overkill. You want a "simple" site made from node/react?
You've already raised your technical requirements higher then they might need
to be. If your site has a rotating team of developers, I'd say start with the
LAMP stack and go from there. It's easier, more affordable, and less time
consuming to find developers with decent HTML5/CSS3/JS then it is to find
dev's competent in the latest thing your senior dev is enthralled by. I turned
down a job offer managing a Rails site because frankly I'm tired of trying to
find Rails devs. Tooling choices by developers have serious staffing issues
that many orgs still have to deal with after the original devs left, which
sucks for the org as they never really understood what they were signing up
for when the senior dev promised them that _insert framework here_ was the
solution to all their problems, when in reality the dev simply wanted to keep
their skill set "up to date."

------
ninjakeyboard
I 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 stored in cassandra.

IMO Ruby, Python and Elixir are perfectly suitable but the last languages I
would choose. I've been working with elixir for the last 1.5 years and have
decided I don't really like it. I'm happiest writing scala - I get more done
faster and less bugs make it into production. Event sourcing and Akka cluster
allow some really interesting patters that move state into application memory.
But those technologies require a much different, more involved skill and
experience set to lead.

I'd probably be using Go or Scala if I had to start a tech company in a small
city. Scala if I were in a large city with talent 100%. There is evidence that
Static typic improves speed of delivery and it's easier to refactor/maintain.
And it's faster (generally). Both languages are much more widely used than
elixir.

~~~
malloryerik
May I ask, what is it that you don't like about Elixir?

~~~
inferiorhuman
Deployments are a nightmare.

~~~
nathan_long
I'm not sure what you're comparing it to. Releases can be tricky, but if
you're accustomed to `git push heroku master`, or to "blue green deployment"
([https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html)),
there's no reason you can't do that with Elixir.

~~~
inferiorhuman
Deployments are a significant amount of magic, moreso than with other
languages. You're deploying a whole beam ecosystem not just a single app. If
you want to do anything remotely dynamic (e.g. using environment variables as
knobs a la 12-factor) you'll have to rely on distillery and voodoo.

Meanwhile distillery has been broken on FreeBSD for months with no fix in
sight and no actual community understanding of how things fit together.
Dockyard also has a good blog post explaining how complex Elixir deployments
get:

[https://dockyard.com/blog/2018/02/28/elixir-deployment-
tools...](https://dockyard.com/blog/2018/02/28/elixir-deployment-tools-update-
february-2018)

No bueno. Generating a WAR or JAR to deploy is typically trivial in
comparison. Capistrano? Easy peasy AND reliable. Distillery? I'm just glad I
don't have any production Elixir apps.

------
pjmlp
Tooling JEE, Spring or ASP.NET MVC, with server side rendering.

Eventually coupled with full stack CMS like Liferay or Sitecore.

For frontend either tiny pieces of vanilajs when dynamic code is really
required, or something that is WebComponents friendly like Angular, if the
backend is mostly composed of Web APIs.

Might not be fashionable, performance is quite good, and we get to focus on
delivering instead of playing JS framework of the month.

------
coder94
Back-end: Clojure Front-end: ClojureScript with Re-frame or Reagent.

check out: [http://www.luminusweb.net/](http://www.luminusweb.net/)

------
beezischillin
My personal preference: React on the Front-end, PHP7+Symfony4 on the Back-end
with Postgres, RabbitMQ for messaging and NodeJS for microservices that deal
with various real-time tasks based on those messages.

~~~
alfonsodev
I stopped using Symfony at early version 3, (php 5.3 I think ) started to use
nodejs, express, which lead to start using react and code SPAs.

Last year I came back to php stack, and it was refreshing, Symfony 4 is really
productive! composer flex system with recipes to finish the bundle
configurations, and webpack encore makes really easy to bundle js,etc.

I think Symfony 4 is underrated when you see how popular React SPA are these
days.

~~~
beezischillin
I find S4 to be really fun to develop with, it's just such a well put-together
framework that it's a joy to use, even when you're digging into the more
obscure bits. Especially when paired with PHPStorm.

------
rishav_sharan
I am using plain crystal to make an api server with a spa in vanilla js and
cant be happier with my choices. Dropping all frameworks and stacks has me far
more productive and a better programmer. My db is postgres and i am hoping to
use nuster as load balancer/cache on digital ocean droplets

~~~
goatlover
How good is the library support for Cyrstal? I love it's performance and it's
much closer to Ruby than Elixir, which is just superficially like Ruby in some
syntactic ways, where is Crystal is really a typed, compiled version of Ruby.

------
pythonist
\- Frontend: Vue with TypeScript and Bulma or TailwindCSS

\- Backend: Go (no framework) with monolith first approach with well defined
internal logical interfaces that can be easily implemented as external
services when they need to scale (session service, user service, notification
service, slack integration service...)

\- Storage: embedded BBoltDB or Badger, separate db for every logical service
and PostgreSQL data structure is very very complex

\- Services communication: Protobuf with GRPC

\- Monitoring and alerting: Prometheus with Grafana

\- Log aggregation: simple central rsyslog, indexing when really needed

\- Editor/IDE: VS Code

As less operational maintenance is needed, the easier is to live with your
creations.

Example: [https://newreleases.io](https://newreleases.io)

------
threeseed
Scala, ScalaJS, Slinky React.

No Javascript to learn and no worrying about ECMA versions or whatever today's
new build tool is. Shared code between client and server. Type safe so you can
get a proper IDE, refactoring and a lot less bugs. Full reuse of React +
Javascript libraries as well as the incomparable JVM ecosystem on the backend.

Also probably the fastest and most scalable language you can use and is used
at Twitter, Netflix, Linkedin, Spotify, Tumblr.

~~~
mark_l_watson
Thanks for the Slinky reference, I had not seen it before. I spent some time
evaluating Scala.js a few years ago and liked it, but ended up not using it.
When I retire from my full time job in a few months I am planning on
reworking/rewriting a few of my web apps and I will do an evaluation of
Scala.js with Slinky.

------
igammarays
My safe enterprise monolith stack for long term maintainability and high
productivity is:

Backend: Django

Realtime/DB: Realm + Postgres

Frontend: Angular

Surprised few have mentioned Angular yet. It is highly opinionated unlike
React, and backed by a giant unlike Vue. Seems like a safer enterprise choice.

~~~
tinyvm
> It is highly opinionated unlike React

Agree on that point , I like Angular because it's opinionated compared to
React.

> and backed by a giant unlike Vue

Strongly disagree , Vue is backed by many large corporations and unlike
AngularJS was designed to guarantee backward compatibility.

AngularJS not being compatible with Angular is what has killed for good the
frameworks and left thousands of entreprises in dust when they believed
angular would become a standard because "it's backed by a giant".

Workings for banking sector , I've many customers build CRM or KYC
applications on top of Nuxt. Developers love the Vue ecosystem.

> Seems like a safer enterprise choice.

Strongly disagree here as well.

Angular is a great framework but it has absolutely unacceptable build size,

A "Hello World" using Angular 7 with Ivy Rendering is 500KB+ ( tested this
morning ). This is not acceptable for modern frameworks to be that big.

Vue and React stay largely under 100KB in terms of build size.

They are lots of scenarios where picking Angular over Vue & React would made
things more complex for a project.

~~~
gitgud
Angular is notorious for breaking compatibility. They're constantly
redesigning and breaking the API of random components.

The best parts about Angular are; the dependency injection system and the
opinionated component templates.

------
ralala
I am surprised no one has mentioned Pyramid and SQLAlchemy yet. SQLAlchemy is
by far the most complete ORM/Query-Builder I have used (yes, I have tried out
Rails, Django and Hibernate).

Also Pyramid's traversal routing is awesome to build REST-applications and ACL
authorization.

What ever stack you decide on, I recommend to stay away from too much magic as
it complicates debugging and understanding the framework completely
(Hibernate, Laravel). If a framework needs to dynamically generate proxy
classes, either the framework has a bad approach or the language is not the
right choice for the approach.

~~~
sethammons
Lots of folks love sqlalchemy. I just don't get it. I only have to use it
infrequently, but when I do, I spend very little time crafting my SQL and a
much longer time translating it to sqlalchemy's query builder. Even a join is
a PITA.

~~~
ralala
Have you tried out SQLAlchemy Core without the ORM?

Regarding the joins:

j=t_user.join(t_address, t_user.c.id==t_address.c.user_id)

select([...], from_obj=j)

------
mogambo1
I recently tried Google's cloud functions for backend and firestore for
database on a decently sized project. I think it is a good fit for quick small
projects and a good experiment if you don't mind a small learning curve. The
minor shift in design patterns took me a while to adjust.

Pros:

\- Setup is pretty quick, you can move quickly from scratch.

\- Deployment is painless.

Cons:

\- Firestore is NoSQL which is a huge caveat.

I had to scale the project and add some features later on. Faced some bumps
here and there but nothing major (since firebase is still under development).
AWS also has similar offerings (lambda, hosted DB etc.) in the same space. I
haven't tried them out but look forward to doing so.

For frontend use Vue 10/10 especially if you're looking to put together
something quickly. I felt Vue provides a lot more room for "hacking" quick
solutions(and improving on top of it later) compared to Angular or even React.

I only prefer this stack for "reactive" web apps though that have a lot of
dynamic components. For a traditional website I'd still go with
jQuery/Django/SQL.

------
gjmacd
Hard to argue anything other than using React (or Vue) on the frontend with a
Node.JS / Express / GraphQL Apollo Server back end. To me that's the "go to"
at the moment and I love Python and really think Elixir is amazing...

BUT...

When the client is 100% JavaScript on a browser (which nobody is avoiding) and
you're marshalling JSON around and JS Objects, any other stack outside of Node
is going to have to do the "JSON object" dance, which we all take for granted
as "no biggie", but matters when your code base is spending 20% of the time
doing that dance.

Node's also super fast and the community is massive. Not to say Python isn't
another good choice but you give up performance in that choice.

Again, this is a "Web stack", so I'm assuming web client talking to the
server. Right now, for me, it's Node / React.

------
PacifyFish
React/node is what I use for side projects.

React is pretty annoying to set up yourself since it needs to be compiled, so
use [https://github.com/facebook/create-react-
app](https://github.com/facebook/create-react-app) to spin up quickly or just
host vanilla html/css/js and slowly transition to react as you please.

Alternatively, I think the React core code can be downloaded on the client via
a cdn.

------
adventured
\- Python, PHP, GO, depending on what I need to do. No frameworks.

\- Vanilla JavaScript and CSS. No frameworks.

\- Relational db and Redis

\- NGINX and Ubuntu. NGINX for caching.

\- AWS or DigitalOcean depending on what I need to do. I strongly prefer
working with DO whenever I can now vs eg AWS or Azure. I've had a good
experience with Linode and Vultr in the past, however DO's ever-improving
offerings keeps putting distance between them.

I've built up my own frameworks for authentication, APIs, etc. over many years
that I evolve regularly. Over the last ~15 years I've strictly only been
building my own things, so I don't have to consider other organizations or
teams and what they want or their pre-existing approaches. My approach only
makes sense because of that.

------
mark242
React hosted in an S3 bucket, API Gateway with one Lambda function per model,
single DynamoDB table with overloaded indexes. This will cost you pennies to
spin up and get traction with.

~~~
jypepin
how do you handle SEO in this case?

AFAIK most crawlers (including facebook etc) don't load javascript, so I'm
always wondering how to allow dynamic pages (say a product's page) to be
crawled and have a og meta tags.

If this had a great solution, boy things today would be much easier!

~~~
mark242
If you are relying on SEO to gain initial traction, your project is going to
fail. Start worrying about SEO when you have a core base of users who are
actually using your product and by then you'll be more interested in refining
features for your userbase that you won't fall into the feng shui trap that is
SEO.

edited to add: The reason I discount SEO like this is because SEO is
essentially chasing a search result against competitors who likely have more
budget, more resources, and more time to play that game. Spend your time on
making your product better, aggressively market directly to people instead of
relying on the passive results of SEO, and by the time your project takes off,
you will hopefully be in a spot where you won't care very much about why using
react-helmet doesn't help with Facebook shares.

~~~
jypepin
Nobody mentioned initial traction or if it is too early to worry about SEO.

As I asked in my question, I also mentioned the need for og meta tags for
social sharing, which is something that is often important for clients I talk
to.

The appeal of a static SPA hosted on s3 is great, but I have trouble getting
good responses about such fundamentals from people who advocate this
architecture.

------
joelthelion
For the tiny web apps I write, I simply use Flask. If it becomes a wee more
complex, I might use vue and bootstrap for the front-end. But it's rarely
needed.

------
jahaja
Worth to note is, well, in my opinion at least, that today's go-to web stack
is generally not about simplicity or quick time-to-deploy. The benefits I
assume are long-term. So unless a goal is to become up-to-date with the latest
popular tech stack I'd instead go with the simplest thing you know that'll do
the job.

Maybe I'm overly negative but JS, React etc are a can of worms short-term that
are likely to take a lot of more time than creating a simple website. IIRC
there even exist quite good static website generators nowadays.

------
cybertim
\- Frontend: Angular 7+

\- Backend: NodeJS with Hapi and Mongoose / Mongodb

\- Auth module in Hapi (JWT)

\- All in Typescript and VSCode

These libraries have been stable for a while now. Tried GraphQL / Apollo for a
while but the amount of breaking updates made me go back to the stack
mentioned above. Currently i'm exploring dotnet core (in C#) and blazor.

------
Alir3z4
Frontend: Angular7 (or Angular8 next week :D).

Backend: Django or Rails.

Database: PostgreSQL.

Deployment: Heroku

Code Sharing: GitHub or Gitlab.

CI: GitLab CI if you're on Gitlab or CircleCI if on GitHub.

CodeCov.io for code coverage

~~~
h1d
This is not your resume, you need to explain.

~~~
Alir3z4
That's your homework!

------
thosakwe
On every project I’ve built, I’ve been alone, so my go-to stack is pretty
traditional (other than the fact that I use Dart).

My backend is Angel, a Dart framework which I wrote, and for the frontend, I
just go with server-side templates. I go with vanilla JS or jQuery when
needed.

The only reason I’ll make an SPA these days is if I’m also making a mobile
app, and then I write everything in Dart and share common code.

But time is really a luxury for me as-is, so I try not to deviate from the
server-side path.

------
kyriakos
PHP /laravel and react.

~~~
bnt
I’m actually surprised Laravel isn’t mentioned much here.

~~~
illuminati1911
Probably because the year is 2019, not 2004.

~~~
detaro
Today is roughly as far from the first release of Laravel as 2004.

------
adrianhel
If you go for React, I would highly recommend Mobx for state management. And
create-react-app + yarn eject to get started. CRA is a joy to work with.

Mobx is a bit more difficult to grok and debug for newcomers than Redux, but
it's really really fast, easy to test and requires little boilerplate.

On the other hand you get reactive state management by default in Vue.

If you use Node for the backend I can recommend using Knex for database
queries and migrations while using Postgres.

But if your app will be write heavy, you should consider NoSQL. Neo4j looks
very promising in this area and Mongodb also works well.

You will have an easier time migrating data and keeping the data in a known,
consistent state with an SQL database. So use that unless your app is write
heavy.

I also like using Sqlite for smaller apps. Your database is a single file, you
can use knex and switch to Postgres if needed.

As for the backend, I recommend using dependency injection and decouple the
http layer from the APIs in all cases where it's possible. It makes things
easier to test. Personally I rolled my own library (@adrianhelvik/container)
for DI in Node.

~~~
TN1ck
I am currently building a really complex application using Mobx, it’s great!
Because of how it works you can do things that are impossible with redux - as
the state would take too long to update with redux. I’m also using mobx-state-
tree which is like the love child of mobx and redux. Amazing project as well,
should be used if you want to have explicit model validation and immutability.
I used it to build a history feature - that would have been almost impossible
with vanilla mobx.

------
DanielBMarkham
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.

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

------
eranation
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)

------
wilsonfiifi
Django for API (business logic, database access and authentication) and
backend admin UI. Nodejs or Go for client facing web application. Riotjs and
jquery for frontend.

------
benatkin
Here's an interesting stack:
[https://github.com/ornicar/lila](https://github.com/ornicar/lila)

It's the server/client for [https://lichess.org/](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're
using a vdom called snabbdom.
[https://github.com/snabbdom/snabbdom](https://github.com/snabbdom/snabbdom)

~~~
jpatokal
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.

~~~
WilliamEdward
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.

~~~
markoman
What would be the reasons, then? (Those that he didn't state, at least.)

~~~
WilliamEdward
Lack of online tutorials is something that comes to mind.

------
tiangolo
I recently created this full-stack project generator, based on previous ones I
had: [https://github.com/tiangolo/full-stack-fastapi-
couchbase](https://github.com/tiangolo/full-stack-fastapi-couchbase)

FastAPI as the Python backend. Couchbase as the database. Vue.js with
TypeScript, Vuex, etc. as the frontend. Celery for asynchronous jobs. All
managed with Docker (including frontend compilation from source). All
integrated with Traefik, so, automatic HTTPS.

Up to a month ago, I used my previous project generators based on Flask and
several plugins, but now I'm doing all the backends with FastAPI as it's about
3 times faster to develop, and about 5 times or so faster (better
performance).

------
sudhirj
For websites, just Ruby on Rails hosted on Heroku with Postgres.

For web applications

React with optional state management (Redux Saga / Mobx) for the front, hosted
on Netlify.

Ruby on Rails in API mode, with Postgres running on Heroku if the API is non
real-time or high traffic / spiky. Go with DynamoDB if it is.

~~~
sudhirj
Vue has a better and more fully integrated solution for state management, but
I prefer non templated code personally.

------
mariushop
Fullstack Go + bits of vanilla JavaScript or JQuery (for the awesome plugins)
in go html templates.

------
mrath
For work, Spring boot, Angular, MS SQL or Oracle.

For fun, any Rust Lang based web frameworks with PG and Angular

------
kamyarg
I would have gone with

\- React + Redux on AWS S3

    
    
      - Redux: You know you will eventually need to add it, so just do it to avoid needless workarounds before you give up
    

\- Python with Django+DRF on AWS ECS

    
    
      - Admin interface to inspect your data + neat REST API with one line
    

\- Postgres on AWS RDS

    
    
      - Plays very well with Django, new features are implemented in Django as soon as possible
    

Might make sense to think of cpu-intensive jobs such as image operations etc.
I personally would have offloaded them to AWS SQS + Lambda running flask
deployed by Zappa(Had nice experiences with Zappa+Flask)

------
raddledsplash
Backend : Since I am more comfortable writing python, for speed and perf i
would go for Sanic, it's pretty similar to Flask with async function. For
personal or MVP I would use Flask with Peewee or Django depending on the
complexity.

Frontend : React for dynamic page only if i really need it. The rest would
simply use any jinja provided by the backend framework.

Database : small project sqlite ( personal blog, MVP ), postgresql for
production level.

For extremely fast and simple RESTful setup I would go for loopbackwhich has
nice cli with lot's of middleware layer for data manipulation.

------
trevordev
Front end: Typescript, Vue, Bootstrap

Backend: Node, Typescript, Express, TypeORM, Postgres, SocketIO, PugJS,
BabylonJS

Webpack for bundling

Digital Ocean or Azure for Ubuntu vm hosting

I feel having the same language for front/back end really reduces mental
overhead.

~~~
h1d
Try parcel for bundling. It's basically zero config and fast.

~~~
trevordev
I did 4 months ago, I loved it at first but when I tried to use it in a more
complex use case during hackathon I ended up hitting some weird compile bugs
with it and decided to go back to webpack. Maybe ill try it again once it
matures a bit more.

------
is0tope
Nodejs for any realtime stack or where websockets need to be used. If it's a
basic crud app django is also a solid choice. For frontend I generally go with
Vue these days if making an SPA or any dynamic functionality, it's just very
easy to work with. For any backend microservice python works quite well, or
even Go if performance is needed. Rabbitmq to join it all together. Redis for
any fast access storage. Front all of this with Nginx and database is
dependent on the usecase.

To run all of it i use docker compose in both prod and dev.

------
rhwk97
I've been looking into JAMstack...static site generators, github pages,
continuous integration, aws lambdas, etc. Makes a lot of sense.

On the other hand, I just got a vps and am planning on learning Golang ;-)

------
epynonymous
golang backend restful api, websocket service, frontend some client side SPA
or static pages. database + redis for k/v and queuing, for heavy duty stuff
rabbitmq.

the nice thing about golang is that i don't need containers because my runtime
package is basically a binary, golang is great about cross compiling for
various platforms, too. when i used ruby or python, i'd have to package up all
the dependencies and even get the runtime interpreter installed while using
some tools like rbenv, etc. really, really annoying.

------
kethinov
Whichever stack you choose, make sure it outputs semantic HTML, has good
accessibility, and progressively enhances the user experience. Avoid creating
any unnecessary JavaScript dependencies.

------
karmakaze
This is something that I've been pondering since reviewing the number of
languages and frameworks I sampled in 2018. Time to pick winners.

Back-end:

    
    
      - backendless if possible (e.g. use GraphQL, Firebase, etc)
      - minimal (1:1 with document store):
        PostgreSQL/JSONB, FoundationDB, MongoDB, RethinkDB, CouchDB(mobile-sync)
      - relational: PostgreSQL(master/replica), MySQL(multi-master), CockroachDB/TiDB (sharded)
        languages: Elixir(Phoenix), Kotlin/Java(Javalin), Clojure(Liberator), Go, Kemal(Crystal)
    

Front-end:

    
    
      - HTML+JS using Phoenix/LiveView (or Vaadin?)
      - Vue.js (possibly Elm) for SPA
    

Runners-up:

    
    
      Spring - slow startup, JPA/Hibernate quirks, latency spikes (gc? of JPA/Hibernate)
      Micronaut - could be the next big thing (too much like Spring, learning curve)
      Ktor - coroutine support potential interesting, prefer a Kotlin+Java ecosystem
      SparkJava - too bare (used with Sql2o), Javalin is a spiritual successor
      DropWizard - older, poor documentation. But JDBI is sweet to use with other microframeworks
      Amber (Crystal) - Kemal has a much faster edit/compile/run cycle
      Rails/Sinatra/Web2py/Django/Flask/etc - prefer static typing and faster/smaller runtime
    

This is obviously still too long a list. Continue testing and culling.

------
georgecalm
\- nuxt (or next if you prefer react) \- tailwind (atomic css)

\- node \- express \- passport (Use cookie based auth keeping the session in
your storage. I wouldn’t waste time on JWT. There’s a decent amount of
complexity if you want both the security of being able to revoke access to a
bad actor and the convenience of long lived sessions, and at the end the auth
server will most likely need to access storage and use cookies for that anyway
(eliminating the benefits of JWT). So I’d start with cookie based auth and
build up complexity as needed.)

\- postgres \- On the Node side, I don’t recommend adding the complexity of an
ORM at first (or ever). The node pg driver will give you arrays of objects
back for rows. It’s convenient enough not to need the extra overhead of an
ORM. \- As a side note, Postgres has modules for you to implement a decent
first version of a lot of things, such as search for example, before you need
to reach for a dedicated solution. This makes it amazing for startups in my
opinion, as you can explore ideas very quickly.

\- statsd / grafana (to monitor your app and learn from the behavior of your
users)

\- docker-colpose.yml to make spinning up your dev environment with node / db
/ stats as simple as “docker-compose up”

\- DigitalOcean for hosting \- Use their dokku image \- Set up daily backups
to Spaces since your DB will be hosted here at first too

\- dokku for deployment with the Postgres, letsencrypt and grafana modules \-
deployments are as easy as “git push master dokku”

------
zmmmmm
If your experience is mainly in Python ecosystem Django is just hard to beat.
If it's Java based then things are more complicated I think - these days I
have been avoiding heavyweight back ends and using minimalist stacks of which
Micronaut [1] is my favorite. I use it with Groovy (though it supports Java /
Kotlin), Postgresql as database and combine it with VueJS on the front end for
a very agile but highly performant and robust stack.

~~~
toyg
As someone coming to modern Java from the Python world, I've been pretty happy
with Spark (no, not _that_ Spark - it could really do with a more unique
name): [http://sparkjava.com](http://sparkjava.com) . It's very simple,
doesn't require any of the Spring madness, and looks a lot like Flask in its
minimalistic approach. It has a (pretty rough) Kotlin version.

I've also dabbled with Ninja
([http://www.ninjaframework.org](http://www.ninjaframework.org)) but that was
ultimately disappointing. It relies heavily on dependency injection, which is
not my cup of tea.

~~~
zmmmmm
Thanks, Spark looks great! Very much like Micronaut actually. The only thing I
see missing that I would want is handling of async ... not sure if I'm just
missing it in the docs.

~~~
toyg
What sort of async? You can try asking on github, actual development seems to
happen in waves but the owner is fairly responsive most of the time.

------
m4xm4n
My current preferences are

Large or complex apps (such as those at work or things I intend to have a long
lifetime):

\- Backend: Rails

\- Frontend: Ember

The combination of these two is really powerful. I can focus on my complex
problem domain and not have to make too many choices about project structure,
testing setup, and other decisions that lead to bike-shedding.

Smaller applications (such as side projects):

\- Backend: Rails, Phoenix, or Amber

\- Frontend: Ember, (P)react

Rails & Ember are still very productive for small apps, but I'm finding Amber
(written in Crystal, similar ethos to Rails) to be a faster, smaller
alternative when a side-project is resource limited (plus, it's an interesting
new community). Preact and React are quite good for building small things
quickly or dropping into existing projects, so I've enjoyed them in that
context. Ember and Rails are phenomenal over a long period of time, because
they tend to have a relatively smooth upgrade path (in many cases with Ember,
there are automated tools.)

I'm a strong proponent of Postgres. It gets better with every version and is
great for both development and production use, especially if you want to do
zero-downtime deploys (Postgres has some cool tools for avoiding locking of
whole tables during updates, e.g. concurrent indexing, etc.)

------
vyrotek
ASP.NET MVC Core

------
Achshar
Vanilla javascript (Yes I said it). Build a PWA and either PHP 7 or node for
backend. Anything else is for you if you already have a preference.

------
IloveHN84
Frontend

Just the bare minimum, favour loading speed on worst case ever (Edge/Bad 3G
connections) over fancyness

\- Bootstrap 4 (minified) \- jQuery (minified) \- Sass/Less (minified)

Backend

Solid programming languages/frameworks, avoid dynamically typed/interpreted
languages, favour statically typed/compiled languages

\- C++17, coupled with httpnh2, Beast or Wt framework \- Java 11, with
Thorntail (avoid Spring bloat) \- Go \- Rust

------
shapiro92
Why would you even need a front end framework if you want to quickly put
together a simple website? use php laravel and you get everything set up, use
.net core and you also get everything. Elixir? Vue? React? say whats the hip
web stack today instead of go-to.

Also people mention nginx, again use apache because it has letsencrypt has
easy support for HTTPS certificate.

~~~
wilsonnb3
Setting up nginx with let’s encrypt was pretty simple the last time I did it.

~~~
shapiro92
oh just checked that certbot has updated their instructions for nginx. Taking
that back.

------
santa_boy
I use Meteor everyday and its actually pretty cool for side projects. But,
then I keep thinking subconsciously if Meteor is dead!

Frankly, it wouldn't really matter if it is dead as the current version seems
to mature enough for my needs in the foreseeable future. But then ... there is
kind of on an ego boost that you get while using something trendy!

------
rajington
\- TypeScript

JS will eventually support types natively and will be similar to TS/Flow's
API. I have more faith in ReasonML taking off than Dart/Flutter but I hope I'm
wrong.

\- React and React Native, even ReactXP/react-native-web if appropriate

Vue is good but not good enough to convince most of the community and the
community makes it. Their native strategy needs more work, and it's too
valuable not to have one.

\- Apollo Client

So much boilerplate disappears, and it's powerful enough to be your one data
source which enforces many best practices and capabilities.

\- GraphQL Gateway stitching GraphQL Servers and serverless resolvers

GraphQL/serverless does for the backend via microservices what React did for
the frontend via components. The benefits to the entire stack are countless.
Apollo Server (even AppSync) make it simple.

\- A serverless datastore

There's also many great GraphQL ORMs but managing infrastructure/scaling
should be avoided.

------
yhoiseth
My go-to stack is Django Rest Framework with Postgres and React, hosted on
Platform.sh.

But if I wanted to quickly put together a website to test some hypotheses, I
would try [https://github.com/sahat/hackathon-
starter](https://github.com/sahat/hackathon-starter).

------
nerdywordy
C# ASP.NET Core Razor Pages SQL Server Dapper vanilla JS

Azure for hosting and peripheral services

It is truly a breeze to put together server rendered apps with this stack. I
come from a JS heavy background but find myself so much more productive with
C#.

It's not trendy, but that's mostly because it's Microsoft. But it is powerful
and productive.

------
krsdcbl
To be honest for most projects I still use Wordpress & a Plugin like Advanced
Custom Fields on the backend side of things, and just plain old PHP/HTML/CSS
on the front.

Although modern frameworks & SPA are really fancy and feel great, there mostly
comes a point in a project where " client needs X" and i feel that keeping
tech oldschool and using a very widely used ecosystem as a CMS base earns me
the most flexibility over the sites lifetime.

It's bloat and overkill for small sites, but it gets the job done just as
quickly as other systems. And on larger or more complex sites it provides all
I'll need without the need to "custom build it" everytime.

(Disclaimer: I'm talking "websites" here, not specific-purpose web
applications where this workflow would be a horrendous workaround)

------
robodale
For me, it's either postgres or mysql for the DB, .NET Core for the website
and/or API (although I'll use nodejs+express for this as well sometimes), and
for the client: vue, bootstrap, html or pug, and maybe a little jQuery if a
decent component is needed.

I develop 100% on a macbook.

------
Rotareti
ReasonReact for the Frontend.

Python/Sanic for the API.

PostgreSQL for the database.

Kubernestes on DigitalOcean (or similar kaas provider) for hosting.

------
neya
If you didn't provide constraints (node/react), I would use the following.
Please note, this is highly opinionated, so nothing to get offended or upset
about. I like to keep my stack simple:

A. Simple static sites:

\- Jekyll

B. Medium complexity, CRUD applications:

\- Phoenix/Elixir \- Coffeescript

Note: With the latest version of Phoenix, you absolutely don't any JS
frontends at all. Watch they keynote presentation for the liveview demo:
[https://www.youtube.com/watch?v=Z2DU0qLfPIY](https://www.youtube.com/watch?v=Z2DU0qLfPIY)

C. Complex Web applications:

\- Phoenix/Elixir \- GraphQL/Absinthe \- VueJs + Vuex + Coffeescript

Developing with Phoenix/Elixir is so much better than any of the node
frameworks in the ecosystem - this has consistently been my experience. So,
give it a shot if you can.

~~~
h1d
Use Elixir only if this isn't going to turn into a team effort or you'll need
your team to learn from the language.

And coffeescript is taken over by other transpilers like TS and even ES6 and
above.

Check here for static site generators. There are good alternatives to Jekyll.

[https://www.staticgen.com](https://www.staticgen.com)

~~~
opencl
As someone who is pretty happy with Jekyll right now, do any of the
alternatives have particularly strong reasons to switch to them?

------
mattlondon
I've found that Angular2/3/4/5/6/7 has been great for quickly putting together
a website. I've been using it to build enterprise sites for several years.

Last time I looked at React you had to pick & include separate libraries for
things like routing or dependency injection yourself, and these are separate
things by separate people and the libraries you pick may or may not work with
others now or in the future - think DLL hell with conflicting versions and a
rock and a hard palce in terms of what you upgrade. That was a deal breaker
for me.

Angular on the other hand has a lot of this built-in already. Bonus points for
Angular is that it has an extensive, mature and well-maintained official UI
library ([https://material.angular.io/](https://material.angular.io/)) and now
has a CLI tool for quickly scaffolding your app. As a result, putting together
a website with Angular these days is trivially easy - its like lego. There are
Long Term Support releases if you are worried about churn, but I've not found
the changes between major versions to be anything to worry about.

Criticisms of Angular:

\- feels like quite a lot of boilerplate code has to be written if you dont
want to use the CLI tool (and if you do, a lot of the code it generates might
look like "magic" unless you bother to go learn how modules and bootstrapping
etc work)

\- inter-component communication (beyond simple parent-child relationships)
feels a bit awkward and "unclean" (parent-child is trivial though)

\- learning curve for the RxJS stuff can be high if you are not familiar with
it and are doing anything slightly complex.

For the backend, I've personally been using Golang. Not used node.js
professionally, but I am very interested by node.js's replacement
[http://deno.land/](http://deno.land/) \- deno+TypeScript on the backend and
Angular+TypeScript on the frontend is very tempting.

VSCode is the absolute go-to editor for all of this stuff. It really is pretty
decent.

------
ernsheong
\- LitElement + Redux for frontend (web components)
[https://github.com/Polymer/lit-element](https://github.com/Polymer/lit-
element)

\- Golang + Postgres for backend

~~~
colordrops
Web Components are highly underappreciated as a front-end framework. With
Microsoft moving over to Blink for their browser engine, they should be usable
natively anywhere now. If you want a standards based approach, go with Web
Components rather than React or Vue or whatever is the current flavor of the
month. LitElement is a thin layer on top of the standard to make binding and
templating easier but still generates standards-based web components. And
performance is theoretically better than virtual DOM.

BTW, LitElement is the bleeding edge front-end framework from the Chrome team
at Google.

~~~
interlocutor
If you like Web Components and TypeScript, think this 200-line library gives
stiff competition to LitElement:
[https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)
UIBuilder brings JSX to Web Components.

------
Illniyar
Lately, for small projects, I'm doing everything in firebase. No need to worry
about anything. And if you use functions for all data manipulations, you have
yourself a fully featured engine with web hosting, file hosting and database,
configured with your code and with realtime updates if you ever need it.

For client I'm mostly using React and typescript.

For bigger projects, as others mentioned Postgres is a must. I use Node.js
with express and knex when I'm able, but usually I'm limited to using either
django/rails or MVC.net, all being pretty great.

------
ojhughes
If you want a simple website, I suggest Ruby on Rails with StimulusJS. React
and friends are a big time investment that will only pay off if you need a
complex web application (not a website)

------
pkjc
I'm surprised that no one has mentioned Spring Boot or JHipster (Or maybe I
missed it).

Please do look into __JHipster.tech __It builds production grade web apps in a
matter of minutes! The backend is Spring framework and you can choose your
frontend to be React /Angular/VueJs (I recommend Vue). You can pick a DB,
testing tools, monitoring tools etc.

The generated app is ready to go into production and all major cloud providers
are supported out of the box.

All you need is a well-defined data model.

------
noodle
Rails + Vue

------
nickjj
Rails, Flask or Phoenix using Turbolinks and server side templates with
sprinkles of Javascript. Pick the one that has language / framework decisions
that you like best.

------
konschubert
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.

------
lrem
For my most recent toy project[1], I've gone with:

Storage: SQLite, assuming that in case of seeing actual load I migrate to
Postgres.

Backend: Flask, I find it a nice tradeoff between features and simplicity.

Frontend: Angular, it seemed to bring some sanity to the frontend... But it
seems rather bad at keeping backwards compatibility and I'm not sure if the
bloat is worth it.

[1]: [https://github.com/lrem/ladders](https://github.com/lrem/ladders)

------
h1d
Try to learn templating engines like 'pug' and 'stylus', if you haven't.
Writing vanilla HTML is getting so old and overly repetitive and they do a
good job of making you type a lot less.

And also you should learn packaging to include dependencies by mentioning
those in a single file. Parcel bundler has been working very good for me as it
is fast (webpack is complicated and not fast) and incremental build is a
fraction of a second.

------
ptrkrlsrd
Frontend: \- Framework: Vue/React + VueX/Redux \- JS Flavor: Typescript \-
CSS: SASS \- Server: NGinx

Backend: \- Language: Go, C# (.Net Core) or Rust \- Database: Postgres. (Redis
if needed)

Deployment: \- Kubernetes or in simple cases a Unix based server running
Docker. \- CI: GitLab CI and/or Drone.io \- Hosting: Google Cloud, AWS or
Digital Ocean

Personally I stay away from Windows Servers, Standard .NET and MSSQL when
possible.

------
crabtree123
Meteor. It is quite mature — it is working well for several demanding
production applications that our team is maintaining. And I greatly appreciate
the breadth and depth of high quality pluggable modules that the meteor team
and other developers have assembled. It is very much a “ Convention over
configuration“ style platform, going all the way down to their Galaxy hosting
service.

------
everdev
Netlify for free hosting. Static site generators for HTML and vanilla CSS/JS.
Sometimes Vue and Material.io if it's a larger SPA.

~~~
slenk
What static site gens do you like? Keep thinking about Hugo, but apparently
its hard to customize well?

~~~
everdev
My sites are usually simple enough that I use a tiny Node script and EJS
templates.

Here's a tutorial: [https://blog.dmatoso.com/build-static-site-generator-
nodejs-...](https://blog.dmatoso.com/build-static-site-generator-
nodejs-8969ebe34b22)

------
ausjke
I am using bootstrap+django+mysql still, may switch to vuejs but so far
bootstrap works well, no SPA needed, no JWT, no K8S or Lambda etc.

------
zachrose
In 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)

------
dabockster
Depends on what you're doing.

Static site: Jekyll

Dynamically generated site w/o real-time updates: Django/Flask (depends on the
scope of the project)

Dynamic site with real-time updates: React \---------------------------

The general idea is old fashioned: keep the actual front end filesize low so
that the user/customer doesn't have to wait for their browser to process a ton
of JS.

------
OldSchoolJohnny
If you want to bring complex applications to market quickly then use .net Core
for the backend, Vue for the front end, Postgres for the db server.

We researched this to death recently and unless you have prior affinity or are
saddled with technical debt the time has come to ditch React, Angular and Node
for new from scratch development.

------
dmatesic
For short-lived projects (which tends to be mostly what I work on outside of
work), I'm using hyperapp/tailwind css on the frontend and node.js/restify on
the backend.

[https://github.com/dmatesic/starter-kit](https://github.com/dmatesic/starter-
kit)

------
mosselman
‘Simole website’ and ‘with react’, in my experience, is a contradictio in
terminis. At least relatively. Just use server-side rendered html with rails
as a platform and you will be building your actual website rather than hooking
library after library together into some unmaintainable mess.

------
bobbydreamer
My web hosting stack would be 1\. Backend nodejs, express 2\. Database if
NoSQL, Firebase/Firestore (Google Cloud Platform) otherwise Cloud SQL 3\.
Authentication firebase handles it 4\. Hosting - firebase handles hosting as
well. 5\. CSS, JavaScript and jQuery 6\. Vscode with prettier

------
barrongineer
Go with the Buffalo framework and Vue.

------
iddqd
A lot of the startups we build we start off with a Vue stack for the Frontend
and a Kotlin + Spring Boot stack for the backend, running on k8s and with
Postgres as a DB. Incredibly productive stack from day one and something that
can be confidently built upon for years.

------
konart
We are using
[https://github.com/jeremyevans/roda](https://github.com/jeremyevans/roda) as
a default Ruby framework right now, maybe will be using Go for some parts of
the service later

Vue.js for the frontend.

------
qaq
BE: Node, Express, PostgreSQL FE: React Node gets bad rap but it's a decent
option for many projects I deviate from Node if there are specific needs that
it will not meet. I was not a fan of node but grew tired of projects with
multiple languages.

------
ddomingo
Frontend

\- Angular

\- vanilla JS

Backend

\- Springboot

\- nodejs

DB

\- MySQL

\- MongoDB

HTTP server (if needed)

\- Apache

OS

\- centos

If the project is complex, Angular + Springboot are the best enterprise ready
frameworks I've worked with.

If it's a simple project. NodeJS with Express for simple API requests. And on
the frontend you rarely need a JS framework if the project is simple, not even
a CSS framework.

As for the databases, MySQL, in my opinion, is the easiest RDB and MongoDB is
a good all purpose DB.

------
boraturant
React, TypeScript, Latest ES6+/Webpack build system .net core on server VS
Code

------
tuesdayrain
Gatsby > Create React App in my experience. Routing is so convenient with
pages

------
petard
I know OP asked for it but how do you suggest a web stack without evening
knowing what the use case is? "Wanted to quickly put together a simple
website", sounds like html / css might be enough.

------
sandGorgon
Use gatsbyjs - it uses react under the covers (and you get the advantage of
the whole ecosystem). But it generates static html that you can just throw on
netlify...or even github.com and have a website up

------
sidcool
Angular with Typescript

Scala with Play

Postgres

Google K8S Engine

GoCD

------
salmonfillet
Not to hijack the thread, but I would be also interested to hear what stack
people use when dealing with requirements that historically have lent
themselves to using CMS's like Drupal.

------
vinitagr
Editor & Code Management: Sublime Text 3, Atom Editor, Bitbucket, Git

Backend: MongoDB, Node.js, Express, RESTFul APIs, EJS Templates, AWS S3, AWS
SQS, AWS EC2

Frontend: jQuery, Backbone.js, Vanila CSS, SPA Application.

------
mindcrime
Personally I use Groovy & Grails, usually with Postgresql. Recently I've
started using Hetzner for hosting since they have better pricing than a lot of
the other options.

------
thruflo22
Firebase hosting is good for static hosting with server side functions.

For a real backend, Phoenix (Elixir) is the new Rails / Django. Google App
Engine Elixir is a good place to deploy it.

------
nathan_long
I have my favorite choices, but there's a lot to be said for using whatever
you already know. Especially if you're quickly putting together a simple
website. :)

------
xatxat
I use this stack:

Frontend: React \- Unstated (or just setState) \- Axios \- Plain CSS (with BEM
notation) \- Create React App \- Prettier \- Jest

Backend: Node.JS \- Express \- Knex \- PostgreSQL \- Tape

------
darepublic
In the past I've used react/redux on front-end, node/Mongo on backend. On my
new project it's react-static, react with unstated for ui.

------
option_greek
If you want to make it real quick:

VueJS (front-end) + Some theme support (bootstrap/framework7) + FireStore with
Cloud functions

Oauth (google/facebook) for authentication.

------
mhd
For the backend, you _need_ something with a standard library. Static typing
and performance is nice, but if you have to pick-and-match every single little
detail where you have to interact with the outside world, you'll still end up
with more bugs, just outside of your own code.

So the "P"s of the "LAMP" stack of olden days might be a good first choice,
probably switching out Ruby for Perl (as much as that pains me to say --
modern Perl + Mojolicious is awesome, but if you don't know this yet, it's
probably too late).

Or C# / Java / Kotlin, if you've already got developers in this space or are
willing to pay more and able to adjust to more mature management styles.

Go is somewhere between those two, and so is my current somewhat-happy place
(old, but in a non-enterprisey org).

Node and Erlang/Elixir currently are good for some end points, i.e. if you
really need a chat module. For the whole backend, I've got my doubts.

For the frontend, as others have said, if it's "just" a website, pick a good
template system if you need to and just enhance it with some small javascript
if needed (fancy selects and pickers). VanillaJS if you've got good JS
programmers, jQuery if you just need fancy modules, (p)react if you need it on
your resume.

If you either need to go SPA or need an REST API for other consumers anyway,
writing the frontend in the devil's own language, 2015 edition might be
necessary. I'm showing my biases again by suggesting something that already
made a few choices, or you're bikeshedding again. One reason why React seems
to be immensely popular with trainers/coaches. Just buy their 13-part video
course and use their personal npms.

Sadly ember seems to be going the way of the dodo, ExtJS is proprietary and
paleolithic and Angular strikes me as having a serious case of Java envy
(which might be good. If you already picked that or C# for the backend and
Struts ain't enough...).

The happy medium in this space seems to be Vue.

For the backend, use Postgres. Model your data properly, before you get to the
shiny parts.

I'm not really happy with most of these parts, but that's webdev for you. The
last time I enjoyed web programming was with Smalltalk/Seaside, but there's no
going back...

For me, right now its: \- Postgres \- Go \- Vue (considering Nuxt)

But for simpler/side projects, I'd seriously look at: \- SQlite \- PHP or
Python/Flask \- preact/htm for enhanced widgets

(And I would probably do the latter if I hadn't done Catalyst while everyone
else was learning RoR)

------
johnymontana
GRANDstack: GraphQL, React, Apollo, Neo4j Database.

The neo4j-graphql integration allows you to drive everything (including the
database) from GraphQL type definitions. Resolvers are auto-implemented so no
need to write boilerplate CRUD operations just to get your app up.

There’s a starter project here that bundles everything together:
[https://grandstack.io/docs/getting-started-grand-stack-
start...](https://grandstack.io/docs/getting-started-grand-stack-starter.html)

------
andybak
Web "sites" or web "apps"? The optimal solution for one end of that spectrum
is very suboptimal at the other.

------
wyem
Front end: Vue/Vuex, Bulma and Nuxt. Static site generation by Nuxt and
hosting on Netlify.

Backend: Self Hosted headless CMS such as Strapi

------
ergo14
On backend I would use Pyramid Web Framework (python), on frontend I would use
lit-html, stencil or svelte paired with redux.

------
wilsonnb3
Judging by the answers in this thread, the real answer is that it doesn’t
matter what you use. Most tools are good enough.

------
BjoernKW
Angular, Spring Boot and PostgreSQL, in case there aren’t any requirements
that call for more specialised technologies.

------
Chloro
React in the front, Node in the back (or Golang if you need extra
performance), postgres for DB.

------
ctulek
React, Apollo Graphql client/server, Node.js, knex.js (no orm), and Postgresql
on Heroku

------
G4BB3R
Nodejs and React for small projects, Elm and Elixir/Phoenix for medium/big
ones.

------
pumaNpl
Frontend: Vue.js Backend: PHP- Laravel Framework, Redis Database: Postgres

------
bytematic
react & redux with typescript, firebase for authentication & hosting, database
depends on the application. prettier & eslint. optional: commitizen for git
commit standardization

------
icco
\- Golang + Graphql on the backend

\- React + Apollo on the frontend

\- Postgres or some other database

------
dsego
Check out realworld.io, like TodoMVC, but for full stack apps.

------
rbosinger
RumseyJS with direct connection to either AstonDB or Sabino.

------
mortond
If you want SEO: Netlify, Netlify lambdas, Gatsbyjs, React, Firebase
authentication, Firebase db.

If you don't need SEO: Heroku, NodeJS, React, Firebase authentication,
Firebase db.

Misc: VSCode, Prettier, ESLint, Jest, Material UI, Enzyme

~~~
lurcio
Solid recommendations - anyone can get a long way fast with Gatsby/Firebase

I'd only add NextJS as an option for the runway it offers and
Meteor/Apollo/AWS as an alternative in that case.

------
buyholdsleep11
the most interesting competition seems to be node+typescript vs Java/Kotlin,
JVM stack. hard to say which one will be more popular in future

------
OutThisLife
Next.js + Apollo/GraphQL tied to Mongo

------
letorruella
Django and Vue CLI

------
ai_ia
Meteor + React + MobX + GraphQl + MongoDB

------
OffTheRails
I've been in full-stack development for about 10 years (most freelancing, 3
years full-time). I started with HTML/CSS, PHP, Ruby which I spent a couple
years with before getting a full-time Ruby job. Since quitting my job 12
months ago to work on my own projects (while part-time freelancing), I decided
to venture into a bunch of technology I'd not used.

I started to build a service in Elixir but found it lacked support for some
crucial aspects (http/s tracing in this case). I've found it to be a very
enjoyable language to work with (not just the Ruby bias talking), and a great
cushion into functional programming.

Over there I've seen mention of Drab and Phoenix LiveView which piggyback on
excellent websocket multiplexing to create an event channel between Elixir and
JavaScript. This essentially means you can interact with the frontend of the
application from the backend framework. There is a lot of discussion around
performance/security implications, of course, but it is a great experience if
you're backend driven.

Where Elixir couldn't meet my demands, Go did. It has `http/trace` in the
standard library. It has static typing, it's fast, simple. Go has worked
perfectly here as an "agent" of my main service. It is used purely to make
requests and spit out results. I've found it much easier to deploy than Elixir
(which usually involves distillery). Static typing in Elixir is often done
through Dialyzer (annotated type-checking). In short, I'm saying I need both
and that they complement each other.

I use a message broker to speak between the main service and the agents.
Because I was using Elixir for the core service, I went with RabbitMQ. I've
found that working very well on very modest hardware, and it is has been a big
help having a well-known messaging standard to work with with available
clients in different languages. To note - I only use this internally. Not sure
if I'd expose this publicly in any way.

The database is always Postgres :P I use that with wal-e for backing up to s3.
Still unsure on clustering. This is on a VPS because RDS and any other managed
Postgres service was charging way too much for the hardware. With clients I
would use RDS from the beginning.. and I would use Postgres as a document
store before reaching for Mongo.

For managing servers, I either use the cloud provided cli (gcloud) or ansible
on my own. I try to make sure I only ever use ansible to provision and modify
them and everything is version controlled. This way I have a record of any
changes I've made. I used ansible to setup wal-e backups on my Postgres
instance. I'll also use it to setup clustering.

Other great tools on that may be Chef, Puppet, Terraform. Leaning more towards
Terraform as it is agentless and declarative.

For application deployment I'm very much containerised. I've found Docker to
have greatly simplified my deployment process once Docker itself is installed.
As for clustering, Swarm is simple to setup. I was lured by Nomad, but I've
decided to fully invest into Kubernetes instead.

I spent a good 4 months trying to setup a Kubernetes federation (cross DC) on
a budget. Not easy. It was very painful. Best on my own was through Rancher
after trying kubespray. Best in the cloud was through GKE. However, not happy
with Google's pricing considering what else I can get. Digital Ocean released
a Kubernetes offering and I can fire up a one node cluster (with free master
plane) for $10/m which has 2gb ram on an ssd. For comparison, I think Google
were charging me about $20+/m for 1.6gb ram with no ssd.

Within 10 minutes I can have a new cluster. I can apply my manifests to the
cluster which have security policies, environment secrets, deployment
strategies, health-checking. I can deploy my applications to it within minutes
and easily integrate it with my CI/CD pipeline. I'm sure I could achieve
similar with some cloud-native offerings (Google App Engine, etc), too, but
I'd rather invest in something cloud-agnostic.

.. that's before even touching the frontend.

I decided to jump into TypeScript and VueJS. I'm still looking for that
"unified" environment where all the layers and processes just seem to fit
together. I've found the frontend ecosystem to be far too fragmented.

I don't see much point in creating any more complexity than VueJS already has.
I use Haml for templating, SASS for extending CSS. Still unsure on a
component/style framework. I think possibly Vuetify.

With all that said, my GO TO stack will eventually look like this:

* frontend: TypeScript/VueJS

* backend: Ruby, Elixir, Go

* database: Postgres

* message broker: RabbitMQ

* packaging: Docker

* container orchestration: Kubernetes

* CI/CD: Gitlab

* monitoring: Prometheus/Munin/Cloud tools

* logging: ?

* exception management: Sentry

* email: SendGrid

..man, could probably go on. It is never ending! I also think this is largely
dependent on the size of the project. However, I still use those tools above
on small projects because it forces me to become more familiar with the tools
which I inevitably use on more important projects.

------
oblib
I'm using the Apache Web Server and CouchDB as a backend along with
PouchDB-(with a few plugins), jQuery, and Bootstrap on the front end. Apps
built this way run almost entirely on the client side.

On the server side I use Perl to code whatever few chores I need there.

It's probably fair to say React is a good alternative to jQuery but I've yet
to find a compelling reason to spend the time learning React as opposed to
getting stuff done with what I already know.

In the end it's really all about productivity and after spending some time
with most all the tools mentioned here looking for what was "best" I decided
instead to look for what was "easiest" and ended up with the above "stack".

I just released a blog app made with these tools that's distributed in a 10k
"blog.html" file that will run on any web server. Nothing else needs to be
installed on your server to run the app. You can get it Azartiz.com along with
a secure CouchDB backend and upload it to your website to check out how this
approach works.

It demonstrates a "single page", run anywhere app, with user authentication,
CRUD, full text search, user and admin accesses, and shifting the load of
dependencies to 3rd party CDNs to reduce loads on the server hosting the app.
Adding "Service Workers" to make it run "Offline First" is a snap using
Google's "Workbox" toolset.

I believe the learning curve to use CouchDB as a backend is the main reason
most developers have shied away from this approach. They're kinda "stuck"
using SQL and haven't realized how much easier it is to build an app that uses
a backend DB designed from the ground up for "web apps".

But... it's really easy to dip you toes in it now using the Azartiz backend
and that blog app on your server. PouchDB.com also has a "Todo" app demo that
can be plugged into the Azartiz CouchDB backend that you can learn with and it
demonstrates a somewhat different approach than the blog app and CouchDB's
"live sync" features that are really cool.

There's also CouchDB backend services available at Couchbase
([https://www.couchbase.com](https://www.couchbase.com)) and Cloudant
([https://www.ibm.com/cloud/cloudant](https://www.ibm.com/cloud/cloudant)),
and CouchDB is pretty easy to install on a vps service like DigitalOcean.

Plus, you can install CouchDB on a desktop Mac, Windows, and even a Raspberry
Pi, and use it to create backups and snapshots of your remote CouchDB
databases, and of course, to develop your apps.

This is an amazingly powerful, flexible, and easy to get and use stack. I've
never been as productive with any other toolset. But I didn't have any love to
lose or time invested in using SQL backends. That's a lot of baggage to leave
behind for most developers.

------
tmsh
\- org mode (including org-publish, org-babel and integration with clojure);
use this to generate static html and publish to s3; use this to generate
literate programming of your AWS environment:

\-
[https://github.com/mcohen01/amazonica](https://github.com/mcohen01/amazonica)
with CIDER (in emacs) all set in a literate org file for setup (but still
customization). So it's easy to ramp up new websites and web services.

\- for advanced compute, deploy clojure to lambda or ec2. for simple compute,
deploy node to lambda.

\- for authentication and other boilerplate web services, use the aws services
that exist. to deploy, again use literate org files (org-babel) and upload
your jars where needed.

\- you have to invent as you go along (for inspiration i like
[https://www.amazon.com/Everything-I-Know-Paul-Jarvis-
ebook/d...](https://www.amazon.com/Everything-I-Know-Paul-Jarvis-
ebook/dp/B00GRBIFH6) \- just started reading it last night, new book coming
out soon), but it's more fun and efficient that way.

The most efficient stack is probably [you] <-> [20% elisp] <-> [60%
clojure/cljs] <-> [20% html and js]. A good set of learnings for understanding
how to get started with AWS services (without the clojure/cljs/elisp part) can
be found in:

[https://github.com/aws-samples/aws-serverless-
workshops](https://github.com/aws-samples/aws-serverless-workshops)
[https://github.com/aws-samples/aws-modern-application-
worksh...](https://github.com/aws-samples/aws-modern-application-
workshop/tree/java)

As a caveat, this is what I'm exploring currently. This is what I'd love to
work on (now unfortunately I gotta go back and do my normal day job stuff that
I didn't finish last week, and then some husbandly errands and things). But if
I had time, I would continue to grow in this area. You can briefly read about
my journey to emacs in the past several months under Emacs here:
[https://github.com/tmsh/home](https://github.com/tmsh/home) (c'est la z's
tutorials + evil mode + clojure/conj presentations are really useful). I
haven't found any of the cloudformation or serverless frameworks easy to use
(but maybe that's just me - kinda slow to start). But I'm optimistic about org
mode + amazonica.

But don't take my word for it! Probably the most senior engineer in the entire
world uses org-mode
([https://www.reddit.com/r/emacs/comments/a2smk0/emacs_and_org...](https://www.reddit.com/r/emacs/comments/a2smk0/emacs_and_orgmode_in_the_new_yorker/)).
And the guy who wrote HN originally was a fan of repl-based development as a
strategic advantage
([http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)). If
you don't like parentheses, you haven't been staring at the screen long enough
so that they fade away (or use
[https://www.emacswiki.org/emacs/DimParentheses](https://www.emacswiki.org/emacs/DimParentheses)).

You have to learn the underlying target languages (JS, HTML, CSS, Xcode+Swift,
Android Studio+Kotlin/Java; i.e., develop in emacs, press run in Xcode/AS)
through various paths. And then you learn to program the programming of them
with org mode/org-babel and to iterate faster with clojure and cljs. That's
the growing theory.

------
jillesvangurp
I'm a backend developer (Java/Kotlin mostly) but I also spend a lot of time
dealing with other people's frontend code as well. I'd recommend not being too
dogmatic and look at requirements and also look forward a bit to 1, 2, and 5
years down the line. My main message is: things are changing and a lot of
stuff that seems right now may seem backwards not to long from now. This is
more true on the frontend than on the backend.

The vibe I'm picking up lately is that react + typescript is not completely
horrible for frontend development and my impression is that I can hire people
to work on such projects. Nothing wrong with this stack. A solid conservative
choice. But what about five years from now?

Some trends that I'm picking up lately that could start changing web stacks in
the next five years and should be kept in mind when choosing stacks right now:

\- Statically compiled languages are now a thing on the frontend. Most of the
senior frontend people I know are very opinionated about which transpilers and
tools they use but writing "native" javascript seems much less of a thing then
it used to be. E.g. Typescript seems popular now. Just a few years ago I would
have seen a lot of people pull up their noses for e.g. coffeescript but
typescript seems to have broken through that. Probably for a new project, you
should go statically compiled from day one across your entire stack from day
one.

\- WASM and PWAs mean that most current javascript frameworks will not be the
only game in town for developing complex UIs in browsers. I'm seeing a lot of
activity around Kotlin and Rust lately and they are looking to provide full
end to end solutions that effectively replace large parts of the stacks that
were common in the last decade or so across web, desktop and mobile
development. People seem to dislike things like Electron, yet it clearly fills
a need. WASM and PWAs take that to the next level.

\- This also means that fullstack no longer means node.js and browsers: other
languages are now becoming full stack. For example, Rust is a proper full
stack language and you can do anything from OS kernels to browser apps in it.
Likewise, Kotlin can compile to the jvm, javascript, wasm, and native code. C#
and a few other languages are also moving into browsers. This means javascript
or transpiled javascript are not going to be the only way to do full stack in
the next few years. This also means that new frameworks more appropriate to
these languages will start competing with e.g. React. I recommend keeping an
eye on this space but being conservative in rushing in as a lot of this stuff
is changing rapidly.

\- VS Code seems to slowly bring frontend work out of the stone age where it
has been stuck since the decline of the likes of Visual Basic, Delphi, and
other IDEs for UI work in the late nineties. Code completion, real time
feedback about syntax issues, and even some refactoring support are now
possible. It's still horribly primitive to what I'm used to for backend
development. But things have improved a lot since VS Code came out. Using
editors that don't tell you your code is broken still seems to be a bit of a
macho thing. But these days there is much less excuse for committing code that
demonstrably is syntactically incorrect, has unused/redundant code, imports,
etc. Or includes things that obviously won't work as intended. Whatever you
pick, make sure there is awesome tool and IDE support for it.

------
grey-area
Go

------
masa331
rails

------
konyli
ok

------
Toutou
For a smallish project we're using Rails + PostgreSQL with just Bootstrap for
the UI. With TurboLinks and remote actions that respond with JS snippets the
site feels fast enough without all the weird SPA machinery.

------
fxfan
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.

~~~
virtualwhys
> 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).

~~~
fxfan
Sorry the kind of work I do doesn't need spa.

I use Scala.js for plain well written client code.

If you're into spa, there's also monix, outwatch and a few others I think.

------
ArrayList
HTML, CSS, and JavaScript ;-O

