Django. Nothing has ever surpassed Django for me. It is soooo much faster to prototype with than anything I've ever used (especially when you know all the amazing shortcuts, but that's not a requirement as their docs are incredibly good).

It can do anything you could possibly want to do with a standard web app and if you really want to do crazy Javascript things you can always just use it as an extremely powerful backend for whatever the frontend framework of the day is. The admin site alone has saved me weeks of work and I keep finding amazing features in it that often just seem like magic (formsets!!).

How do you feel about implementing social authentication with Django Rest Framework? What are the packages you'd normally use?

I just lost the whole explanation I was about to send because Android is really stupid sometimes, so here's the short version:

Most social auth uses OAuth2, which doesn't exactly make sense with REST, but you can still use it alongside a REST-based app.

I see 4 scenarios:

1. A JS web app that uses SessionAuthentication can just use python-social-auth's Django app directly. Since the session is shared, it should Just Work™.

2. A JS web app that uses tokens: django-rest-framework-social-oauth2 seems to be made for this, but you could also do it with plain python-social-auth (which the former uses internally) by generating a token on your /success URL and sticking it into localStorage.

3. A non-web app that uses tokens: like number 2, but in a WebView.

4. A non-web app that uses sessions: like number 1, but copy your cookies into a WebView, do authenticate in there, then copy the cookies back.

How is deploying Django? Is it easy to integrate with Nginx or Apache?

I know PHP is super easy but wasn't sure how it was for Python frameworks?

