Use the language your team is familiar with! If it is PHP don't hesitate just because it is not "cool"..

PHP was a great tool back in the day and today!

PHP with a decent framework like Laravel [1] or Zend Framework [2] really works well and addresses all the features that you have listed (except the last 2).

Uniquely among modern languages, * PHP was born in a web server *. Its strengths are tightly coupled to the context of request-oriented, server-side execution.

We've managed to develop several complex apps over the last 10 years on PHP. For Web Socket support, we use Socket.IO or Firebase and it both really well together with PHP.

If you choose PHP now, you are not alone. Many companies still choose PHP for their Web Application. Slack uses PHP for most of its server-side application logic [3]

[1] https://laravel.com/ [2] https://framework.zend.com/ [3] https://slack.engineering/taking-php-seriously-cf7a60065329

I don't know about 'back in the day'... php was way ugly and hackety hack... BUT... laravel + composer now is a beautiful thing, super easy to get going. PHP in 2017 has grown up a lot and isn't the same as php in 2007.

I think most important thing is picking something that you can hit the ground running fast, it doesn't matter what you build in (though I'd stay away from nosql personally... never know when you'll need rdbms on scaling, and starting w/ mysql/postgres is safer in many cases)..

people avoid languages because they don't know if a php job ad means "20 year old codebase" or greenfield.

As someone who uses Laravel the most between all backend frameworks, it still sucks because it's rare to impossible to find jobs that use it and employers still largely care about what you're most proficient with and look down on it because it's PHP. That said, I do really like Laravel

Literally one job for my city and it's the first time I've ever seen one posted for my city. I do appreciate the resource though.

Many of them hire remotely though.

OP lists websockets, a feature PHP cannot implement well.

(and no ratchet, php-websocket do not count)

Well, to be honest if you want to use websockets, you better do that part in Node.js, Elixir or Go. The creator of Juggernaut, which was one of the most popular websocket library for Rails, ended up porting to Node.js until he said that people should stop using websockets and rely on Server Sent Events instead.

https://www.html5rocks.com/en/tutorials/eventsource/basics/

Considering there is absolutely no IE or Edge support for SSE, it seems like a non-starter for a general website.

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...

There is a polyfill for IE.

https://github.com/remy/polyfills/blob/master/EventSource.js

If by "websockets" you mean "notify a web client immediately when a server side event occurs", then PHP + Laravel + Pusher is a mature solution for this.

Has anyone tried Grav? Some ex-Drupal people use it.

I write Go for a living, and know Ruby/Rails, Python/Django, Node, PHP and C# amongst others.

I don't think one thing wins everything.

I'd shoot for:

1. PostgreSQL for DB

2. Admin tool in Django

3. API in Go

4. Front-end in whatever you know best.

Go I find best for APIs. But there's no out of the box admin tooling and the web stuff still feels immature (l10n and i18n).

Django admin has always proven solid, but maintaining APIs in Python over many years has been more overhead than Go APIs. I liked the web stuff, but kept finding I ended up using third party extras that didn't seem as well maintained.

PostgreSQL for the database is a no-brainer and allows easy migration to Google Cloud or whatever when you're ready.

The front-end is personal choice... whatever you can be most productive in and it handles all of the internationalisation stuff.

Not a great help I know... it feels like there are fewer one-stop shops really capable of shining at every level. C# should be a contender, it's tooling is great at all levels, but I don't know of a web framework that brings it all together to make it a few clicks and you're done.

So you end up maintaining two codebases that talk to the backend database? Implement a feature in one, you have to port it to the other too?

Sounds like a way to artificially pad hours on a project to me.

This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.

> This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.

It stems from APIs having bugs, and not being consumed by the writers. The flows were badly designed because they would never write a client against the API.

By making the web be a client to the API, the design, quality and maintenance of the API is very much to the fore. It also allows the implementations to evolve at their own speed, which helps a lot with maintenance, especially when one adds a mobile client, or changes some other UX flow... it becomes easier to work through things.

