Ask HN: Simplest stack to build web apps in 2021?
189 コメント
Rails. But do Rails 7 (still in alpha but it's on rubygems - it's also super stable, I think the alpha label is simply because DHH hasn't finalized all the changes). Gone is all the webpack JS nonsense (it doesn't have any dependency on Node at all). Hotwire/Turbo/Stimulus is standard. ES Modules/import maps are standard. It's dead simple, almost reminds me of the early days of Rails. But of course it's industrial-strength, better than ever, Ruby is also better than ever.
Edit - to make life extra easy also set it up with Postgres and deploy to Heroku. Everything literally just works.
Edit - to make life extra easy also set it up with Postgres and deploy to Heroku. Everything literally just works.
This is debatable and I'd say absolutely not :)
For OP's criteria it works. It's relatively simple (by today's standards), it's full-stack, has everything out-of-the-box. Getting started is as easy as it gets (in 2021).
What would you choose?
What would you choose?
Elixir Phoenix. It’s what rails copied for the Hotwire stuff. With distillery you can compile all of it, css, js, images, html, down to one tarball that you unpack and run as a service placed behind a forward proxy for complex setups or standalone if desired. Plus it’ll blow the doors off a Rails app performance wise, measured in micro not milli seconds, and will deploy on a fraction of the resources. Plus the community is filled with ex rails devs who left ruby for elixir so it has a very familiar feel if you come from Rails.
> It’s what rails copied for the Hotwire stuff
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.
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.
When I say copy I don't mean implementation but inspiration. They may not have copied it exactly in implementation, it is FP vs OO, but stimulus.js was a direct response to LiveView. I don't think there is anything wrong with that however I welcome any advancement that requires less JS.
If we're talking about inspiration, then maybe it goes the opposite way? Given Turbolinks existed many years before even elixir or phoenix existed. In fact the creator of elixir was a very prominent rails dev.
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.
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.
They're his words not mine. Go fight with him if you think otherwise https://www.youtube.com/watch?v=Of1phFsC4ZI&t=3290s
I'd argue against that. Recently, I tried making a few test apps with Phoenix and Rails to get my feet wet with something different (I write Go, Java and PHP in my day job), and with Phoenix I ran into a few issues getting the environment set up, the guide doesn't seem to be as coherent as the Rails dev guide, and there is no matching the resources available for Rails compared to Phoenix.
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.
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.
Not a knock on you but maybe you're too new to Rails too.
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.
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.
You'd argue against using a framework for a project because you encountered a few issues (which ones?) setting up the environment, and recommend another one because you love coding in ruby?
Do you realize how biased you sound to be?
Do you realize how biased you sound to be?
Everytime this questions comes up (and it comes up a lot especially on HN), the answer is almost always: start with the Language that you already know and then reverse engineer. For example:
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.
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.
As an aside (and as a Python/Flask user on several past projects) I'd also recommend taking a look at FastApi. (https://fastapi.tiangolo.com/)
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'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 like that following the idiomatic pydantic/data class style in the fastapi docs really forces you down the OOP rabbit hole and puts some guardrails around your architecture (unlike flask, where you’re free to shoot yourself in the foot however you want). What I don’t like is that fastapi gives the appearance of being batteries included, but the docs on the batteries tend to just point to example projects/templates that a beginner will look at and think omgwtf is all this shit (e.g. https://github.com/tiangolo/full-stack-fastapi-postgresql)
Something like Next.js for JavaScript would be better. Express is too bare-bones for OP's criteria. It's bring your own batteries. Just trying to choose from all the batteries available is a full-time job.
I'd go one more, and say specifically Laravel Livewire. It's a pleasure to use and gives you the flexibility of having a reactive frontend.
I do recommend dipping in Laravel first, before Livewire.
I do recommend dipping in Laravel first, before Livewire.
Probably use Nest over Express if you want something complete like Rails. Express is pretty barebones, its not much more than a wrapper for Node’s http module.
Nest gives you a structured project with strong conventions. On top of that, their document provides plenty of recipes to get common tasks done quickly (authentication/authorisation, persistence, queues, etc). Very solid framework.
Node/Express != Rails, one is a low-level gives you almost nothing at all. The other is a high-level CRUD based framework.
This is the correct answer.
With the addition of:
C# => .Net Core
With the addition of:
C# => .Net Core
More specifically,
C# => Blazor using .NET 6.
Their latest web framework running on the latest long-term support version of .NET
Their latest web framework running on the latest long-term support version of .NET
Anything wrong with Spring? It seems somewhat intuitive for me for some reason. But I have no experience with the others
In my experience, spring has been intuitive until you need anything slightly custom, or until layers deep configuration / reflection magic bites you. Other thing I didn't like about spring was that documentation was pretty sparse and didn't explain concepts well, it's either some hyper-specific tutorials or reference docs. (There are some good blog posts though, but I couldn't build a comprehensive mental model just following the tutorials). It's still what I reach for when I need to spin up a CRUD API quickly.
Rooting for quarkus to become more mature though. (Recently tried based on someone's recommendation on HN).
Rooting for quarkus to become more mature though. (Recently tried based on someone's recommendation on HN).
This is the correct answer.
I haven’t used it myself, but Next.js is a popular choice if you want to use React. It’s primarily a front end framework, but can do all of the things you mentioned in your post. But probably not the best if you’re looking for something to build a traditional web app with a database. I think there are comparable frameworks for Svelte if you’d rather use that.
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.
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.
I second NextJS, you get React, SSR, serverless endpoints and a rich ecosystem of integrations. It works great with things like Friebase, Supabase or any regular DB / Redis.
I use NextJS at work and it fits everything the OP wants, I would definitely recommend it especially if you're comfortable with JS or TypeScript already.
Thanks! NextJS is mentioned many times in this thread. I'll definitely check it out.
Bracing myself for the downvotes but meh, let's live life dangerously.
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.
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.
+1 on WordPress
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.
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.
I haven’t used it in years but concrete5 was awesome for this.
Yeah, I keep coming back to Concrete5 (now Concrete CMS). We don't often do CMS-based projects but when we do I test out all the big names and Concrete wins out every time. It had a block-based page editor years before Wordpress introduced Gutenberg and theming has always been pretty straightforward.
Can you give some examples of great web apps built on Wordpress? It’s a full-featured CMS as another commenter details, but to me a content website is not really what I think of when I hear “web app.”
Depends on what you’re doing with it. WordPress core is built to be highly customizable. I’ve built multiple projects that staple JS/React apps on top of the core WordPress Dashboard experience. It typically meant disabling the default post/page content editing and using WordPress in a headless fashion.
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.
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.
Yeh, my method is a bit different but only because I’m less knowledgeable about js / headless approaches. I tend to make the front end (what in a traditional site would be just “the website”) into the admin dashboard. So - a normal user never gets to see wp-admin at all.
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
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
Woocommerce. The most popular e-commerce platform on Earth.
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.
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 agree, and I think that other commenter misunderstood the context of the OP’s question. I mean, they were right, Wordpress is a great cms for all those reasons, but I’ve become convinced that it is a viable option for app development, too. I’m certainly biased, and definitely see nails because I’ve got a hammer but even with this in mind I’ve been excited by the potential.
Agreed. You can build a lot of scratch, sure. But WP + something like Avada or another templatey thing, and you can cover most brochure ware sites super easily.
I just wonder: have you ever developed anything in a proper framework like laravel or Symfony?
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.
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.
I’ve played with laravel, and yeh, I can see it’s really compelling. But my personal use case is that we’re a tiny WP agency, so that’s where all our skills are. I’ve got a head full of ideas for apps, and the least friction to get to prototype (and production!) is using what we know. I’ve been really surprised at how much WP gives us out of the box.
Yeah, I get that. "Use what you know" does beat most things.
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.
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.
Yeh, I agree. There are some nasty little WP pitfalls which can totally bite you on the ass if you're not used to it as an environment.
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...]
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...]
Yes it is pleasantly surprising what you can create purely with themes and plugins. No code. Also surprising how much power you get from one of those cheap shared hosts like Hostgator.
Thanks. How easy is it to add a custom page that retrieves data via REST? Does it have to be written in PHP and as a Wordpress plugin?
If I've understood correctly, you'd make a new page template and make your new page use that. Then you can code this page up however you like. PHP, js, etc.
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.
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.
> 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!
This sounds really tempting :). Thanks!
http://htmx.org + whatever backend you like best
And pair with https://tailwindcss.com and you are golden.
Seriously, is super productive this way!
Seriously, is super productive this way!
This is really interesting. Assuming I'm willing to trust the author's claim that semantic class names are the reason CSS is hard to maintain, what's the advantage of `<img class="w-32 h-32">` over `<img style="width: 32px; height: 32px;">`?
I'm willing to trust the author's claim that semantic class names are the reason CSS is hard to maintain
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.
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.
Think is like the most "functional" way to do CSS, in contrast with the "OO" way (like bootstrap).
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.
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.
Normally you wouldn't use `w-32` but rather something like `w-8`, that translates to `width: 2rem;`. Same with colors, you would use `bg-red-400`, that happens to translate to `rgba(248, 113, 113)`.
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.
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.
I like to think of Tailwind as CSS without the C.
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.
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.
Less typing, less bandwidth (ab)used.
I'd think the former would typically (depending on how many times the class is re-used) use more bandwidth, if anything, since it still requires the framework to define the `w-32 h-32` class attributes elsewhere using the more verbose identifiers. Plus the overhead for an additional request if that class definition happens in an external style sheet.
Media Queries
Wait, this looks and feels like a very pragmatic way of making modern websites. How has this not become more popular? What are its cons?
> What are its cons?
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!)
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!)
You return HTML from your "api" endpoint's is the biggest opposition I have found. Can mean additional work when you do want to switch to JSON, as the endpoints end up not being very reusable.
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.
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.
You don't return HTML from API endpoints, you return it from your UI endpoints. You could reuse those for JSON with content negotiation, or have a frontend server+backend server setup where the backend server is also a public API, or some other solution.
Semantics over the name aside, you end up returning small chunks of HTML from newly defined routes that are only useful for your HTMX frontend, hence my usage of API as the interface really only makes sense to the machine and not the user without the rest of the page content.
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.
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.
essay related: https://htmx.org/essays/splitting-your-apis/
Thanks for HTMX and your essays. Today I was reading HTMX documentation on what to do when we design API-first for a particular project but don't want any of the frontend magic aka SPA. I found immediately that I need to use both json_enc and client-side-templates extensions. Hope I am on the right path.
hi animesh, that would only be the case if you are trying to retrofit htmx on top of an existing JSON API
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
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
That makes sense. I didn't think about it that way, but traditional MVC views would do just as well I guess for greenfield work.
> Semantics over the name aside, you end up returning small chunks of HTML from newly defined routes that are only useful for your HTMX frontend, hence my usage of API as the interface really only makes sense to the machine and not the user without the rest of the page content.
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.
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.
I'm a big fan of Unpoly. Pretty similar to Htmx. Unpoly just fits my brain better.
https://unpoly.com/
https://unpoly.com/
I have being searching for web frameworks too recently. I want the development of web app to be close to desktop app as possible. I want web UI to be treated as desktop controls, and I don't want to deal with any html/css/js at all. I don't want to handle the back and force between the server and the client, and the framework should hide all the complexity for me. Because I want to focus on the business logic.
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 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.
Sounds like you might want to just build a desktop app?
Kind of, but need to access from other computers with browser. No need to handle high traffic.
OK. I don't know how you'll avoid the html/css/js part entirely, maybe look into a fairly complete UI framework?
> 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.
> 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.
Interesting that Svelte hasn't come up yet. Personally I find it to be the only sane web framework out there. Easy to learn, little boilerplate code, very well structured, very fast. Give it a try!
Frontend is what will get you. The kids have decided everything now needs to be compiled and transpiled so you won't be able to avoid the hassle of frontend development. If you want to avoid all of that then Flutter/Dart might be a good option: https://dart.dev/web. But this is just me giving random advice. I tried Dart for a while and it's a nice language, no worse than all the other contenders when it comes to web development.
Flutter is cool but not ready for the web, much as Google wants to label their web support as "stable"
What's missing?
In my experience: performance. Even Google's Flutter apps lag horribly in Firefox and feel slow and wonky in Chromium.
The development framework is pretty nice with the way you can share code between native and web, but the end result is just lacking.
The development framework is pretty nice with the way you can share code between native and web, but the end result is just lacking.
Slow scrolling, is a major issue. Hard to solve.
Flutter is great for native iOS and Android though.
Flutter is great for native iOS and Android though.
The performance is terrible.
I looked at the flutter gallery and it looks like they just compile everything to js files and paint the widgets on a canvas element. Would be interesting to know if they're investing any effort in different backends like WASM. Would probably solve their performance problems. Canvas is obviously a sensible option for rendering but it looks like it might be another reason why their performance isn't great.
They are actually pretty active on the WASM GC group because yeah I think that is the exact plan in the future to ship Flutter web apps as WASM rather than JS.
That's good news. Looking forward to the performance improvements.
> If you want to avoid all of that then Flutter/Dart might be a good option: https://dart.dev/web.
I don't get your point, Dart is also compiled to JavaScript.
I don't get your point, Dart is also compiled to JavaScript.
It reduces the effort of learning different frameworks for the frontend and the backend. You use one language that includes simple interoperatbility between the frontend and the backend. It will still obviously need to be compiled into a format that browsers can work with but if you're gonna use a framework anyway then Dart/Flutter is a reasonable choice (modulo performance issues as mentioned by others in this thread).
But you could make the exact same argument for plain JavaScript? With the difference that JavaScript is way bigger in the web space.
The point is no one uses plain javascript anymore so if you're going to use some domain specific language with its own build pipeline to generate compiled assets for the browser then Dart/Flutter is no worse than any other javascript framework.
It is worse, because very few people use it, and the performance on the frontend is terrible.
My point is the frontend web stack is already very complicated for no good reason so using Flutter/Dart instead of dealing with webpack or whatever the latest build tool is for frontend web projects isn't that big of a difference.
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.
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.
And my point is that since you're going to learn a JS-like with build tools, you would better be served by JS or TS instead of Dart, since Dart isn't that popular, the frontend experience is terrible and there's not much choice in terms of backend and libraries.
I've tried js, ts, and dart and dart is a much more pleasant language with simpler tooling than the current js/ts web stack. We can continue going back and forth on this but I don't think we're getting anywhere. My suggestion was to someone that was looking to avoid the main hassles of web development and I suggested Flutter/Dart to simplify the toolchain and not worry about having to pick and choose frontend frameworks and build tools because all of that is baked into Flutter/Dart already.
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
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
Yup, everything is a constanatly changing fix on top of broken JS and a broken architecture.
If you know c#, then .net6 released recently, which is a LTS release and has really cool features like hot reload, minimal API etc. It also has sufficient performance improvements as compared to its predecessors. As a language, personally I find C# to be much easier and better to use as compared to java/python, especially for web dev and C# 10 has some really good language improvements like record types etc. I have used it mostly in windows env, so, not sure about it's performance on Linux, but considering its cross platform, I'm guessing it would be good.
Honestly, I've yet to find a backend that is as productive and performant as C# + Entity Framework out of the box. I've tried a wide array of other products, but somehow for ease of use this really sticks out. Of course scalability maybe be in an issue in the long run with EF, but I don't know if simplest and scalability really go hand in hand.
Strapi + Hugo + Python
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/)
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/)
+1 for Jinja2
For backend I'd say -> Golang, PostgreSQL, Redis. I've just worked with Vue.js but I've seen some of the React codebases and don't really appreciate that complexity. Vue does a far better job and simplifying things.
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
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
> With Golang, you actually don't need a mega framework to get started
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.
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.
After many years of trying all kinds of things, this is exactly where I landed. Go, Psql, Redis. Unless your data or workload is highly specific and abnormal, it really covers about anything you'd want to accomplish.
Same. Vue/capacitor in the front, go on the back with postgres and sqlite for tests. Also using laravel for the web site.
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...
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...
I was starting to look at the same thing. I used to do a bit of Django development (5ish years ago) and things seemed to have changed a good amount with the tooling / frontend.
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:
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
I do!
Backend:
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> django vs DRF
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.
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.
> They all look complicated and require lots of configs and plumbing to get started.
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.
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.
Thanks. What do you think about SvelteKit? I looked at Svelte, liked it a bit and went on to explore SvelteKit to see how the API/SSR/route was handled but I couldn't get through their docs. Maybe I should find a better tutorial to evaluate it.
Ooh, if you liked what you saw of Svelte, you might like these videos that do a great job explaining some of its benefits: https://www.youtube.com/watch?v=AdNJ3fydeao and https://www.youtube.com/watch?v=BzX4aTRPzno
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.
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.
I've just finished watching the 1st video, it's awesome. Thanks for sharing!
If your app is stateless; FastAPI. Otherwise Django all the way (with some cloud managed SQL, if you are not into hosting it yourself). Remember backups.
Put in on a VM, deploy with Ansible, and call it a day.
Put in on a VM, deploy with Ansible, and call it a day.
Even for stateful apps, I reach for FastAPI now. It's just so expressive. For the "full stack bits" there are plenty of libraries, it's just a little work to stitch them together.
This is my boilerplate: https://github.com/ttymck/fastapi-fullstack-boilerplate
This is my boilerplate: https://github.com/ttymck/fastapi-fullstack-boilerplate
I use Laravel both at my day job and for a few side projects, and it's a real blast to work with. It's very similar to Rails in that you can auto-generate most boilerplate for models/views/controllers, and then paint-by-numbers from there. The HTML templating is nice enough for static sites, but it has great Vue integration if you're making something a little more interactive. If you also ever need to venture outside the super feature-packed framework, the PHP ecosystem is absolutely enormous so it's rare you'll ever be wanting for packages.
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.
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 want an all-in-one, which it sounds like you do, I'd look into something like Nuxt and VueJS 3[1]
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
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
Thanks. I do prefer an all-in-one option so this looks promising. The website says v3 is beta and not ready for "production use". Have you encountered major issues with it?
If you want a batteries included framework, maybe take a look at ember? [1]
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
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
I would advise against ember only because of the very steep learning curve. I wpuod even say that it's a learning wall.
Ember uses most of the classical MVC concepts, so I'd argue that the learning curve is redundant when you come from an MVC world outside web development.
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.
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.
Flask.
Very lightweight without much black box magic.
Miguel Grinberg’s tutorials and book are a great and quick crash course.
Very lightweight without much black box magic.
Miguel Grinberg’s tutorials and book are a great and quick crash course.
Flask Mega-Tutorial: https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...
I'd like to know too, but I think I'm going to be disappointed. Currently using dot net core web api with angular or react. I was thinking about trying to pick up django again, is that still likely to be worthwhile? Have done java spring previously. Node/ express didn't seem to have enough batteries included.
Can you define 'worthwhile'?
1. Does it offer significant technical advantages e.g. easier to learn/deploy/ more powerful/ quicker?
2. Not sure of it's market share, does it attract many jobs and projects and in which sectors?
Thanks
2. Not sure of it's market share, does it attract many jobs and projects and in which sectors?
Thanks
If you already are experienced with Node & Java, I doubt it is worthwhile for you. Just keep gaining experience there, I don't see Django overtaking any market anytime soon. It's a niche compared to others, but there is a lot of work in building microservices and API's. As a junior & freelancer, there is no shortage of work for me. Sectors range from API's to pure backend service & DevOps automation. Purely backend jobs.
With .NET and React in your toolbelt, you already got easy to deploy, powerful and job market. What else do you want? :P
Could always try out F# if you think the grass is greener out there.
Could always try out F# if you think the grass is greener out there.
I was in the same boat as you. I'm mostly a backend person and I had avoided frontend frameworks and used vanilla JavaScript directly because I did't like the complexity of modern JavaScript frameworks.
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.
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.
Thanks. Seems like many people recommend Next.js. I'll definitely take a look.
I'd absolutely go for next.js and deploy with Vercel. It's got a huge community, lots of starter templates and enterprisey add-ons. There's stuff to learn but react is easily the most popular frontend framework right now and has the most energy.
Next.js or a create-react-app project for the frontend, which you can host for free on Azure Static Web Apps.
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.
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.
I would also consider using Cloudflare Workers for the backend and for the static site hosting if it is a simple enough app.
Next.js. It takes care of most of the config for you, and integrates client/server/static/API beautifully under a single roof. Also gives you nice bells and whistles like hot reloading out of the box
I'm no longer mostly doing web dev, so take with a grain of salt. But I believe you are looking for something that has been considered "not a best practice" for almost ten years now, which is why you are having trouble finding it.
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.
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.
I'd be tempted to use Blazor if I was starting a new greenfield project and somebody else was paying.
Check out remix.run - it just opened sourced today. Created by Michael & Ryan & Kent C Dodds from React Router.
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!
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!
Thanks. It's funny I saw it on HN a bit after my post. Will check it out.
If you need full-stack and want to build quick take a look at https://www.meteor.com/.
SvelteKit (JS/TS),
Flutter & Dart (one language for everything / every target system) (Dart),
Django w/ Django Rest Framework (Python)
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.
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 was using Django Rest Framework for many years (and still using) but I can't recommend it to anybody. I would recommend FastAPI which is more straightforward and has modern features and not abandoned (like DRF is).
I quite liked the recent Remix v1 demo (https://www.youtube.com/watch?v=wsJaUjd1rUo). The way you can get data in and out of react with their loader is great.
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.
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.
If you really want a clean slate, I think Elixir & Phoenix is the most promising stack available right now and is worth investing in. Channels, PubSub, Live View, and BEAM clustering can really simplify building interactive web applications. In my experience it has made full-stack engineering much more approachable and manageable for small development teams. The BEAM itself scales well should the need arise and Phoenix does not make many assumptions about what kind of application you are building, so you won't find yourself fighting your framework if your direction changes.
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.
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.
NextJS has everything you’re asking for, including handling the API. Super simple to get started with straight out of the box and the docs are great.
PHP and jquery.
I think many people will think this is a joke answer, but IMHO "server-side language of choice + jQuery" is actually the best answer.
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.
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.
Nothing against PHP as a language but much against bare PHP as a framework. I really suggest you look into Laravel (or any other PHP MVC framework) instead.
I’ve got nothing against PHP and jquery, but those are not even a full stack, let alone a batteries-included framework.
Blazor with .NET6 is looking pretty fantastic
Meteor, Typescript template, with React frontend, MongoDB for the Meteor built-in accounts and authentication, and Postgresql for data management. Can also easily use Express to expose some REST endpoints. Plus there is a server side rendering package that makes it pretty easy.
Thanks. I looked at Meteor a long time ago, didn't get a chance to use it and didn't know they're still in existence. Will check it out.
I suggest flutter, opting flutter, a revolutionary web stack for the cross-platform development industry. Its major components include Dart, the Flutter engine, Foundation Library, and design-specific widgets.
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/
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/
Do you have extensive experience with anything else than flutter? I have a feeling only inexperienced people are recommending flutter while ignoring bunch of things such as: hire-ability, maturity, ecosystem, system integrations, seo, accessibility, learning curve, ...
Would you mind to explain how some of these things are tackled?
Would you mind to explain how some of these things are tackled?
Flutter is amazing even for web.
But if you're looking to deliver search engines friendly websites i didn't recommend it.
But if you're looking to deliver search engines friendly websites i didn't recommend it.
Counterpoint to the suggestions above, why not try out a no/low code framework like Bubble.io?
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'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 tried it. It's nice but it feels a bit slower. The usual problem with these things is we're so used to doing everything with plaintext that the mouse based approach feels unwieldy.
Interesting. I didn't even think of this option. Let's say the app will eventually grow beyond simple CRUD, do you think something like Bubble.io can still be easy to build on? Or at that point, one would have to migrate to a more bare metal framework?
Perhaps, although by then you will have likely proven traction and can invest confidently in the future stack knowing your needs. Until then getting up and running quickly could be the way to go.
Quasar has all of that. Its strength is the front end. The SSR feature gives you have a place where you can plug in an Express based REST API. There is a large enough community around it to help ensure you don't get stuck.
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 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’m glad you asked this question. I have similar wonderings.
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.
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.
I would say Spring Boot. A full stack system with server side rendering and easy production deployment, at least IMO. It is a framework that support all you mentioned out of the box and them some. Start with (https://start.spring.io/) and look up an official documentation for your use case to get a feel of development process.
[Spring boot](https://spring.io/projects/spring-boot)
[Spring boot](https://spring.io/projects/spring-boot)
Next.js, React is the de-facto fronted way of doing things. Why not super charge it with SSG, SSR and other bells and whistles and the ability to deploy easily to vercel/netlify.
Just this week I was watching a video of the head of Vercel devrel trying to explain their latest approach to server side to an actual server guy (Kelsey Hightower) and honestly my main takeaway was that they hadn’t really even understood what trade offs they were making in the process. It kind of scared me off ever even considering this “front end for the backend” trend that seems to be picking up.
100% Laravel. A joy to work with. You get so much out of the box.
Phoenix+Liveview or Laravel+Livewire or Rails+Hotwire/Turbo
PETAL (Phoenix, Elixir, Tailwind, Alpine.js, LiveView)
I do ASP.NET core + vuejs for work and like it well enough.
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.
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.
Have you ever tried Jinja templates? Kit55 (https://stack55.com) provides a super simple tech stack with barely any config if all you need are static pages + a simple JSON based CMS backend. Disclosure - I work for Stack55.
Dotnet 5.0, kestrel server, MVC sample project. You can use dotnet and deploy to linux. Pretty simple.
Try IMBA https://imba.io/
For everyone opposing Django to FastAPI, please take a look to the excellent Django Ninja: https://django-ninja.rest-framework.com/
[deleted]
Crystal programming language with Kemal or Lucky
https://kemalcr.com/
https://luckyframework.org/
https://kemalcr.com/
https://luckyframework.org/
Nuxt (Vue.js) and any cheatsheet and you should be good to go in less than 3 days.
Blazor alone could account for 99% of your codebase exclusively in C# with little to no js on your way. (ex. https://collanon.app)
“You have provoked a gang war”
Hasura, nextjs and auth0
Nextjs with a Strapi backend...simple and performant.
Redwoodjs is pretty cool and friendly
I use Rust with Rocket and Tera.
Vue.js
Golang backend
Containers
Fargate
RDS
Golang backend
Containers
Fargate
RDS
htmx + Clojure backend.
html, css, javascript, nodejs, filesystem
Smells like market landscape fishing but ok. Vanilla JS + vanilla PHP....frameworks are for resumes, not for sense or pleasure...
> frameworks are for resumes, not for sense or pleasure
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.
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.
No fishing. Just a dev looking for HN recommendation to avoid missing out on a good framework fitting my needs. Thanks for your idea. Going vanilla JS/PHP to build modern web apps can get complicated real quick I think. I'd prefer a framework to take care of all the plumbings (route, state, binding, SSR etc.) so that I just throw in the app UI & logic.
It's been a while since I can develop from a clean slate and I was hoping web dev in 2021 would be much simpler than what I am used to. However, I spent this entire morning looking at modern frameworks (not going to name them to avoid turning this into a different kind of discussion) and I'm kinda disappointed. They all look complicated and require lots of configs and plumbing to get started.
Any stack/framework that you find simple and joyful to develop with?