
Ask HN: Starting a project today, which web framework would you use? - betimd
If you will start your project today (medium to large application) which web framework technology would you pick:
- Asp.Net Core 
- Node + Angular
- Node + React
- Django or Flask
- Rails
- Laravel or Zend 
- Play Framework
- Other
======
sharmi
My usecase is mostly side-projects that I want to take to the market. So I
stick to Django.

Why?

* I am already familiar with it's advantages and quirks. So I can get running faster. The knowledge that I have accumulated in my previous projects will be handy to get going. Time to market is important for both validating the product and avoiding a burnout.

* There is a well defined way to do most common stuff. So you need not experiment and reinvent the most basic stuff. All those get out of the way and I can concentrate on the meat of the problem.

* Many libraries like auth, rest framework are battle tested and most likely tested for security vulnerabilities. if you are taking something to market, it is in everybody's best interest to ensure security is taken care of by the pros. Django is solid in that aspect.

* Though python may not be the most performant language (I have been bit by that a lot in data processing) it is still fast enough for websites with normal loads (which is 99.999% of today's websites).

* If I do have a performance bottleneck, there are lessons from pioneers on how to optimize it.

For me, django fits all these needs. For you it might be Rails, Node, Play or
Phoenix. I used to want to learn Phoenix and Play.

But I realized it is a no-win situation when you mix a brand new tech with
brand new product.

Now I reach out to new tech only if it fixes a sore need that my existing
toolkit cannot handle.

For example, I am looking into webpack and purifycss, because django does not
have the necessary functionality to trim the fat in bloated CSS, while Node
stack excels.

If I work on a interaction heavy front-end, I might reach for vue or react,
and that too only if I really need it.

Else, I am quite happy with django/vanilla-javascript/sass/bootstrap(for
prototyping)

~~~
sjellis
This is really solid advice, I think.

Either you are building something for learning, or you are building something
to ship it, and it's better not to mix the two. If you are building something
to learn new technology, then use whatever that excites you to make something
that you won't feel guilty throwing away.

If you are building something to ship, then you should preferably use nothing
that you haven't already used before. You'll still improve as a developer,
because you will get better at technology that you have already invested in.

------
Existenceblinks
Frontend: Elm

Backend: Rails|Phoenix

Database: PostgreSQL

I don't understand why people still write javascript except legacy codebase
maintenance although I respect everyone's freedom. Especially, sorry,
React/Redux why? Yet, people are obsessed managing state on client (browser),
that's the bad days of whatever framework including Elm. 90' Game developers
would wonder too since they often prevent corrupt states from bad people was
trying hard to mess (cheat) game states, thus source of truth and constraints
must only live on server. States on front-end must be just something only for
sake of displaying.

~~~
devopsproject
You are conflating two ideas.

Game developers protect state to prevent cheating. For example, allowing a
player to update his location could allow teleporting or spawning tons of
bullets\projectiles

If a web developer creates an IM webapp, why should they care if you modify
your local copy of the message data? It only affects your session and the next
time you get a copy of the message it will be the original. All other users
are still seeing the original

~~~
Existenceblinks
I don't see any of what you said is opposite to what I said (Local message is
just for sake of displaying)

I think we meant the same thing.

~~~
nkristoffersen
"Global" state should live on server. Only local state lives on client. I'm
not sure how you are against react, angular, etc, since they only manage
"local" state.

~~~
Existenceblinks
I know any framework or any single line of code on client is all about "local"
state. But when people lost focus they _potentially_ couple business logics,
local truth and constraints with "Global" state from servers, and trust wrong
source of truth. And that might end up with next corrupted, e.g. POST,
requests.

~~~
sboselli
But then you're essentially talking about BAD code.

Bad code is bad; in any language or framework.

Don't blame the knife (in this case React/Redux or w/e), blame the person
wielding it.

~~~
pvorb
If the knife has a sharp handle, it _is_ to blame. Many frameworks have common
pitfalls. I've got no opinion where these are in React/Redux though.

~~~
Existenceblinks
> If the knife has a sharp handle, it is to blame

Agreed, this is a good example.

I am trying to avoid blaming React/Redux specifically because it's going to
end up with a blog post. Tree nodes communication, composition and state.

Imagine you have a 5-height tree, each node is an object that can receive
properties from its parent (hell yeah, lightly inheritance smell), that's not
that bad until all objects' methods (components' callbacks) execution orders
come together (hell yeah, lightly recursion smell in _imperative ways_ while a
normal recursion can be done in declarative way of thinking). Next turn,
Redux. Connect a store to any level of tree you want, ahh that sounds handy
but I have no ideas who setState, when and where. Saga|Thunk hmm this is
slightly better since it is a separate middleware but wait, it's not
completely isolated, anything _available_ for you there; Dispatch, Store,
setState etc. Finally, all these built on top javascript ahhhh I personally
suck at orchestrating these things.