So yes, I agree... slower to get started and 2 codebases. But, so many advantages, higher quality, and lower maintenance costs that arise from the kind of short cuts that a single monolith codebase makes possible.

Tests have nothing to do with it. You can have 100% coverage on your API and it can still not be "quality". The best APIs I've seen have been "API First" design.

When talking about API "quality" I mean "does what it says on the tin, reliably".

Testing means you catch regressions.

You seem to be talking about API design, which is honestly a minor concern compared to whether it works reliably.

Have you ever tried to use the Facebook API? It breaks randomly such as endpoints suddenly return 404's, and there is no followup to bug reports.

That is what I'm talking about when I say "quality".

A "perfectly designed" API that randomly breaks because someone made a change and the lack of tests means its an end-user who discovers it is worse than terrible IMO.

- You can have many clients that talk to the same backend. This is really nice if you have an api that you can offer to partners.

- You can throw your client app away and build a new one pretty quickly without worries because it's totally decoupled from the backend. This is really nice when you have fickle stakeholders that have no idea what they want.

Client using API (irrespective of languages used) is about dogfooding. And, actually prevents the "one bug = two updates" scenario you suggest.

This is a great help given your experience.

Can you elaborate further on why you think Go is best for API work? I do like that go has goroutines, a fast compiler, and a single statically linked binary.

Fewer abstractions really help with APIs. Go gets out of the way more, and for APIs that really makes a difference.

An example might be handling the Accept header to give back multiple formats... many frameworks try and hide this from you, and so you have to fight to get something done. But Go exposes everything in a consistent and intuitive way, and there are mature packages for all of this stuff so it becomes trivially easy to work with.

JSON work is simple, CSV work is simple, XML work is fairly easy, image work is simple. It's pretty beautiful as language/std package experiences go.

It would need a more intuitive templating workflow for web stuff though (the "page.html inherits base.html and includes []block_*.html" story is a bit janky), and I've not yet found a decent answer for the l10n and i18n stuff, and whilst Hugo has a great template funcs library they've purposefully entangled it with their code, and so there is a lack of a core template func package to deliver a lot of things along the lines of Django templates.

So Go is great for APIs, but weak for web.

Thx Buro9

Do you deal with user management with Django? How do you deal with authorization with Go?

I use Ruby on Rails professionally and personally, and it addresses most of your features very easily (with Devise being a popular auth system that can be added).

Ruby follows duck-typing, so variables are not typed. If that was a strong point for you, Ruby might not be what you need.

I'm not quite sure about the admin UI (I usually use the rails console when I have things to change), though, but there's probably a gem that does exactly that (?).

Ruby on Rails is very powerful and intuitive, and I'll miss it if/when I change jobs and have to use some other language.

Edit:

> [...] so variables are not typed.

I might have used the wrong words... Ruby is dynamic, strongly typed. Variables are not limited to a certain type after they are created, and can change anytime.

There's [active admin](https://github.com/activeadmin/activeadmin) if you really want that kind of website, with a separate administration panel.

In my experience it's always better to just write it on your own and better integrate it into the app, but Active Admin allows for some fast prototyping.

In my opinion your requirements are a little fuzzy. If you're developing a website (no hard database requirements) you could go with something easy as jeykill, middleman or gatsby. If you're developing a web application I would try to evaluate my future needs:

Need #1: Since I don't know what my users will do I need to be agile and quickly adapt to business changes. Tool #1: Rails - the flexibility of RoR is still unbeatable. Especially if you're a startup this is really a timesaver. Furthermore it's no rocketscience to develop a decent frontend on top using React or Vue.

Need #2: Shitload of people will use my site. Tool #2: Elixir / Phoenix has kick ass performance and language and framework are well written and thought through.

Need #3: My whole team are frontend devs who just know JavaScript. Tool #3: Maybe Node.js is for you. In the past I've rarely seen a good Node.js backend project but if you're really disciplined (aka writing a lot of tests) it should be doable.

Need #4: My project is a FinTech and I need to talk to banks. Tool #4: Java/Scala/Clojure since you'll might talk to these services directly and all of the have JVM based SDKs.

