Edit - to make life extra easy also set it up with Postgres and deploy to Heroku. Everything literally just works.

What would you choose?

It is not. From the outside the end result for the user might be similar, but that's where the similarities end. Elixir's LiveView what I assume you're talking about keeps state on the server, in memory, and sychronizes changes back to the client over a websocket. Hotwire is "stateless" in the sense that no end user state is kept in memory on the server across requests. You can also use most of Hotwire without websockets.

My previous company was using Elixir, and they moved away from it because everything took longer to develop, the ecosystem of libraries was very lacking, the tooling (such as editor support) was terrible, and it was very difficult to hire experienced developers.

Performance wise, I agree, it is faster and you will use less servers. A nice problem to have to be honest.

But I insist, they have almost nothing in common other than maybe the end user result. The approaches they take are architecturally very different and with very different trade offs.

It'd be great to see that change over time, but to be honest I'd be more excited to see some movement behind the crystal lang, because I love coding in Ruby. All of my side projects are now being written in Ruby because I don't need something that scales in microseconds, or 10's of milliseconds for that matter, and I feel so much more productive.

Again, I hope I'm proven wrong. I think Phoenix has a lot of potential, but it still has a long way to dethrone Rails.

I've been using Rails for 10+ years now and setting up a phoenix app is very intuitive. A lot of "oh this is like X in Rails". IME most of the complexity was around JavaScript and that's changed with esbuild.

However it sets up with very similar patterns to Rails. Something I'd expect as it's creators came from Rails. Usually the differences are specific to FP vs OO.

Admittedly coming in from another language especially with an OO background would be harder as it's a smaller community than Rails and doesn't have 10 years of documentation sitting out there. That said documenting elixir code is much easier IMO, so that is sure to change. Also the scope of FP languages requires significantly less documentation IME.

The only thing vs Rails that I have found somewhat needing more attention in Phoenix is SSO integration but it's there and progressing especially with the Phoenix 1.6 changes.

Do you realize how biased you sound to be?

PHP => Symfony or Laravel

Python => Django or Flask

Javascript => Node/Express

Ruby => Rails

Then there are others like elixir/Phoenix etc and then you can do your own in Go etc.

I've not used it in depth yet, but from a poke around the overall design and syntax seem very nicely thought out (much more logical/intuitive than Flask, honestly) and it's very fast.

I do recommend dipping in Laravel first, before Livewire.

With the addition of:

C# => .Net Core

Their latest web framework running on the latest long-term support version of .NET

Rooting for quarkus to become more mature though. (Recently tried based on someone's recommendation on HN).

But if you really want a full stack framework or don’t want to deal with fancy JavaScript frameworks, I think you’re better off sticking with Rails/Django/Express or something you’ve probably heard of.

WordPress.

Why? Incredibly easy to dev against. Powerful API built in. User model. Flexible theming. Plugins for extensibility. Multisite for more complex apps.

I've built a few web apps in house using it and am now making a couple for production use. I might one day find I need to get this made bespoke but I can't see a requirement any day soon. WP does everything I need.

WP is a full blown CMS. It’s very versatile and you can achieve a lot with just the core. Additionally the Gutenberg Editor is the definitive editor for building content-pages.

A few month ago I tried to find a CMS as feature-complete as WP. However, I wasn’t able to find any good alternatives. I also asked on another forum and summed up my favorite WP features:

- Extendable admin area

- Custom post types

- Single- and archive-pages/-routes

- Taxonomy aka categories and tags

- Dynamic meta data (especially with ACF)

- Solid page editor for content

- Action-/Filter-capabilities

- Shortcodes

- Open Source

- Very compatible upgrade philosophy

- Media Library including automatic image scaling

- User Login

- API Support with custom routes

However, you need to know, that WP is higher settled than frameworks like Laravel. Especially data-management gets tedious on bigger instances. Just have a look at the DB schema and you will see, what I mean. On our company we solved this issue by integrating Illuminate/Database btw.

The biggest business chore is usually around user management, roles, permissions—all easily expanded/modified through WP’s extremely well-documented core framework APIs. Custom REST API endpoints are a breeze to implement with or without authentication requirements. If you need external deps, you can manage them like any other modern php project with composer. Deploying is easy with docker and uploads sent off to some S3-like bucket.

One recent project I built had WordPress driving fully custom content for a set of giant LED screens in a corporate HQ lobby that allowed users to build presentations, manage a recurring and one-off scheduling, build, edit, and manage reusable content, view live video feeds of what’s currently on the screens, and request static image and video preview renders from an on-prem media server. Users authenticate via the typical WP dashboard experience, but have rich web app features presented to them for their tasks using the WordPress custom REST API endpoints and the existing WP data model behind the scenes (for the most part). Any business needs they presented were easily absorbed by WordPress through straightforward customizations. IMO, WP is an underrated contender in building CRUD-ware.

By using custom post types, ACF forms and user permissions you can get most stuff done pretty easily.

One of the things I’ve done quite a lot is to use Wordpress multi site for building apps. Then each new client has their own site. If you use mu plugins you can trigger a new site creation to make all the pages you need, and configure / populate them.

It’s a really compelling way of making apps, IMO

Seriously, whenever a customer asks for something relatively simple that I know can be implemented using WP, I usually do it. You already have user management and many other functions built in, and extending it is very easy. It comes very handy when all the customer wants is basically a CRUD connecting to some internal system.

I ask because not long ago what you write was true - but only if you've not seen how 'it can be' in modern stacks. WordPress is (was) great for a time that is (was) gone.

I'm saying was because I have not worked with WP in a while so I can't really judge.

That's why I was asking - for someone who does not have your experience starting WP today, in my opinion, would be a mistake. If you're a "proper" developer, there are much easier, less painful, ways of making money (and making websites) than using WP.

But that said, it's amazing to see what a proper developer with a lot of experience with WP ecosystem (which I'm guessing you are) can churn out in the website game.