------
deedubaya
Everyone is posting layers upon layers of components and frameworks. It just
seems so bloated, so hostile towards the developer.

From my experience, the more independent projects you include, the harder an
application will be to maintain, let alone configure and build. Am I just old
and cranky? Or is there reasonable justification to do this?

~~~
devopsproject
> Am I just old and cranky?

No, but you may be a bit too optimistic. By the time you hand craft your CSS
and Javascript to support all the browsers and features you need, you will
have created yet another framework: deedubaya.js

> Or is there reasonable justification to do this?

The browser was meant to display documents. We keep trying to make into an
runtime environment.

------
yeukhon
1\. Django 2\. Pryamid 3\. Flask

I used to use Pyramid for everything unless I needed forms and UI then Django
is a no brainer choice. But I stopped wanting to setup SQLAlchemy and writing
bootstrap codes for managing test states etc. I still love Pyramid because of
its flexibility, but perhaps I need to invest time in the plugins to see if
there's anything quality to support SQLAlchemy integration much like Django's
ORM out of the box, and whether there's quality test integration out of the
box much like django test command. Flask I have a love & hate relationship
too. I feel like the community is too lose. I used to write Flask apps but
back then half of the recommended libraries/projects would not have updates
for months. I can't trust code that isn't widely adopted and widely used,
because I don't want to be the only one filing bugs. At least Pyramid has
built-in Authentication modules that you can use, but Flask I'd have to rely
on the community project which to be really honest, I am not sure if I want to
trust it in the long run. So these days, I fall back to Django first, Pryamid
second, then Flask finally (especially convenient for quick projects).

I don't really do any front-end development because I totally not good at it,
so I gave up ~3 years now. But I would look at EmberJS and React.

------
scarface74
* What I would _not_ use is any language that is not statically typed. The compiler can catch an entire class of errors and there are great tools for automated refactors. For me this narrows down my choice of languages to C#, TypeScript (Node), and if really necessary Java. But today I would probably use Kotlin instead of Java if possible.

* Technology is a means to and end for me - to get stuff done and to remain marketable. So I would probably choose the front end framework that is the most marketable. Which seems to still be Angular. Two advantages - when it's time to switch jobs I have more choices and when I'm looking for contractors to come on to projects that I'm over, Angular coders are a dime a dozen.

That being said, I'm really finding the combination of Bootstrap + JQuery +
Handlebars to be refreshing for non-SPA websites.

* Databases. If I'm spending other people's money, I prefer SQL Server/Entity Framework as an MS person. When NoSql is the right choice, SQL Server has pretty good support for JSON. It really is the best of both worlds.

If I'm spending my own money or don't have a budget, I would probably choose
either MySQL (relational) or MongoDB (NoSql)

* I know this wasn't part of the question, but for hosting, AWS all of the way and I would use as many of their services as possible except for DynamoDB. It just feels a little odd.

* And to go even more down the rabbit hole. I would hate coding without my JetBrains subscription. Right now, I just have Resharper. But if I were doing this as a side project I would have the subscription that included everything.

~~~
runT1ME
If you're a MS/.NET leaning person, why not F#?

~~~
scarface74
Because:

 _Technology is a means to and end for me - to get stuff done and to remain
marketable._

I have never seen a job listing that wants someone who can do a web backend
with F#.

~~~
jon49
Fascinating, You'll use Kotlin but not F#.

------
1ba9115454
Rails. No question.

In my 7 years of using this framework I have come across nothing that comes
even close to in terms of LOC, ease of pickup and quality of the end product.

------
LouisSayers
Rails + JQuery + Postgres + Heroku

Why? It works. It's not gonna have crazy changes. It's simple. There are a
million relevant resources to help learn how to do x, or help you if you get
stuck. It's easy to hire skilled people that know this stuff back to front.

btw - you don't start a medium to large project. You start a small one, build
incrementally, and see what happens. If you have success, then you can spend
money building in whatever you like.

------
realharo
Depends on the project, but most likely just Node + express + TypeScript on
the backend (so no "framework" in the traditional sense).

On the frontend, React + MobX + TypeScript.

This of course means it would be a single-page application.

Benefit of using TypeScript on both client and server is that you get to
automatically share the schema of the data they're exchanging (and maybe some
more code as well, like validation). For free. And when you change the
structure of something - and you will - you get immediately alerted to any
issues on both sides (e.g. this property is now required, and you omitted it
in this function!). This is huge because maintenance is often more difficult
than writing the initial version - and I don't even mean the initial
_released_ version.

Also you get to potentially reuse some of the code in the future for a React
Native based mobile app.

I'm also eyeing GraphQL and Apollo a bit, but I don't have enough experience
with them to use them in a "real" project just yet.

~~~
GeneralMaximus
> Benefit of using TypeScript on both client and server is that you get to
> automatically share the schema of the data they're exchanging (and maybe
> some more code as well, like validation). For free.