Need #5: I'm a microsoft consultant. Tool #5: Well then go with C#/F#.

I personally would never use PHP. But if you have to: Go with Laravel - it's the best Rails clone around.

JavaEE. Modern JavaEE that is.

(Gonna upvote other answers as well, esp "whatever you are currently comfortable with".)

But if there is one stack I think gets way too little attention that would be JavaEE.

It turned out to be a lot nicer than anything I'd tried (-the JSF bit, that is still ugly but I guess everyone will just use the REST part with their favourite frontend framework these days.)

Now that I have significant experience with both .Net/Visual Studio and all three mainstream Java IDEs I'd also say that Java tooling is almost unbeatable for now. (A few small exceptions but I find myself choosing Java even if C# has some really nice features and I love Asp.Net MVC and Entity Framework.)

PS: I came to JavaEE 3 years ago because the company I started working for already had invested in it.

Rails 5 API Mode and ReactJS / VueJS. All with great communities and lots of free resources.

Maybe also a minimal go framework instead of rails for better performance...

I have been working as a web developer for 10 years. Here is my little secret. I have started with PHP, then moved to Rails, then to Node. Guess what? I am finally back to PHP. Why? Because I am tired of chasing the hype to feel cool. I just need to get things done and PHP is just that. I like to use Vanilla PHP, but if you need more features, I would suggest Laravel.

I have similar experience but I'm not so quick to say I'm back to PHP. "Use the best tool for the job" is the way I think about it.

PHP is great for marketing websites that don't need a lot of javascript.

But Node.js still wins for javascript heavy web apps. This is because you can write a js validator that will run on the client-side and server-side. Sometimes this is called Isomorphic JS (or Universal JS).

For example, this app[0] shows how to render React on the server and the client with shared props.

That being said, my personal website[1] still runs PHP and I'm glad I haven't taken on all the build dependencies of a modern web app just to host a simple blog.

[0]: https://github.com/styfle/react-server-example-tsx

[1]: https://www.ceriously.com/blog/

I like PHP as well, and ended up getting jobs that had these massive codebases that needed to be updated to modern standards. So, maybe not sexy but plenty of work.

Anyhow, I was recently fiddling with Elixir. Forget the hype and all that. If you like programming languages in general, I think you are going to enjoy this stuff for weekend projects.

My rule of thumb for websites/apps is: use whatever the team knows best. Certain stacks provide specific advantages (time to MVP, performance...) but I don't think any of them trumps an experienced team with production projects under their belt.

Ruby on Rails for everything, front and back end. There is no advantage to using front-end frameworks such as React for most apps that I have seen. I could only imagine something like Slack is nicer to build with something like React/Ember/Vue.js/whatever.io but for most applications Rails has got your back.

I've been using Rails and React for a couple of projects, one using Rails API mode with a separate React front end, and one using react-rails. I'd argue that with webpacker built in, there's no reason not to use React. You get server side rendering built in, automatic production builds and hot reloading. It's a great Dev experience out of the box with no setup.

Of course this depends on your frontend and your goals. If you're just going to have a minimal static frontend, then maybe React isn't a great choice. Although I'd still use React and just render it to static HTML at build time.

There's two general approaches you can take, it also depends on your risk threshold and experience.

1. Use a traditional framework that includes everything.

2. Use a microframework and stitch together individual pieces.

1. All in one - start with everything

If you know you're going to require all those things then I would focus on tools that offer that in Core, like Django. The benefit is that all the main components you need are 'guaranteed' to work together as a single unit, all go through the same security procedures and have many many people supporting the development. This can still be greatly customized and extended but you need to work within greater restraints of the framework. There are limitations, eg: NoSQL and Django don't really jive.

2. Do it yourself - only add what you need