I guess I'd also like to chew into what "a website" is. I mean - I still maintain that for basically all "normal" content-rich websites you'd be hard pushed to find a better solution than WordPress. It's not just the rich plugin/theme/development ecosystem* but the fact that editing is so, so simple that makes this the case - so although many modern solutions for delivering websites focus lots on the front end, actually (in my sector / experience - working with very content rich, complex sites), it's "a nice editing experience" that is critical too.

At "transactional" level - ie as your "web thing" is less about pure content and more about "something app-like" then it becomes a different sort of problem. Saving state and logins and so on is absolutely in WP's space in theory, but you definitely run the risk of entering an arena where you're making it do things it really shouldn't be doing, and that can get really gnarly really quickly.

But - having said that (and back to the thread) - I've been pleasantly surprised that using WP as an actual (simple!) web app framework brings lots to the table, and not many people have thought about it in this way.

[* this is also a downside. We do "proper" WordPress development - fully bespoke "from scratch" themes, proper deployments etc - but many, many people just throw up a Divi site with 80 plugins and say they're a WordPress developer...]

The functions / classes you use could be in a plugin for portability, or just on the page or in your functions.php file for ease, whatever you like.

The nice thing about building like this for me is that the journey from nothing to something is short and so much is supported out of the box.

This sounds really tempting :). Thanks!

Seriously, is super productive this way!

Here's a great talk on why he asserts that: https://www.youtube.com/watch?v=J_7_mnFSLDg

Not sure I 100% agree, but I appreciate the fresh look at oil patters.

Each class is applied in pipeline.

And ONLY to that tag. This is key. This leads to know, exactly, what are the effects on each tag, making the UI design very readable.

Then, you can customize it, and have a way to generate a VERY small CSS as result (another big advantage!) because the naming is normalized.

In short: Is the "same" but with more structure, predictability and tooling applied.

The more you need to customize, and the more pain you to "reverse" a CSS made by others, the more this make sense.

Half of TailwindCSS is a _way_ of using styles, but the other half is almost a theme: a set of margins, paddings, text sizes, colours, etc. that work well together.

Everything is now all at the same global namespace and all of the issues that people run into with specificity go away in the process.

It’s not my personal choice on how to solve that problem I think shadowDOM via web components are a much nicer option personally but Tailwind has a lot of very enthusiastic fans who seem to enjoy it.

Is very pragmatic. That means your whole investment in the arcane ways of JS are dust. Not hipster at all.

---

More seriously, Is of little issues here. You setup and it works, so is not something that lead to "generate content" like other setups.