How do you do this? Do you have a separate NPM package that just contains your
schema/validation code? Or do you keep your backend and frontend code in the
same repository?

~~~
realharo
Same repository, 3 different directories (client, server, shared). This also
makes it easy to have shared docs, dockerfiles, and other things needed for
the complete setup on any machine.

But you can also just do this with a git submodule for example, or any other
method that will physically get you the shared files there.

~~~
GeneralMaximus
Thanks for answering.

I've always wanted to try breaking projects down into separate NPM packages,
but I usually end up using git submodules. Path of least resistance and all.

~~~
realharo
Not sure what you mean by NPM packages, but I don't publish anything to NPM
(not even a local repository).

On the other hand, the client and the server obviously each have their own
package.json, with their own dependencies, etc.

~~~
GeneralMaximus
> Not sure what you mean by NPM packages, but I don't publish anything to NPM
> (not even a local repository).

Break your applications into separate Node modules and publish them to a
private NPM.

Now that I type it out, it sounds like more trouble than it's worth.

------
TurboHaskal
Mojolicious (Perl), Spring Boot (Java / Kotlin) or plain Go. Depending on
productivity, performance and hardware constrains.

If it's the typical CRUD site I'd use Django (Python) if I worried about
finding developers, otherwise sticking to good old Catalyst (Perl) or perhaps
giving Phoenix (Elixir) a try.

~~~
strictfp
Why Spring Boot? Just curious. I work with it daily and have grown to detest
it.

~~~
_pmf_
> I work with it daily and have grown to detest it.