Using the build it all yourself approach, you'll spend time doing what the above does for free by custom coding it. Be prepared to spend time reviewing individual packages that extend functionality, like Forms handling, and determining which one to use can be overwhelming. You may experience incompatibility issues and some of the smaller components have a single developer working on them for fun so you might up end having to takeover responsibility yourself or find a new drop in replacement - more time and work. The benefit is that you have nuts and bolts understanding of everything, and it can be highly customized. Lots more overhead, lots more time to get up and running. I find this works well for specific API's and not for something that includes everything in your shopping list above. Great for building very clean services, I'd argue more geared for experienced devs.

I like to start with Node.js and add modules from npm as needed. For example I'll npm install:

- `websocket-stream` for websockets support.

- `secure-password` for password security.

- `is-my-json-valid` for API/scheme validation.

- `level` for data persistence on disk.

- `sodium-native` or `sodium-universal` for crypto.

Mostly I use The Lebron Stack[1].

For client work I still use php, and we typically put them on WordPress or CraftCMS. Those are usually typical CMS builds and don't require anything too fancy aside from maybe a few plug-ins.

1. http://lebron.technology/

I hated web dev until Node.js! I agree with the top comment though, there's no 'best', got to try what's available and see which one clicks with you, as I did when finding Node.js.

From what I see, Node is something you install on a web server and it executes javascript server-side. How is it possible to build a web application (with user authentication, web pages with different content, etc.) from that? It doesn't seem anything like web frameworks I've heard about in the past like Rails and Django.

There is also Meteor, which is almost like a RoR for Node.js. I've used it for work and I personally find it a bit bloated though. For my own projects I mainly use static sites like GatsbyJS and Jekyll, but these are just for plain old websites and not that appropriate if you have users.

My team is building https://forestry.io for just this purpose (A CMS for static sites) :)

Very interesting! The first static CMS I've seen that isn't just an API. I've used http://prose.io in the past to edit content in GitHub, but this seems nicer. Currently I'm using WordPress as a CMS and Gatsby as a frontend, mostly due to custom post type support. I need more than posts/pages.

Does this support custom post types? I believe Hugo does.

django, but I'm interested in a language with real types.

Edit: many of the things you asked about, Django does exceptionally well. Migrations, built-in auth, built-in admin (what other framework has this?), APIs through DRF, form-model validation.

I've spent a good bit of time trying to find the "go-to" options for this in the Java/Scala world, and if you look into something like Play framework, the choice isn't clear for a newbie to the ecosystem. There's JPA, Hibernate, Slick, Anorm, EBean, flyway migrations, among others. Maybe I'm experiencing information overload, if that's the case, please comment below and suggest what you would use on a new Java project today.

I've been using the type hinting introduced in Python 3 and it works very well. I just wish that there was a way to check/verify the annotations. They work very well as documentation right now but not so much for preventing bugs.

The MyPy support for Django is severely lacking.

I've been thinking about writing a decorator to check this in development (should be doable) but then I would have to decorate every function and I really do not want to do that.

I love type hinting! Also using it quite a bit. Although, that's part of my desire to work with a stronger-typed language... I'm putting in all this effort to annotate Python, I'd probably get much higher application performance and I'd assume it's more efficient for the IDE to introspect a typed language than a loosely-annotated one.

And, playing around with things like Swing or Play, the whole ecosystem feels much more mature right out of the box.

i would be hardpressed to find a better front-end framework than React + typescript.

And it doesnt make sense to me to use a different tech for the backend unless you have a very specialized usecase (datascience <-> python for example).

migrations - use Python alembic. Nothing comes close. Its worth using it separately.

I use python and flask heavily with a react frontend at my current startup. But the only reason we do it is because we do crazy amount of math and data science - there is seriously no replacement for the python ecosystem here. If I didnt have that restriction, i would go full react+TS

If you just need to get up and running quickly with all batteries included, I think Django fits the bill. There simply isn't much else out there as comprehensive, unless you want to re-invent the wheel and write a lot of code to create simple CRUD apps.

You are correct. Django gets a lot of checkmarks on the above list.

"Best tech" depends on your requirements. Ease of development, speed, scalability, community?

I would go with Python 3 (yes, use 3 when starting a new project) and Flask & Co. because you write less boilerplate code and have a big community.