I found only a significant issue (to me) (https://github.com/bigskysoftware/htmx/issues/596) but then I do something that have never done in long time with a JS library: I poke into the source and fix it myself. Far easier than expected! (ie: The code is plain!)

I quite like HTMX myself, although I consider it a tool you use to enhance websites and not something you use to build full blown web apps.

Yes you could inspect the headers and such to determine what type to return, but the core problem remains, that the HTML in those is not reusable whereas as JSON would be.

How much overhead this is for you depends on your design of course, but it does mean some work might potentially be wasted if you go down the full SPA application later and even if not changing layouts and such might be a pain.

if it is greenfield development, it is much better to simply return SSR HTML and avoid that complexity

you can join the discord for more immediate help:

https://htmx.org/discord

Web2py (being phased out by py4web which I haven't tried) made that very easy. If your api is accessed as api/hello.html, it can return HTML. According to the extension, hello.json, hello.csv, hello.txt, hello.pdf, etc. can return the adequate content.

Of course you can always return JSON regardless of the extension, but I found the same endpoints serving different formats very convenient.

https://unpoly.com/

I heard .net Blazor or Razor page is something like that, but as I checked, they don't hide html/css/js.

R Shiny is the closest I get. You don't have to use any html/css/js code to build a web app. Only R language is needed. See a simple example here: https://shiny.rstudio.com/articles/basics.html

I would love to hear about more options here.

> I don't want to handle the back and force between the server and the client

Maybe you could look into something like pouchDB -> couchDB here? Or some other similar solution that handles the networking for you.

The development framework is pretty nice with the way you can share code between native and web, but the end result is just lacking.

Flutter is great for native iOS and Android though.

I don't get your point, Dart is also compiled to JavaScript.

Dart is very easy to learn so whether a lot of people know it or not is not really an issue. Any competent programmer will be able to learn it in a few days.

In my brief experience, learning the language and framework only took a few days and it was much easier than making sense of all the issues with the current frontend web stack. Dart also has JavaScript interop so using libraries written in js is not an issue. [1]

1: https://dart.dev/web/js-interop

Strapi has a great builtin admin panel and cms And gives you built in api to create, read , update and manage access, so its almost like a combination of wordpress + hasura kinda, and it comes in one docker image to host, you can choose between sqlite3 and postgres for the db.

Hugo for building my static web pages and page templates, after that I either render it statically with hugo (and serve it with nginx) or migrate the final file into template folder for my python app

Then for the dynamic content (SSR) , fastapi + jinja2 (for simple pages) or if i need to built a custom api (i try to handle it with strapi and only build my custom api if i need to)

When i want to build a spa , i use lemonade.js for csr, with fastapi for custom apis, and strapi takes care of the simple crud apis.

[strapi](https://strapi.io/)

[hugo](https://gohugo.io/)

[fast-api](https://fastapi.tiangolo.com/)

[lemonade-js](https://lemonadejs.net/)

With Golang, you actually don't need a mega framework to get started, you can use small libraries that will do the job for you without doing any magic behind the scenes. (Like, for sure you can use echo[0] but you would probably be happy with mux[1] and it's middlewares itself). And it's not uncommon in Go codebases to repeat yourself. I'd argue that's a much better paradigm than polluting your codebase with 10k indirect dependencies, the garbage that is the Node.js ecosystem.

[0]: https://echo.labstack.com/ [1]: https://github.com/gorilla/mux

You just need to build it from scratch, document it and ensure it is well tried and tested.

"mega frameworks" are there for a reason. Rails, Django, Laravel, etc have everything they have because almost any web application you build (except if it is just a minimalist micro-service) will need routing, authentication, i18n, ORM or similar, migrations, caching, e2e testing, validation, background job processing (the one that works after a deploy or restart), and a thousand more other things.

Of course you don't need it to "get started", but 1 week after getting started you'll find yourself rebuilding the wheel yourself or tying together 10k dependencies (something doable if you have enough experience and know what to pick and what to not pick, but risky).

> And it's not uncommon in Go codebases to repeat yourself.

The fact that it is not uncommon doesn't make it any better. Rewriting the universe from scratch in every single project is the worst idea ever.

I don't think that because we like a programming language which happens to have no popular web framework we need to negate all the problems of not having one, or say it is in benefit of simplicity. It is not.

I'm very sorry for my rant, but I've already faced too many disasters in work environment were people thought that "just flask" would be enough, and years later we're still fighting the fire and trying to understand why this custom ORM validation integration doesn't work.

I looked at fastapi but when I saw the benchmarks I thought I might as well just use go for the type safety, speed and ease of deployment.

Currently running on Google cloud run. I'll probably switch to AWS though because Google dns doesn't do naked domain redirection, but AWS app run seems half baked...

Does anyone have an opinionated stack they like with Django to get things up and running quickly that could also set me up well for the future for a website and an app(if I want to transition the website to a stable business, etc)?

The things I'd be looking for opinions on:

  - django vs DRF
  - react (or next.js) vs vue vs something else for frontend
  - what other tooling should I use for modern front end development
  - what else is in your stack for CI/CD, rollbacks, db migrations, deployments, etc.
  - do you use any other templates or themes for the frontend to make the UI look good?
  - how you handle security / auth when using a front end framework with django as the backend -- are there any tricks? I've heard JWT can cause headaches 
  - any django packages they recommend using, or other front end packages that are popular

Backend:

  - Huey for background jobs
  - Whitenoise for statics handling
  - Gunicorn for running the application
  - Honcho for process management (also for development, for spawning js and css bundling)
  - Slippers for django template components
  - django-all-auth for signup/password recovery/etc.
  - django-rest-framework if you need an API

  - Unpoly for ajaxy SPAish feel (just the good parts of that feeling)
  - Tailwind for styling
  - esbuild (CLI) for bundling js
  - npm for frontend dependencies
  - postcss (CLI) for building/packaging css

  - Dokku for hobbie or side projects
  - Heroku for getting started with production apps, AppEngine if shit gets real.
  - No need for Websockets, polling is good enough most of the time.
  - Sqlite for side projects
  - PostgresQL for serios stuff
  - Maybe redis

It's not a "vs"; DRF is merely a library for Django thus requires Django. It gives you building blocks to create REST APIs and handles the boring stuff such as validation & serialization, pagination, rate-limiting, authentication, URL routing (in a RESTful manner), etc. If you need more than a few read-only API endpoints I suggest you go with DRF; it takes some time to learn the way it wants to do things but it's worth it in the end.

If all you need is to expose your models as a REST API, DRF will do that with pretty much zero code required, and in most cases that's enough. You can of course decouple your API structure from your models and write custom viewsets, serializers, etc but in this case you lose a lot of the built-in functionality of DRF and have to implement it all manually.

> react (or next.js) vs vue vs something else for frontend

Look at it from the perspective of the problem you're trying to solve as opposed to hype or frontend developers' career prospects.

Good old server-side rendered HTML (with ad-hoc JS or even jQuery where needed) can be good enough. The main advantage is that there's no barrier to entry, you grow as you go. Since you render the pages directly on the server you don't have to worry about providing API endpoints, then parsing that data back in JS, you just directly output it in the HTML.

If you do choose a single-page application approach, I suggest serving the SPA as static files from your Django app so that it is served from the same domain from the browser's point of view. This also allows you to mix and match SPA and server-side-rendered views (you can have your main app an SPA, but the login page - which is just a form and has no need for SPA features - can be server-side rendered for example).

In terms of which frontend framework to choose, I would advise against React as it's just a UI library meaning you need to (poorly) reinvent everything else such as URL routing, REST API clients, etc manually. Every React project I've been involved in had a custom, different, and differently flawed way of doing basic things like hitting a REST API even though it should be a solved problem (there's DRF on the server that can generate RESTful endpoint based on just a model, why is there no "JRF or JavaScript REST Framework" as a client-side equivalent?). I think Ember.js might be worth exploring as it's an MVC framework and should take care of the boring stuff so you can focus on business logic. It looks like it has the concept of "data adapters" so provided your API has a consistent structure it looks like you can have a data adapter that'll automatically map it all back to JS replicas of your model classes and then be able to use it as an ORM of sorts (and have the network communication, serialization, pagination, etc abstracted away by the data adapter).

> what else is in your stack for CI/CD, rollbacks, db migrations, deployments, etc.

Django now has built-in migrations which is pretty good. Deployments and stuff is highly dependent on whatever target you're deploying to. One thing I could suggest is Dokku (https://dokku.com) coupled with a bare-metal server from OVH or Hetzner. It's basically Heroku but orders of magnitude cheaper and more powerful. Depending on your uptime requirements this might be good enough for production, but if not it's at least a good option for a staging/test environment.

Use Celery with RabbitMQ for background & scheduled tasks. Do not use the Redis backend for it even if it's technically supported - it can fail catastrophically with the workers thrashing on the same task over and over again (speaking from previous experience having had to use the fire extinguisher more than once).

Use Sentry (cloud or self-hosted) for exception tracking.

> how you handle security / auth when using a front end framework with django as the backend -- are there any tricks?

Built-in Django auth is good if all you need is username/password auth. The django-registration package provides server-side-rendered views for registration/login. If you need social/federated login I suggest django-allauth which also provides its own views. For API endpoints you'll most likely need to roll your own login endpoint (with serializer) which takes a username/password, calls the auth backend(s) to check those credentials and then returns some kind of reusable token to the user (see below).

> I've heard JWT can cause headaches

JWTs (or other auth token formats) only come in play once you've already authenticated the user somehow (by them providing some secret info - most likely a username and password) and just want to give their client a way to reauthenticate without having to resubmit the same secret info again and again. You still need to actually handle that first part (see above). Once you actually authed the user and want to give them a token, then JWTs or similar come into play.

JWT's only selling point is that they can be validated statelessly without hitting a DB (they carry all the information you need along with a signature). This is mainly a benefit in microservices environments where some services might be completely stateless. In most Django projects you'd be hitting the DB to access the user model anyway (by accessing request.user for example) thus nullifying the sole benefit of JWTs. The rest of JWTs' features are just drawbacks is that it's extremely extensible meaning it's more complex than most projects need, and easy to screw up their validation or issuance, either from your side or even from the JWT library developer's side, thus I don't recommend them.

If you need to provide an API to browser-based clients, serve your frontend from the same domain as the API and use Django's built-in session authentication. On the login API endpoint, initialize the user's session (which will send a cookie back to the browser) and the browser will automatically send the session cookie for subsequent requests without your frontend ever having to do anything - all it needs to do is check for 401s and handle those by displaying the login view. As a bonus, any server-side-rendered views will also work out of the box.

For mobile apps, technically cookie-based sessions can also work, but common practice is to use some kind of bearer token. In this case, DRF has a very simple "Token" auth mechanism that just stores tokens in the DB and is good enough to get started. I suggest however extending that and making those "Device" models instead where you also store some device-specific metadata such as the push notification token, that way if you delete the auth token you implicitly delete the push token too and don't end up sending pushes to devices that are no longer authorized (seen that in production multiple times sadly). This also gives you a way to display to the user all the devices logged into their account and revoke them.

For the logins themselves something I recommend is to actually make your login page always server-side-rendered even if you use a SPA or a mobile app and render that page in a webview/iframe. This will allow you to easily change the login requirements later on (such as responding to brute-force attacks by adding a captcha, etc) without having to update the clients at all. That way you can swiftly react to new & constantly evolving security threats.

I felt the same way so I made my own full-stack "framework" just for me centered around the Svelte component library which I love:

https://github.com/Glench/full-stack-svelte-prototype/

Been using it in production and really really happy with it. Obviously kind of stinks to not have community support but so far it hasn't been a huge issue.

It basically sets up all the crap that I don't want to have to think about while keeping a tight coupling between the front-end and back-end (which is how I develop) — clear separation of code that runs on the server vs the client (with code splitting and CSS generation), rendering pages on server and hydrating client components, communicating between the server and client, re-rendering components when new data arrives. It really fits my needs well.

SvelteKit is very new and I haven't had a chance to use it yet, but my own framework was directly inspired by it. SvelteKit does a lot and looks great — fantastic developer experience, deploys to lots of types of services, SSR/SSG/client-side routing support, etc. And it seems like a great thing for Svelte to have as a default way for developers to start making Svelte components.

Personally, I'm going to wait till SvelteKit a bit more mature before I dig in, but I'm guessing I'll end up rewriting my framework on top of SvelteKit at some point.

Put in on a VM, deploy with Ansible, and call it a day.

This is my boilerplate: https://github.com/ttymck/fastapi-fullstack-boilerplate

The PHP language obviously still has some sharp edges and annoying design choices, but it's seen some huge improvements in the past few years imo. Simply using a framework like Laravel will also save you from some of the more infamous footguns, since there's a lot of secure/sane defaults included.

If you don't mind separating them out (which lets you use different tools for your web tier and your middle tier) I'd probably use a combination of a static page driven by VueJS on the frontend and Golang on the backend for the API.

[1]: https://v3.nuxtjs.org/getting-started/introduction

It tries to automate a lot via the ember-data module (which also makes queries automatically, e.g. left/right joins etc) so it shines with its predefined rules, lots of former rails people seem to contribute to its ecosystem these days.

[1] https://emberjs.com

From my personal perspective I'd say that Ember tries to keep the "fatigue" effect as low as possible when comparing it with e.g. what's going on since the React Hooks "refactors" everywhere.

Very lightweight without much black box magic.

Miguel Grinberg’s tutorials and book are a great and quick crash course.

2. Not sure of it's market share, does it attract many jobs and projects and in which sectors?

Thanks

Could always try out F# if you think the grass is greener out there.

Recently, I tried Next.js and it changed my mind a bit. It prefers convention over configuration, requiring tremendously less configuration compared to other frontend frameworks. It is still a bit complex, but hides the fact nicely under a well-defined abstraction. I might try another project with Next.js in the near future.

Azure functions or Google Firebase for the backend.

With this approach you might not need to pay a cent depending on your usage, plus you can take advantage of the large ecosystem of React components. For a "non-serverless" approach, I would set up a VM on Linode and use docker-compose behind nginx.

Over the last decade, people moved away from thinking of a backend+frontend combo as being the correct abstraction, and more towards thinking of a web client as just another client, akin to a mobile client, which happens to be connected to an API. Because of the very different needs of the two parts, it became much more popular to split them up (either conceptually, or with actual separate codebases being deployed separately).

So nowadays, the standard way of looking at things is to pick some kind of framework for building a backend, e.g. Django, and some kind of front-end framework, e.g. ReactJS, and develop them separately.

I'm not saying this is the only way to do things, but I believe this is correct approach a lot of the time.

Plenty of folks who "haven't used a framework, but heard X is great" are missing out on the real deal. Give it a go, you won't regret it!

Concentrate on delivering value to your target group. I'd recommend not to do SPA frontends just for the sake of it.

A terrific solution for creating most websites with some dynamic components is the Astro framework. Handles partial hydration and allows using Svelte, Vue, React for dynamic components.

I personally am looking into using it (or most probably next.js) with Cloudflare Workers / Durable Objects. Running backend code close to end users is awesome.

For a more conservative approach, if you are looking to rapidly scale up a team and/or desire a huge ecosystem of packages to use, then I'd say modern Ruby on Rails is the way to go for maximum initial velocity. However, in my experience Ruby on Rails requires a lot of experience and discipline to keep things "on the rails" as you grow your application, and that initial velocity can quickly vanish if you are not careful.

I say this as someone with a good amount of experience with both frameworks.

So much can be accomplished with server-side rendering and some jQuery sprinkled on top. (jQuery isn't even strictly necessary with modern vanilla JS, but it's very nice syntactic sugar at the least.)

90% of apps/sites will fit into a basic CRUD/REST document format, which is exactly what server-side HTML served over a RESTful interface was made for. Judicious use of jQuery fills in the front end blanks for all but the most advanced use cases.

The big benefit of this is that you're not locked in to the JS framework-of-the-week once it inevitably becomes either deprecated by its mammoth corporate sponsor who doesn't care about you, or when it's no longer the new hotness and you can't find developers who understand it anymore. jQuery has been around with a largely stable interface for a decade and a half.

The secondary benefit is that you're not including some vast framework with innumerable, inauditable dependencies, requiring special expertise from highly-paid developers, just to put an AJAX button on a webform.

A single codebase is used to create applications for Android, iOS, Mac, Windows, Web, and Linux with Flutter. It lets you build user interfaces, add new features, and fix bugs without sacrificing speed.

However, hire a dedicated developer for your app development projects if you wanna build a website or an app click the link down below.

https://aglowiditsolutions.com/hire-developers/

Would you mind to explain how some of these things are tackled?

But if you're looking to deliver search engines friendly websites i didn't recommend it.

I've met a few devs recently that are starting with that for simple CRUD projects even though they could easily spin something up in Rails.

I looked extensively at various frameworks to see which would make me most productive in starting projects from scratch in my limited development time and this is the one I settled on.

For me, front end is the biggest time sink, so I wanted one that had the best coverage there. Full components suites debugged and working, etc. It really helps that it can target SPA, PWA, mobile (capacitor) as well as SSR.

I enjoy writing typescript so much and from the answers maybe I’ll try next.js

I know rails is pretty impressive in what it can get setup and running super quickly but I have little joy writing Ruby.

[Spring boot](https://spring.io/projects/spring-boot)

I’m also doing some projects in nodejs+Fastify+vuejs

One weird thing: I prefer not using Webpack, full spa frameworks etc if I can help it. Just add vuejs from cdn and use it to add client behavior to plain HTML output by asp.net or nodejs if I can get away with it.

For mobile app dev, Ionic Framework in the angular flavor- last I tried their Vue implementation was lacking.

https://kemalcr.com/

https://luckyframework.org/

Golang backend

Containers

Fargate

RDS

Frameworks automate the boilerplate away so you can focus on the things that deliver business value. Clients ultimately don't care how their problem gets solved, but from your perspective you're better off spending 1 hour implementing the business logic rather than that + an extra 10 hours implementing a URL routing system, database access/management/migrations, etc.