What exactly do you hate? (I feel weird liking Spring quite a bit, and would
like to get in on the hatin' ...)

~~~
strictfp
To be as concise as I can, I would say that Spring Boot is a framework which
minimizes the amount of "code" you have to write at the cost of everything
else.

And this means that it's hard to understand what is going on under the covers,
hard to debug (partly due to metaprogramming bananza), slow to start, uses too
much CPU, uses huge amounts of stack, has all bells and whistles turned on by
default etc etc. It gives you all errors at runtime. Encourages you to make
your app too configurable (hard to test all configs). Reimplements a bunch of
tools and libs badly (like one-jar). Its also intrusive like all frameworks.
Requiring a custom test runner is not a feature, Spring! For these type of
reasons you cannot easily integrate it with other frameworks.

And that is just from the top of my head.

~~~
giobox
> "all bells and whistles turned on by default etc"

Arguably a little unfair? Spring boot makes it pretty trivial to just pick and
choose the components you need for a project, especially with the
[https://start.spring.io/](https://start.spring.io/) tool.

> Requiring a custom test runner is not a feature, Spring!

I'm guessing this is a reference to using Spring's test runner to support
Spring's dependency injection mechanism? No one forces you to use this so it's
a stretch to say its 'required', but for certain tests it will save time over
manually mocking etc, and often only applies to integration tests anyway. You
can absolutely unit test without it.

> "It gives you all errors at runtime."

I'm sure it does, if you have errors.

> "Encourages you to make your app too configurable"

Spring boot apps are only as configurable as you make them, much like any
other application. At least Spring tries to provide a standardized
methodology/pattern for externalizing configuration parameters. I fail to see
the 'encouragement'.

> you cannot easily integrate it with other frameworks.

It's java at the end of the day - there's a ludicrous number of third party
frameworks it will play nicely with.

> slow to start, uses too much CPU

Sure JVM applications rarely have 'instant' startup for various reasons, but
is a handful of seconds really a problem? 'Uses too much CPU' \- I don't
really think this is fair either - Spring Boot applications can deliver very
efficient solutions.

Not going to argue it's the perfect choice for every project, but no framework
is.

~~~
raudbjorn
Isn't spring boot "thread-per-request"? Some people care about that kind of
performance-related stuff.

Also, I think "It gives you all errors at runtime.", should have been "It
doesn't give you the errors other frameworks are able to give you at compile
time." -and I kind of agree, if memory serves "Spring" is sort of synonymous
with "reflection", which isn't exactly performant either.

EDIT: Wow, just read my comment and realized it comes across like I really
hate Spring. I don't, I think it's nice. It's great for web apps that have
human users; for services that are consumed by other services, I would
probably go for something else.

~~~
polotics
Spring? If you need Java DI you will find Guice fixed the warts.

~~~
penetrarthur
Does it have Auth and so much more Spring has to offer?

------
jetti
Phoenix (Elixir) for the backend because I started with Elixir this year and
really enjoy it. If the app was simple enough and I was feeling up for a
challenge than maybe just Erlang directly with Cowboy (so no real framework).

For the front end: Elm or maybe Ember.js. I started learning Elm this year too
and like it but I possibly would go Ember because it seems interesting and
since I have a membership to Daily Drip I have free tutorials on Ember (as
well as Elm and Elixir)

------
richardknop
Django if front end is complex (lots of forms, complicated templating, need to
have a free admin interface for out of the box).

Or if the front end is simple, I'd just write it in Go using core net/http
library.

To make it more maintainable, I'd probably split the application into two
components, so backend could be API written in Go and front end a Django app.

------
borplk
Node + Koa + React (server side rendering) + ReactRouter + Redux + TypeScript
+ Postgres

Not because they are so great but because everything else is even worse.

After significant React experience I can no longer tolerate send-html-
template-sprinkle-javascript stacks.

The downside is that the amount of boilerplate is unbearable. There's
significant friction in the tooling because of transpiling, sourcemaps,
multiple layers of sourcemaps, file watching, having to produce multiple
different bundles for server side rendering, client-side bundle and so on,
testing with transpiling is a pain, test coverage with transpiling is at times
borderline impossible, proper isomorphic data-loading is difficult and the
list goes on. Still prefer it to the other stuff.

~~~
Xeoncross
> The downside is that the amount of boilerplate is unbearable.

This is often a deal-breaker for smaller projects where the whole team is not
used to all the tooling.

~~~
borplk
Even if they are extremely familiar with the tooling it's still a huge
problem.

People get seduced by unrealistic examples online and think "oh easy just drop
this little config thing here and done".

The problem is the little things pile up on top of each other before you know
for a production app you are deep into plugins and transpilers and configs to
your knees and you have to make them all play with each other.

Just some examples of difficulties of this architecture,

\- You must have an API for doing anything because the client-side needs the
API, but on the server you also have to use the same code for server side
rendering. It gets more fun because you have to deal with authentication as
well on both sides. So you will have to "proxy" the cookies from the client on
the server side to the API to load initial data for server side rendering.
This is full of gotchas and largely undocumented it will take you at least
multiple days to get right.

\- Data loading for client-side navigation is tricky. At what point do you
fire ajax calls to load data for the destination? Sometimes multiple calls are
needed. With react router you'll need a custom "Link" component with data
loading functions that produce promises then you can do Promise.all on them
and transition when ready. For a good experience you have to incorporate
timeouts. In my case I immediately start loading target data upon link click
for navigation, wait up to 100ms ("navigation wait tolerance") and if things
are not done by then I navigate to the target in a loading state and the page
re-renders when data is loaded or error happens and error is displayed. Again,
full of gotchas.

\- Need an admin panel? well you better not have any potentially sensitive
text on your admin pages because guess what that ASCII text is going right
into your javascript bundle. This is a minefield if you don't want to be
leaking your admin UI and capabilities. At this point you will need to have a
separate admin bundle that is not given to normal users. Good luck with that.
You can't just "add" it on top of the normal bundle (too hard to explain, try
it and you'll find out). So it needs to be a complete application bundle that
is built for admins. But well if you want the admins to go through the normal
login page like all the other users ... gotta switch somewhere in there.

\- Testing? Forget about all the usual CLI tools like
mocha/jasmine/ava/jest/etc... they will all blow up one way or another when
facing a sufficiently complex application with webpack/jsx/transpiling/etc. So
you have to have another "test" bundle that imports all the tests, you have to
transpile and build that bundle then execute it with a test runner. At this
point all the usual tools for test coverage become nearly unusable.

\- Server side rendering: since your client-side stuff like React components
are also needed on the server now you need to be building a server side
rendering bundle and then you have to constantly keep running the output of
that build so your server-side-rendering during development works correctly.

These problems will interact with each other in complex ways you can't just
solve them separately one by one. Each one you try to fix will create other
compromises or problems in another area.

In summary, it's an absolute cluster fuck and I challenge anyone who think
it's easy to do a non-trivial project complete with user
signup/login/logout/admin panel/authentication/authorization/roles/server side
rendering/tests and come back.

And with all of this bullshit I still prefer this to the old(er) way of jQuery
event handlers and so on.

At some point I got so fed up with the problems I described earlier I tried to
go back to the old stuff but I couldn't tolerate it anymore so I came back and
accepted the new nonsense.

Mind you it has improved a lot since the last year as well. Especially with
the newer versions of React Router.

~~~
cutler
Sounds like you might like Clojurescript + Reagent which is based on React but
with much simpler tooling (Leiningen). You can also run Clojurescript on Node
now with Macchiato ([https://macchiato-framework.github.io](https://macchiato-
framework.github.io)). If you need something CPU-heavy you can hook it up to a
backend API written in Clojure. Turtles all the way down :)

------
pleasecalllater
I think there is just one sane choice: I'd use the one that I know best, and
the one that has huge number of users (which means it's more battle tested).

In my case it would be Django + PostgreSQL.

------
mobitar
There are pros and cons for each.

React: once you get the framework down, it's a lot easier to build a native
mobile app with React Native. There's no Angular Native.

Angular: powerful and abundant. A little different, but flexible. Answers on
SO for every little thing that will come up to ask. Not sure if newer
frameworks will have that same luxury.

Rails: a lot of convention. But once you get it down, you'll be able to build
complex apps in little time. Also a lot of community support and search engine
presence.

If it helps, I've open-sourced all code around Standard Notes. It's mostly a
Rails/Angular stack.

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

~~~
rpeden
I agree with what you've written, but just wanted to note that Nativescript
provides a React Native equivalent for Angular 2/4+.

I still prefer React Native overall as more people are using it and the
ecosystem is bigger, but using Nativescript with Angular was surprisingly
pleasant when I first tried it out a few weeks ago.

------
smilesnd
If I was to start a project today it would be Elixir using cowboy and plug. I
like to keep things simple. If I thought the project was more on the medium
size I would probably use Asp.Net Core. For the frontend I like to stay
vanilla and use bare bone so html/sass/typescript with maybe jquery if needs
be. Postgres for my database needs.

------
gtf21
Frameworks? none.

Technologies? node.js + express; postgres; react + redux

Why? Speed and flexibility of development (although tbh this is just about
what you're used to), using the same language on both ends, and I really like
js.

~~~
astrogator
Help me understand why react+redux would not be considered a framework?

~~~
gtf21
See this comment:
[https://news.ycombinator.com/item?id=14422926](https://news.ycombinator.com/item?id=14422926)

------
metachris
Backend: Django as soon as you want an admin interface for your models. It
just saves so much time, and nobody enjoys writing those dumb CRUD routes. If
you don't need an admin interface and want to stay in Python, I'd recommend
Flask. Else I'm also enjoying Node.js.

Frontend: Vue.js or React.

------
harel
Backend: Django (Python 3.5+). Yes flask might be lighter etc, but at the end
of the day, when you need to do things quick, batteries included approach goes
a long way. Also, it will be easier to find developers who can hit the ground
running. Most of the time, I would use it for an API layer coupled with Django
Rest Framework.

Database: PostgreSQL 9.6. That's easy. You get the best of all worlds here.
RDBMS with indexable JSON document store. Stable, fast. There is no other
choice for me.

Front end: Depends. React/Redux works for me 80% of the time. I prefer to use
Semantic-UI (the React port is excellent) for the presentation. The other 20%
are simple admin only apps where plain old html would do just fine. I now try
to avoid all-in frameworks which tie you in like a Catholic marriage.

Async: Celery + RabbitMQ. It works, and works very very well as a background
task/job runner.

Source control and Project Management: Git and Github.

Specialised system apps - Go(lang). For fast specialised servers, websockets,
etc.

Deployment/Provisioning: Ansible.

Bonus points: Personal Development: Learn a new language every year. Do a
little project in it.

------
thiagooffm
Rails: stable ecosystem, just heroku it

~~~
betimd
The selection is because of rails or heroku?

~~~
thiagooffm
Both. It's easy to develop and also to deploy, which is something you want in
a project.

------
ryanom
Django has a lot of nice things that come with it and you can get a project
setup in a flash using CookieCutter-Django:
[https://github.com/pydanny/cookiecutter-
django](https://github.com/pydanny/cookiecutter-django)

------
strictnein
Other: the one you're most familiar with

If you're starting up a new project, choosing the "best" framework vs the one
you're most familiar with is going to make everything that much more
difficult. You're going to learn something before you can build something? And
build something more slowly because you're trying to learn something?

My untrendy answer:

    
    
       Frontend: Backbone/Bootstrap
       Backend: Node
       DB: Postgres or Mongo
    

If you don't know those things, then this isn't the right answer for you, but
whenever I start up a new little project in my spare time and utilize
Backbone, it's like a breath of fresh air, compared to most of the current
popular frameworks and what we have to use at work.

------
renke1
My current stack:

Backend: Go (standard library mostly, httprouter, and some homegrown libraries
for stuff like dependency injection, configuration etc.)

Frontend: TypeScript (with React and Redux/mobx)

Other than that, I think using something like Kotlin, Swift or Elixir could be
interesting in the backend, too.

~~~
amorphid
I really like Elixir. Learning to write & test concurrent code has certainly
been adventure! It's probably been a good warmup for testing microservices.

------
bussierem
I've created a list of every technology (language, framework, DB, etc) posted
as of 0913 May 22: (This list may contain some overlap, since I don't
recognize like 75% of these names)

Elm, Rails, Phoenix, Postgres, React, MobX, Typescript, GraphQL, Apollo,
Kotlin, Mojolicious, Sprint Boot, Go, Django, Catalyst, Node, Koa,
ReactRouter, Redux, C#, Bootstrap, JQuery, MongoDB, Express, Vuejs, Flask,
Swift, Elixir, Cowboy, Plug, Asp.Net, Heroku, Tornado, SQLAlchemy, Celery,
Clojure, Ring, Compojure, ClojureScript, Reagent, Knockout, Meteor, Haskell,
VanillaJS, ReasonML, Tachyons, Flow, Redis, EventStore, Suave, Python Bottle,
Preact, Play (Scala), Sanic, Loopback, Werkzeug, Laravel, AngularJS, EF Core,
Dapper, Vert.x

------
tarboreus
Try lightweight. Flask, Skeleton, and sqlite. Don't use SQLalchemy until you
need it. (Hint: you probably won't need it.)

------
outsidetheparty
After years working in an Angular 1.x stack, I took a long, hard look at
Angular 4 and decided to make the switch to Vue.js (with firebase on the back
end). I'm happier and more productive with this combination than I have been
with any web development setup in literally decades.

Vue does everything Angular did for me without nearly as much cognitive
overhead. Working in Angular just felt like an endless stream of hidden
gotchas and idiosyncratic jargon; for the year or so it took me to really
start to feel like I had a handle on the framework it seemed like the answer
to "How do I do foo in Angular?" was always "Don't do foo; do bar, baz and bat
instead, but make sure you don't quux, that'd be really bad". And even after
I'd more or less gotten used to the Angular Way To Do Things it always felt
like I was fighting against the framework instead of depending on it.

Vue just works. The component structure is really developer-friendly, it's
much easier to incorporate non-Vue code when you need to, and it all just
pretty much DWIM without you having to think about what's going on in the guts
of the framework. It took maybe two weeks of practice before I felt totally
comfortable with the system. Clientside performance is a zillion times better
than Angular; you don't have to pick through an entire freaking ecosystem of
secondary frameworks just to get started like you do in React; vue-cli gives
you sensible scaffolding and you don't have to spend much time fiddling around
with webpack and build configuration. Yeah. Good stuff.

Firebase I'm a tiny bit less unreservedly enthusiastic about -- don't get me
wrong, it's super convenient, and it's nice not having to spend much attention
on the network layer of my apps, but there are times I wish it were a little
bit less magic than it is: I can't always tell whether I'm using it
efficiently or not. And the tree data structure isn't appropriate for every
project; I kinda wish there were an equivalent with the same websocket live
data updates but backed by a boring old RDBMS instead of a JSON store. Plus,
you know, vendor lock-in is always a concern. For a mostly-front-end guy who
just wants to be able to store and retrieve data without thinking too much
about it, it's fine; I'm not ready to evangelize for it quite as much as I am
Vue though.

------
thom
Clojure + Ring + Compojure on the server, ClojureScript + Reagent on the
client. Because I don't know any better, and want to be punished the moment I
have to hire anybody.

~~~
cutler
Another server-side option is Macchiato ([https://macchiato-
framework.github.io](https://macchiato-framework.github.io)), ie.
Clojurescript on Node.js. The whole Clojure/script stack really deserves wider
adoption given that it arguably enhances React while reducing the insane
amount of JS tooling.

------
jon49
PostgRest with Mithril.js or Elm on the front end. Keep it simple. Or
WebSharper with SQL Server for a more integrated feel with static typing all
the way from the database all the way down to the front end. Studies have
shown static typing to be extremely important for removing bugs and programmer
productivity, and from what I've seen WebSharper would give the best
experience for that.

I've only used Mithril.js in those technologies though.

------
spapas82
Django for the backend with a postgres database. Just use django - I am using
it for around 7 years: never regretted it, always happy with my choice. This
is important to me and has not happened with other things I've used (like
spring mvc, jsf, angular.js, android dev etc).

I generally try to avoid complex front end stuff, in most cases a little
jquery and a datepicker are enough. If I need something more client heavy then
I'll always try the least complex solution - if jquery isn't enough then
knockout.js would suffice most of the time.

On extreme cases (UI heavy SPAs) I'd use react+redux with a django rest
framework backend. But only if it is absolutely required. I have measured that
using pure django (and friends like django filters, django tables etc) is like
5 times productive and 10 times more DRay than if you add client side/ajax
stuff to the mix (along with the required bloat like client side
tooling/weback, apis, auth, routing, client side models and forms etc).

------
anhtran
I may use many languages and frameworks in one project if needed. I will start
with Django because I'm good in that skill set.

------
sidcool
Play Framework with Scala. Very simple and super scalable.

------
npolet
It's nice to see all the love for django here. I've been developing with
django for many years now and I feel like more and more developers are finally
picking it up for various projects. It's remained very popular for quite some
time now. I especially love the django developers, as they really seem to put
out high quality releases that make updating to the latest version fairly
painless.

I would also opt for django, postures and react+redux on the front for any
complex hi needs. With django rest framework powering an API, building complex
ui's becomes less painful. I've yet to find something quite as powerful as
DRF.

Recently started a large commercial project 4 months ago and I'm seriously
glad I went with django.

------
out_of_protocol
Backend: Elixir, Phoenix, Postgres, Redis (All components proved to be rock
stable for me)

Frontend: Vue.js, ?, ?

------
marcus_holmes
Go (stdlib + gorilla/mux) + Postgres + React/Vue/Vanilla depending on need

------
dexterchief
It feels like the constraints/expectations we face building in 2017 are
different from those of 2004 (when Rails was created) or 2005 (when Django was
created). Both of these predate the iphone (launched in 2007) and the
dominance of mobile, as well as stuff like Websockets (2011), 12 factor,
immutable infrastructure, distributed systems...

It feels extremely unlikely that that if we decided to design a framework with
these things in mind we would end up with something that looks like Rails or
Django (or some other RESTish/MVC thing), and yet somehow these are the things
we overwhelmingly use and recommend.

------
jasim
For projects I will maintain for the foreseeable future: Rails, Reason-React
in ReasonML, CSS-in-JS, and Postgres.

For clients: Rails, React+immutability-helper in Javascript, Tachyons+BEM
combo, and Postgres. Possibly Flow or TypeScript.

------
holografix
Definitely pick Python and Django or Flask for your server side.

Python is a super easy language to work with and if you combine with heroku
for hosting it's a no brainer.

Now if you want to develop something more front end heavy maybe Flask to
quickly layout your API endpoints.

I would suggest learning react redux if you want to get into JavaScript as you
come out the other side with a better understanding of functional programming
and a pathway into modern Webdev in terms of componentisation and progressive
web apps.

The tool chain for React has been simplified to regular human levels of
patience now through create-react-app

------
mythrwy
Depends.

Tiny project, Python Bottle.

Flask if project isn't complicated or not expected to grow much or I don't
care about model admin. (and maybe even Flask if project is expected to
grow... Flask really is a pleasure to work with).

Otherwise Django.

~~~
betimd
What about for a public web app ?

~~~
mythrwy
Any of the above would work.

I prefer Flask of the three because I don't like a lot of built in extras, but
prefer a larger plugin ecosystem than Bottle has. But Django isn't a bad
choice either and maybe a better choice for organization.

------
typednothing
A web user interface is just a user interface to the actual program, which I
always construct as a commandline (cli) program. It should also be easy (or at
least doable) to build a mobile and/or desktop user interface for the same
backend cli program. All of that should naturally be able to run as docker
microservices. In other words, web "frameworks" are just a pile of retarded
crap that is totally incapable of doing any of the aforementioned.

------
rbutler
Buffalo - [http://gobuffalo.io/docs/getting-
started](http://gobuffalo.io/docs/getting-started)

------
vorotato
EventStore + Suave + React + RX

I'd be really tempted to use Fable's F# -> javascript for the frontend, but I
don't know the ins and outs of that yet.

------
mabynogy
None. Plain Javascript and static pages. CGI for APIs.

~~~
elymar
Any specifics on why you choose this approach vs a framework?

------
ljw1001
For the backend, Kotlin on Intellij. It's crazy awesome and you can use it now
for android clients as well.

The Javascript transpiler is probably not ready yet (in beta) so I would use a
Bootstrap and/or Material Design library with lots of components and tie it
together with javascript.

Database Postgres. You can go hard relational if that's appropriate or use the
Json support like a better Mongo.

------
patatino
Asp.Net Core or Flask.. why? Becuase I know them.

------
aprdm
If it's a small project / defined REST api - flask

If it's a big project / still not sure of the requirements - django

For the frontend: React

------
jakozaur
Meteor with React: [https://www.meteor.com/](https://www.meteor.com/)

~~~
ai_ia
I am making a website based on this and the experience is amazing. I literally
started learning a week back, pivoted from firebase (after 7000% fiasco), and
have been kicking myself, why I wasn't aware of this before.

Meteor is smooth. And react makes me feel good.

~~~
betimd
You moved away from firebase?

------
roro5678
Node.JS + Express + Vue.js

------
sAbakumoff
Pure Go on the back plus jQuery on the front.

~~~
betimd
even a complex app, large web app?

~~~
sAbakumoff
Facebook is a large web app, Google Docs is a large web app, but the projects
I have been working on - not so much.

------
kamalkishor1991
Ruby on rails Here is my experience: [https://hackernoon.com/ruby-on-rails-is-
more-productive-even...](https://hackernoon.com/ruby-on-rails-is-more-
productive-even-after-learning-from-scratch-for-your-new-web-app-3cb22a06fa8a)

------
BerislavLopac
For the server-side, definitely Tornado + SQLAlchemy + PostgreSQL. This is the
core, with a likely addition of things like Celery depending on how large the
system gets.

The client side would depend on the complexity of the user interaction, but
the Web part would probably involve React.

------
gregopet
For larger apps I'd use Grails (think Rails on Spring Boot) with Postgres.
Depending on the app I'd either use the built-in Hibernate offspring or the
awesome jOOQ library to access the database. No freaking idea about the
frontend, so much choice..

------
kennu
Serverless Framework + Phenomic (React static site). No servers to worry
about, no OS maintenance, out-of-the-box scalability (using AWS API Gateway /
Lambda / S3). All development in JavaScript, so no need to context-switch for
client/server.

------
rwieruch
Depends on the case:

\- Do I want to use the latest technology?

\- Do I want to bootstrap fast?

\- Do I want to experiment/learn or do I want to build a business?

Depending on these questions, everyone has to decide on their own. If it would
be me, I would take MERN stack (MongoDB, Express, React and Node).

~~~
betimd
Yes, latest technologies. I started this thread because almost all web
frameworks had a big improvement year and they're somehow converging in a lot
of features and concepts.

------
slake
Angular + Flask is my go to. Still haven't jumped to Angular2 though.

------
tdevito
FAM stack; firebase + angular + material design. Get anything up and running
in hours. With cloud functions you can set up server side code with minimal
effort.

------
exabrial
The choices presented make my head hurt... A simple stack is a happy life.
Spend time on the business problem and choose the most boring technology
available.

------
justin_vanw
Werkzeug + Postgresql

------
brianwawok
Django!

------
ashlin
Having experience with Node, Rails, Go I would choose Rails for backend and
Vue or Backbone (for full control) on the front.

------
jftuga
ITT: Postgres is a lot more popular that MySQL

------
dna_polymerase
For Python I'd use Sanic. Database depends on your needs, but for me it is
MySQL mostly. Cloud Hosting from Google.

------
rimliu
Rails. For frontend: depending on need. Maybe jQuery, maybe intercooler, maybe
vue, maybe react. No Angular for sure.

------
cbenz
Frontend: definitively Elm.

Backend: Node for popularity, Elixir or Haskell to try something new, or
Python Flask which I already know.

------
madiathomas
I will write an API using ASP.NET MVC framework using C#.NET. Front-end I will
use HTML5, CSS3 and jQuery.

------
BigBalli
The answer to "Do I need a framework?" will inherently include "which" one to
use.

------
sirrele
Node.js + Loopback + Angular2 + MySQL

~~~
SamUK96
This is identical to my stack. Never thought I'de see loopback and angular 2
here, they're rather unpopular from experience.

------
theoneone
I would go safe and use PHP(laravel)

~~~
wolco
It gives you so much out of the box. Easy choice for the backend. Second
choice node/express for games.

Front end would depend on the project. JQuery for simple things, Vue for
website components or single page apps and react for games.

------
niftylettuce
[https://crocodilejs.com](https://crocodilejs.com)

------
staticelf
ASP.NET Core + Angular probably

~~~
thom
I'd love to be able to recommend ASP.NET Core, but there have just been too
many changes and U-turns. I have spent too many hours shaving the yaks of
changing project formats, features missing from the old ASP.NET stack, warring
dependencies, and half-finished implementations of related projects like
Entity Framework Core.

I _do_ believe they'll get there, but it's been painful maintaining apps built
with these technologies over the past couple of years.

~~~
avtar
Which issues did you run into with EF Core? I've been dipping my toes in the
water and was on the fence about investing time in their offering after seeing
their long-ish roadmap or just switching to Dapper.

~~~
thom
My knowledge of the state of the art in *Core is likely out of date, partly
because I have stopped trying to keep up. But last I checked, lazy loading
wasn't supported, it lacked a find-by-pk method, seemingly with the knock-on
effect that it didn't have any sort of identity map or anything resembling
real object-graph management. I have live apps running on it, it's mostly
fine, but the overriding sense I have of this stuff since the great open
sourcing is of barely contained chaos. Starting from scratch today, the
feeling might be different, I don't know.

------
krystiangw
Choose technologies you are the most comfortable with. I would go with MEAN
stack.

------
newdayrising
Definitely Elixir/Phoenix. Front-end it really depends on the type of app.

------
aeharding
Node + Vue

------
scalatohaskell
Scala Play backend (because i know it most), ScalaJs and ScalaReact

------
philmander
I started one recently with Preact + Mobx. Very happy with it

------
samsonradu
Yii2. React on the front if the UX really requires it.

------
Elemerald
Backend: Vert.x (Java) Frontend: Angular 2 or React

------
Traubenfuchs
Spring Boot with spring-data + MySQL + vue.js

------
MichaelBurge
Rails + Postgres

------
meerita
I would go definitely with Ruby on Rails.

------
matdehaast
Backend: laravel

Frontend: vuejs or react with ssr on both

------
romanovcode
Backend: .NET Core

Db: Postgres

Frontend: jQuery and Bootstrap

------
geekme
Go + MySQL + Angular JS

------
hondadriver
Aurelia + TypeScript for the front-end and C# on .NET Core for the back-end.

------
haskellandchill
Haskell + GHCJS

------
UK-AL
asp.net core + c#, typescript + react

------
pknerd
Laravel 5.4

~~~
wolco
5.4? I'm loving dusk.

------
tarikozket
Ember.js

------
aeikenberry
Django

------
bbcbasic
I'd use what I'm familiar with. That's be asp.net and knockout