Go is interesting but you might end up with more dead ends and more boilerplate code than Python 3 (yes I know, it's faster than Python but Python has more/bigger [proven to work] libraries/community).

If you like Java or Scala go with the Play Framework. Most beautiful documentation of all 3 and it covers more of your "requirements" with its base than Flask (which is a micro framework).

Your feature list almost read like a feature list for Django.

I don't believe in a "best tech", it depends on what you're building, the skills of your team, there's no point in picking Python/Django with you have a talented PHP team who would could accomplish more, faster, with Laravel.

Also if performance is hugely important, then Go or Java might be a better choice... And Java developers are still easier to find. Depending on where you're located you'd also have an easier time finding a good PHP developer than a average Python developer.

Be careful when thinking about performance. It’s true Python isn’t as “fast” in CPU heavy microbenchmarks, but there are lots of real world trade offs to be made here.

If you truly need to handle the kind of CPU bound and high connection count workload today (not some hypothetical future state) where Python struggles, then of course look at alternatives.

Completely agree, often it's better to just spin up an additional server that rewriting in another language.

Nextjs (react) + Graph.cool as a backend

Nextjs provide out of the box server side rendering, routing, code splitting and all the new front-end stuff out of the box with just one command (no need to setup webpackj, babel, etc)

Graph.cool gets you backend as a service with grapgql. You can manage your db from their consle panel. You're not locked in to their service, you can install it on your cloud cluster too.

Don't discount C# and the .NET framework. I'm not an expert in the differences, just another coder, but there's been a lot of enhancements to C# .NET in the past couple of years.

I made a prototype using .NET Core MVC + Entity Framework + Npgsql + Autofac (Probably better IoC containers available out there but I'm used to Autofac open to suggestions btw).

It was very easy to develop, test and deploy. Npgsql has support for most of the postgres features (except complex types but that's planned).

I deployed everything on Ubuntu servers and runs like a champ. (I'm saying prototype and it is indeed, but it has 100-something users across the globe testing their workflows continuously and it has a lot of CPU-intensive stuff which is child's play with .NET to manage asynchronously. A production app would have two orders of magnitude more users but I think I'll be able to get away with a single server if it comes to that).

What was your experience upgrading a dotnet-core app?

We had a couple experiments at my company but going from 1.0 to 1.1 had breaking changes so we couldn’t upgrade easily.

I think everything was beta-quality until 2.0 - so yeah it wasn't easy. Nowadays it's smooth sailing.

Does .NET on Linux really work as well as Python, Ruby, Java, etc. do? Windows isn't cheap and Microservice-friendly.

Using Docker containers it does.. And .Net Core, even more so...

Can completely run on Linux and Kestrel (behind NGINX) is a very fast webserver. https://docs.microsoft.com/en-us/aspnet/core/publishing/linu...

.NET is excellent in my opinion. You have C# striking a great balance between features, performance, type safety and flexibility.

Definitely microservice friendly. Azure is reasonably priced with various serverless offerings.

And you can just run .NET Core if you want to target Linux and pick a dirt cheap host.

And you can self serve from Linux if that is what you're into.

I think it's not really about the tech but the constraints and the goals of your project with the resources you have.

For a lot of CRUD use cases a Web App/SPA is not really needed and a classic "monolith" can go quite far, and for this I find Rails still unmatched (maybe Django or Laravel too but I'm not familiar with it). You can have something up and running with nearly everything you listed in a week-end.

If you need a SPA you can still use Rails in API mode in the back-end with a front in React/Vue.

And if you are not about short-term productivity gains and looking for more long-term maintainability and scalability, then you can have multiple services in any language that fits you (static typing, ...) using the appropriate micro-framework for each.

Use whatever language you know best, and if you feel like trying something different maybe give Modern Perl and Mojolicious a try. http://mojolicious.org

I highly recommend Laravel. It's php based and ticks all your boxes except the admin ui * . It's old enough to be stable and have a large ecosystem of plugins and stackeoverflow answers.

The most important thing for me was the high quality official and free unofficial docs (laracasts).

I've used it for a little more than a year and always reach for it for my commercial work now.

Oh it also has really good Vuejs support if you wanna get fancy with a js framework sometime.

* There are some starting projects on github with admin uis, but I haven't tried any yet.

I'll say... whatever suits your needs.

I can't speak for others, but I'm using PHP frameworks and as you stated, developing in PHP evolved and you have now great stuff.

I'm mostly using Laravel, easy to set up, and with a lot of features. And a bit simpler than Symfony, that I use too, mostly because working with Magento 2, you are more comfortable if you know Symfony.

For front, VueJS, perfectly integrated in Laravel

Go/go-kit is pretty good for api backend of a modern web ui written entirely in React or similar.

Or if you don’t want to host api backend yourself, then a server less/lambda type implementation using nodejs or others, with the same React front end.

(Edit: missed that you wanted “admin ui” - then I’d add Django, but you might struggle with adapting it for non cms type scenarios)

I think a Django on Go would be a really good combo too. I like python (and other langs), but the goroutines, compiler, and single binary are really nice features.

Django makes a crazy use of reflection (and the higher concept that Python has of Metaclasses).

I don't really see how Go would make a better job than Python at something like Django.

The upside of Django is that you write so little code and all is covered. The downside, is that you have to test it carefully.

It sounds like you are interested more in what framework to use than the languages.

I still use php and Silex micro framework for the small sites I develop, Its not very full featured (not ticking a lot of items on your list) but its fast enough and I know it well enough to put a site together quickly.

Spring Boot

Grails

Rails

Are all excellent technologies. Grails has excellent form/model binding and validation with what they call command objects.

Elixir/cowboy seems the best answer for the web in my opinion. I wouldn't default to phoenix framework like most people would suggest. Most people default to a framework before they have a problem that it was made to solve.

You can build a lot using only plug and maybe ecto as orm.

The road ahead is Elixir / Phoenix.

Flask (a Python micro-framework) + all the available Python toolkits/libraries/plugins it works with, comes very close. It's easy to learn, and quick to spin up.

If you want all of those features built in, then I think you're looking at Laravel, Rails and Django, which are analagous to one another in my mind. I don't see much difference between the capabilities of these tools, I'd pick one based on what the team is most comfortable with.

I'm partial to Python and Flask but Flask has less built-in features.

https://evenbettermotherfucking.website/ (a follower of http://motherfuckingwebsite.com/)

I really dislike the 'better' and 'evenbetter' ones. The contrast is pretty low which makes it more annoying to read. It's also way too wide still.

https://bestmotherfucking.website/ is actually better than these others.

If your are familiar with Rails, you can look at Phoenix Framework. Its looks pretty neat to me.

The hot thing from an infrastructure perspective is serverless. You can do the http and user management stuff with cloud services like api gateway and cognito (AWS). Business logic lives in lambda functions, which only support a handful of languages.

Django is quite good. It might not be as "cool" anymore but the language is really simple and the framework is battle-tested and has support for pretty much everything in your list, short of type systems (Python isn't strongly typed).

Rails is still the king of batteries included.

There are some nice frameworks for rest services in JavaScript but tend toward microservices and components. The landscape in all the upstart languages lack a batteries included monolith builder.

Poll

Compiled to JS

Typescript

Clojurescript

ES 2016

Reason ML

Elm

Database

Postgres

Mongo

Mysql

Frontend

React

Vue

No FE framework required

Angular

Python

Java

Elixir

RoR 5 API

NodeJS

Clojure

PHP

Golang

Vue or angular 1 for frontend and PHP with laravel or slim fw for backend. I've tried many solutions but this is the best way to get shit done.

For me, it's Grails. But really, go with the "use what you know" mantra unless there's a really compelling reason not to.

I may be a little biased, but don’t discount Drupal 8 as a viable framework as a solution.

"It depends"

Solo projects Use whatever you want or want to learn

Team projects Use whatever your team prefers