You run collectstatic to get all of your static assets in one folder, use gunicorn (python package, there are other options as well such as uwsgi) to serve your wsgi server, and have nginx in front of gunicorn to intercept anything with /static/* to pull from your static assets folder. This is all 3 or 4 lines of config in nginx.

Your first try might take a couple of hours to get right. If you want HTTPS (you should) Caddy might be a better route than nginx. It's certainly easier.

For Apache, the easiest is just using mod_wsgi and pointing it at your source folder. It takes 3 trivial lines of Apache configs if you're using system-wide Python and 2 additional slightly longer ones to use a virtualenv instead (recommended) - all nice and copy-pastable from the official docs.

Nginx has a similar module, but I haven't used it personally.

My personal picks would be:

- React for the front end (https://reactjs.org)

- Node.js for your back end (https://nodejs.org)

- Deploy using Adapt, which ties your front and back end together using React-like components. (https://adaptjs.org).

- (Optional) If this project is larger or commercial, definitely use TypeScript on all 3 of the above (http://www.typescriptlang.org/)

[Disclosure: I'm a maintainer of Adapt, but a strong believer in the React model and ecosystem]

> Use React’s declarative JSX syntax, JavaScript components, and a rich component library to build, deploy, and operate your <NodeService>

Im sorry but why would someone want to use a templating language to configure infrastructure? It’s like using CSS syntax for defining an HTTP API. Doable, but... why? It’s not any easier to pick up or reason about than any existing configuration language.

On React + node, this assumes no rendering on the server, plus you’ll need to pick your own state management solution, data layer, http framework, router, and a whole host of secondary tools, which will comprise about 96% of your actual development time.

A template language suggests something that uses code points to inject dynamic values. JSX is a bit more than that in that it bundles a template plus the corresponding assigned logic. It is more of a component language than a template language.

At any rate the reason why somebody might want to do this is purely because its declarative. I prefer imperative programming myself, because I want to know exact what the logic is doing from reading the code, but many people don't think that way. Many people want to know what is happening without being overwhelmed by how its happening and they need the code to communicate to them in exactly that way.

In my opinion, the power of the React/JSX model is really about allowing you to declaratively specify everything that can/should be specified that way. But then also allowing you to selectively use imperative constructs where they're needed, all while making it fairly seamless to move back and forth between the two at any level of abstraction.

Of course, with great power comes great responsibility...

Why do you advise TypeScript as a definite for larger or commercial projects? Thank you very much.

In a small project, it's pretty easy for one or two devs to mentally keep track of the codebase and also makes any refactoring fairly quick.

As a project gets larger (more code or more devs), each dev spends more and more time figuring out what the correct types need to be when using various internal APIs. Refactors get harder because it becomes harder to know whether you've correctly found and changed each place that was needed.

And although all projects have this to a certain degree, one typical goal of a commercial project is a higher quality bar for software while still optimizing amount of effort to get that quality. (And commercial projects are often larger too.)

TypeScript helps with these issues (and others). In my opinion, it increases developer productivity for all but the smallest JavaScript projects. It's a combination of both the static typing and the tools available that help the dev immediately, as opposed to waiting for a compile or test run.

I'm actually passionate enough about the topic that I have an old blog article about it: https://medium.com/hackernoon/3-reasons-why-we-use-typescrip...

Thanks a lot for the response. I will take a look at your blog.

I have never been a big fan of javascript on the backend(or the frontend for that matter but we have no choice).

A 200 l.o.c. promise chain vs a 10 liner in Python or PHP or Ruby?

Just feels dirty to me.

You shouldn't need promise chains nowadays since async/await is available. Also, I'd be interested to see 200 lines of idiomatic JS being written in 10 lines of idiomatic Python, PHP or Ruby if you have an example.

Still Django. It's in a weird state where it's starting to show its age, but everything else is at least 10 years away from catching up. So still the best bet if you're starting something new today.

I always reach for django for new projects. It's never let me down and can be used in many, many ways.

I usually end up with fairly succinct code and it's never difficult coming back to a project that is 5-6 years old. Can always understand what's going on in the project and get my mind back and running quickly with it.

Using it with GraphQL (graphene) makes it feels a bit more like one of the newer frameworks out there.

Really happy I learned it years and years ago. Nice to invest time into a framework that is still going strong so many years later.

Can you share a bit more about how it's showing its age?

(I'm not a web dev, but played around with Flask recently and in general find the giant ecosystem of different frameworks fascinating.)

> Can you share a bit more about how it's showing its age?

1. There are some bugs that can't be fixed just because they break backwards compatibility. E.g. usernames are stored to the database incorrectly by default, but the dev team isn't going to change it. So if you don't know that it works the way that it does, it can cause issues.

2. Most people now use a js frontend and a REST backend. Django can do this well, but because it wasn't originally designed to be used that way there is a ton of random cruft that isn't super useful to most people anymore.

3. No good async story. They are working on this, but it's going to be kind of bolted on rather than designed for async from the ground up.

4. Lots of random cruft related to weird design patterns that folks have advocated for over the years. You don't have to use any of it, but the fact that it's there leads a lot of people to believe they should be using it, which leads to bad codebases.

Basically you can do everything you'd want to or need to using Django, but there is just a bunch of random crap in there that you need to prevent people from using. And preventing people from doing stuff that they want to do tends to lead to either conflict or technical debt, so it would be much better if it just weren't there in the first place.

>4. Lots of random cruft related to weird design patterns that folks have advocated for over the years. You don't have to use any of it, but the fact that it's there leads a lot of people to believe they should be using it, which leads to bad codebases.

If i saw this sentence out of context I would have bet a decent amount of money you're talking about C++. This describes C++ to a T.

Do most people actually use a js front-end and a rest backend?

It's still brittle, it's still user hostile and it's still slow. Seems like a massive waste of time and a vanity project to me.

I'm still mainly doing server-side templates coupled with complicated js widgets when I really need them.

A js front end itself (versus templates) is probably a wash for most use cases, but the benefits of having a REST back end that imposes a clear separation between the front end and the back end is enormous. IMHO the benefits are big enough to make it worth re-writing the front end over again every 5 years until the front end folks eventually get their act together. Just try to make sure you're doing as little logic as possible in the front end, because as I said every line of code you write is going to need to be rewritten, whereas with Django any code you write today will still be good 10 years from now with only minor maintenance needed.

I've not seen any of those magic benefits, just had massive pains with debugging and maintainability.

How do you feel about implementing social authentication with Django Rest Framework? What are the packages you'd normally use?

I don't like social auth so I haven't used any of them. But there are several packages for that.

Rails is less "easy" than it used to be due to the integration of Webpack (via the Webpacker gem) and thus the entire world of frontend JS development…yet that move in many ways "saved" Rails as a serious tool for modern web professionals.

So while I'm not sure Rails is easiest to pick up for a complete newbie, I am sure that there is still no framework that can touch Rails when it comes to fast/easy to build an entire web application from scratch that is truly broadly deployable and maintainable for years to come and won't cause you to tear your hair out every other day. :)

Yeah - I'm still a bit confused how not much has changed in more than 10 years. Seems like setting up a rails app with your typical gems — devise, stripe ruby, puma, carrierwave, sidekiq, railsadmin, etc. is still by far the fastest way to build a functioning, production ready SaaS app.

I'm a bit tired of all this react and javascript mubojumbo and keen to learn more about rails. what would be the best tutorial that isn't outdated? so much things are just old...

https://www.railstutorial.org/book I found this really useful.

5 answers as of my typing this, all 5 recommending almost entirely different options.

I think you're not going to see much consensus to this question, merely a comment-based list of all possible frameworks that people know.

User joshmn had it right in his reply:

> If you know something now, use it.

Anything your team already knows will be easiest and fastest for you to use. Any new person you hire will have a lot to learn no matter which one you choose, unless you hire people for the framework/stack you chose.

There is no "right" answer to this, and there probably never will be, and that's not a bad thing. Trying to find the "perfect" solution is a futile effort.

Exactly this! Current shop has a crufty in-house monstrosity with a weird history. All due to someone deciding that the stack had to be Python/Django + Backbone.js + jQuery.

Not a bad stack, but the development team was a group of PHP developers. Rather than go with something they all knew, the leadership decided that switching stacks and having the entire group learn Python with the CMS/CRM/Fulfillment system being their first professional project was the way to go.

What resulted was a misshapen monstrosity. Plenty of good ideas, ruined by limitations in understanding of the stack they tried to implement, and further hampered by a lack of good direction and herding of the team. The stakeowners of various bits were allowed to snag their pet developer and lean on them until their "feature" was implemented, with little to no cohesive architecture in place.

Perfect is the enemy of good. There are dozens of frameworks because they all have their uses. Stick to what you know, and let that guide you. If you have a desire to learn a new stack, go for it. But don't pick one because someone else says "it's the best".

If you know something now, use it.

If you don't, Rails or Laravel are both good options. I'm partial to Ruby, its syntax, its expressiveness; the ecosystem cannot be beat, and the tooling is stable and mature. There's nothing not to like.

Yes the ecosystem can be beat. Have you seen the PHP ecosystem lately? And Laravel’s? Especially Laravel actually. The documentation is amazing. There is Laracast. A lot of tools to help. Dedicated CI services (ChipperCI). So many great components.

Check out Graphile Starter; it is a fullstack starter project for building a SaaS with PostGraphile in TypeScript with React (Next.js) and Apollo Client. It has all of the modern tooling preconfigured including type checking, linting, formatting, unit testing, acceptance testing with Cypress, CI via GitHub actions, code generation to increase development velocity and much more. On top of that, the user account system is pre-built with everything you’d expect: login with username/email and password or social login with OAuth, forgot password flow, change password, multiple email management, email verification, etc. It also has a job queue and migration framework built in and preconfigured, plus instructions on how to deploy... I’ve put a lot of work into it! https://github.com/graphile/starter

VueJs/Reactjs for the front end.

PostgREST or Serverless framework for the backend.

Avoid middle ware all together!

https://github.com/PostgREST/postgrest

https://serverless.com/

I’ve been doing some trialing with hasura and postgraphile lately, any thoughts vs. Postgrest?

I am the maintainer of Zero[0]. The idea is to abstract all the config that causes the friction in the beginning.

[0]https://zeroserver.io/

Been looking for something like this for a long time! Thanks!

Ruby on Rails, hosted on Heroku, with the Jumpstart Rails template. https://jumpstartrails.com/

Stimulus Reflex for real-time dynamic updates without the complexities of React components. https://github.com/hopsoft/stimulus_reflex

Depends on your choice of language:

Python => Django

PHP => Laravel

Ruby => Rails

Node/JS => ExpressJS

Elixir => Phoenix

My personal opinion on building web applications the quickest way. I mostly use Laravel.

There's also a good case to be made for using Symfony for PHP and Flask for Python.

I gave a talk a couple of years ago about using WordPress and still highly recommend it. It solves so many problems out of the box - account management, routing, CRUD, etc. Here's a video of the talk:

https://wordpress.tv/2019/04/23/corey-maass-build-a-web-app-...

There are a number of large web apps that use it, so it's not just for MVP's. I also heard the book "Building Web Apps with WordPress: WordPress as an Application Framework" will be getting a second edition this year.

It's not the coolest, shiniest option, but a solid one, I think.

A lot of answers suggest a Node.js stack. I’d like to say that the problem with Node is that there isn’t really a “batteries included” stack you can choose from, unlike other languages.

You can indeed use Express.js for the HTTP part, but you’ll need to pick an ORM, a rest framework, etc and make sure they integrate properly which might include writing “glue” code to bring them together.

Unless you’re knowledgeable about Javascript I suggest you avoid this option and instead pick another language you know that happens to have a batteries-included framework like Django, Laravel or Rails just to make development faster as these frameworks include everything you need out of the box and are tested to work well out of the box.

Check out Graphile Starter; it’s extremely batteries included! https://github.com/graphile/starter

It is a great job to create an "starter" project.

However I would expect at this time of the JS to have one single import that does all the work for me hiding all the configuration files. Making good/best decisions for the default configuration. Also deciding how to do things like database connection, transactions, HTTP server, SSL, UI, ...

I'd recommend taking a look at October CMS (https://octobercms.com/). It looks pretty simple from the intro video but if you take a bit of time getting to know it better you'll be blown away at how quickly and easily you can get something up and running that remains flexible & scalable enough to grow pretty big.

Disclaimer, biased as I am the lead maintainer for the project ;)

This looks very cool and intriguing. I see it's built on Laravel which I love. I see it adds themes which is dope! How else does it improve on Laravel?

I know that Meteor has a somehow bad reputation, but I still believe the framework is the best full-stack solution in the Node universe and has a bright future. It has evolved a lot, and currently has a new owner, team and funding.

- Tight integration with React, Vue, Svelte - Natively supports Mongo, but there are good GraphQL and SQL integrations these days - Plug 'n play user accounts (customisable) - Easy to deploy - Builds to Android, iOS, even desktop these days. - Tight integration between back and frontend. Extremely simple to write API's or realtime applications - It's simply Node on backend, do whatever you're used to - Still a very active community - Tons of apps running happily in production (the myth of it not scaling is due to developers not understanding, not the framework itself)

We continue using it, nothing develops as fast and easy - at least in the Node world.

I would recommend looking into Node.js for the back-end. You can then combine it with either React/Angular or even just a plain jQuery front-end.

The nice part about Node is that you'll have JS on both the front and back ends.

It really scalable and if you use typescript, you can get type safety as well :)

"think how easy Rails was in 2006"

There is your answer!

But for anyone with a decent amount of programming experience in a mainstream high level language like C# / Java / JS / Python / Ruby etc. it's probably best to stick to your own language and pick it's stack, if it is dev speed you are after. Some might be easier to set up than others, but there are plenty of example github repos you can clone to get started anyway.

For (what I'll call.. sue me) "systems" languages C, C++, Haskell, Rust, GO etc, I'd probably move over to one of the mainstream stacks for getting things done fast, as they will have a better ecosystem. Also if you already know one of those languages you can easily work with the mainstream ones!

My go-to are Next.js (https://nextjs.org/) and Hasura (https://hasura.io/). Graphql has a bit of a learning curve if you haven't worked with it, but those two tools deliver a pretty amazing developer experience.

Next.js is react + ssr + routing and more. Hasura exposes an auto-generated graphql API in front of a postgres instance, with hooks for auth/authz and much more.

The setup I'm using right probably can't be picked by "anyone" but I think is the best/future-proof for small apps and it's also very easy to maintain if you are growing.

- Front-End: Vue.js with Bulma.css - Webpack/Gulp for building JavaScript/SCSS. (I have the blueprint here: https://github.com/omarabid/front-root but there is still no docs and rough edges). The website is/will always be static files generated by Gulp. First frontier for scaling is eased.

- API: I use a GraphQl server. This avoid the mess that is RESTful. It also give me a nice explorer, so I can make my application and be able to roughly work with it before I have an interface ready. This part is also easy to scale.

- Application: Rust. Technically, you can use anything here. But since I don't have any web components (the site is static and the API is served through GraphQl) then I use Rust which I find very productive. Rust generates a compiled program which run inside a container and makes deployment more enjoyable.

- Database: Postgres/Redis.

- Deployment: Everything runs in a container. I use Hashicorp software for deploying and orchestrating the servers. Terraform if I have a simple single server app. Or Consul/Nomad/Vault if I'm running multiple servers.

It might sound complicated but beyond the initial investment to set things up, you have a stable/reliable micro-services app.

Laravel feels very similar to what Rails was like in 2006.

It has a great ecosystem and lots of great packages and tools to make it fun and easy to develop web applications.

Ruby on Rails - Libraries/Gems it have are quite matured with very good documentation.

Authentication, file upload, admin interface ... are some of those.

I'm building a new application this year and I'll be using Go for the backend and Flutter for the frontend (both web and mobile).

How's your experience using flutter web? I love flutter and dart used it for a few mobile apps. Tried using Flutter Web and felt like it was missing a lot to make it usable in production.

I haven't used it yet, actually. I'm hoping that it's good enough for what I'm doing (which is more or less just a fancy CRUD app), but if it's not, then I can always wait on the web app until it's ready.

Hahah. I just published a blog post on this very topic. I will self-promote and link it here as it is certainly relevant:

https://www.simplecto.com/django-my-go-to-application-framew...

Following on that, enough HNers have laid out the Django story, but I want to give some more depth to it. This is my entire stack:

- Linux Server/VM Hosted anywhere (I like Azure, Digital Ocean, or Scaleway) - Docker. Just plain docker - Postgresql running in docker - Django in a container - Intercoolerjs for easy and slick Ajax-like front-end work - Traefik for reverse proxy and TLS with LetsEncrypt - Sentry for catching production bugs (easy three-lines added to your config) - Bitbucket pipelines for CI/CD

For smaller projects I run tests locally in docker containers and then push directly into produciton. I dont bother with full CI/CD because I don't need the complexity of it all.

The one with the language you are already most comfortable with. Believe me.

Use what you know.

If you know JS, just stick to Node + Express.

I stick to Go or Node for the backend, and create-react-app for the web client. I prefer Go in most cases because I don't need to rely on many external deps, and I have my own starters for both Go and Node to create services quickly (rest, real time, assets, data/repository)

I like gatsby.js hosted on netlify. Netlify provides a limited set of backend and lands support. It is a JAM stack app (JavaScript/APIs/Markup)

It does have graphQL which can get a little tricky, but the constantly rebuilding dev environment and GitHub hook driven deployments make running a site a breeze.

For front-end single-page-app I'd choose Vue over React.

For back-end I'm currently favouring F#/Giraffe. I'm new to .NET Core but F# is reason enough to try it out. Previously I've used Go or Kotlin/Java with Javalin/JDBI which I find lighter and simpler than Spring/Boot.

If I may, I have a related question I'd like to ask.

I'm a front-end developer looking to get serious about practicing my back-end development skills. Any recommendations for a language/framework with static typing (outside of Node + TS)? Spring Boot and Kotlin? .NET Core? Go?

I am in a very similar situation to you, I'm a full stack developer (slightly stronger at frontend) that used to do a lot of Ruby on Rails work, but I've been looking for a statically typed backend framework to specialise in. Hopefully some of my research / bike shedding / procrastination will be helpful to you :) I've been trying different backends to find the 'perfect' stack that's statically typed (spoiler: no stack/language is perfect). I've had a mix of personal and commercial experience with Spring Boot, Go and .NET Core.

Big Disclaimer: My observations are completely subjective and personal so YMMV.

Spring Boot and Kotlin: I REALLY like Kotlin as a language, though Spring Boot felt heavy and sluggish from a developer productivity standpoint. This could be my inexperience with Spring and the JVM ecosystem, though I've also read comments on Hacker News that roughly say the same thing (1). I've also read that the heavy use of annotations in Spring Boot are great initially, but it creates headaches for more complex projects. The Maven/Gradle package management experience wasn't great either when compared to RubyGems/NPM. I also tried Kotlin + Ktor(2) on a personal project. It felt better, but at the time it was hard to find solutions to problems on Stackoverflow or the web.

Go: I briefly worked on a project that used Go + Gin. I loved the simplicity of Go and features like concurrency and the built in code formatter. Though at times code felt a little too low-level when implementing business logic such as model validation etc. I missed language features such as generics, null checks and discriminated unions that other languages have. Handling errors also felt tedious at times. However I completely understand the appeal of keeping the core language simple.

.NET Core: I'm probably the most torn about .NET Core. I've always preferred a *nix/Mac system and borderline hated Microsoft during the Balmer years. However C# is a properly good language (though not quite as nice as Kotlin) and the .NET Core standard library feels well designed. There are new features coming in C# 9 like discriminated unions (sealed classed in Kotlin) and records (data classes in Kotlin) that will make it even better. It's not all great, I found unit testing is much more tedious in C#, especially compared to something like Jest or RSpec. Mocking/stubbing was especially difficult as you can't easily override a method unless it's tagged as 'virtual'. One way around it is to use interfaces for the argument type, however this can cause your project to be scatted with pointless interfaces that are only used to overcome this restriction (3).

ASP.NET Core overall is very nice to work with and it's blazingly fast (4). It does have remnants of some enterprisey cruft, but overall I found it very productive to work with. Using VS Code and Jetbrain's Rider made coding on a Mac a breeze though full Visual Studio for Mac is pretty awful.

But here's biggest issue with .NET Core: while it's truely cross-platform and open source, I found the broader .NET ecosystem and community is yet to embrace this. I'm not sure if it ever will completely. The vast majority of YouTube videos and articles I've read assume you're using Visual Studio on Windows. That makes sense, as a 2019 Jetbrains survey indicated that 90% of C#/.NET developers use Windows (5). But if Windows is your jam, this might not be an issue for you.

I also have the strong feeling that Microsoft's strategy for an open sourced .NET is to push the use of Azure for hosting. While it's definitely possible to deploy a .NET Core application to AWS or GCP I worry that Microsoft will always have a bias (even if it's unintentional) to make .NET Core be better on Azure and have soft lock-in. E.g .NET Core will run on any cloud provider, but you'll get the most of it if you're running on Azure.

All of these frameworks were weak in the REPL department. One of the great things about Ruby/Rails and Python/Django is the interactive console. There have been countless times when I've SSH'd into a production box to manually trigger a password reset for a user, or use the ORM to run a one-off report for a product manager. I couldn't find anything close in statically typed frameworks. Because of that I'm quite liking the combo of Python + typings + FastAPI (6) for personal projects. It's not perfect but it's ticking most of the boxes for what I'm looking for.

Again I can't stress enough that this is all my biased personal opinion influenced by how I like to code and my strengths and weaknesses as a developer. But hopefully it will help you in choosing a language/framework that you'll enjoy. Another thing to keep in mind is the amount jobs available for each stack near where you live.

1) https://news.ycombinator.com/item?id=20602318 2) https://ktor.io/ 3) https://stackoverflow.com/questions/20400734/how-do-i-mock-a... 4) 'aspcore-mvc-ef-pg' in https://www.techempower.com/benchmarks/#section=data-r18&hw=... 5) https://www.jetbrains.com/lp/devecosystem-2019/csharp/ 6) https://fastapi.tiangolo.com/

edit: typos and formatting

Hey, thanks for the detailed reply!

Last night, I went through a lot of research and bikeshedding myself, and a lot of my intuitions aligned with your experiences.

I was curious about Go, but it seemed while it was possible to do mostly everything you wanted to do, it wasn't necessarily a smooth experience.

I looked at Kotlin next. I'd used Spring Boot before with Java, and at the time I was fond of the annotations, but, like you said, I've heard that they can become a burden in larger projects. Thankfully, I saw that there were a number of other Kotlin web frameworks that had vocal support.

Finally, I spent the last bit of my time choosing between C# (.NET Core) and Kotlin with Ktor something else. I ended up finding this very helpful site[1] that showed examples from the two languages side by side. That had settled it for me; C# just looked more like what I wanted out of a programming language's syntax. Plus, LINQ looks really cool.

At some point in the future, I'd also like to gain more comfort with Python and Django. I can't stop hearing good things about those two.

[1]https://ttu.github.io/kotlin-is-like-csharp/

You can't go wrong with either one (Kotlin, C#) tbh. The Microsoft Docs and Jetbrains docs are pretty decent.

I really like Flask at the moment. It seems to satisfy all your prerequisites.

How easy is it to integrate python frameworks with nginx or apache for deployment?

I love Python but have only deployed PHP apps.

Well actually very easy.

Sample for Apache:

https://www.codementor.io/@abhishake/minimal-apache-configur...

Do you want fastest/easiest? I may be opinionated but try JHipster. If you want a Kotlin version try KHipster. Full Stack + Open source + all bells and whistles loded

Ruby on Rails

The one you know best. If you have 0 programming experience go with php. If you do have programming experience, then framework for the language you know best.

If you love Java but hate JavaEE, check out Spark Java: http://sparkjava.com/

Dropwizard is another, more popular and well adapted solution without much JEE clutter.

We use this at work and love it. Great easy to use framework and easy to build on top of

I still love CodeIgniter for it‘s good documentation, simple deployment (just use SFTP) and easy to learn curve.

Some friends are working on budibase.com. We are part of the same incubator programme.

Meteor.js

Meteor.js is my favorite too. They seem to have got renewed sponsorship now from Tiny ([Tiny acquires Meteor | TechCrunch](https://techcrunch.com/2019/10/02/tiny-acquires-meteor/))

The last 2 months have seen more activity after a pretty long silent period.

For me it is Clojure(script) + libraries, no frameworks.

Which libraries do you use? Do you use Ring? We use Luminus with Reagent and re-frame at work.

Front: Quasar/Vue

Back: FastAPI

>think how easy Rails was in 2006

So why not use Rails?

Idk. I haven't done any web dev in years. So that's kind of what I'm asking here. If Rails is still the answer then I guess that's it. I would have assumed there'd be something new by now.

Ruby on Rails

Ruby on Rails

LAMP + Vue

Check out Vue.JS before React/Angular. I find it much more succinct. Node+Express is a very fast backend.

Plus the advantage is ES6 all around. Node utilizes the host resources much more effectively than PHP. And PHP requires Laravel/Artisan to make up for its shortcomings, IMHO. It feels like those to extensions were built for people with extensive PHP backgrounds, and not newcomers. Whereas Node does a better job onramping IMHO.

I find using JS on both ends is much easier than trying to bring in a bigger system like Rails/Django/Apache+PHP.

Especially if you are starting from Square One.